platform/kernel/linux-starfive.git
4 years agomedia: venus: Add debugfs interface to set firmware log level
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>
4 years agomedia: docs: Deprecate mfc frame skip control
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>
4 years agomedia: s5p-mfc: Use standard frame skip mode control
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>
4 years agomedia: venus: venc: Add support for frame-skip mode v4l2 control
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>
4 years agomedia: v4l2-ctrl: Add frame-skip std encoder control
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>
4 years agomedia: venus: venc: Add support for constant quality control
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>
4 years agomedia: v4l2-ctrls: Add encoder constant quality control
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>
4 years agomedia: venus: Add new interface queues reinit
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>
4 years agomedia: venus: Rework recovery mechanism
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>
4 years agomedia: venus: parser: Prepare parser for multiple invocations
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>
4 years agomedia: venus: Fix reported frame intervals
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>
4 years agomedia: venus: fixes for list corruption
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>
4 years agomedia: cedrus: Use H264_SCALING_MATRIX only when required
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>
4 years agomedia: hantro: Use H264_SCALING_MATRIX only when required
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>
4 years agomedia: rkvdec: Use H264_SCALING_MATRIX only when required
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>
4 years agomedia: rkvdec: Drop unneeded per_request driver-specific control flag
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>
4 years agomedia: cedrus: h264: Fix frame list construction
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>
4 years agomedia: cedrus: h264: Properly configure reference field
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>
4 years agomedia: rkvdec: Don't require unneeded H264_SLICE_PARAMS
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>
4 years agomedia: hantro: Don't require unneeded H264_SLICE_PARAMS
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>
4 years agomedia: uapi: h264: Rename and clarify PPS_FLAG_SCALING_MATRIX_PRESENT
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>
4 years agomedia: uapi: h264: Clean slice invariants syntax elements
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>
4 years agomedia: uapi: h264: Clarify SLICE_BASED mode
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>
4 years agomedia: uapi: h264: Drop SLICE_PARAMS 'size' field
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>
4 years agomedia: uapi: h264: Increase size of DPB entry pic_num
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>
4 years agomedia: uapi: h264: Clean DPB entry interface
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>
4 years agomedia: uapi: h264: Increase size of 'first_mb_in_slice' field
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>
4 years agomedia: uapi: h264: Clarify pic_order_cnt_bit_size field
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>
4 years agomedia: uapi: h264: Split prediction weight parameters
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>
4 years agomedia: uapi: h264: Further clarify scaling lists order
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>
4 years agomedia: uapi: h264: Update reference lists
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>
4 years agomedia: ov5675: correct the maximum exposure value
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>
4 years agomedia: Documentation: media: Document how to write camera sensor drivers
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>
4 years agomedia: ov7740: use SCCB regmap
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>
4 years agomedia: imx274: fix frame interval handling
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>
4 years agomedia: m5mols: Check function pointer in m5mols_sensor_power
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>
4 years agomedia: i2c: fix error check on max9286_read call
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>
4 years agomedia: omap: Replace HTTP links with HTTPS ones
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>
4 years agomedia: ov5640: Correct Bit Div register in clock tree diagram
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>
4 years agomedia: ipu3.rst: Format media-ctl and yavta commands as code blocks
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>
4 years agomedia: MAINTAINERS: ov5647: Replace maintainer
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>
4 years agomedia: dt-bindings: media: ov5647: Document clock-noncontinuous
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>
4 years agomedia: dt-bindings: media: ov5647: Document pwdn-gpios
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>
4 years agomedia: dt-bindings: media: ov5647: Convert to json-schema
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>
4 years agomedia: intel-ipu3: Fix code style issue
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>
4 years agomedia: MAINTAINERS: Fix email typo and correct name of Tianshu
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>
4 years agomedia: i2c: ov2740: get OTP data ready before nvmem registration
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>
4 years agomedia: radio: si476x: no need to check return value of debugfs_create functions
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>
4 years agomedia: sti: no need to check return value of debugfs_create functions
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>
4 years agomedia: mtk-vpu: no need to check return value of debugfs_create functions
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>
4 years agomedia: exynos4-is: no need to check return value of debugfs_create functions
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>
4 years agomedia: coda: no need to check return value of debugfs_create functions
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>
4 years agomedia: cec: no need to check return value of debugfs_create functions
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>
4 years agomedia: dt-bindings: media: Correct samsung-fimc parallel port numbering
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>
4 years agomedia: exynos4-is: Handle duplicate calls to vidioc_streamoff
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>
4 years agomedia: exynos4-is: Remove unused struct member input_index
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>
4 years agomedia: exynos4-is: Remove inh_sensor_ctrls
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>
4 years agomedia: exynos4-is: Add support for multiple sensors on one port
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>
4 years agomedia: exynos4-is: Use global num_sensors rather than local index
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>
4 years agomedia: exynos4-is: Properly set JPEG options for parallel ports
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>
4 years agomedia: exynos4-is: Correct missing entity function initialization
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>
4 years agomedia: exynos4-is: Fix nullptr when no CSIS device present
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>
4 years agomedia: exynos4-is: Request syscon only if ISP writeback is present
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>
4 years agomedia: exynos4-is: Remove static driver data for S5PV210 FIMC variants
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>
4 years agomedia: hantro: postproc: Fix motion vector space allocation
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>
4 years agomedia: hantro: h264: Get the correct fallback reference buffer
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>
4 years agotm6000: drop unnecessary list_empty
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>
4 years agosaa7134: drop unnecessary list_empty
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>
4 years agomedia: cx231xx: drop unnecessary list_empty
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>
4 years agomedia: Use fallthrough pseudo-keyword
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>
4 years agomedia: staging: rkisp1: uapi: remove __packed
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>
4 years agomedia: staging: rkisp1: params: don't release lock in isr before buffer is done
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>
4 years agomedia: staging: rkisp1: params: use rkisp1_param_set_bits to set reg in isr
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>
4 years agomedia: staging: rkisp1: call params isr only upon frame out
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>
4 years agomedia: staging: rkisp1: change type of fields in 'rkisp1_cif_isp_lsc_config' from...
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>
4 years agomedia: staging: rkisp1: replace two identical macros with one
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>
4 years agomedia: staging: rkisp1: set "*_data_tbl" fields in rkisp1_cif_isp_lsc_config as 2D...
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>
4 years agomedia: Documentation: v4l: move table of v4l2_pix_format(_mplane) flags to pixfmt...
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>
4 years agomedia: staging: rkisp1: improve documentation of rkisp1-common.h
Dafna Hirschfeld [Thu, 6 Aug 2020 10:34:17 +0000 (12:34 +0200)]
media: staging: rkisp1: improve documentation of rkisp1-common.h

