Joe Perches [Tue, 25 Aug 2020 04:56:18 +0000 (06:56 +0200)]
media: atomisp: Avoid comma separated statements
Use semicolons and braces.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Dinghao Liu [Fri, 21 Aug 2020 05:49:16 +0000 (07:49 +0200)]
media: atomisp: fix memleak in ia_css_stream_create
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>
Colin Ian King [Thu, 6 Aug 2020 11:57:17 +0000 (13:57 +0200)]
media: atomisp: fix spelling mistake "unsupport" -> "unsupported"
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>
Cengiz Can [Sat, 1 Aug 2020 22:01:02 +0000 (00:01 +0200)]
media: atomisp: move null check to earlier point
`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>
Juan Antonio Aldea-Armenteros [Mon, 27 Jul 2020 17:48:12 +0000 (19:48 +0200)]
media: atomisp: mt9m114: replace fixed function names
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>
Rohit K Bharadwaj [Sun, 26 Jul 2020 06:25:42 +0000 (08:25 +0200)]
media: atomisp: fix code style issues
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>
Suraj Upadhyay [Sun, 19 Jul 2020 14:26:23 +0000 (16:26 +0200)]
media: atomisp: Replace deprecated MSI APIs
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>
Mauro Carvalho Chehab [Mon, 15 Jun 2020 05:43:03 +0000 (07:43 +0200)]
media: atomisp: fix identation at I2C Kconfig menu
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>
Ankit Baluni [Wed, 29 Jul 2020 08:05:16 +0000 (10:05 +0200)]
media: atomisp: fix a brace coding sytle issue
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>
Aditya Jain [Thu, 23 Jul 2020 16:21:33 +0000 (18:21 +0200)]
media: atomisp: Fix braces placement coding style errors
Fix braces placement errors as reported by checkpatch.pl
Signed-off-by: Aditya Jain <aditya.jainadityajain.jain@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Ankit Baluni [Wed, 29 Jul 2020 07:49:50 +0000 (09:49 +0200)]
media: atomisp: fixed a brace coding sytle issue
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>
Rahul Gottipati [Wed, 22 Jul 2020 14:58:19 +0000 (16:58 +0200)]
media: atomisp: coding style: correct multiline comments
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>
Rahul Gottipati [Wed, 22 Jul 2020 14:55:28 +0000 (16:55 +0200)]
media: atomisp: coding style: remove beginning whitespaces
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>
Mauro Carvalho Chehab [Fri, 25 Aug 2017 14:56:42 +0000 (16:56 +0200)]
media: open.rst: document mc-centric and video-node-centric
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>
Mauro Carvalho Chehab [Fri, 25 Aug 2017 14:49:32 +0000 (16:49 +0200)]
media: docs: add glossary.rst with common terms used at V4L2 spec
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>
Mauro Carvalho Chehab [Fri, 25 Aug 2017 14:54:20 +0000 (16:54 +0200)]
media: open.rst: remove the minor number range
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>
Mauro Carvalho Chehab [Fri, 25 Aug 2017 14:51:53 +0000 (16:51 +0200)]
media: open.rst: better document device node naming
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>
Mauro Carvalho Chehab [Wed, 26 Aug 2020 07:16:41 +0000 (09:16 +0200)]
media: docs: use SPDX GPL-2.0 OR GFDL-1.1 instead of text on *.svg files
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>
Mauro Carvalho Chehab [Wed, 26 Aug 2020 07:12:13 +0000 (09:12 +0200)]
media: docs: use SPDX GPL-2.0 OR GFDL-1.1 instead of text on *.rst files
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>
Mauro Carvalho Chehab [Wed, 26 Aug 2020 07:09:10 +0000 (09:09 +0200)]
media: docs: use the new SPDX header for GFDL-1.1 on *.svg files
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>
Mauro Carvalho Chehab [Wed, 26 Aug 2020 07:03:09 +0000 (09:03 +0200)]
media: docs: use the new SPDX header for GFDL-1.1 on *.rst files
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>
Stanimir Varbanov [Tue, 7 Jul 2020 17:48:54 +0000 (19:48 +0200)]
media: venus: Make debug infrastructure more flexible
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>
Stanimir Varbanov [Thu, 21 May 2020 11:35:16 +0000 (13:35 +0200)]
media: venus: Add debugfs interface to set firmware log level
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>
Stanimir Varbanov [Sun, 5 Jul 2020 00:58:27 +0000 (02:58 +0200)]
media: docs: Deprecate mfc frame skip control
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>
Stanimir Varbanov [Sun, 5 Jul 2020 00:11:26 +0000 (02:11 +0200)]
media: s5p-mfc: Use standard frame skip mode control
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>
Stanimir Varbanov [Sat, 4 Jul 2020 23:46:23 +0000 (01:46 +0200)]
media: venus: venc: Add support for frame-skip mode v4l2 control
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>
Stanimir Varbanov [Sat, 4 Jul 2020 23:41:00 +0000 (01:41 +0200)]
media: v4l2-ctrl: Add frame-skip std encoder control
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>
Stanimir Varbanov [Tue, 16 Jun 2020 12:14:22 +0000 (14:14 +0200)]
media: venus: venc: Add support for constant quality control
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>
Maheshwar Ajja [Sat, 23 May 2020 01:05:26 +0000 (03:05 +0200)]
media: v4l2-ctrls: Add encoder constant quality control
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>
Stanimir Varbanov [Thu, 30 Jul 2020 11:46:32 +0000 (13:46 +0200)]
media: venus: Add new interface queues reinit
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>
Stanimir Varbanov [Thu, 30 Jul 2020 11:46:31 +0000 (13:46 +0200)]
media: venus: Rework recovery mechanism
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>
Stanimir Varbanov [Thu, 30 Jul 2020 11:46:30 +0000 (13:46 +0200)]
media: venus: parser: Prepare parser for multiple invocations
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>
Loic Poulain [Tue, 4 Aug 2020 12:21:57 +0000 (14:21 +0200)]
media: venus: Fix reported frame intervals
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>
Vikash Garodia [Tue, 4 Aug 2020 11:48:45 +0000 (13:48 +0200)]
media: venus: fixes for list corruption
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:45 +0000 (05:52 +0200)]
media: cedrus: Use H264_SCALING_MATRIX only when required
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:44 +0000 (05:52 +0200)]
media: hantro: Use H264_SCALING_MATRIX only when required
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:43 +0000 (05:52 +0200)]
media: rkvdec: Use H264_SCALING_MATRIX only when required
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:42 +0000 (05:52 +0200)]
media: rkvdec: Drop unneeded per_request driver-specific control flag
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>
Jernej Skrabec [Tue, 25 Aug 2020 03:52:41 +0000 (05:52 +0200)]
media: cedrus: h264: Fix frame list construction
Current frame list construction algorithm assumes that decoded image
will be output into its own buffer. That is true for progressive content
but not for interlaced where each field is decoded separately into same
buffer.
Fix that by checking if capture buffer is listed in DPB. If it is, reuse
it.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jernej Skrabec [Tue, 25 Aug 2020 03:52:40 +0000 (05:52 +0200)]
media: cedrus: h264: Properly configure reference field
When interlaced H264 content is being decoded, references must indicate
which field is being referenced. Currently this was done by checking
capture buffer flags. However, that is not correct because capture
buffer may hold both fields.
Fix this by checking newly introduced flags in reference lists.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:39 +0000 (05:52 +0200)]
media: rkvdec: Don't require unneeded H264_SLICE_PARAMS
Now that slice invariant parameters have been moved,
the driver no longer needs this control, so drop it.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:38 +0000 (05:52 +0200)]
media: hantro: Don't require unneeded H264_SLICE_PARAMS
Now that slice invariant parameters have been moved,
the driver no longer needs this control, so drop it.
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:37 +0000 (05:52 +0200)]
media: uapi: h264: Rename and clarify PPS_FLAG_SCALING_MATRIX_PRESENT
Applications are expected to fill V4L2_CID_MPEG_VIDEO_H264_SCALING_MATRIX
if a non-flat scaling matrix applies to the picture. This is the case if
SPS scaling_matrix_present_flag or PPS pic_scaling_matrix_present_flag
are set, and should be handled by applications.
On one hand, the PPS bitstream syntax element signals the presence of a
Picture scaling matrix modifying the Sequence (SPS) scaling matrix.
On the other hand, our flag should indicate if the scaling matrix
V4L2 control is applicable to this request.
Rename the flag from PPS_FLAG_PIC_SCALING_MATRIX_PRESENT to
PPS_FLAG_SCALING_MATRIX_PRESENT, to avoid mixing this flag with
bitstream syntax element pic_scaling_matrix_present_flag,
and clarify the meaning of our flag.
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:36 +0000 (05:52 +0200)]
media: uapi: h264: Clean slice invariants syntax elements
The H.264 specification requires in section 7.4.3 "Slice header semantics",
that the following values shall be the same in all slice headers:
pic_parameter_set_id
frame_num
field_pic_flag
bottom_field_flag
idr_pic_id
pic_order_cnt_lsb
delta_pic_order_cnt_bottom
delta_pic_order_cnt[ 0 ]
delta_pic_order_cnt[ 1 ]
sp_for_switch_flag
slice_group_change_cycle
These bitstream fields are part of the slice header, and therefore
passed redundantly on each slice. The purpose of the redundancy
is to make the codec fault-tolerant in network scenarios.
This is of course not needed to be reflected in the V4L2 controls,
given the bitstream has already been parsed by applications.
Therefore, move the redundant fields to the per-frame decode
parameters control (DECODE_PARAMS).
Field 'pic_parameter_set_id' is simply removed in this case,
because the PPS control must currently contain the active PPS.
Syntax elements dec_ref_pic_marking() and those related
to pic order count, remain invariant as well, and therefore,
the fields dec_ref_pic_marking_bit_size and pic_order_cnt_bit_size
are also common to all slices.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:35 +0000 (05:52 +0200)]
media: uapi: h264: Clarify SLICE_BASED mode
Currently, the SLICE_BASED and FRAME_BASED modes documentation
is misleading and not matching the intended use-cases.
Drop non-required fields SLICE_PARAMS 'start_byte_offset' and
DECODE_PARAMS 'num_slices' and clarify the decoding modes in the
documentation.
On SLICE_BASED mode, a single slice is expected per OUTPUT buffer,
and therefore 'start_byte_offset' is not needed (since the offset
to the slice is the start of the buffer).
This mode requires the use of CAPTURE buffer holding, and so
the number of slices shall not be required.
On FRAME_BASED mode, the devices are expected to take care of slice
parsing. Neither SLICE_PARAMS are required (and shouldn't be
exposed by frame-based drivers), nor the number of slices.
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:34 +0000 (05:52 +0200)]
media: uapi: h264: Drop SLICE_PARAMS 'size' field
The SLICE_PARAMS control is intended for slice-based
devices. In this mode, the OUTPUT buffer contains
a single slice, and so the buffer's plane payload size
can be used to query the slice size.
To reduce the API surface drop the size from the
SLICE_PARAMS control.
A follow-up change will remove other members in SLICE_PARAMS
so we don't need to add padding fields here.
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:33 +0000 (05:52 +0200)]
media: uapi: h264: Increase size of DPB entry pic_num
DPB entry PicNum maximum value is 2*MaxFrameNum for interlaced
content (field_pic_flag=1).
As specified, MaxFrameNum is 2^(log2_max_frame_num_minus4 + 4)
and log2_max_frame_num_minus4 is in the range of 0 to 12,
which means pic_num should be a 32-bit field.
The v4l2_h264_dpb_entry struct needs to be padded to avoid a hole,
which might be also useful to allow future uAPI extensions.
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:32 +0000 (05:52 +0200)]
media: uapi: h264: Clean DPB entry interface
As discussed recently, the current interface for the
Decoded Picture Buffer is not enough to properly
support field coding.
This commit introduces enough semantics to support
frame and field coding, and to signal how DPB entries
are "used for reference".
Reserved fields will be added by a follow-up commit.
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:31 +0000 (05:52 +0200)]
media: uapi: h264: Increase size of 'first_mb_in_slice' field
Slice header syntax element 'first_mb_in_slice' can point
to the last macroblock, currently the field can only reference
65536 macroblocks which is insufficient for 8K videos.
Although unlikely, a 8192x4320 video (where macroblocks are 16x16),
would contain 138240 macroblocks on a frame.
As per the H264 specification, 'first_mb_in_slice' can be up to
PicSizeInMbs - 1, so increase the size of the field to 32-bits.
Note that v4l2_ctrl_h264_slice_params struct will be modified
in a follow-up commit, and so we defer its 64-bit padding.
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>
Philipp Zabel [Tue, 25 Aug 2020 03:52:30 +0000 (05:52 +0200)]
media: uapi: h264: Clarify pic_order_cnt_bit_size field
Since pic_order_cnt_bit_size is not a syntax element itself, explicitly
state that it is the total size in bits of the pic_order_cnt_lsb,
delta_pic_order_cnt_bottom, delta_pic_order_cnt[0], and
delta_pic_order_cnt[1] syntax elements contained in the slice.
[Ezequiel: rebase]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:29 +0000 (05:52 +0200)]
media: uapi: h264: Split prediction weight parameters
The prediction weight parameters are only required under
certain conditions, which depend on slice header parameters.
As specified in section 7.3.3 Slice header syntax, the prediction
weight table is present if:
((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \
(weighted_bipred_idc == 1 && slice_type == B))
Given its size, it makes sense to move this table to its control,
so applications can avoid passing it if the slice doesn't specify it.
Before this change struct v4l2_ctrl_h264_slice_params was 960 bytes.
With this change, it's 188 bytes and struct v4l2_ctrl_h264_pred_weight
is 772 bytes.
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>
Ezequiel Garcia [Tue, 25 Aug 2020 03:52:28 +0000 (05:52 +0200)]
media: uapi: h264: Further clarify scaling lists order
Commit
0b0393d59eb4a ("media: uapi: h264: clarify
expected scaling_list_4x4/8x8 order") improved the
documentation on H264 scaling lists order.
This commit improves the documentation by clarifying
that the lists themselves are expected in raster scan order.
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>
Jernej Skrabec [Tue, 25 Aug 2020 03:52:27 +0000 (05:52 +0200)]
media: uapi: h264: Update reference lists
When dealing with interlaced frames, reference lists must tell if
each particular reference is meant for top or bottom field. This info
is currently not provided at all in the H264 related controls.
Change reference lists to hold a structure, which specifies
an index into the DPB array and the field/frame specification
for the picture.
Currently the only user of these lists is Cedrus which is just compile
fixed here. Actual usage of will come in a following commit.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
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>
Bingbu Cao [Fri, 21 Aug 2020 07:59:50 +0000 (09:59 +0200)]
media: ov5675: correct the maximum exposure value
The unit of exposure value is different from other OmniVision sensors,
driver will divide by 2 before set register, the exposure range exposed
by v4l2 ctrl to user should be same as others, so the calculation for
the maximum exposure value in current driver need be fixed.
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sakari Ailus [Wed, 6 May 2020 13:28:20 +0000 (15:28 +0200)]
media: Documentation: media: Document how to write camera sensor drivers
While we have had some example drivers, there has been up to date no
formal documentation on how camera sensor drivers should be written; what
are the practices, why, and where they apply.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Raag Jadav [Thu, 6 Aug 2020 15:48:27 +0000 (17:48 +0200)]
media: ov7740: use SCCB regmap
Make use of SCCB APIs for regmap operations.
Remove i2c_check_functionality as devm_regmap_init_sccb
does it for us.
Signed-off-by: Raag Jadav <raagjadav@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Hans Verkuil [Fri, 3 Jul 2020 09:20:32 +0000 (11:20 +0200)]
media: imx274: fix frame interval handling
1) the numerator and/or denominator might be 0, in that case
fall back to the default frame interval. This is per the spec
and this caused a v4l2-compliance failure.
2) the updated frame interval wasn't returned in the s_frame_interval
subdev op.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Tom Rix [Sun, 19 Jul 2020 15:34:47 +0000 (17:34 +0200)]
media: m5mols: Check function pointer in m5mols_sensor_power
clang static analysis reports this error
m5mols_core.c:767:4: warning: Called function pointer
is null (null dereference) [core.CallAndMessage]
info->set_power(&client->dev, 0);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In other places, the set_power ptr is checked.
So add a check.
Fixes:
bc125106f8af ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Colin Ian King [Mon, 20 Jul 2020 16:13:35 +0000 (18:13 +0200)]
media: i2c: fix error check on max9286_read call
Currently the error return from the call to max9286_read is masked
with 0xf0 so the following check for a negative error return is
never true. Fix this by checking for an error first, then masking
the return value for subsequent conflink_mask checking.
Addresses-Coverity: ("Logically dead code")
Fixes:
66d8c9d2422d ("media: i2c: Add MAX9286 driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Alexander A. Klimov [Sun, 19 Jul 2020 11:21:33 +0000 (13:21 +0200)]
media: omap: Replace HTTP links with HTTPS ones
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Paul Kocialkowski [Mon, 3 Aug 2020 09:06:58 +0000 (11:06 +0200)]
media: ov5640: Correct Bit Div register in clock tree diagram
Although the code is correct and doing the right thing, the clock diagram
showed the wrong register for the bit divider, which had me doubting the
understanding of the tree. Fix this to avoid doubts in the future.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Fixes:
aa2882481cada ("media: ov5640: Adjust the clock based on the expected rate")
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jordan Hand [Fri, 24 Jul 2020 17:37:38 +0000 (19:37 +0200)]
media: ipu3.rst: Format media-ctl and yavta commands as code blocks
Fix improper line breaks and format all example yavta and media-ctl
commands as code blocks to improve readability.
Signed-off-by: Jordan Hand <jorhand@linux.microsoft.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jacopo Mondi [Mon, 10 Aug 2020 21:55:43 +0000 (23:55 +0200)]
media: MAINTAINERS: ov5647: Replace maintainer
Since the current maintainer email address bounces back, replace
the entry and make myself and Dave Stevenson maintainers of the driver.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jacopo Mondi [Mon, 10 Aug 2020 21:55:42 +0000 (23:55 +0200)]
media: dt-bindings: media: ov5647: Document clock-noncontinuous
Document the optional clock-noncontinuous endpoint property that
allows enabling MIPI CSI-2 non-continuous clock operations.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jacopo Mondi [Mon, 10 Aug 2020 21:55:41 +0000 (23:55 +0200)]
media: dt-bindings: media: ov5647: Document pwdn-gpios
Document in dt-schema bindings for the ov5647 sensor the optional
'pwdn-gpios' property.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jacopo Mondi [Mon, 10 Aug 2020 21:55:40 +0000 (23:55 +0200)]
media: dt-bindings: media: ov5647: Convert to json-schema
Convert the ov5647 image sensor bindings to DT schema and add
the file entry to MAINTAINERS.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Rahul Gottipati [Wed, 22 Jul 2020 08:20:48 +0000 (10:20 +0200)]
media: intel-ipu3: Fix code style issue
This fixes a multiline comment style warning as found by checkpatch.pl.
Signed-off-by: Rahul Gottipati <rahul.blr97@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Bingbu Cao [Tue, 28 Jul 2020 02:01:05 +0000 (04:01 +0200)]
media: MAINTAINERS: Fix email typo and correct name of Tianshu
Fix the typo in email address of Tianshu Qiu and correct the name.
Reported-by: Bjorn Helgaas <helgaas@kernel.org>
Signed-off-by: Tianshu Qiu <tian.shu.qiu@intel.com>
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Bingbu Cao [Fri, 24 Jul 2020 03:45:38 +0000 (05:45 +0200)]
media: i2c: ov2740: get OTP data ready before nvmem registration
The OTP data was not ready after registered as nvmem device, it is
risky as the nvmem read may happen once the device exists, this patch
get the OTP data ready before registering the nvmem device. OTP data
missing should not break the normal camera sensor probe, so use a
warning instead of an error message.
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Qingwu Zhang <qingwu.zhang@intel.com>
Suggested-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Greg Kroah-Hartman [Tue, 18 Aug 2020 13:36:07 +0000 (15:36 +0200)]
media: radio: si476x: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Greg Kroah-Hartman [Tue, 18 Aug 2020 13:36:06 +0000 (15:36 +0200)]
media: sti: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Greg Kroah-Hartman [Tue, 18 Aug 2020 13:36:05 +0000 (15:36 +0200)]
media: mtk-vpu: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Greg Kroah-Hartman [Tue, 18 Aug 2020 13:36:04 +0000 (15:36 +0200)]
media: exynos4-is: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Greg Kroah-Hartman [Tue, 18 Aug 2020 13:36:03 +0000 (15:36 +0200)]
media: coda: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Greg Kroah-Hartman [Tue, 18 Aug 2020 13:36:02 +0000 (15:36 +0200)]
media: cec: no need to check return value of debugfs_create functions
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jonathan Bakker [Thu, 30 Jul 2020 23:01:14 +0000 (01:01 +0200)]
media: dt-bindings: media: Correct samsung-fimc parallel port numbering
The parallel port nodes should be numbered 1 and 2, not 0 and 1
for A and B respectively. The driver has always implemented 1
and 2 and the in-tree Goni DTS uses 1 as port A as well. Update
the documentation to match this behaviour.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jonathan Bakker [Thu, 30 Jul 2020 23:01:13 +0000 (01:01 +0200)]
media: exynos4-is: Handle duplicate calls to vidioc_streamoff
vidioc_streamoff can be called multiple times from userspace, but we
should only call media_pipeline_stop when we're actually setup.
This became more noticeable after commit
2a2599c66368 ("[media] media:
entity: Catch unbalanced media_pipeline_stop calls") was merged as it
added a WARN for unbalanced calls to media_pipeline_stop.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jonathan Bakker [Thu, 30 Jul 2020 23:01:12 +0000 (01:01 +0200)]
media: exynos4-is: Remove unused struct member input_index
This is no longer used since the conversion to DT
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jonathan Bakker [Thu, 30 Jul 2020 23:01:11 +0000 (01:01 +0200)]
media: exynos4-is: Remove inh_sensor_ctrls
This is a no-op as it is never set and is a remnant from non-DT days
that can be safely removed.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jonathan Bakker [Thu, 30 Jul 2020 23:01:10 +0000 (01:01 +0200)]
media: exynos4-is: Add support for multiple sensors on one port
On some devices, there may be multiple camera sensors attached
to the same port. Make sure we probe all of them, not just the
first one.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jonathan Bakker [Thu, 30 Jul 2020 23:01:09 +0000 (01:01 +0200)]
media: exynos4-is: Use global num_sensors rather than local index
Instead of keeping a local copy of how many sensors we've probed
(which may not even properly represent the number of sensors
probed if we have a port without a sensor), use the global
num_sensors counter that has the actual number used.
This will also make it easier to add support for multiple sensors
being connected to the same port.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jonathan Bakker [Thu, 30 Jul 2020 23:01:08 +0000 (01:01 +0200)]
media: exynos4-is: Properly set JPEG options for parallel ports
Commit
ee7160e57c98 ("[media] s5p-fimc: Add support for JPEG capture")
added support for JPEG capture, but missed setting a register when the
parallel port was used rather than the CSIS device.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jonathan Bakker [Thu, 30 Jul 2020 23:01:07 +0000 (01:01 +0200)]
media: exynos4-is: Correct missing entity function initialization
Commit
bae4500399c4 ("[media] exynos4-is: Add missing entity function
initialization") tried to suppress the warnings such as
s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!
However, this missed setting for the subdev. Set it now to avoid the
ugly warnings on boot.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jonathan Bakker [Thu, 30 Jul 2020 23:01:06 +0000 (01:01 +0200)]
media: exynos4-is: Fix nullptr when no CSIS device present
Not all devices use the CSIS device, some may use the FIMC directly in
which case the CSIS device isn't registered. This leads to a nullptr
exception when starting the stream as the CSIS device is always
referenced. Instead, if getting the CSIS device fails, try getting the
FIMC directly to check if we are using the subdev API
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Tomasz Figa [Thu, 30 Jul 2020 23:01:05 +0000 (01:01 +0200)]
media: exynos4-is: Request syscon only if ISP writeback is present
On FIMC variants which don't have writeback channel, there is no need to
access system registers. This patch makes the driver request sysreg
regmap conditionally depending on whether writeback is supported.
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Jonathan Bakker [Thu, 30 Jul 2020 23:01:04 +0000 (01:01 +0200)]
media: exynos4-is: Remove static driver data for S5PV210 FIMC variants
The S5PV210 platform only supports device tree based booting
where the FIMC variant data is parsed directly from
the device tree, hence the now unused static data can be removed.
Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Ezequiel Garcia [Mon, 27 Jul 2020 17:05:38 +0000 (19:05 +0200)]
media: hantro: postproc: Fix motion vector space allocation
When the post-processor is enabled, the driver allocates
"shadow buffers" which are used for the decoder core,
and exposes the post-processed buffers to userspace.
For this reason, extra motion vector space has to
be allocated on the shadow buffers, which the driver
wasn't doing. Fix it.
This fix should address artifacts on high profile bitstreams.
Fixes:
8c2d66b036c77 ("media: hantro: Support color conversion via post-processing")
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Ezequiel Garcia [Mon, 27 Jul 2020 17:05:37 +0000 (19:05 +0200)]
media: hantro: h264: Get the correct fallback reference buffer
If the bitstream and the application are incorrectly configuring
the reference pictures, the hardware will need to fallback
to using some other reference picture.
When the post-processor is enabled, the fallback buffer
should be a shadow buffer (postproc.dec_q), and not a
CAPTURE queue buffer, since the latter is post-processed
and not really the output of the decoder core.
Fixes:
8c2d66b036c77 ("media: hantro: Support color conversion via post-processing")
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Julia Lawall [Sun, 26 Jul 2020 10:58:31 +0000 (12:58 +0200)]
tm6000: drop unnecessary list_empty
list_for_each_entry is able to handle an empty list.
The only effect of avoiding the loop is not initializing the
index variable.
Drop list_empty tests in cases where these variables are not
used.
Note that list_for_each_entry is defined in terms of list_first_entry,
which indicates that it should not be used on an empty list. But in
list_for_each_entry, the element obtained by list_first_entry is not
really accessed, only the address of its list_head field is compared
to the address of the list head, so the list_first_entry is safe.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
<smpl>
@@
expression x,e;
iterator name list_for_each_entry;
statement S;
identifier i;
@@
-if (!(list_empty(x))) {
list_for_each_entry(i,x,...) S
- }
... when != i
? i = e
</smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Julia Lawall [Sun, 26 Jul 2020 10:58:30 +0000 (12:58 +0200)]
saa7134: drop unnecessary list_empty
list_for_each_safe is able to handle an empty list.
The only effect of avoiding the loop is not initializing the
index variable.
Drop list_empty tests in cases where these variables are not
used.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
<smpl>
@@
expression x,e;
iterator name list_for_each_safe;
statement S;
identifier i,j;
@@
-if (!(list_empty(x))) {
list_for_each_safe(i,j,x) S
- }
... when != i
when != j
(
i = e;
|
? j = e;
)
</smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Julia Lawall [Sun, 26 Jul 2020 10:58:28 +0000 (12:58 +0200)]
media: cx231xx: drop unnecessary list_empty
list_for_each_entry is able to handle an empty list.
The only effect of avoiding the loop is not initializing the
index variable.
Drop list_empty tests in cases where these variables are not
used.
Note that list_for_each_entry is defined in terms of list_first_entry,
which indicates that it should not be used on an empty list. But in
list_for_each_entry, the element obtained by list_first_entry is not
really accessed, only the address of its list_head field is compared
to the address of the list head, so the list_first_entry is safe.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
<smpl>
@@
expression x,e;
iterator name list_for_each_entry;
statement S;
identifier i;
@@
-if (!(list_empty(x))) {
list_for_each_entry(i,x,...) S
- }
... when != i
? i = e
</smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Gustavo A. R. Silva [Fri, 24 Jul 2020 22:10:14 +0000 (00:10 +0200)]
media: Use fallthrough pseudo-keyword
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.
[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Helen Koike [Fri, 24 Jul 2020 16:25:55 +0000 (18:25 +0200)]
media: staging: rkisp1: uapi: remove __packed
The driver access struct's fields one by one, they are not blindly
copied to/from the hardware, so we can remove __packed from the
structs.
Tested on Scarlet Chromebook with ChromeOS stack and verified images
with the Camera app.
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Dafna Hirschfeld [Sat, 15 Aug 2020 10:37:24 +0000 (12:37 +0200)]
media: staging: rkisp1: params: don't release lock in isr before buffer is done
In the irq handler 'rkisp1_params_isr', the lock 'config_lock'
should be held as long as the current buffer is used. Otherwise the
stop_streaming calback might remove it from the list and
pass it to userspace while it is referenced in the irq handler.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Dafna Hirschfeld [Sat, 15 Aug 2020 10:37:22 +0000 (12:37 +0200)]
media: staging: rkisp1: params: use rkisp1_param_set_bits to set reg in isr
replace a read and write of RKISP1_CIF_ISP_CTRL register
in the isr with the 'rkisp1_param_set_bits' function
that does that.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Dafna Hirschfeld [Sat, 15 Aug 2020 10:37:21 +0000 (12:37 +0200)]
media: staging: rkisp1: call params isr only upon frame out
Currently the params isr is called and then returned when
isp-frame interrupt is not set. This condition is already
tested in the isp's isr so move the call under the condition
in the isp's isr.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Dafna Hirschfeld [Thu, 25 Jun 2020 18:50:17 +0000 (20:50 +0200)]
media: staging: rkisp1: change type of fields in 'rkisp1_cif_isp_lsc_config' from u32 to u16
The fields in struct 'rkisp1_cif_isp_lsc_config' need to hold
values of 12 bits, therefore it is enough to declare them as u16.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Dafna Hirschfeld [Thu, 25 Jun 2020 18:50:16 +0000 (20:50 +0200)]
media: staging: rkisp1: replace two identical macros with one
The two macros RKISP1_CIF_ISP_LSC_{GRAD/SIZE}_TBL_SIZE have
the same value which is the number of sectors in the grads
and size parameters. Therefore there is no need for two
different macros. Replace them with one macro
RKISP1_CIF_ISP_LSC_SECTORS_TBL_SIZE. Also use the macro
when iterating the arrays instead of hardcoded '4'.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Dafna Hirschfeld [Thu, 25 Jun 2020 18:50:15 +0000 (20:50 +0200)]
media: staging: rkisp1: set "*_data_tbl" fields in rkisp1_cif_isp_lsc_config as 2D arrays
Currently the fields '*_data_tbl' in the struct
'rkisp1_cif_isp_lsc_config' are one dimensional arrays
of size 290. The entries are accessed in a nested
loop by summing two indexes for the rows and columns.
Therefore it fits better to define the arrays as two
dimensional arrays of size 17x17.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Dafna Hirschfeld [Tue, 18 Aug 2020 08:18:01 +0000 (10:18 +0200)]
media: Documentation: v4l: move table of v4l2_pix_format(_mplane) flags to pixfmt-v4l2.rst
The table of the flags of the structs
v4l2_pix_format(_mplane) is currently in pixfmt-reserved.rst
which is wrong, it should be in pixfmt-v4l2.rst
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
projects / linux-2.6-microblaze.git / log