- 29 Nov, 2021 18 commits
-
-
Mauro Carvalho Chehab authored
This isn't used anywhere. So, drop it. Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
-
Mauro Carvalho Chehab authored
When the version warning is given, multiple dev_warn() are called. Consolidate the ones that could be merged altogether. Suggested-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Clang doesn't like "%hu" on macros: drivers/media/radio/si470x/radio-si470x-i2c.c:414:4: error: format specifies type 'unsigned short' but the argument has type 'int' [-Werror,-Wformat] drivers/media/radio/si470x/radio-si470x-i2c.c:417:4: error: format specifies type 'unsigned short' but the argument has type 'int' [-Werror,-Wformat] Besides that, changeset cbacb5ab ("docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi]") dropped recomendation of using %h. So, just replace them with "%u". Reviewed-by:
-
Mauro Carvalho Chehab authored
There are several unused helper macros there, meant to parse some fields. As those actually help to document the hardware, the better is to keep them. However, it generates clang warnings with W=1, causing build to break with CONFIG_WERROR. So, add __always_unused to fix such warnings. Acked-by:
Ismael Luceno <ismael@iodev.co.uk> Signed-off-by:
-
Mauro Carvalho Chehab authored
If an error occurs while setting the registers at set_frontend, it is silently ignored. Yet, the variable status is updated. Change the logic to return an error if it fails to write values to the registers. Signed-off-by: -
Mauro Carvalho Chehab authored
This value is never used at the code. So, drop it. Solves a W=1 clang warning. Reviewed-by:
-
Mauro Carvalho Chehab authored
This var is set, but never used. So, drop it. Signed-off-by: -
Mauro Carvalho Chehab authored
The offset is not needed, and it is never used, as the pointer itself is already incremented. So, drop it, in order to solve a W=1 clang warning. Reviewed-by:
-
Mauro Carvalho Chehab authored
vpif_get_default_field() seems to be some left-over from a past code that sets the field order. Reviewed-by:
Lad Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
This is just an alias for container_of() and it is used only on a commented code. The commented code actually is an issue that require fixes, so, move the container_of() call to the commented code, and drop the unused function. This way, a fix for the function could be added later without needing to re-add to_state() function. This fixes a clang W=1 warning. Reviewed-by:
-
Mauro Carvalho Chehab authored
Those functions just call a V4L2 core macro, and aren't used anywhere. Get rid of them, in order to avoid clang warnings with W=1. Reviewed-by:
-
Mauro Carvalho Chehab authored
Clang with W=1 produces the following warnings: drivers/media/platform/omap3isp/isph3a_af.c:173:6: error: result of comparison of constant 256 with expression of type '__u8' (aka 'unsigned char') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (IS_OUT_OF_BOUNDS(paxel_cfg->height, OMAP3ISP_AF_PAXEL_HEIGHT_MIN, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/media/platform/omap3isp/isph3a_af.c:24:33: note: expanded from macro 'IS_OUT_OF_BOUNDS' (((value) < (min)) || ((value) > (max))) ~~~~~~~ ^ ~~~~~ drivers/media/platform/omap3isp/isph3a_af.c:179:6: error: result of comparison of constant 256 with expression of type '__u8' (aka 'unsigned char') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (IS_OUT_OF_BOUNDS(paxel_cfg->width, OMAP3ISP_AF_PAXEL_WIDTH_MIN, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/media/platform/omap3isp/isph3a_af.c:24:33: note: expanded from macro 'IS_OUT_OF_BOUNDS' (((value) < (min)) || ((value) > (max))) ~~~~~~~ ^ ~~~~~ 2 errors generated. Use a typecast to avoid such warnings. Reviewed-by:Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
This function is only used for debugging purposes. When DEBUG is disabled, it becomes unused, causing a clang warning with W=1. Reviewed-by:
-
Mauro Carvalho Chehab authored
This function is an alias for container_of() that it is currently not used, causing clang warnings. So, drop it. Signed-off-by: -
Mauro Carvalho Chehab authored
Solve some clang warnings about unused functions by dropping some time-conversion inline funcs that aren't used anywhere. Signed-off-by: -
Mauro Carvalho Chehab authored
The typecasts at the dvb-core generate clang warnings when W=1 is enabled. The warns are harmless, but they cause the build to break with CONFIG_WERROR, so do the cast on a way that it won't produce warnings anymore. Signed-off-by: -
Mauro Carvalho Chehab authored
The gobj_type() function translates the media object type into a name, being useful for debugging purposes. It is currently not used. So, drop it. Signed-off-by: -
Mauro Carvalho Chehab authored
The stb6100_normalise_regs() function is not used with current boards, but the driver says that some devices could need it. Ok, we could simply drop it, but as there's a macro to mark unused functions, use it. This should shut up a clang warning. Signed-off-by:
-
- 22 Nov, 2021 15 commits
-
-
Mauro Carvalho Chehab authored
The macro p_to_snd_cx18_card() is just a variant for container_of(), not actually used inside the code. So, drop it. This address a clang warning. Signed-off-by: -
Mauro Carvalho Chehab authored
The macro p_to_snd_ivtv_card() is just a variant for container_of(), not actually used inside the code. So, drop it. This address a clang warning. Signed-off-by: -
Mauro Carvalho Chehab authored
This function is defined twice, one at cx25821-i2c and the other inside cx25821-core. It turns that only the first is actually used inside the code. This causes a clang warning. Signed-off-by: -
Andrzej Pietrasiewicz authored
The G2 decoder block produces NV12 4x4 tiled format (NV12_4L4). Enable the G2 post-processor block, in order to produce regular NV12. The logic in hantro_postproc.c is leveraged to take care of allocating the extra buffers and configure the post-processor, which is significantly simpler than the one on the G1. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Andrzej Pietrasiewicz authored
The struct is not used outside this file, so it can be static. Signed-off-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by:
-
Andrzej Pietrasiewicz authored
VeriSilicon Hantro G2 core supports VP9 codec. [hverkuil: add kerneldoc line for HANTRO_MODE_VP9_DEC] Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by:
-
Andrzej Pietrasiewicz authored
VeriSilicon Hantro G2 core supports other codecs besides hevc. Factor out some common code in preparation for vp9 support. Signed-off-by:
-
Andrzej Pietrasiewicz authored
Add more consistency in the way registers are named. Signed-off-by:
-
Andrzej Pietrasiewicz authored
The Rockchip VDEC supports VP9 profile 0 up to 4096x2304@30fps. Add a backend for this new format. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
Adrian Ratiu <adrian.ratiu@collabora.com> Co-developed-by:
-
Andrzej Pietrasiewicz authored
Provide code common to vp9 drivers in one central location. Signed-off-by:
-
Andrzej Pietrasiewicz authored
Add the VP9 stateless decoder controls plus the documentation that goes with it. Signed-off-by:
Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by:
-
Ezequiel Garcia authored
The G2 core decoder engine produces NV12_4L4 format, which is a simple NV12 4x4 tiled format. The driver currently hides this format by always enabling the post-processor engine, and therefore offering NV12 directly. This is done without using the logic in hantro_postproc.c and therefore makes it difficult to add VP9 cleanly. Since fixing this is not easy, add a small quirk to force NV12 if HEVC was configured, but otherwise declare NV12_4L4 as the pixel format in imx8mq_vpu_g2_variant.dec_fmts. This will be used by the VP9 decoder which will be added soon. Signed-off-by:
-
Ezequiel Garcia authored
Add a 'postprocessed' boolean property to struct hantro_fmt to signal that a format is produced by the post-processor. This will allow to introduce the G2 post-processor in a simple way. Signed-off-by:
-
Ezequiel Garcia authored
Turns out the post-processor block on the G2 core is substantially different from the one on the G1 core. Introduce hantro_postproc_ops with .enable and .disable methods, which will allow to support the G2 post-processor cleanly. Signed-off-by:
-
Ezequiel Garcia authored
When the post-processor hardware block is enabled, the driver allocates an internal queue of buffers for the decoder enginer, and uses the vb2 queue for the post-processor engine. For instance, on a G1 core, the decoder engine produces NV12 buffers and the post-processor engine can produce YUY2 buffers. The decoder engine expects motion vectors to be appended to the NV12 buffers, but this is only required for CODECs that need motion vectors, such as H.264. Fix the post-processor logic accordingly. Signed-off-by:
-
- 19 Nov, 2021 7 commits
-
-
Sudip Mukherjee authored
The pointer 'mem' was initialized to 'fw->data' but immediately after that it was assigned 'fw->data + 10'. Lets remove the extra assignement and initialize the pointer to the address its going to use. Link: https://lore.kernel.org/linux-media/20210416235336.1552102-1-sudipm.mukherjee@gmail.com Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by:
-
Lukas Middendorf authored
At connection time (or boot) in si2168_probe(), the firmware is not loaded to the device and the device is not fully activated. It is not useful or sensible to do this full initialization on resume in case it has not been previously initialized and is expected to be in this initialized state. Calling si2168_init() and therefore reading the firmware file for the first time during resume leads to problems and should be avoided. It is however safe to read the firmware file once it has already been read outside of a suspend/resume situation. Add a staus flag 'initialized' to store whether si2168_init() has successfully been called. If initialization fails (e.g. due to missing firmware file), the flag is not set. Register a separate si2168_resume callback which only calls si2168_init() once the 'initialized' flag has been set and it is safe to load the firmware at resume. The first call to si2168_init() will now always happen when the device is actually used for the first time and never during resume. This avoids the unsafe firmware file reading and should also speed up resume by skipping unnecessary device initialization. Link: https://lore.kernel.org/linux-media/20210418001204.7453-3-kernel@tuxforce.de [mchehab: fix several Coding Style issues] Cc: Antti Palosaari <crope@iki.fi> Signed-off-by:
Lukas Middendorf <kernel@tuxforce.de> Signed-off-by:
-
Lukas Middendorf authored
The si2168 B40 firmware file name has been changed in or before 2014. During initialization, the new file name is preferred, but the old file name is used as a fallback when request_firmware with the new file name fails. Once reading the old file name has been attempted, only this name will be used on further firmware loading attempts. During resume, firmware reading with the new file name can (and likely will) fail even when it actually exists. So this permanent switch to the fallback firmware name happens even when not desired. Any system using a recent kernel version can be expected to have the firmware under the new name. The major distributions are either using the dvb firmware collection from LibreELEC, which has the new firmware file name, or do not package the firmware file but have documentation pointing towards a manual installation of the firmware file under the new name. If the firmware is available under the old name, it is severely outdated. If the switch to the old file name is performed, further firmware loading will either permanently fail (if it is not available) or an outdated firmware version will be used. Drop support for the fallback firmware file name and fail directly if the firmware is not available under its current name. On following attempts, the firmware read will then be retried with the correct current name instead of the old name. As reasoned above, there should be no negative effects of this change, while simplifying code (the B40 variant will be handled identical compared to the other variants of the si2168) and at the same time fixing possible problems if firmware loading fails on resume. Link: https://lore.kernel.org/linux-media/20210418161544.58858-1-kernel@tuxforce.deSigned-off-by:
-
Mauro Carvalho Chehab authored
Only touch the right bit to enable/disable an adapter channel, without touching the other adapter's one. Tested on Nova-TD. Link: https://lore.kernel.org/linux-media/4214942f248baddec9cfd2b4b2424993ac356a51.1632689033.git.mchehab+huawei@kernel.org Cc: linuxarm@huawei.com, mauro.chehab@huawei.com, Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, Mauro Carvalho Chehab <mchehab@kernel.org>, Michael Kuron <michael.kuron@gmail.com>, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, pb@linuxtv.org Signed-off-by:
-
Mauro Carvalho Chehab authored
Having two different paths to start/stop streaming, depending weather the USB endpoints are 0x82/0x83 or not makes it more prune to errors. Unify the logic. Link: https://lore.kernel.org/linux-media/065a6fff925a42153671fa5202c81882ca12c59c.1632689033.git.mchehab+huawei@kernel.org Cc: linuxarm@huawei.com, mauro.chehab@huawei.com, Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, Mauro Carvalho Chehab <mchehab@kernel.org>, Michael Kuron <michael.kuron@gmail.com>, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, pb@linuxtv.org Signed-off-by:
-
Michael Kuron authored
This fixes a problem where closing the tuner would leave it in a state where it would not tune to any channel when reopened. This problem was discovered as part of https://github.com/hselasky/webcamd/issues/16. Since adap->id is 0 or 1, this bit-shift overflows, which is undefined behavior. The driver still worked in practice as the overflow would in most environments result in 0, which rendered the line a no-op. When running the driver as part of webcamd however, the overflow could lead to 0xff due to optimizations by the compiler, which would, in the end, improperly shut down the tuner. The bug is a regression introduced in the commit referenced below. The present patch causes identical behavior to before that commit for adap->id equal to 0 or 1. The driver does not contain support for dib0700 devices with more adapters, assuming such even exist. Tests have been performed with the Xbox One Digital TV Tuner on amd64. Not all dib0700 devices are expected to be affected by the regression; this code path is only taken by those with incorrect endpoint numbers. Link: https://lore.kernel.org/linux-media/1d2fc36d94ced6f67c7cc21dcc469d5e5bdd8201.1632689033.git.mchehab+huawei@kernel.org Cc: stable@vger.kernel.org Fixes: 7757ddda ("[media] DiB0700: add function to change I2C-speed") Signed-off-by:
Michael Kuron <michael.kuron@gmail.com> Signed-off-by:
-
Scott K Logan authored
This looks like a typo. By manipulating the antenna on a device while monitoring the reported SNR, I was able to see the unexpected jump. After applying this patch, the spike was no longer present. Link: https://lore.kernel.org/linux-media/20211003001805.735092-1-logans@cottsay.netSigned-off-by:
Scott K Logan <logans@cottsay.net> Signed-off-by:
-