Add more detailed documentation of the structs and functions
in rkisp1-common.h

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>
4 years agomedia: staging: rkisp1: group declaration of similar functions together
Dafna Hirschfeld [Thu, 6 Aug 2020 10:34:16 +0000 (12:34 +0200)]
media: staging: rkisp1: group declaration of similar functions together

In file rkisp1-common.h, group declaration of register/unregister
functions together and group other functions together to make
the code easier to read.

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>
4 years agomedia: staging: rkisp1: remove declaration of unimplemented function 'rkisp1_params_i...
Dafna Hirschfeld [Thu, 6 Aug 2020 10:34:15 +0000 (12:34 +0200)]
media: staging: rkisp1: remove declaration of unimplemented function 'rkisp1_params_isr_handler'

The file rkisp1-common.h has a function declarion
'rkisp1_params_isr_handler' that is not implemented.
Remove it.

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>
4 years agomedia: staging: rkisp1: unify (un)register functions to have the same parameters
Dafna Hirschfeld [Thu, 6 Aug 2020 10:34:14 +0000 (12:34 +0200)]
media: staging: rkisp1: unify (un)register functions to have the same parameters

The different register/unregister functions receive
different parameters. This patch unify them so they all receive just
'struct *rkisp1_device' as parameter.

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>
4 years agomedia: staging: rkisp1: don't define vaddr field in rkisp1_buffer as an array
Dafna Hirschfeld [Thu, 6 Aug 2020 10:34:13 +0000 (12:34 +0200)]
media: staging: rkisp1: don't define vaddr field in rkisp1_buffer as an array

The field vaddr in rkisp1_buffer struct is used only by the
rkisp1-stats and rkisp1-params entities and they both use only
vaddr[0] so there is no need to define this field as an array.

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>
4 years agomedia: staging: rkisp1: improve documentation in file rkisp1-config.h
Dafna Hirschfeld [Thu, 6 Aug 2020 11:50:33 +0000 (13:50 +0200)]
media: staging: rkisp1: improve documentation in file rkisp1-config.h

