As reported by smatch:
drivers/media/pci/cx88/cx88-alsa.c:286 cx88_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type?
the number of patches should be unsigned long.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As reported by smatch:
drivers/media//pci/cx23885/cx23885-alsa.c:83 cx23885_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type?
the number of patches should be unsigned long.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As reported by smatch:
drivers/media/pci/cx25821/cx25821-alsa.c:146 cx25821_alsa_dma_init() warn: should 'nr_pages << 12' be a 64 bit type?
the number of patches should be unsigned long.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As reported by smatch:
drivers/media/v4l2-core/videobuf-dma-sg.c:245 videobuf_dma_init_kernel() warn: should 'nr_pages << 12' be a 64 bit type?
The printk should not be using %d for the number of pages.
After looking better, the real problem here is that the
number of pages should be long int.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As warned by smatch:
drivers/media/rc/serial_ir.c:550 serial_ir_probe() warn: should '8 << ioshift' be a 64 bit type?
the "8" constant should be unsigned long.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The usage of castings and float point when checking for
the setup based at the symbol_rate cause those warnings
with smatch:
drivers/media/dvb-frontends/tda10021.c:153 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
drivers/media/dvb-frontends/tda10021.c:155 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
drivers/media/dvb-frontends/tda10021.c:157 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
drivers/media/dvb-frontends/tda10021.c:159 tda10021_set_symbolrate() warn: unsigned 'symbolrate' is never less than zero.
While the code should work with gcc, as it will evaluate the
values into a constant before compiling, other compilers
could do otherwise. So, get rid of float pointing math on it,
avoiding the need of doing typecasts.
While here, cleanup some coding style issues at the related
code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sparse warns about this symbol:
drivers/media/platform/qcom/venus/hfi_venus.c:133:5: warning: symbol 'venus_fw_debug' was not declared. Should it be static?
Because hfi_venus.c doesn't include a header file with the
extern. So, move it to core.h, with is included by both
hfi_venus.c and dbgfs.c.
This way, if something changes with it, warnings or errors
will be produced.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As reported by smatch:
drivers/media/radio/wl128x/fmdrv_common.c:736 fm_irq_handle_rdsdata_getcmd_resp() warn: potential spectre issue 'rds_fmt.data.groupdatabuff.buff>
Address it by using array_index_nospec().
While here, reorder the linux/ includes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
While smatch reports an issue there:
drivers/media/pci/ttpci/av7110_v4l.c:163 ves1820_set_tv_freq() warn: unsigned 'freq' is never less than zero.
drivers/media/pci/ttpci/av7110_v4l.c:165 ves1820_set_tv_freq() warn: unsigned 'freq' is never less than zero.
The logic is actually fine. Yet, removing the typecast
shuts up smatch and makes the code more readable.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As pointed by smatch:
drivers/media/tuners/qt1010.c:239 qt1010_init_meas1() error: uninitialized symbol 'val2'.
drivers/media/tuners/qt1010.c:273 qt1010_init_meas2() error: uninitialized symbol 'val'.
The logic is ok, but it is hard for static analyzers
to parse it, as it depends on a value read in the middle
of a loop.
Also, it takes a while for humans to verify.
Re-write the first function to use a more direct way.
At the second one, I opted to just initialize the read var,
in order to shut up the report.
While here, address a few coding style issues at the
function code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The original logic had an integer to unsigned integer
conversion, plus a float-point math. While gcc should be
able to do the match at compile time, other compilers might
not do the same. Also, those produce the following warnings
with static code analyzers:
drivers/media/dvb-frontends/tda10086.c:300 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:303 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:306 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:309 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:312 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:315 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:318 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:321 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:324 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
drivers/media/dvb-frontends/tda10086.c:327 tda10086_set_symbol_rate() warn: unsigned 'symbol_rate' is never less than zero.
Change the logic to declare the reference constant as unsigned
and to not use float point math.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Upon running Sparse, "warning: dubious: !x | !y" is brought to notice
for this file. Logical and bitwise OR are basically the same in this
context, so it doesn't cause a runtime bug. But let's change it to
logical OR to make it a little bit cleaner and silence the Sparse
warning.
Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When aspect_ratio_crop_init() fails, curr_stream needs
to be freed just like what we've done in the following
error paths. However, current code is returning directly
and ends up leaking memory.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are spelling mistakes in some dev_err messages. Fix these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
`find_gmin_subdev()` that returns a pointer to `struct
gmin_subdev` can return NULL.
In `gmin_v2p8_ctrl()` there's a call to this function but the
possibility of a NULL was not checked before its being dereferenced,
i.e.:
/* Acquired here --------v */
struct gmin_subdev *gs = find_gmin_subdev(subdev);
/* v------Dereferenced here */
if (gs->v2p8_gpio >= 0) {
...
}
With this change we're null checking `find_gmin_subdev()` result
and we return an error if that's the case. We also WARN()
for the sake of debugging.
Signed-off-by: Cengiz Can <cengiz@kernel.wtf>
Reported-by: Coverity Static Analyzer CID 1465536
Suggested-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are a couple of debug messages using hardcoded function names
instead of the preferred __func__ magic constant.
Replace them:
WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this function's name, in a string
215: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:215:
+ v4l2_err(client, "misensor_rmw_reg error exit, read failed\n");
WARNING: Prefer using '"%s...", __func__' to using 'misensor_rmw_reg', this function's name, in a string
236: FILE: ./media/atomisp/i2c/atomisp-mt9m114.c:236:
+ v4l2_err(client, "misensor_rmw_reg error exit, write failed\n");
Signed-off-by: Juan Antonio Aldea-Armenteros <juant.aldea@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fix warnings and errors generated after running checkpatch.pl on pci/sh_css_firmware.c.
Signed-off-by: Rohit K Bharadwaj <bharadwaj.rohit8@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Replace deprecated MSI IRQ enabler and disabler
with pci_alloc_irq_vectors and pci_free_irq_vectors respectively.
And as a result handle the returned error as appropriate.
Compile tested.
[mchehab: solved a merge conflict that renamed dev->pdev]
Signed-off-by: Suraj Upadhyay <usuraj35@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are several bad whitespacing usage there. Remove them.
While here, place all Kconfig options for sensors at the
same place.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Removed braces in 'if else' condition as it only consists of
one line each and according to coding style rules , in this case
the braces are not required.
Signed-off-by: Ankit Baluni <b18007@students.iitmandi.ac.in>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Removed braces for a 'if' condition as it contain only single line &
there is no need for braces for such case according to coding style
rules.
Signed-off-by: Ankit Baluni <b18007@students.iitmandi.ac.in>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This fixes some coding style issues of multiline comments to
correct a few checkpatch.pl warnings.
Signed-off-by: Rahul Gottipati <rahul.blr97@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This removes whitespaces at the beginning of a few lines to fix
some checkpatch.pl warnings.
Signed-off-by: Rahul Gottipati <rahul.blr97@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When we added support for omap3, back in 2010, we added a new
type of V4L2 devices that aren't fully controlled via the V4L2
device node.
Yet, we have never clearly documented in the V4L2 specification
the differences between the two types.
Let's document them based on the the current implementation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a glossary of terms used within the media userspace API
documentation, as several concepts are complex enough to cause
misunderstandings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
minor numbers use to range between 0 to 255, but that
was changed a long time ago. While it still applies when
CONFIG_VIDEO_FIXED_MINOR_RANGES, when the minor number is
dynamically allocated, this may not be true. In any case,
this is not relevant, as udev will take care of it.
So, remove this useless misinformation.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Right now, only kAPI documentation describes the device naming.
However, such description is needed at the uAPI too. Add it,
and describe how to get an unique identifier for a given device.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are some files that are dual licensed GPL and GFDL.
As SPDX v3.10 gained support for GFDL-1.1 with no invariant sections:
https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html
Let's remove the dual license text, replacing them by:
SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are some files that are dual licensed GPL and GFDL.
As SPDX v3.10 gained support for GFDL-1.1 with no invariant sections:
https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html
Let's remove the dual license text, replacing them by:
SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
SPDX v3.10 gained support for GFDL-1.1 with no invariant sections:
https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html
So, remove the license text, replacing them by this new SPDX license.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
SPDX v3.10 gained support for GFDL-1.1 with no invariant sections:
https://spdx.org/licenses/GFDL-1.1-no-invariants-or-later.html
So, remove the license text, replacing them by this new SPDX
license.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Here we introduce debug prefixes for dev_dbg groups by level of
importance - Venus{Low,Med,High,FW} Enabling the particular level
will be done by dynamic debug.
For example to enable debug messages with low level:
echo 'format "VenusLow" +p' > debugfs/dynamic_debug/control
If you want to enable all levels:
echo 'format "Venus" +p' > debugfs/dynamic_debug/control
All the features which dynamic debugging provide are preserved.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This will be useful when debugging specific issues related to
firmware HFI interface.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Deprecate mfc private frame skip mode control for new
clients and use the standard one instead.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Use the standard menu control for frame skip mode in the MFC
driver. The legacy private menu control is kept for backward
compatibility.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This adds support for frame-skip-mode standard v4l2 control in
encoder driver. The control is implemented based on the
combination of client selected bitrate-mode and frame-skip-mode.
Once The client selected bitrate-mode (constant or variable) and
the frame-skip-mode is not disabled we set variable framerate for
rate controller.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Adds encoders standard v4l2 control for frame-skip. The control
is a copy of a custom encoder control so that other v4l2 encoder
drivers can use it.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Adds implementation of V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY v4l
control when the bitrate mode is CQ.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When V4L2_CID_MPEG_VIDEO_BITRATE_MODE value is
V4L2_MPEG_VIDEO_BITRATE_MODE_CQ, encoder will produce
constant quality output indicated by
V4L2_CID_MPEG_VIDEO_CONSTANT_QUALITY control value.
Encoder will choose appropriate quantization parameter
and bitrate to produce requested frame quality level.
Signed-off-by: Maheshwar Ajja <majja@codeaurora.org>
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Presently the recovery mechanism is using two hfi functions
to destroy and create interface queues. For the purpose of
recovery we don't need to free and allocate the memory used
for interface message queues, that's why we introduce new
function which just reinit the queues. Also this will give
to the recovery procedure one less reason to fail (if for
some reason we couldn't allocate memory).
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Fritz Koenig <frkoenig@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
After power domains and clock restructuring the recovery for
sdm845 and v4 did not work properly. Fix that by reworking the
recovery function and the sequence.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Fritz Koenig <frkoenig@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Presently the hfi_parser has been called only once during driver
probe. To prepare the parser function to be called multiple times
from recovery we need to initialize few variables which are used
during parsing time.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Reviewed-by: Fritz Koenig <frkoenig@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
On dragonboard-410c (apq8016) with HFI_VERSION_1XX, the reported
framerate is in unit of 1/65535 fps (for fine grained control).
So the current reported supported frame intervals is wrong (max
is 1/65535 fps), leading to encoding issues or format negotiation
failures with gstreamer.
Fix that by setting the framerate denominator to coherent value
based on the the framerate factor.
The factor is not always the same, e.g. with db820c (apq8096) HFI
reports framerate in fps unit. So only apply that for HFI_VERSION_1XX.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are few list handling issues while adding and deleting
node in the registered buf list in the driver.
1. list addition - buffer added into the list during buf_init
while not deleted during cleanup.
2. list deletion - In capture streamoff, the list was reinitialized.
As a result, if any node was present in the list, it would
lead to issue while cleaning up that node during buf_cleanup.
Corresponding call traces below:
[ 165.751014] Call trace:
[ 165.753541] __list_add_valid+0x58/0x88
[ 165.757532] venus_helper_vb2_buf_init+0x74/0xa8 [venus_core]
[ 165.763450] vdec_buf_init+0x34/0xb4 [venus_dec]
[ 165.768271] __buf_prepare+0x598/0x8a0 [videobuf2_common]
[ 165.773820] vb2_core_qbuf+0xb4/0x334 [videobuf2_common]
[ 165.779298] vb2_qbuf+0x78/0xb8 [videobuf2_v4l2]
[ 165.784053] v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem]
[ 165.789067] v4l2_m2m_ioctl_qbuf+0x2c/0x38 [v4l2_mem2mem]
[ 165.794624] v4l_qbuf+0x48/0x58
[ 1797.556001] Call trace:
[ 1797.558516] __list_del_entry_valid+0x88/0x9c
[ 1797.562989] vdec_buf_cleanup+0x54/0x228 [venus_dec]
[ 1797.568088] __buf_prepare+0x270/0x8a0 [videobuf2_common]
[ 1797.573625] vb2_core_qbuf+0xb4/0x338 [videobuf2_common]
[ 1797.579082] vb2_qbuf+0x78/0xb8 [videobuf2_v4l2]
[ 1797.583830] v4l2_m2m_qbuf+0x80/0xf8 [v4l2_mem2mem]
[ 1797.588843] v4l2_m2m_ioctl_qbuf+0x2c/0x38 [v4l2_mem2mem]
[ 1797.594389] v4l_qbuf+0x48/0x58
Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
Reviewed-by: Fritz Koenig <frkoenig@chromium.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Baseline, Main and Extended profiles are specified to
not support a scaling matrix. Also, High profiles
can optionally specify a scaling matrix, using
SPS and PPS NAL units.
To meet this expectation, applications are required to
set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control
and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT
flag only when a scaling matrix is specified for a picture.
Implement this on cedrus, which has hardware support for this
case.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Baseline, Main and Extended profiles are specified to
not support a scaling matrix. Also, High profiles
can optionally specify a scaling matrix, using
SPS and PPS NAL units.
To meet this expectation, applications are required to
set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control
and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT
flag only when a scaling matrix is specified for a picture.
Implement this on hantro, which has hardware support for this
case.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Baseline, Main and Extended profiles are specified to
not support a scaling matrix. Also, High profiles
can optionally specify a scaling matrix, using
SPS and PPS NAL units.
To meet this expectation, applications are required to
set the V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX control
and set the V4L2_H264_PPS_FLAG_SCALING_MATRIX_PRESENT
flag only when a scaling matrix is specified for a picture.
Implement this on rkvdec, which has hardware support for this
case.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently, the drivers makes no distinction between per_request
and mandatory, as both are used in the same request validate check.
The driver only cares to know if a given control is
required to be part of a request, so only one flag is needed.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Tested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