There is some missing documentation of structs and
fields in rkisp1-config.h. This patch improves the
documentation.

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>
4 years agomedia: staging: rkisp1: rename RKISP1_CIF_ISP_STAT_AFM_FIN to RKISP1_CIF_ISP_STAT_AFM
Dafna Hirschfeld [Thu, 6 Aug 2020 11:50:32 +0000 (13:50 +0200)]
media: staging: rkisp1: rename RKISP1_CIF_ISP_STAT_AFM_FIN to RKISP1_CIF_ISP_STAT_AFM

The flag RKISP1_CIF_ISP_STAT_AFM_FIN indicates userspace
that auto-focus measurements were collected. Therefore
the suffix _FIN in the flag's name does not fit.

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>
4 years agomedia: staging: rkisp1: replace 3 fields 'ct_offset_*' with one array
Dafna Hirschfeld [Thu, 6 Aug 2020 11:50:31 +0000 (13:50 +0200)]
media: staging: rkisp1: replace 3 fields 'ct_offset_*' with one array

The struct rkisp1_cif_isp_ctk_config contains 3 fields
ct_offset_{rgb}. Replace them with one array field 'ct_offset[3].

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>
4 years agomedia: staging: rkisp1: replace 9 coeff* fields with a 3x3 array
Dafna Hirschfeld [Thu, 6 Aug 2020 11:50:30 +0000 (13:50 +0200)]
media: staging: rkisp1: replace 9 coeff* fields with a 3x3 array

The struct rkisp1_cif_isp_ctk_config has 9 fields 'coeff*' for the
3x3 color correction matrix. Replace these fields with one 3x3
array coeff[3][3] and document the field.

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>
4 years agomedia: exynos4-is: Simplify the pinctrl code
Sylwester Nawrocki [Mon, 10 Aug 2020 15:32:40 +0000 (17:32 +0200)]
media: exynos4-is: Simplify the pinctrl code

There is no need to request the "idle" pinctrl state in the driver as that
is implemented in the driver core and the pinctrl_pm_* API can be used for
switching between the default and the idle state.

Simplify the pinctrl code to only request and check for the mandatory
"default" pinctrl state.

Switching between the default/idle pinctrl state is not yet implemented
in the driver and this patch doesn't change that.

Signed-off-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>
4 years agomedia: Revert "media: exynos4-is: Add missed check for pinctrl_lookup_state()"
Sylwester Nawrocki [Mon, 10 Aug 2020 15:32:39 +0000 (17:32 +0200)]
media: Revert "media: exynos4-is: Add missed check for pinctrl_lookup_state()"

The "idle" pinctrl state is optional as documented in the DT binding.
The change introduced by the commit being reverted makes that pinctrl state
mandatory and breaks initialization of the whole media driver, since the
"idle" state is not specified in any mainline dts.

This reverts commit 18ffec750578 ("media: exynos4-is: Add missed check for pinctrl_lookup_state()")
to fix the regression.

Fixes: 18ffec750578 ("media: exynos4-is: Add missed check for pinctrl_lookup_state()")
Signed-off-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>
4 years agomedia: camss: __video_try_fmt(): don't use hardcoded constants
Andrey Konovalov [Fri, 14 Aug 2020 20:54:03 +0000 (22:54 +0200)]
media: camss: __video_try_fmt(): don't use hardcoded constants

Use the definitions introduced by commit "media: camss: add support
for vidioc_enum_framesizes ioctl" instead of the hardcoded values.

Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
4 years agomedia: camss: add support for vidioc_enum_framesizes ioctl
Andrey Konovalov [Fri, 14 Aug 2020 20:54:02 +0000 (22:54 +0200)]
media: camss: add support for vidioc_enum_framesizes ioctl

VIDIOC_ENUM_FRAMESIZES support in the video capture driver is required by
libcamera. Without this change libcamera errors out with:
"ERROR V4L2 v4l2_videodevice.cpp:1059 /dev/video0[cap]: Unable to enumerate
frame sizes: Inappropriate ioctl for device"

Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
4 years agomedia: camss: Make use of V4L2_CAP_IO_MC
Andrey Konovalov [Fri, 14 Aug 2020 20:54:01 +0000 (22:54 +0200)]
media: camss: Make use of V4L2_CAP_IO_MC

Implement mbus_code filtering for format enumeration.

Without this patch libcamera errors out with:
"ERROR V4L2 v4l2_videodevice.cpp:982 /dev/video0[cap]: Media bus code
filtering not supported by the device"

Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
4 years agomedia: rcar-vin: Register media device when all sub-devices bound
Niklas Söderlund [Thu, 13 Aug 2020 21:06:02 +0000 (23:06 +0200)]
media: rcar-vin: Register media device when all sub-devices bound

The media device is not usable by userspace before all devices involved
in capture are present in the system. Move registering of the media
device to the async complete callback.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
4 years agomedia: rcar-vin: Unconditionally unregister notifier on remove
Niklas Söderlund [Thu, 13 Aug 2020 21:06:01 +0000 (23:06 +0200)]
media: rcar-vin: Unconditionally unregister notifier on remove

If the VIN device is part of a group of VIN devices (all Gen3 boards)
there is no reason to only unregister the group notifier if the VIN that
registers the notifier is removed. The VIN that registers the notifier
is always the last VIN device to be bound, so keeping the notifier
around after any VIN is unbound creates an unbalanced state where no VIN
in the group is operational.

Fix this by unconditionally unregistering the notifier when any VIN
device is unbound. Unregistering the notifier will lead to unbound()
being called and all video devices exposed by any VIN instance to be
removed.

The lock was only needed to protect the check which VIN registers the
notifier and is no longer needed.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
4 years agomedia: tw5864: check status of tw5864_frameinterval_get
Tom Rix [Mon, 10 Aug 2020 19:25:18 +0000 (21:25 +0200)]
media: tw5864: check status of tw5864_frameinterval_get

clang static analysis reports this problem

tw5864-video.c:773:32: warning: The left expression of the compound
  assignment is an uninitialized value.
  The computed value will also be garbage
        fintv->stepwise.max.numerator *= std_max_fps;
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^

stepwise.max is set with frameinterval, which comes from

ret = tw5864_frameinterval_get(input, &frameinterval);
fintv->stepwise.step = frameinterval;
fintv->stepwise.min = frameinterval;
fintv->stepwise.max = frameinterval;
fintv->stepwise.max.numerator *= std_max_fps;

When tw5864_frameinterval_get() fails, frameinterval is not
set. So check the status and fix another similar problem.

Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
4 years agomedia: MAINTAINERS: Remove broken bluecherry.net email
Ismael Luceno [Mon, 10 Aug 2020 19:17:55 +0000 (21:17 +0200)]
media: MAINTAINERS: Remove broken bluecherry.net email

Remove broken bluecherry.net email

Signed-off-by: Ismael Luceno <ismael@iodev.co.uk>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
4 years agomedia: mc-device.c: change media_device_request_alloc to match media_ioctl_info
Frederic Chen [Thu, 6 Aug 2020 15:58:22 +0000 (17:58 +0200)]
media: mc-device.c: change media_device_request_alloc to match media_ioctl_info

We modified the type of media_device_request_alloc()'s second
parameter from int* to void* so that it can match the interface
defined in struct media_ioctl_info.

[hverkuil: move #ifdef before variable to avoid compile warning]

Signed-off-by: Frederic Chen <frederic.chen@mediatek.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
4 years agomedia: staging: tegra-vde: Mark tegra_vde_runtime_suspend/resume as __maybe_unused
YueHaibing [Tue, 4 Aug 2020 01:41:37 +0000 (03:41 +0200)]
media: staging: tegra-vde: Mark tegra_vde_runtime_suspend/resume as __maybe_unused

If CONFIG_PM is not set, gcc warns:

drivers/staging/media/tegra-vde/vde.c:916:12:
 warning: 'tegra_vde_runtime_suspend' defined but not used [-Wunused-function]

Make it __maybe_unused to fix this.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
4 years agomedia: ttusb-dec: convert tasklets to use new tasklet_setup() API
Allen Pais [Mon, 17 Aug 2020 08:31:53 +0000 (10:31 +0200)]
media: ttusb-dec: convert tasklets to use new tasklet_setup() API

In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.

Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
4 years agomedia: media/radio: wl128x: convert tasklets to use new tasklet_setup() API
Allen Pais [Mon, 17 Aug 2020 08:31:52 +0000 (10:31 +0200)]
media: media/radio: wl128x: convert tasklets to use new tasklet_setup() API

In preparation for unconditionally passing the
struct tasklet_struct pointer to all tasklet
callbacks, switch to using the new tasklet_setup()
and from_tasklet() to pass the tasklet pointer explicitly.

Signed-off-by: Romain Perier <romain.perier@gmail.com>
Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>