Re: [PATCH v2 2/3] media: usb: pvrusb2: Fix Wcast-function-type-strict warnings

2024-02-28 Thread Hans Verkuil
On 26/02/2024 18:32, Ricardo Ribalda wrote:
> Building with LLVM=1 throws the following warning:
> drivers/media/usb/pvrusb2/pvrusb2-context.c:110:6: warning: cast from 'void 
> (*)(struct pvr2_context *)' to 'void (*)(void *)' converts to incompatible 
> function type [-Wcast-function-type-strict]
> drivers/media/usb/pvrusb2/pvrusb2-v4l2.c:1070:30: warning: cast from 'void 
> (*)(struct pvr2_v4l2_fh *)' to 'pvr2_stream_callback' (aka 'void (*)(void 
> *)') converts to incompatible function type [-Wcast-function-type-strict] 
> drivers/media/usb/pvrusb2/pvrusb2-dvb.c:152:6: warning: cast from 'void 
> (*)(struct pvr2_dvb_adapter *)' to 'pvr2_stream_callback' (aka 'void (*)(void 
> *)') converts to incompatible function type [-Wcast-function-type-strict]

This patch from Arnd has already been merged, superseding your patch:

https://lore.kernel.org/linux-media/20240213100439.457403-1-a...@kernel.org/

Marking your patch as Obsolete in patchwork.

Regards,

Hans

> 
> Reviewed-by: Nathan Chancellor 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/pvrusb2/pvrusb2-context.c | 5 +++--
>  drivers/media/usb/pvrusb2/pvrusb2-dvb.c | 7 ---
>  drivers/media/usb/pvrusb2/pvrusb2-v4l2.c| 7 ---
>  3 files changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-context.c 
> b/drivers/media/usb/pvrusb2/pvrusb2-context.c
> index 1764674de98bc..16edabda191c4 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-context.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-context.c
> @@ -90,8 +90,9 @@ static void pvr2_context_destroy(struct pvr2_context *mp)
>  }
>  
>  
> -static void pvr2_context_notify(struct pvr2_context *mp)
> +static void pvr2_context_notify(void *data)
>  {
> + struct pvr2_context *mp = data;
>   pvr2_context_set_notify(mp,!0);
>  }
>  
> @@ -107,7 +108,7 @@ static void pvr2_context_check(struct pvr2_context *mp)
>  "pvr2_context %p (initialize)", mp);
>   /* Finish hardware initialization */
>   if (pvr2_hdw_initialize(mp->hdw,
> - (void (*)(void *))pvr2_context_notify,
> + pvr2_context_notify,
>   mp)) {
>   mp->video_stream.stream =
>   pvr2_hdw_get_video_stream(mp->hdw);
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-dvb.c 
> b/drivers/media/usb/pvrusb2/pvrusb2-dvb.c
> index 26811efe0fb58..8b9f1a09bd53d 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-dvb.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-dvb.c
> @@ -88,8 +88,9 @@ static int pvr2_dvb_feed_thread(void *data)
>   return stat;
>  }
>  
> -static void pvr2_dvb_notify(struct pvr2_dvb_adapter *adap)
> +static void pvr2_dvb_notify(void *data)
>  {
> + struct pvr2_dvb_adapter *adap = data;
>   wake_up(>buffer_wait_data);
>  }
>  
> @@ -148,8 +149,8 @@ static int pvr2_dvb_stream_do_start(struct 
> pvr2_dvb_adapter *adap)
>   if (!(adap->buffer_storage[idx])) return -ENOMEM;
>   }
>  
> - pvr2_stream_set_callback(pvr->video_stream.stream,
> -  (pvr2_stream_callback) pvr2_dvb_notify, adap);
> + pvr2_stream_set_callback(pvr->video_stream.stream, pvr2_dvb_notify,
> +  adap);
>  
>   ret = pvr2_stream_set_buffer_count(stream, PVR2_DVB_BUFFER_COUNT);
>   if (ret < 0) return ret;
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c 
> b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> index c04ab7258d645..590f80949bbfc 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> @@ -1032,9 +1032,10 @@ static int pvr2_v4l2_open(struct file *file)
>   return 0;
>  }
>  
> -
> -static void pvr2_v4l2_notify(struct pvr2_v4l2_fh *fhp)
> +static void pvr2_v4l2_notify(void *data)
>  {
> + struct pvr2_v4l2_fh *fhp = data;
> +
>   wake_up(>wait_data);
>  }
>  
> @@ -1067,7 +1068,7 @@ static int pvr2_v4l2_iosetup(struct pvr2_v4l2_fh *fh)
>  
>   hdw = fh->channel.mc_head->hdw;
>   sp = fh->pdi->stream->stream;
> - pvr2_stream_set_callback(sp,(pvr2_stream_callback)pvr2_v4l2_notify,fh);
> + pvr2_stream_set_callback(sp, pvr2_v4l2_notify, fh);
>   pvr2_hdw_set_stream_type(hdw,fh->pdi->config);
>   if ((ret = pvr2_hdw_set_streaming(hdw,!0)) < 0) return ret;
>   return pvr2_ioread_set_enabled(fh->rhp,!0);
> 




Re: [PATCH v2 1/3] media: pci: sta2x11: Fix Wcast-function-type-strict warnings

2024-02-27 Thread Hans Verkuil
On 26/02/2024 18:32, Ricardo Ribalda wrote:
> Building with LLVM=1 throws the following warning:
> drivers/media/pci/sta2x11/sta2x11_vip.c:1057:6: warning: cast from 
> 'irqreturn_t (*)(int, struct sta2x11_vip *)' (aka 'enum irqreturn (*)(int, 
> struct sta2x11_vip *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void 
> *)') converts to incompatible function type [-Wcast-function-type-strict]
> 
> Reviewed-by: Nathan Chancellor 
> Signed-off-by: Ricardo Ribalda 

Arnd's patch for this has already been merged:

https://lore.kernel.org/linux-media/20240213095451.454142-1-a...@kernel.org/

So I'm marking your patch as 'Obsolete' in patchwork.

Regards,

Hans

> ---
>  drivers/media/pci/sta2x11/sta2x11_vip.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/pci/sta2x11/sta2x11_vip.c 
> b/drivers/media/pci/sta2x11/sta2x11_vip.c
> index e4cf9d63e926d..a6456673be3f6 100644
> --- a/drivers/media/pci/sta2x11/sta2x11_vip.c
> +++ b/drivers/media/pci/sta2x11/sta2x11_vip.c
> @@ -757,7 +757,7 @@ static const struct video_device video_dev_template = {
>  /**
>   * vip_irq - interrupt routine
>   * @irq: Number of interrupt ( not used, correct number is assumed )
> - * @vip: local data structure containing all information
> + * @data: local data structure containing all information
>   *
>   * check for both frame interrupts set ( top and bottom ).
>   * check FIFO overflow, but limit number of log messages after open.
> @@ -767,8 +767,9 @@ static const struct video_device video_dev_template = {
>   *
>   * IRQ_HANDLED, interrupt done.
>   */
> -static irqreturn_t vip_irq(int irq, struct sta2x11_vip *vip)
> +static irqreturn_t vip_irq(int irq, void *data)
>  {
> + struct sta2x11_vip *vip = data;
>   unsigned int status;
>  
>   status = reg_read(vip, DVP_ITS);
> 




Re: [PATCH v2 3/3] media: mediatek: vcodedc: Fix Wcast-function-type-strict warnings

2024-02-27 Thread Hans Verkuil
Ricardo,

First of all, note the typo in theo subject line: vcodedc -> vcodec.

There is also a similar (but not identical!) patch from Arnd:

https://patchwork.linuxtv.org/project/linux-media/patch/20240224121059.1806691-1-a...@kernel.org/

That patch and yours share the change to common/mtk_vcodec_fw_vpu.c but 
otherwise
they are different, which is a bit odd.

Can you take a look at Arnd's patch and see if you need to incorporate his 
changes
into your patch?

Regards,

Hans

On 26/02/2024 18:32, Ricardo Ribalda wrote:
> Building with LLVM=1 throws the following warning:
> drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c:38:32: 
> warning: cast from 'mtk_vcodec_ipi_handler' (aka 'void (*)(void *, unsigned 
> int, void *)') to 'ipi_handler_t' (aka 'void (*)(const void *, unsigned int, 
> void *)') converts to incompatible function type [-Wcast-function-type-strict]
> 
> Constify the types to avoid the warning.
> 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/platform/mediatek/mdp3/mtk-mdp3-vpu.c  | 12 
> ++--
>  .../media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h|  2 +-
>  .../platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c  | 10 +-
>  drivers/media/platform/mediatek/vcodec/decoder/vdec_vpu_if.c |  2 +-
>  drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c |  2 +-
>  drivers/remoteproc/mtk_scp.c |  4 ++--
>  include/linux/remoteproc/mtk_scp.h   |  2 +-
>  include/linux/rpmsg/mtk_rpmsg.h  |  2 +-
>  8 files changed, 14 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-vpu.c 
> b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-vpu.c
> index 49fc2e9d45dd5..c4f1c49b9d52a 100644
> --- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-vpu.c
> +++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-vpu.c
> @@ -77,10 +77,10 @@ void mdp_vpu_shared_mem_free(struct mdp_vpu_dev *vpu)
>   dma_free_wc(dev, vpu->config_size, vpu->config, 
> vpu->config_addr);
>  }
>  
> -static void mdp_vpu_ipi_handle_init_ack(void *data, unsigned int len,
> +static void mdp_vpu_ipi_handle_init_ack(const void *data, unsigned int len,
>   void *priv)
>  {
> - struct mdp_ipi_init_msg *msg = (struct mdp_ipi_init_msg *)data;
> + const struct mdp_ipi_init_msg *msg = data;
>   struct mdp_vpu_dev *vpu =
>   (struct mdp_vpu_dev *)(unsigned long)msg->drv_data;
>  
> @@ -91,10 +91,10 @@ static void mdp_vpu_ipi_handle_init_ack(void *data, 
> unsigned int len,
>   complete(>ipi_acked);
>  }
>  
> -static void mdp_vpu_ipi_handle_deinit_ack(void *data, unsigned int len,
> +static void mdp_vpu_ipi_handle_deinit_ack(const void *data, unsigned int len,
> void *priv)
>  {
> - struct mdp_ipi_deinit_msg *msg = (struct mdp_ipi_deinit_msg *)data;
> + const struct mdp_ipi_deinit_msg *msg = data;
>   struct mdp_vpu_dev *vpu =
>   (struct mdp_vpu_dev *)(unsigned long)msg->drv_data;
>  
> @@ -102,10 +102,10 @@ static void mdp_vpu_ipi_handle_deinit_ack(void *data, 
> unsigned int len,
>   complete(>ipi_acked);
>  }
>  
> -static void mdp_vpu_ipi_handle_frame_ack(void *data, unsigned int len,
> +static void mdp_vpu_ipi_handle_frame_ack(const void *data, unsigned int len,
>void *priv)
>  {
> - struct img_sw_addr *addr = (struct img_sw_addr *)data;
> + const struct img_sw_addr *addr = data;
>   struct img_ipi_frameparam *param =
>   (struct img_ipi_frameparam *)(unsigned long)addr->va;
>   struct mdp_vpu_dev *vpu =
> diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h 
> b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> index 300363a40158c..2561b99c95871 100644
> --- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> +++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> @@ -23,7 +23,7 @@ enum mtk_vcodec_fw_use {
>  
>  struct mtk_vcodec_fw;
>  
> -typedef void (*mtk_vcodec_ipi_handler) (void *data,
> +typedef void (*mtk_vcodec_ipi_handler) (const void *data,
>   unsigned int len, void *priv);
>  
>  struct mtk_vcodec_fw *mtk_vcodec_fw_select(void *priv, enum 
> mtk_vcodec_fw_type type,
> diff --git 
> a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c 
> b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c
> index 9f6e4b59455da..4c34344dc7dcb 100644
> --- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c
> +++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vpu.c
> @@ -29,15 +29,7 @@ static int mtk_vcodec_vpu_set_ipi_register(struct 
> mtk_vcodec_fw *fw, int id,
>  mtk_vcodec_ipi_handler handler,
>  const char *name, void *priv)
>  {
> - 

Re: [PATCH] visl: use canonical ftrace path

2023-10-04 Thread Hans Verkuil
On 10/4/23 15:57, Steven Rostedt wrote:
> On Wed, 4 Oct 2023 08:33:12 +0200
> Hans Verkuil  wrote:
> 
>> On 03/10/2023 23:41, Steven Rostedt wrote:
>>>
>>> Could this go through the linux-media tree, or if you give it an Ack, I'll
>>> take it through the tracing tree.  
>>
>> I prefer to take this through the media subsystem. Ross, can you post this
> 
> Thanks!
> 
>> patch again, this time including linux-me...@vger.kernel.org?
> 
> The original patch did have linux-me...@vger.kernel.org Cc'd. Was it dropped?

You are correct, it was sitting in patchwork, I somehow missed it.

It's now delegated to me, so it is in my pipeline.

Regards,

Hans

> 
> -- Steve
> 
> 
>>
>> The patch looks fine, so I'll pick it up.
>>
>> Regards,
>>
>>  Hans




Re: [PATCH] visl: use canonical ftrace path

2023-10-04 Thread Hans Verkuil
On 03/10/2023 23:41, Steven Rostedt wrote:
> 
> Could this go through the linux-media tree, or if you give it an Ack, I'll
> take it through the tracing tree.

I prefer to take this through the media subsystem. Ross, can you post this
patch again, this time including linux-me...@vger.kernel.org?

The patch looks fine, so I'll pick it up.

Regards,

Hans

> 
> -- Steve
> 
> 
> On Tue, 29 Aug 2023 14:46:01 -0600
> Ross Zwisler  wrote:
> 
>> From: Ross Zwisler 
>>
>> The canonical location for the tracefs filesystem is at /sys/kernel/tracing.
>>
>> But, from Documentation/trace/ftrace.rst:
>>
>>   Before 4.1, all ftrace tracing control files were within the debugfs
>>   file system, which is typically located at /sys/kernel/debug/tracing.
>>   For backward compatibility, when mounting the debugfs file system,
>>   the tracefs file system will be automatically mounted at:
>>
>>   /sys/kernel/debug/tracing
>>
>> Update the visl decoder driver documentation to use this tracefs path.
>>
>> Signed-off-by: Ross Zwisler 
>> ---
>>  Documentation/admin-guide/media/visl.rst | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/media/visl.rst 
>> b/Documentation/admin-guide/media/visl.rst
>> index 7d2dc78341c9..4328c6c72d30 100644
>> --- a/Documentation/admin-guide/media/visl.rst
>> +++ b/Documentation/admin-guide/media/visl.rst
>> @@ -78,7 +78,7 @@ The trace events are defined on a per-codec basis, e.g.:
>>  
>>  .. code-block:: bash
>>  
>> -$ ls /sys/kernel/debug/tracing/events/ | grep visl
>> +$ ls /sys/kernel/tracing/events/ | grep visl
>>  visl_fwht_controls
>>  visl_h264_controls
>>  visl_hevc_controls
>> @@ -90,13 +90,13 @@ For example, in order to dump HEVC SPS data:
>>  
>>  .. code-block:: bash
>>  
>> -$ echo 1 >  
>> /sys/kernel/debug/tracing/events/visl_hevc_controls/v4l2_ctrl_hevc_sps/enable
>> +$ echo 1 >  
>> /sys/kernel/tracing/events/visl_hevc_controls/v4l2_ctrl_hevc_sps/enable
>>  
>>  The SPS data will be dumped to the trace buffer, i.e.:
>>  
>>  .. code-block:: bash
>>  
>> -$ cat /sys/kernel/debug/tracing/trace
>> +$ cat /sys/kernel/tracing/trace
>>  video_parameter_set_id 0
>>  seq_parameter_set_id 0
>>  pic_width_in_luma_samples 1920
> 




Re: [PATCH 1/6] staging: media: atomisp: improve function argument alignment

2021-04-20 Thread Hans Verkuil
On 20/04/2021 19:19, Deepak R Varma wrote:
> On Tue, Apr 20, 2021 at 03:24:32PM +0200, Hans Verkuil wrote:
>> On 19/04/2021 21:12, Deepak R Varma wrote:
>>> Improve multi-line function argument alignment according to the code style
>>> guidelines. Resolves checkpatch feedback: "Alignment should match
>>> open parenthesis".
>>>
>>> Signed-off-by: Deepak R Varma 
>>
>> WARNING: From:/Signed-off-by: email address mismatch: 'From: Deepak R Varma 
>> ' != 'Signed-off-by: Deepak R Varma
>> '
>>
>> Which email should I use? Ideally you should post from the same email
>> as the Signed-off-by.
> 
> I am really sorry for this. I was trying to set up mutt to handle both
> my accounts and guess that led to this issue. I will resubmit the patch
> set with the appropriate email match. Will that be okay?

It is sufficient to just let me know which email I should use. I can edit
it so it shows the correct author email.

Regards,

Hans

> 
> Thank you,
> deepak.
> 
>>
>> Regards,
>>
>>  Hans
>>
>>> ---
>>>  drivers/staging/media/atomisp/i2c/atomisp-gc0310.c | 4 ++--
>>>  drivers/staging/media/atomisp/i2c/atomisp-gc2235.c | 4 ++--
>>>  drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 4 ++--
>>>  3 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c 
>>> b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
>>> index 2b71de722ec3..6be3ee1d93a5 100644
>>> --- a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
>>> +++ b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
>>> @@ -192,8 +192,8 @@ static int __gc0310_buf_reg_array(struct i2c_client 
>>> *client,
>>>  }
>>>  
>>>  static int __gc0310_write_reg_is_consecutive(struct i2c_client *client,
>>> -   struct gc0310_write_ctrl *ctrl,
>>> -   const struct gc0310_reg *next)
>>> +struct gc0310_write_ctrl *ctrl,
>>> +const struct gc0310_reg *next)
>>>  {
>>> if (ctrl->index == 0)
>>> return 1;
>>> diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c 
>>> b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
>>> index 78147ffb6099..6ba4a8adff7c 100644
>>> --- a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
>>> +++ b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
>>> @@ -171,8 +171,8 @@ static int __gc2235_buf_reg_array(struct i2c_client 
>>> *client,
>>>  }
>>>  
>>>  static int __gc2235_write_reg_is_consecutive(struct i2c_client *client,
>>> -   struct gc2235_write_ctrl *ctrl,
>>> -   const struct gc2235_reg *next)
>>> +struct gc2235_write_ctrl *ctrl,
>>> +const struct gc2235_reg *next)
>>>  {
>>> if (ctrl->index == 0)
>>> return 1;
>>> diff --git a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c 
>>> b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
>>> index eecefcd734d0..aec7392fd1de 100644
>>> --- a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
>>> +++ b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
>>> @@ -212,8 +212,8 @@ static int __ov2722_buf_reg_array(struct i2c_client 
>>> *client,
>>>  }
>>>  
>>>  static int __ov2722_write_reg_is_consecutive(struct i2c_client *client,
>>> -   struct ov2722_write_ctrl *ctrl,
>>> -   const struct ov2722_reg *next)
>>> +struct ov2722_write_ctrl *ctrl,
>>> +const struct ov2722_reg *next)
>>>  {
>>> if (ctrl->index == 0)
>>> return 1;
>>>
>>



Re: [PATCH 0/2] drm/bridge: dw-hdmi: disable loading of DW-HDMI CEC sub-driver

2021-04-20 Thread Hans Verkuil
On 16/04/2021 13:38, Neil Armstrong wrote:
> On 16/04/2021 11:58, Laurent Pinchart wrote:
>> Hi Neil,
>>
>> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
>>> This adds DW-HDMI driver a glue option to disable loading of the CEC 
>>> sub-driver.
>>>
>>> On some SoCs, the CEC functionality is enabled in the IP config bits, but 
>>> the
>>> CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is 
>>> set
>>> but the DW-HDMI CEC signal is not connected to a physical pin, leading to 
>>> some
>>> confusion when the DW-HDMI CEC controller can't communicate on the bus.
>>
>> If we can't trust the CEC config bit, would it be better to not use it
>> at all, and instead let each platform glue logic tell whether to enable
>> CEC or not ?
> 
> Actually, the CEC config bit is right, the HW exists and should be 
> functional, but
> this bit doesn't tell if the CEC signal is connected to something.
> 
> This lies in the IP integration, like other bits under the 
> "amlogic,meson-*-dw-hdmi"
> umbrella.
> 
> The first attempt was by Hans using DT, but adding a property in DT for a 
> vendor
> specific compatible doesn't make sense. Another idea would be to describe the
> CEC signal endpoint like we do for video signal, but I think this is out of 
> scope and
> this solution is much simpler and straightforward, and it's more an exception 
> than
> a general use case to solve.

While a DT property might not make sense in this particular case, I still
believe that it is a perfectly valid approach in general: whether or not
the CEC pin is connected is at the hardware level decision, it is not
something that software can detect. If the designer of the board didn't
connect it, then the only place you can define that is in the device tree.

Anyway, for meson I am fine with this solution. At least it prevents creating
a non-functioning cec device. So for this series:

Acked-by: Hans Verkuil 

Regards,

Hans

> 
> Neil
> 
>>
>>> Jernej Skrabec (1):
>>>   drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC
>>> driver
>>>
>>> Neil Armstrong (1):
>>>   drm/meson: dw-hdmi: disable DW-HDMI CEC sub-driver
>>>
>>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>>>  drivers/gpu/drm/meson/meson_dw_hdmi.c | 1 +
>>>  include/drm/bridge/dw_hdmi.h  | 2 ++
>>>  3 files changed, 4 insertions(+), 1 deletion(-)
>>>
>>
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 



Re: [PATCH 5/6] staging: media: atomisp: fix CamelCase variable naming

2021-04-20 Thread Hans Verkuil
On 20/04/2021 10:39, Fabio Aiuto wrote:
> Hi,
> 
> On Tue, Apr 20, 2021 at 12:45:57AM +0530, Deepak R Varma wrote:
>> Mixed case variable names are discouraged and they result in checkpatch
>> script "Avoid CamelCase" warnings. Replace such CamelCase variable names
>> by lower case strings according to the coding style guidelines.
>>
>> Signed-off-by: Deepak R Varma 
>> ---
>>  .../media/atomisp/i2c/atomisp-mt9m114.c   | 62 +--
>>  1 file changed, 31 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c 
>> b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
>> index 160bb58ce708..e63906a69e30 100644
>> --- a/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
>> +++ b/drivers/staging/media/atomisp/i2c/atomisp-mt9m114.c
>> @@ -999,10 +999,10 @@ static long mt9m114_s_exposure(struct v4l2_subdev *sd,
>>  struct mt9m114_device *dev = to_mt9m114_sensor(sd);
>>  int ret = 0;
>>  unsigned int coarse_integration = 0;
>> -unsigned int FLines = 0;
>> -unsigned int FrameLengthLines = 0; /* ExposureTime.FrameLengthLines; */
>> -unsigned int AnalogGain, DigitalGain;
>> -u32 AnalogGainToWrite = 0;
>> +unsigned int f_lines = 0;
>> +unsigned int frame_len_lines = 0; /* ExposureTime.FrameLengthLines; */
>> +unsigned int analog_gain, digital_gain;
>> +u32 analog_gain_to_write = 0;
>>
> 
> this patch is made of multiple logical changes, i.e. more than one
> variable at a time are renamed. Maybe this should be split in
> one patch per variable name.

I'm OK with this, it's pretty readable and obvious what is going on.

Regards,

Hans


Re: [PATCH 1/6] staging: media: atomisp: improve function argument alignment

2021-04-20 Thread Hans Verkuil
On 19/04/2021 21:12, Deepak R Varma wrote:
> Improve multi-line function argument alignment according to the code style
> guidelines. Resolves checkpatch feedback: "Alignment should match
> open parenthesis".
> 
> Signed-off-by: Deepak R Varma 

WARNING: From:/Signed-off-by: email address mismatch: 'From: Deepak R Varma 
' != 'Signed-off-by: Deepak R Varma
'

Which email should I use? Ideally you should post from the same email
as the Signed-off-by.

Regards,

Hans

> ---
>  drivers/staging/media/atomisp/i2c/atomisp-gc0310.c | 4 ++--
>  drivers/staging/media/atomisp/i2c/atomisp-gc2235.c | 4 ++--
>  drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c 
> b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
> index 2b71de722ec3..6be3ee1d93a5 100644
> --- a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
> +++ b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
> @@ -192,8 +192,8 @@ static int __gc0310_buf_reg_array(struct i2c_client 
> *client,
>  }
>  
>  static int __gc0310_write_reg_is_consecutive(struct i2c_client *client,
> - struct gc0310_write_ctrl *ctrl,
> - const struct gc0310_reg *next)
> +  struct gc0310_write_ctrl *ctrl,
> +  const struct gc0310_reg *next)
>  {
>   if (ctrl->index == 0)
>   return 1;
> diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c 
> b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
> index 78147ffb6099..6ba4a8adff7c 100644
> --- a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
> +++ b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
> @@ -171,8 +171,8 @@ static int __gc2235_buf_reg_array(struct i2c_client 
> *client,
>  }
>  
>  static int __gc2235_write_reg_is_consecutive(struct i2c_client *client,
> - struct gc2235_write_ctrl *ctrl,
> - const struct gc2235_reg *next)
> +  struct gc2235_write_ctrl *ctrl,
> +  const struct gc2235_reg *next)
>  {
>   if (ctrl->index == 0)
>   return 1;
> diff --git a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c 
> b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
> index eecefcd734d0..aec7392fd1de 100644
> --- a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
> +++ b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
> @@ -212,8 +212,8 @@ static int __ov2722_buf_reg_array(struct i2c_client 
> *client,
>  }
>  
>  static int __ov2722_write_reg_is_consecutive(struct i2c_client *client,
> - struct ov2722_write_ctrl *ctrl,
> - const struct ov2722_reg *next)
> +  struct ov2722_write_ctrl *ctrl,
> +  const struct ov2722_reg *next)
>  {
>   if (ctrl->index == 0)
>   return 1;
> 



Re: [PATCH v2] staging: media: atomisp: pci: Change line break to avoid an open parenthesis at the end of the line

2021-04-20 Thread Hans Verkuil
On 15/04/2021 19:08, Aline Santana Cordeiro wrote:
> Change line break to avoid an open parenthesis at the end of the line.
> It consequently removed spaces at the start of the subsequent line.
> Both issues detected by checkpatch.pl.
> 
> Signed-off-by: Aline Santana Cordeiro 
> ---
> 
> Changes since v1:
>  - Keep the * with the function return type 
>instead of left it with the function name
> 
>  drivers/staging/media/atomisp/pci/atomisp_cmd.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.h 
> b/drivers/staging/media/atomisp/pci/atomisp_cmd.h
> index 1c0d464..e2b36fa 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp_cmd.h
> +++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.h
> @@ -75,8 +75,8 @@ void atomisp_wdt(struct timer_list *t);
>  void atomisp_setup_flash(struct atomisp_sub_device *asd);
>  irqreturn_t atomisp_isr(int irq, void *dev);
>  irqreturn_t atomisp_isr_thread(int irq, void *isp_ptr);
> -const struct atomisp_format_bridge *get_atomisp_format_bridge_from_mbus(
> -u32 mbus_code);
> +const struct atomisp_format_bridge*

Keep the space before the *!

Regards,

Hans

> +get_atomisp_format_bridge_from_mbus(u32 mbus_code);
>  bool atomisp_is_mbuscode_raw(uint32_t code);
>  int atomisp_get_frame_pgnr(struct atomisp_device *isp,
>  const struct ia_css_frame *frame, u32 *p_pgnr);
> @@ -381,9 +381,9 @@ enum mipi_port_id __get_mipi_port(struct atomisp_device 
> *isp,
>  
>  bool atomisp_is_vf_pipe(struct atomisp_video_pipe *pipe);
>  
> -void atomisp_apply_css_parameters(
> -struct atomisp_sub_device *asd,
> -struct atomisp_css_params *css_param);
> +void atomisp_apply_css_parameters(struct atomisp_sub_device *asd,
> +   struct atomisp_css_params *css_param);
> +
>  void atomisp_free_css_parameters(struct atomisp_css_params *css_param);
>  
>  void atomisp_handle_parameter_and_buffer(struct atomisp_video_pipe *pipe);
> 



Re: [PATCH] media: atomisp: silence "dubious: !x | !y" warning

2021-04-20 Thread Hans Verkuil
Hi Ashish,

On 18/04/2021 03:26, Ashish Kalra wrote:
> On Sat, Apr 17, 2021 at 08:56:13PM +0200, Mauro Carvalho Chehab wrote:
>> Em Sat, 17 Apr 2021 21:06:27 +0530
>> Ashish Kalra  escreveu:
>>
>>> Upon running sparse, "warning: dubious: !x | !y" is brought to notice
>>> for this file.  Logical and bitwise OR are basically the same in this
>>> context so it doesn't cause a runtime bug.  But let's change it to
>>> logical OR to make it cleaner and silence the Sparse warning.
>>>
>>> Signed-off-by: Ashish Kalra 
>>> ---
>>>  .../media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c| 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git 
>>> a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c 
>>> b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c
>>> index 358cb7d2cd4c..3b850bb2d39d 100644
>>> --- 
>>> a/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c
>>> +++ 
>>> b/drivers/staging/media/atomisp/pci/isp/kernels/vf/vf_1.0/ia_css_vf.host.c
>>> @@ -58,7 +58,7 @@ sh_css_vf_downscale_log2(
>>> unsigned int ds_log2 = 0;
>>> unsigned int out_width;
>>>  
>>> -   if ((!out_info) | (!vf_info))
>>> +   if ((!out_info) || (!vf_info))
>>
>>
>> While here, please get rid of the unneeded parenthesis:
>>
>>  if (!out_info || !vf_info)
>>
>>
>>> return -EINVAL;
>>>  
>>> out_width = out_info->res.width;
>>
>>
>>
>> Thanks,
>> Mauro
> Updated Patch as per your feedback

Please don't post patches as an attachment. Just post it inline as you did the
first time, but with Subject prefix [PATCHv2].

Thanks!

Hans


Re: [PATCH v9 03/13] media: hantro: Use syscon instead of 'ctrl' register

2021-04-20 Thread Hans Verkuil
On 20/04/2021 11:31, Benjamin Gaignard wrote:
> 
> Le 20/04/2021 à 11:16, Hans Verkuil a écrit :
>> On 20/04/2021 11:10, Benjamin Gaignard wrote:
>>> Le 16/04/2021 à 17:14, Lucas Stach a écrit :
>>>> Am Freitag, dem 16.04.2021 um 15:08 +0200 schrieb Benjamin Gaignard:
>>>>> Le 16/04/2021 à 12:54, Lucas Stach a écrit :
>>>>>> Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
>>>>>>> In order to be able to share the control hardware block between
>>>>>>> VPUs use a syscon instead a ioremap it in the driver.
>>>>>>> To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
>>>>>>> phandle is not found look at 'ctrl' reg-name.
>>>>>>> With the method it becomes useless to provide a list of register
>>>>>>> names so remove it.
>>>>>> Sorry for putting a spoke in the wheel after many iterations of the
>>>>>> series.
>>>>>>
>>>>>> We just discussed a way forward on how to handle the clocks and resets
>>>>>> provided by the blkctl block on i.MX8MM and later and it seems there is
>>>>>> a consensus on trying to provide virtual power domains from a blkctl
>>>>>> driver, controlling clocks and resets for the devices in the power
>>>>>> domain. I would like to avoid introducing yet another way of handling
>>>>>> the blkctl and thus would like to align the i.MX8MQ VPU blkctl with
>>>>>> what we are planning to do on the later chip generations.
>>>>>>
>>>>>> CC'ing Jacky Bai and Peng Fan from NXP, as they were going to give this
>>>>>> virtual power domain thing a shot.
>>>>> That could replace the 3 first patches and Dt patche of this series
>>>>> but that will not impact the hevc part, so I wonder if pure hevc patches
>>>>> could be merged anyway ?
>>>>> They are reviewed and don't depend of how the ctrl block is managed.
>>>> I'm not really in a position to give any informed opinion about that
>>>> hvec patches, as I only skimmed them, but I don't see any reason to
>>>> delay patches 04-11 from this series until the i.MX8M platform issues
>>>> are sorted. AFAICS those things are totally orthogonal.
>>> Hi Hans,
>>> What do you think about this proposal to split this series ?
>>> Get hevc part merged could allow me to continue to add features
>>> like scaling lists, compressed reference buffers and 10-bit supports.
>> Makes sense to me!
> 
> Great !
> If the latest version match your expectations how would you like to processed 
> ?
> Can you merged patches 4 to 12 ? or should I resend them in a new shorted 
> series ?

A separate patch series would be easier for me.

Regards,

Hans

> 
> Regards,
> Benjamin
> 
>>
>> Regards,
>>
>>  Hans
>>



Re: [PATCH v9 03/13] media: hantro: Use syscon instead of 'ctrl' register

2021-04-20 Thread Hans Verkuil
On 20/04/2021 11:10, Benjamin Gaignard wrote:
> 
> Le 16/04/2021 à 17:14, Lucas Stach a écrit :
>> Am Freitag, dem 16.04.2021 um 15:08 +0200 schrieb Benjamin Gaignard:
>>> Le 16/04/2021 à 12:54, Lucas Stach a écrit :
 Am Mittwoch, dem 07.04.2021 um 09:35 +0200 schrieb Benjamin Gaignard:
> In order to be able to share the control hardware block between
> VPUs use a syscon instead a ioremap it in the driver.
> To keep the compatibility with older DT if 'nxp,imx8mq-vpu-ctrl'
> phandle is not found look at 'ctrl' reg-name.
> With the method it becomes useless to provide a list of register
> names so remove it.
 Sorry for putting a spoke in the wheel after many iterations of the
 series.

 We just discussed a way forward on how to handle the clocks and resets
 provided by the blkctl block on i.MX8MM and later and it seems there is
 a consensus on trying to provide virtual power domains from a blkctl
 driver, controlling clocks and resets for the devices in the power
 domain. I would like to avoid introducing yet another way of handling
 the blkctl and thus would like to align the i.MX8MQ VPU blkctl with
 what we are planning to do on the later chip generations.

 CC'ing Jacky Bai and Peng Fan from NXP, as they were going to give this
 virtual power domain thing a shot.
>>> That could replace the 3 first patches and Dt patche of this series
>>> but that will not impact the hevc part, so I wonder if pure hevc patches
>>> could be merged anyway ?
>>> They are reviewed and don't depend of how the ctrl block is managed.
>> I'm not really in a position to give any informed opinion about that
>> hvec patches, as I only skimmed them, but I don't see any reason to
>> delay patches 04-11 from this series until the i.MX8M platform issues
>> are sorted. AFAICS those things are totally orthogonal.
> 
> Hi Hans,
> What do you think about this proposal to split this series ?
> Get hevc part merged could allow me to continue to add features
> like scaling lists, compressed reference buffers and 10-bit supports.

Makes sense to me!

Regards,

Hans


Re: [PATCH] staging: media: atomisp: pci: Change line break to avoid an open parenthesis at the end of the line

2021-04-15 Thread Hans Verkuil
On 14/04/2021 22:56, Aline Santana Cordeiro wrote:
> Change line break to avoid an open parenthesis at the end of the line.
> It consequently removed spaces at the start of the subsequent line.
> Both issues detected by checkpatch.pl.
> 
> Signed-off-by: Aline Santana Cordeiro 
> ---
>  drivers/staging/media/atomisp/pci/atomisp_cmd.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/media/atomisp/pci/atomisp_cmd.h 
> b/drivers/staging/media/atomisp/pci/atomisp_cmd.h
> index 1c0d464..8c4fc2b 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp_cmd.h
> +++ b/drivers/staging/media/atomisp/pci/atomisp_cmd.h
> @@ -75,8 +75,8 @@ void atomisp_wdt(struct timer_list *t);
>  void atomisp_setup_flash(struct atomisp_sub_device *asd);
>  irqreturn_t atomisp_isr(int irq, void *dev);
>  irqreturn_t atomisp_isr_thread(int irq, void *isp_ptr);
> -const struct atomisp_format_bridge *get_atomisp_format_bridge_from_mbus(
> -u32 mbus_code);
> +const struct atomisp_format_bridge
> +*get_atomisp_format_bridge_from_mbus(u32 mbus_code);

You keep the * on the previous line since it is part of the return type.

Regards,

Hans

>  bool atomisp_is_mbuscode_raw(uint32_t code);
>  int atomisp_get_frame_pgnr(struct atomisp_device *isp,
>  const struct ia_css_frame *frame, u32 *p_pgnr);
> @@ -381,9 +381,9 @@ enum mipi_port_id __get_mipi_port(struct atomisp_device 
> *isp,
>  
>  bool atomisp_is_vf_pipe(struct atomisp_video_pipe *pipe);
>  
> -void atomisp_apply_css_parameters(
> -struct atomisp_sub_device *asd,
> -struct atomisp_css_params *css_param);
> +void atomisp_apply_css_parameters(struct atomisp_sub_device *asd,
> +   struct atomisp_css_params *css_param);
> +
>  void atomisp_free_css_parameters(struct atomisp_css_params *css_param);
>  
>  void atomisp_handle_parameter_and_buffer(struct atomisp_video_pipe *pipe);
> 



Re: [PATCH] staging: media: tegra-video: Align line break to match with the open parenthesis in file vi.c

2021-04-15 Thread Hans Verkuil
On 14/04/2021 15:09, Aline Santana Cordeiro wrote:
> Align line break to match with the open parenthesis.
> Issue detected by checkpatch.pl.
> 
> Signed-off-by: Aline Santana Cordeiro 
> ---
>  drivers/staging/media/tegra-video/vi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/tegra-video/vi.c 
> b/drivers/staging/media/tegra-video/vi.c
> index 7a09061c..9878d1e 100644
> --- a/drivers/staging/media/tegra-video/vi.c
> +++ b/drivers/staging/media/tegra-video/vi.c
> @@ -1813,7 +1813,8 @@ static int tegra_vi_graph_parse_one(struct 
> tegra_vi_channel *chan,
>   }
>  
>   tvge = v4l2_async_notifier_add_fwnode_subdev(>notifier,
> - remote, struct tegra_vi_graph_entity);
> +  remote,

Add this line to the previous line. That looks a bit better and is one line
shorter.

Regards,

Hans

> +  struct 
> tegra_vi_graph_entity);
>   if (IS_ERR(tvge)) {
>   ret = PTR_ERR(tvge);
>   dev_err(vi->dev,
> 



Re: [PATCH v3] staging: media: zoran: reduce length of a line

2021-04-15 Thread Hans Verkuil
On 13/04/2021 18:35, Mitali Borkar wrote:
> Reduced length of a line which exceed the 100 columns limit by splitting
> the line into two statements and commenting it with '*' to meet linux
> kernel coding style for long(multi-line) comments.
> Reported by checkpatch.
> 
> Signed-off-by: Mitali Borkar 
> ---
> 
> Changes from v2:- Rebased this patch and made changes against mainline
> code.
> Changes from v1:- Made style changes according to linux kernel coding style
> for long comments.
> 
>  drivers/staging/media/zoran/zr36060.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/zoran/zr36060.c 
> b/drivers/staging/media/zoran/zr36060.c
> index 4f9eb9ff2c42..27eec3446592 100644
> --- a/drivers/staging/media/zoran/zr36060.c
> +++ b/drivers/staging/media/zoran/zr36060.c
> @@ -249,7 +249,11 @@ static const char zr36060_ta[8] = { 0, 1, 1, 0, 0, 0, 0, 
> 0 };//table idx's AC
>  static const char zr36060_decimation_h[8] = { 2, 1, 1, 0, 0, 0, 0, 0 };
>  static const char zr36060_decimation_v[8] = { 1, 1, 1, 0, 0, 0, 0, 0 };
>  
> -/* SOF (start of frame) segment depends on width, height and sampling ratio 
> of each color component */
> +/*
> + * SOF (start of frame) segment depends on width,
> + * height and sampling ratio of each color component
> + */
> +

No need for this extra newline. The comment block describes the function,
so the function should directly follow that comment.

Regards,

Hans

>  static int zr36060_set_sof(struct zr36060 *ptr)
>  {
>   char sof_data[34];  // max. size of register set
> 



Re: Subject: [PATCH v4] staging: media: zoran: add '*' in long(multi-line) comments

2021-04-15 Thread Hans Verkuil
Hi Mitali,

You have 'Subject' in the Subject line. That looks weird...

On 13/04/2021 19:26, Mitali Borkar wrote:
> Added '*' before every line inside long(multi-line) comments. Removed
> '*/' from end of the comment line and added to next line as per linux
> kernel coding style. Aligned '*' accordingly to make code neater.
> 
> Signed-off-by: Mitali Borkar 
> ---
> Changes from v3:- Rebased this patch and made changes against mainline
> code. 
> Changes from v2:- made style changes in code according to linux kernel
> coding style for long comments.
> Changes from v1:- Changes made in code according to linux kernel coding
> style for long(multi-line) comments.
> 
>  drivers/staging/media/zoran/zr36050.c | 192 +++---
>  1 file changed, 112 insertions(+), 80 deletions(-)
> 
> diff --git a/drivers/staging/media/zoran/zr36050.c 
> b/drivers/staging/media/zoran/zr36050.c
> index 2826f4e5d37b..a1084aa142e7 100644
> --- a/drivers/staging/media/zoran/zr36050.c
> +++ b/drivers/staging/media/zoran/zr36050.c
> @@ -24,8 +24,11 @@
>  /* codec io API */
>  #include "videocodec.h"
>  
> -/* it doesn't make sense to have more than 20 or so,
> -  just to prevent some unwanted loops */
> +/*
> + * it doesn't make sense to have more than 20 or so,
> + * just to prevent some unwanted loops
> + */
> +

Why add an empty line here? Since the comment describes the define, you expect
that the define follows directly after the comment.

>  #define MAX_CODECS 20
>  
>  /* amount of chips attached via this driver */
> @@ -43,10 +46,11 @@ MODULE_PARM_DESC(debug, "Debug level (0-4)");
>   } while (0)
>  
>  /* =

/* should be on a line by itself:

/*
 * =

That said, I would just delete those '===' lines: they don't really
add anything.

Regards,

Hans

> -   Local hardware I/O functions:
> -
> -   read/write via codec layer (registers are located in the master device)
> -   = 
> */
> + * Local hardware I/O functions:
> + *
> + * read/write via codec layer (registers are located in the master device)
> + * =
> + */
>  
>  /* read and write functions */
>  static u8 zr36050_read(struct zr36050 *ptr, u16 reg)
> @@ -80,10 +84,11 @@ static void zr36050_write(struct zr36050 *ptr, u16 reg, 
> u8 value)
>  }
>  
>  /* =
> -   Local helper function:
> -
> -   status read
> -   = 
> */
> + * Local helper function:
> + *
> + * status read
> + * =
> + */
>  
>  /* status is kept in datastructure */
>  static u8 zr36050_read_status1(struct zr36050 *ptr)
> @@ -95,10 +100,11 @@ static u8 zr36050_read_status1(struct zr36050 *ptr)
>  }
>  
>  /* =
> -   Local helper function:
> -
> -   scale factor read
> -   = 
> */
> + * Local helper function:
> + *
> + * scale factor read
> + * =
> + */
>  
>  /* scale factor is kept in datastructure */
>  static u16 zr36050_read_scalefactor(struct zr36050 *ptr)
> @@ -112,10 +118,11 @@ static u16 zr36050_read_scalefactor(struct zr36050 *ptr)
>  }
>  
>  /* =
> -   Local helper function:
> -
> -   wait if codec is ready to proceed (end of processing) or time is over
> -   = 
> */
> + * Local helper function:
> + *
> + * wait if codec is ready to proceed (end of processing) or time is over
> + * =
> + */
>  
>  static void zr36050_wait_end(struct zr36050 *ptr)
>  {
> @@ -133,10 +140,11 @@ static void zr36050_wait_end(struct zr36050 *ptr)
>  }
>  
>  /* =
> -   Local helper function:
> -
> -   basic test of "connectivity", writes/reads to/from memory the SOF marker
> -   = 
> */
> + * Local helper function:
> + *
> + * basic test of "connectivity", writes/reads to/from memory the SOF marker
> + * =
> + */
>  
>  static int zr36050_basic_test(struct zr36050 *ptr)
>  {
> @@ -174,10 +182,11 @@ static int zr36050_basic_test(struct zr36050 *ptr)
>  }
>  
>  /* =
> -   Local 

Re: [PATCH] staging: media: omap4iss: Remove unused macro functions

2021-04-14 Thread Hans Verkuil
On 13/04/2021 20:21, ascordeiro wrote:
> Em ter, 2021-04-13 às 17:06 +0200, Hans Verkuil escreveu:
>> On 12/04/2021 15:42, Aline Santana Cordeiro wrote:
>>> Remove unused macro functions "to_iss_device()", "to_device()",
>>> and "v4l2_dev_to_iss_device(dev)".
>>
>> 'git grep to_iss_device drivers/staging/omap4iss' gives me lots of
>> hits!
>> Same for to_device. Only v4l2_dev_to_iss_device appears to be unused.
>>
>> Regards,
>>
>> Hans
>>
> This command is really helpful, I didin't know. 
> Thank you for the tip.
> 
> May I send a v2 removing just v4l2_dev_to_iss_device?

Sure, that's fine.

Regards,

Hans

> 
> Thank you in advance,
> Aline
> 
>>>
>>> Signed-off-by: Aline Santana Cordeiro <
>>> alinesantanacorde...@gmail.com>
>>> ---
>>>  drivers/staging/media/omap4iss/iss.h | 8 
>>>  1 file changed, 8 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/omap4iss/iss.h
>>> b/drivers/staging/media/omap4iss/iss.h
>>> index b88f952..a354d5f 100644
>>> --- a/drivers/staging/media/omap4iss/iss.h
>>> +++ b/drivers/staging/media/omap4iss/iss.h
>>> @@ -29,11 +29,6 @@
>>>  
>>>  struct regmap;
>>>  
>>> -#define to_iss_device(ptr_module)  \
>>> -   container_of(ptr_module, struct iss_device, ptr_module)
>>> -#define
>>> to_device(ptr_module)  \
>>> -   (to_iss_device(ptr_module)->dev)
>>> -
>>>  enum iss_mem_resources {
>>> OMAP4_ISS_MEM_TOP,
>>> OMAP4_ISS_MEM_CSI2_A_REGS1,
>>> @@ -119,9 +114,6 @@ struct iss_device {
>>> unsigned int isp_subclk_resources;
>>>  };
>>>  
>>> -#define v4l2_dev_to_iss_device(dev) \
>>> -   container_of(dev, struct iss_device, v4l2_dev)
>>> -
>>>  int omap4iss_get_external_info(struct iss_pipeline *pipe,
>>>    struct media_link *link);
>>>  
>>>
>>
> 
> 



Re: [PATCH v3 0/2] Intra-refresh period control

2021-04-13 Thread Hans Verkuil
On 13/04/2021 17:49, Stanimir Varbanov wrote:
> Hi Hans,
> 
> Any comments?

Thanks for the reminder, I replied to the patch.

Regards,

Hans

> 
> On 3/2/21 11:53 AM, Stanimir Varbanov wrote:
>> Hi,
>>
>> This series add a new intra-refresh period control for encoders. The
>> series is a continuation of [1]. Comments addressed:
>>  * A typo in .rst (Hans)
>>  * Clarified the relationship with CYCLIC_INTRA_REFRESH_MB (Hans)
>>
>> Comments are welcome!
>>
>> regards,
>> Stan
>>
>> [1] https://www.spinics.net/lists/linux-media/msg183019.html
>>
>> Stanimir Varbanov (2):
>>   media: v4l2-ctrls: Add intra-refresh period control
>>   venus: venc: Add support for intra-refresh period
>>
>>  .../media/v4l/ext-ctrls-codec.rst | 12 
>>  drivers/media/platform/qcom/venus/core.h  |  1 +
>>  drivers/media/platform/qcom/venus/venc.c  | 28 +++
>>  .../media/platform/qcom/venus/venc_ctrls.c| 13 -
>>  drivers/media/v4l2-core/v4l2-ctrls.c  |  2 ++
>>  include/uapi/linux/v4l2-controls.h|  1 +
>>  6 files changed, 50 insertions(+), 7 deletions(-)
>>
> 



Re: [PATCH v3 1/2] media: v4l2-ctrls: Add intra-refresh period control

2021-04-13 Thread Hans Verkuil
On 02/03/2021 10:53, Stanimir Varbanov wrote:
> Add a control to set intra-refresh period.
> 
> Signed-off-by: Stanimir Varbanov 
> ---
>  .../userspace-api/media/v4l/ext-ctrls-codec.rst  | 12 
>  drivers/media/v4l2-core/v4l2-ctrls.c |  2 ++
>  include/uapi/linux/v4l2-controls.h   |  1 +
>  3 files changed, 15 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst 
> b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> index 00944e97d638..49e6d364ded7 100644
> --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> @@ -1104,6 +1104,18 @@ enum v4l2_mpeg_video_h264_entropy_mode -
>  macroblocks is refreshed until the cycle completes and starts from
>  the top of the frame. Applicable to H264, H263 and MPEG4 encoder.
>  
> +``V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD (integer)``
> +Intra macroblock refresh period. This sets the period to refresh
> +the whole frame. In other words, this defines the number of frames
> +for which the whole frame will be intra-refreshed.  An example:
> +setting period to 1 means that the whole frame will be refreshed,
> +setting period to 2 means that the half of macroblocks will be
> +intra-refreshed on frameX and the other half of macroblocks
> +will be refreshed in frameX + 1 and so on. Setting period to zero
> +means no period is specified. Note that intra-refresh  is mutually

Double space after 'intra-refresh'

> +exclusive with V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB control.

1) The same must be mentioned in the V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB
   control documentation as well.
2) What does it mean: 'mutually exclusive'? Does that mean that a driver
   implements only one or the other? If not, and both can be implemented, then
   how does userspace know which control is applied?

Also, you mentioned that V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB is
enumerated in the venus driver, but doesn't do anything. Wouldn't it be
better to remove it?

Regards,

Hans

> +Applicable to H264 and HEVC encoders.
> +
>  ``V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE (boolean)``
>  Frame level rate control enable. If this control is disabled then
>  the quantization parameter for each frame type is constant and set
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 016cf6204cbb..2ee463e08f1e 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -869,6 +869,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>   case V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE:   return "Decoder 
> Slice Interface";
>   case V4L2_CID_MPEG_VIDEO_DECODER_MPEG4_DEBLOCK_FILTER:  return "MPEG4 
> Loop Filter Enable";
>   case V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB:   return "Number 
> of Intra Refresh MBs";
> + case V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD:  return "Intra 
> Refresh Period";
>   case V4L2_CID_MPEG_VIDEO_FRAME_RC_ENABLE:   return "Frame 
> Level Rate Control Enable";
>   case V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE:  return "H264 MB 
> Level Rate Control";
>   case V4L2_CID_MPEG_VIDEO_HEADER_MODE:   return 
> "Sequence Header Mode";
> @@ -1276,6 +1277,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
> v4l2_ctrl_type *type,
>   break;
>   case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
>   case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
> + case V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD:
>   *type = V4L2_CTRL_TYPE_INTEGER;
>   break;
>   case V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME:
> diff --git a/include/uapi/linux/v4l2-controls.h 
> b/include/uapi/linux/v4l2-controls.h
> index 039c0d7add1b..1fddd9f0d4f1 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -428,6 +428,7 @@ enum v4l2_mpeg_video_multi_slice_mode {
>  #define V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE
> (V4L2_CID_CODEC_BASE+228)
>  #define V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME  
> (V4L2_CID_CODEC_BASE+229)
>  #define V4L2_CID_MPEG_VIDEO_BASELAYER_PRIORITY_ID
> (V4L2_CID_CODEC_BASE+230)
> +#define V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD 
> (V4L2_CID_CODEC_BASE+231)
>  
>  /* CIDs for the MPEG-2 Part 2 (H.262) codec */
>  #define V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL  
> (V4L2_CID_CODEC_BASE+270)
> 



Re: [PATCH] staging: media: tegra-vde: Align line break to match with the open parenthesis in file trace.h

2021-04-13 Thread Hans Verkuil
Hi Aline,

On 13/04/2021 00:20, Aline Santana Cordeiro wrote:
> Align line break to match with the open parenthesis.
> Issue detected by checkpatch.pl.
> It consequently solved a few end lines with a '(',
> issue also detected by checkpatch.pl

These trace headers are almost a language by themselves, and the
usual alignment rules do not apply. Look at other existing trace.h files
in the kernel and you'll see that they have their own coding style.

So I prefer not to apply this patch.

You couldn't have known that, so it's not your fault.

Regards,

Hans

> 
> Signed-off-by: Aline Santana Cordeiro 
> ---
>  drivers/staging/media/tegra-vde/trace.h | 111 
> ++--
>  1 file changed, 50 insertions(+), 61 deletions(-)
> 
> diff --git a/drivers/staging/media/tegra-vde/trace.h 
> b/drivers/staging/media/tegra-vde/trace.h
> index e571410..1fcc573 100644
> --- a/drivers/staging/media/tegra-vde/trace.h
> +++ b/drivers/staging/media/tegra-vde/trace.h
> @@ -11,79 +11,68 @@
>  #include "vde.h"
>  
>  DECLARE_EVENT_CLASS(register_access,
> - TP_PROTO(struct tegra_vde *vde, void __iomem *base,
> -  u32 offset, u32 value),
> - TP_ARGS(vde, base, offset, value),
> - TP_STRUCT__entry(
> - __string(hw_name, tegra_vde_reg_base_name(vde, base))
> - __field(u32, offset)
> - __field(u32, value)
> - ),
> - TP_fast_assign(
> - __assign_str(hw_name, tegra_vde_reg_base_name(vde, base));
> - __entry->offset = offset;
> - __entry->value = value;
> - ),
> - TP_printk("%s:0x%03x 0x%08x", __get_str(hw_name), __entry->offset,
> -   __entry->value)
> + TP_PROTO(struct tegra_vde *vde, void __iomem *base,
> +  u32 offset, u32 value),
> + TP_ARGS(vde, base, offset, value),
> + TP_STRUCT__entry(__string(hw_name, 
> tegra_vde_reg_base_name(vde, base))
> +  __field(u32, offset)
> +  __field(u32, value)
> + ),
> + TP_fast_assign(__assign_str(hw_name,
> + 
> tegra_vde_reg_base_name(vde, base));
> +__entry->offset = offset;
> +__entry->value = value;
> + ),
> + TP_printk("%s:0x%03x 0x%08x", __get_str(hw_name), 
> __entry->offset,
> +   __entry->value)
>  );
>  
>  DEFINE_EVENT(register_access, vde_writel,
> - TP_PROTO(struct tegra_vde *vde, void __iomem *base,
> -  u32 offset, u32 value),
> - TP_ARGS(vde, base, offset, value));
> +  TP_PROTO(struct tegra_vde *vde, void __iomem *base,
> +   u32 offset, u32 value),
> +  TP_ARGS(vde, base, offset, value));
>  DEFINE_EVENT(register_access, vde_readl,
> - TP_PROTO(struct tegra_vde *vde, void __iomem *base,
> -  u32 offset, u32 value),
> - TP_ARGS(vde, base, offset, value));
> +  TP_PROTO(struct tegra_vde *vde, void __iomem *base,
> +   u32 offset, u32 value),
> +  TP_ARGS(vde, base, offset, value));
>  
>  TRACE_EVENT(vde_setup_iram_entry,
> - TP_PROTO(unsigned int table, unsigned int row, u32 value, u32 aux_addr),
> - TP_ARGS(table, row, value, aux_addr),
> - TP_STRUCT__entry(
> - __field(unsigned int, table)
> - __field(unsigned int, row)
> - __field(u32, value)
> - __field(u32, aux_addr)
> - ),
> - TP_fast_assign(
> - __entry->table = table;
> - __entry->row = row;
> - __entry->value = value;
> - __entry->aux_addr = aux_addr;
> - ),
> - TP_printk("[%u][%u] = { 0x%08x (flags = \"%s\", frame_num = %u); 0x%08x 
> }",
> -   __entry->table, __entry->row, __entry->value,
> -   __print_flags(__entry->value, " ", { (1 << 25), "B" }),
> -   __entry->value & 0x7F, __entry->aux_addr)
> + TP_PROTO(unsigned int table, unsigned int row, u32 value, u32 
> aux_addr),
> + TP_ARGS(table, row, value, aux_addr),
> + TP_STRUCT__entry(__field(unsigned int, table)
> +  __field(unsigned int, row)
> +  __field(u32, value)
> +  __field(u32, aux_addr)
> + ),
> + TP_fast_assign(__entry->table = table;
> +__entry->row = row;
> +__entry->value = value;
> +__entry->aux_addr = aux_addr;
> + ),
> + TP_printk("[%u][%u] = { 0x%08x (flags = \"%s\", frame_num = 
> %u); 0x%08x }",
> +   

Re: [PATCH v3] staging: media: meson: vdec: declare u32 as static const

2021-04-13 Thread Hans Verkuil
On 13/04/2021 16:11, Mitali Borkar wrote:
> Declared 32 bit unsigned int as static constant inside a function and
> replaced u32[] {x,y} as canvas3, canvas4 in codec_h264.c
> This indicates the value of canvas indexes will remain constant throughout 
> execution.

checkpatch.pl output:

WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per 
line)
#9:
This indicates the value of canvas indexes will remain constant throughout 
execution.

Regards,

Hans

> 
> Reported-by: kernel test robot 
> Signed-off-by: Mitali Borkar 
> ---
> Changes from v2:- Rebased this patch and made changes against mainline code
> Changes from v1:- Rectified mistake by declaring u32 as static const
> properly as static const u32 canvas'x'[]
> 
>  drivers/staging/media/meson/vdec/codec_h264.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/media/meson/vdec/codec_h264.c 
> b/drivers/staging/media/meson/vdec/codec_h264.c
> index c61128fc4bb9..80141b89a9f6 100644
> --- a/drivers/staging/media/meson/vdec/codec_h264.c
> +++ b/drivers/staging/media/meson/vdec/codec_h264.c
> @@ -287,10 +287,10 @@ static void codec_h264_resume(struct amvdec_session 
> *sess)
>   struct amvdec_core *core = sess->core;
>   struct codec_h264 *h264 = sess->priv;
>   u32 mb_width, mb_height, mb_total;
> + static const u32 canvas3[] = { ANCO_CANVAS_ADDR, 0 };
> + static const u32 canvas4[] = { 24, 0 };
>  
> - amvdec_set_canvases(sess,
> - (u32[]){ ANC0_CANVAS_ADDR, 0 },
> - (u32[]){ 24, 0 });
> + amvdec_set_canvases(sess, canvas3, canvas4);
>  
>   dev_dbg(core->dev, "max_refs = %u; actual_dpb_size = %u\n",
>   h264->max_refs, sess->num_dst_bufs);
> 



Re: [PATCH] staging: media: omap4iss: Remove unused macro functions

2021-04-13 Thread Hans Verkuil
On 12/04/2021 15:42, Aline Santana Cordeiro wrote:
> Remove unused macro functions "to_iss_device()", "to_device()",
> and "v4l2_dev_to_iss_device(dev)".

'git grep to_iss_device drivers/staging/omap4iss' gives me lots of hits!
Same for to_device. Only v4l2_dev_to_iss_device appears to be unused.

Regards,

Hans

> 
> Signed-off-by: Aline Santana Cordeiro 
> ---
>  drivers/staging/media/omap4iss/iss.h | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss.h 
> b/drivers/staging/media/omap4iss/iss.h
> index b88f952..a354d5f 100644
> --- a/drivers/staging/media/omap4iss/iss.h
> +++ b/drivers/staging/media/omap4iss/iss.h
> @@ -29,11 +29,6 @@
>  
>  struct regmap;
>  
> -#define to_iss_device(ptr_module)\
> - container_of(ptr_module, struct iss_device, ptr_module)
> -#define to_device(ptr_module)
> \
> - (to_iss_device(ptr_module)->dev)
> -
>  enum iss_mem_resources {
>   OMAP4_ISS_MEM_TOP,
>   OMAP4_ISS_MEM_CSI2_A_REGS1,
> @@ -119,9 +114,6 @@ struct iss_device {
>   unsigned int isp_subclk_resources;
>  };
>  
> -#define v4l2_dev_to_iss_device(dev) \
> - container_of(dev, struct iss_device, v4l2_dev)
> -
>  int omap4iss_get_external_info(struct iss_pipeline *pipe,
>  struct media_link *link);
>  
> 



Re: [PATCH v3 1/2] media: zoran: add spaces around '<<'

2021-04-13 Thread Hans Verkuil
Missing commit message.

You used to have one in v1 of this patch!

Regards,

Hans

On 10/04/2021 17:33, Mitali Borkar wrote:
> Signed-off-by: Mitali Borkar 
> ---
> Changes from v2:- No changes. 
> Changes from v1:- NO changes.
> 
>  drivers/staging/media/zoran/zr36057.h | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/media/zoran/zr36057.h 
> b/drivers/staging/media/zoran/zr36057.h
> index 71b651add35a..a2a75fd9f535 100644
> --- a/drivers/staging/media/zoran/zr36057.h
> +++ b/drivers/staging/media/zoran/zr36057.h
> @@ -30,13 +30,13 @@
>  #define ZR36057_VFESPFR_HOR_DCM  14
>  #define ZR36057_VFESPFR_VER_DCM  8
>  #define ZR36057_VFESPFR_DISP_MODE6
> -#define ZR36057_VFESPFR_YUV422  (0<<3)
> -#define ZR36057_VFESPFR_RGB888  (1<<3)
> -#define ZR36057_VFESPFR_RGB565  (2<<3)
> -#define ZR36057_VFESPFR_RGB555  (3<<3)
> -#define ZR36057_VFESPFR_ERR_DIF  (1<<2)
> -#define ZR36057_VFESPFR_PACK24  (1<<1)
> -#define ZR36057_VFESPFR_LITTLE_ENDIAN(1<<0)
> +#define ZR36057_VFESPFR_YUV422  (0 << 3)
> +#define ZR36057_VFESPFR_RGB888  (1 << 3)
> +#define ZR36057_VFESPFR_RGB565  (2 << 3)
> +#define ZR36057_VFESPFR_RGB555  (3 << 3)
> +#define ZR36057_VFESPFR_ERR_DIF  (1 << 2)
> +#define ZR36057_VFESPFR_PACK24  (1 << 1)
> +#define ZR36057_VFESPFR_LITTLE_ENDIAN(1 << 0)
>  
>  #define ZR36057_VDTR0x00c/* Video Display "Top" Register 
> */
>  
> 



Re: [PATCH v3 2/2] staging: media: zoran: align code appropriately

2021-04-13 Thread Hans Verkuil
On 10/04/2021 17:34, Mitali Borkar wrote:
> Aligned the code properly by using tabs to make code neater and improve
> readability.
> 
> Signed-off-by: Mitali Borkar 
> ---
>  drivers/staging/media/zoran/zr36057.h | 108 +-
>  1 file changed, 54 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/staging/media/zoran/zr36057.h 
> b/drivers/staging/media/zoran/zr36057.h
> index 198d344a8879..db42f445248f 100644
> --- a/drivers/staging/media/zoran/zr36057.h
> +++ b/drivers/staging/media/zoran/zr36057.h
> @@ -13,28 +13,28 @@
>  /* Zoran ZR36057 registers */
>  
>  /* Video Front End, Horizontal Configuration Register */
> -#define ZR36057_VFEHCR   0x000
> +#define ZR36057_VFEHCR   0x000
>  #define ZR36057_VFEHCR_HS_POLBIT(30)

Same issue as the other patches: this patch depends on other local changes
so won't apply to mainline code...

Regards,

Hans

> -#define ZR36057_VFEHCR_H_START   10
> -#define ZR36057_VFEHCR_H_END 0
> -#define ZR36057_VFEHCR_HMASK 0x3ff
> +#define ZR36057_VFEHCR_H_START   10
> +#define ZR36057_VFEHCR_H_END 0
> +#define ZR36057_VFEHCR_HMASK 0x3ff
>  
>  /* Video Front End, Vertical Configuration Register */
> -#define ZR36057_VFEVCR   0x004
> +#define ZR36057_VFEVCR   0x004
>  #define ZR36057_VFEVCR_VS_POLBIT(30)
> -#define ZR36057_VFEVCR_V_START   10
> -#define ZR36057_VFEVCR_V_END 0
> -#define ZR36057_VFEVCR_VMASK 0x3ff
> +#define ZR36057_VFEVCR_V_START   10
> +#define ZR36057_VFEVCR_V_END 0
> +#define ZR36057_VFEVCR_VMASK 0x3ff
>  
>  /* Video Front End, Scaler and Pixel Format Register */
>  #define ZR36057_VFESPFR  0x008
>  #define ZR36057_VFESPFR_EXT_FL   BIT(26)
>  #define ZR36057_VFESPFR_TOP_FIELDBIT(25)
>  #define ZR36057_VFESPFR_VCLK_POL BIT(24)
> -#define ZR36057_VFESPFR_H_FILTER 21
> +#define ZR36057_VFESPFR_H_FILTER 21
>  #define ZR36057_VFESPFR_HOR_DCM  14
>  #define ZR36057_VFESPFR_VER_DCM  8
> -#define ZR36057_VFESPFR_DISP_MODE6
> +#define ZR36057_VFESPFR_DISP_MODE6
>  #define ZR36057_VFESPFR_YUV422   (0 << 3)
>  #define ZR36057_VFESPFR_RGB888   BIT(3)
>  #define ZR36057_VFESPFR_RGB565   (2 << 3)
> @@ -44,34 +44,34 @@
>  #define ZR36057_VFESPFR_LITTLE_ENDIANBIT(0)
>  
>  /* Video Display "Top" Register */
> -#define ZR36057_VDTR 0x00c
> +#define ZR36057_VDTR 0x00c
>  
>  /* Video Display "Bottom" Register */
> -#define ZR36057_VDBR 0x010
> +#define ZR36057_VDBR 0x010
>  
>  /* Video Stride, Status, and Frame Grab Register */
> -#define ZR36057_VSSFGR   0x014
> -#define ZR36057_VSSFGR_DISP_STRIDE   16
> +#define ZR36057_VSSFGR   0x014
> +#define ZR36057_VSSFGR_DISP_STRIDE   16
>  #define ZR36057_VSSFGR_VID_OVF   BIT(8)
>  #define ZR36057_VSSFGR_SNAP_SHOT BIT(1)
>  #define ZR36057_VSSFGR_FRAME_GRABBIT(0)
>  
>  /* Video Display Configuration Register */
> -#define ZR36057_VDCR 0x018
> +#define ZR36057_VDCR 0x018
>  #define ZR36057_VDCR_VID_EN  BIT(31)
> -#define ZR36057_VDCR_MIN_PIX 24
> +#define ZR36057_VDCR_MIN_PIX 24
>  #define ZR36057_VDCR_TRITON  BIT(24)
>  #define ZR36057_VDCR_VID_WIN_HT  12
> -#define ZR36057_VDCR_VID_WIN_WID 0
> +#define ZR36057_VDCR_VID_WIN_WID 0
>  
>  /* Masking Map "Top" Register */
> -#define ZR36057_MMTR 0x01c
> +#define ZR36057_MMTR 0x01c
>  
>  /* Masking Map "Bottom" Register */
> -#define ZR36057_MMBR 0x020
> +#define ZR36057_MMBR 0x020
>  
>  /* Overlay Control Register */
> -#define ZR36057_OCR  0x024
> +#define ZR36057_OCR  0x024
>  #define ZR36057_OCR_OVL_ENABLE   BIT(15)
>  #define ZR36057_OCR_MASK_STRIDE  0
>  
> @@ -83,42 +83,42 @@
>  #define ZR36057_GPPGCR1  0x02c
>  
>  /* MPEG Code Source Address Register */
> -#define ZR36057_MCSAR0x030
> +#define ZR36057_MCSAR0x030
>  
>  /* MPEG Code Transfer Control Register */
> -#define ZR36057_MCTCR0x034
> +#define ZR36057_MCTCR0x034
>  #define ZR36057_MCTCR_COD_TIME   BIT(30)
>  #define ZR36057_MCTCR_C_EMPTYBIT(29)
>  #define 

Re: [Outreachy kernel][PATCH 1/2] staging: media: omap4iss: Align line break to the open parenthesis in file iss.c

2021-04-13 Thread Hans Verkuil
On 09/04/2021 21:01, Aline Santana Cordeiro wrote:
> Aligns line break with the remaining function arguments
> to the open parenthesis. Issue found by checkpatch.
> 
> Signed-off-by: Aline Santana Cordeiro 

Obsolete, a similar patch from Beatriz Martins de Carvalho 

has already been applied in the media subsystem tree.

Regards,

Hans

> ---
>  drivers/staging/media/omap4iss/iss.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss.c 
> b/drivers/staging/media/omap4iss/iss.c
> index dae9073..c89f268a 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -960,7 +960,7 @@ iss_register_subdev_group(struct iss_device *iss,
>   }
>  
>   subdev = v4l2_i2c_new_subdev_board(>v4l2_dev, adapter,
> - board_info->board_info, NULL);
> +board_info->board_info, 
> NULL);
>   if (!subdev) {
>   dev_err(iss->dev, "Unable to register subdev %s\n",
>   board_info->board_info->type);
> 



Re: [PATCH v3] staging: media: zoran: remove and move statement in next line with '*'

2021-04-13 Thread Hans Verkuil
On 09/04/2021 13:40, Mitali Borkar wrote:
> Removed and moved statement in line in long(multi-line) comments and
> added '*' before it to meet linux kernel coding style for long (multi-line) 
> comments
> 
> Signed-off-by: Mitali Borkar 
> ---
> 
> Changes from v2:- made style changes in code according to linux kernel
> coding style for long comments.
> 
> drivers/staging/media/zoran/zr36050.c | 26 +-
>  1 file changed, 17 insertions(+), 9 deletions(-)

This too sits on top of other commits from your own private branch, so
it won't apply against the mainline code.

Regards,

Hans

> 
> diff --git a/drivers/staging/media/zoran/zr36050.c 
> b/drivers/staging/media/zoran/zr36050.c
> index 703064009c6b..b89afa239b0c 100644
> --- a/drivers/staging/media/zoran/zr36050.c
> +++ b/drivers/staging/media/zoran/zr36050.c
> @@ -24,7 +24,8 @@
>  /* codec io API */
>  #include "videocodec.h"
>  
> -/* it doesn't make sense to have more than 20 or so,
> +/*
> + * it doesn't make sense to have more than 20 or so,
>   * just to prevent some unwanted loops
>   */
>  #define MAX_CODECS 20
> @@ -311,7 +312,8 @@ static const char zr36050_decimation_v[8] = { 1, 1, 1, 0, 
> 0, 0, 0, 0 };
>  
>  /* - 
> */
>  
> -/* SOF (start of frame) segment depends on width, height and sampling ratio
> +/*
> + * SOF (start of frame) segment depends on width, height and sampling ratio
>   *of each color component
>   */
>  
> @@ -343,7 +345,8 @@ static int zr36050_set_sof(struct zr36050 *ptr)
>  
>  /* - 
> */
>  
> -/* SOS (start of scan) segment depends on the used scan components
> +/*
> + * SOS (start of scan) segment depends on the used scan components
>   *   of each color component
>   */
>  
> @@ -432,7 +435,8 @@ static void zr36050_init(struct zr36050 *ptr)
>   sum += zr36050_set_sos(ptr);
>   sum += zr36050_set_dri(ptr);
>  
> - /* setup the fixed jpeg tables - maybe variable, though -
> + /*
> +  * setup the fixed jpeg tables - maybe variable, though -
>* (see table init section above)
>*/
>   dprintk(3, "%s: write DQT, DHT, APP\n", ptr->name);
> @@ -551,8 +555,9 @@ static void zr36050_init(struct zr36050 *ptr)
>   * =
>   */
>  
> -/* set compression/expansion mode and launches codec -
> - *  this should be the last call from the master before starting processing
> +/*
> + * set compression/expansion mode and launches codec -
> + * this should be the last call from the master before starting processing
>   */
>  
>  static int zr36050_set_mode(struct videocodec *codec, int mode)
> @@ -581,7 +586,8 @@ static int zr36050_set_video(struct videocodec *codec, 
> const struct tvnorm *norm
>   ptr->name, norm->h_start, norm->v_start,
>   cap->x, cap->y, cap->width, cap->height,
>   cap->decimation, cap->quality);
> - /* if () return -EINVAL;
> + /*
> +  * if () return -EINVAL;
>* trust the master driver that it knows what it does - so
>* we allow invalid startx/y and norm for now ...
>*/
> @@ -603,7 +609,8 @@ static int zr36050_set_video(struct videocodec *codec, 
> const struct tvnorm *norm
>  
>   ptr->real_code_vol = size >> 3; /* in bytes */
>  
> - /* Set max_block_vol here (previously in zr36050_init, moved
> + /*
> +  * Set max_block_vol here (previously in zr36050_init, moved
>* here for consistency with zr36060 code
>*/
>   zr36050_write(ptr, ZR050_MBCV, ptr->max_block_vol);
> @@ -661,7 +668,8 @@ static int zr36050_control(struct videocodec *codec, int 
> type, int size, void *d
>   if (size != sizeof(int))
>   return -EFAULT;
>   ptr->total_code_vol = *ival;
> - /* (Kieran Morrissey)
> + /*
> +  * (Kieran Morrissey)
>* code copied from zr36060.c to ensure proper bitrate
>*/
>   ptr->real_code_vol = (ptr->total_code_vol * 6) >> 3;
> 



Re: [PATCH v2] staging: media: zoran: moved statement to next line with '*'

2021-04-13 Thread Hans Verkuil
On 09/04/2021 13:40, Mitali Borkar wrote:
> Moved the statement to next line and added '*' before it to meet
> linux kernel coding style for long(multi-line) comments.
> 
> Signed-off-by: Mitali Borkar 
> ---
> 
> Changes from v1:- made style changes according to linux kernel coding style
> for long comments.
> 
> drivers/staging/media/zoran/zr36060.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/zoran/zr36060.c 
> b/drivers/staging/media/zoran/zr36060.c
> index 035634fc1c6d..8c6f4d792a9d 100644
> --- a/drivers/staging/media/zoran/zr36060.c
> +++ b/drivers/staging/media/zoran/zr36060.c
> @@ -249,7 +249,8 @@ static const char zr36060_ta[8] = { 0, 1, 1, 0, 0, 0, 0, 
> 0 }; //table idx's AC
>  static const char zr36060_decimation_h[8] = { 2, 1, 1, 0, 0, 0, 0, 0 };
>  static const char zr36060_decimation_v[8] = { 1, 1, 1, 0, 0, 0, 0, 0 };
>  
> -/* SOF (start of frame) segment depends on width,
> +/*
> + * SOF (start of frame) segment depends on width,
>   * height and sampling ratio of each color component
>   */
>  static int zr36060_set_sof(struct zr36060 *ptr)
> 

Same problem as with other patches: this sits on top of your v1, so won't apply
to mainline code.

Regards,

Hans


Re: Subject: [PATCH v2] staging: media: meson: vdec: declare u32 as static const appropriately

2021-04-13 Thread Hans Verkuil
On 13/04/2021 13:09, Mitali Borkar wrote:
> On Tue, Apr 13, 2021 at 09:26:01AM +0200, Hans Verkuil wrote:
>> On 13/04/2021 08:27, Mitali Borkar wrote:
>>> Declared 32 bit unsigned int as static constant inside a function
>>> appropriately.
>>>
>>> Reported-by: kernel test robot 
>>> Signed-off-by: Mitali Borkar 
>>> ---
>>>
>>> Changes from v1:- Rectified the mistake by declaring u32 as static const
>>> properly.
>>>
>>>  drivers/staging/media/meson/vdec/codec_h264.c | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/meson/vdec/codec_h264.c 
>>> b/drivers/staging/media/meson/vdec/codec_h264.c
>>> index ea86e9e1c447..80141b89a9f6 100644
>>> --- a/drivers/staging/media/meson/vdec/codec_h264.c
>>> +++ b/drivers/staging/media/meson/vdec/codec_h264.c
>>> @@ -287,8 +287,8 @@ static void codec_h264_resume(struct amvdec_session 
>>> *sess)
>>> struct amvdec_core *core = sess->core;
>>> struct codec_h264 *h264 = sess->priv;
>>> u32 mb_width, mb_height, mb_total;
>>> -   static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
>>> -   static const u32[] canvas4 = { 24, 0 };
>>> +   static const u32 canvas3[] = { ANCO_CANVAS_ADDR, 0 };
>>> +   static const u32 canvas4[] = { 24, 0 };
>>
>> This is a patch on top of your previous (v1) patch. That won't work
>> since the v1 is not merged, you need to make a patch against the current
>> mainline code.
>>
> But Sir, since I have made changes in the code, and committed them, now,
> if I open that file, it will contain those changes. Then should I
> rewrite the patch body more accurately? 

You only committed the v1 change in your own repository, it's not in the
upstream repository. And the patches you post must be against the upstream
repository, not your own.

'git rebase -i' can be your friend here, it makes it easy to fold the
second patch into the first, and then you only have to post the final
version.

Regards,

Hans

> 
>> Regards,
>>
>>  Hans
>>
>>>  
>>> amvdec_set_canvases(sess, canvas3, canvas4);
>>>  
>>>
>>



Re: Subject: [PATCH v2] staging: media: meson: vdec: declare u32 as static const appropriately

2021-04-13 Thread Hans Verkuil
On 13/04/2021 08:27, Mitali Borkar wrote:
> Declared 32 bit unsigned int as static constant inside a function
> appropriately.
> 
> Reported-by: kernel test robot 
> Signed-off-by: Mitali Borkar 
> ---
> 
> Changes from v1:- Rectified the mistake by declaring u32 as static const
> properly.
> 
>  drivers/staging/media/meson/vdec/codec_h264.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/media/meson/vdec/codec_h264.c 
> b/drivers/staging/media/meson/vdec/codec_h264.c
> index ea86e9e1c447..80141b89a9f6 100644
> --- a/drivers/staging/media/meson/vdec/codec_h264.c
> +++ b/drivers/staging/media/meson/vdec/codec_h264.c
> @@ -287,8 +287,8 @@ static void codec_h264_resume(struct amvdec_session *sess)
>   struct amvdec_core *core = sess->core;
>   struct codec_h264 *h264 = sess->priv;
>   u32 mb_width, mb_height, mb_total;
> - static const u32[] canvas3 = { ANCO_CANVAS_ADDR, 0 };
> - static const u32[] canvas4 = { 24, 0 };
> + static const u32 canvas3[] = { ANCO_CANVAS_ADDR, 0 };
> + static const u32 canvas4[] = { 24, 0 };

This is a patch on top of your previous (v1) patch. That won't work
since the v1 is not merged, you need to make a patch against the current
mainline code.

Regards,

Hans

>  
>   amvdec_set_canvases(sess, canvas3, canvas4);
>  
> 



Re: [PATCH v2] staging: media: zoran: remove and add '*' in long(multi-line) comments

2021-04-12 Thread Hans Verkuil
On 11/04/2021 13:47, Mitali Borkar wrote:
> On Fri, Apr 09, 2021 at 12:53:35PM +0200, Hans Verkuil wrote:
>> On 09/04/2021 12:49, Mitali Borkar wrote:
>>> Added '*' before every line inside long(multi-line) comments. Removed
>>> '*/' from end of the comment line and added to next line as per linux
>>> kernel coding style. Aligned '*' accordingly to make code neater.
>>>
>>> Signed-off-by: Mitali Borkar 
>>> ---
>>>
>>> Changes from v1:- Changes made in code according to linux kernel coding
>>> style for long(multi-line) comments.
>>>
>>> drivers/staging/media/zoran/zr36050.c | 138 +++---
>>>  1 file changed, 81 insertions(+), 57 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/zoran/zr36050.c 
>>> b/drivers/staging/media/zoran/zr36050.c
>>> index 663ac2b3434e..703064009c6b 100644
>>> --- a/drivers/staging/media/zoran/zr36050.c
>>> +++ b/drivers/staging/media/zoran/zr36050.c
>>> @@ -25,7 +25,8 @@
>>>  #include "videocodec.h"
>>>  
>>>  /* it doesn't make sense to have more than 20 or so,
>>
>> The coding style says that /* is on a line of its own. So change that too.
>>
> 
> Sir, I have sent v3 patch for this two days ago and didnt received reply
> til now, should I resend that patch?

It was weekend, you know :-)

If you don't hear from me for more than a week, and the patch state in
patchwork (https://patchwork.linuxtv.org/project/linux-media/list/) is still
'New', then ping me, i.e. just reply to your patch with a 'Gentle ping!'
message.

Regards,

Hans

> 
>> Regards,
>>
>>  Hans
>>
>>> - * just to prevent some unwanted loops */
>>> + * just to prevent some unwanted loops
>>> + */
>>>  #define MAX_CODECS 20
>>>  
>>>  /* amount of chips attached via this driver */
>>> @@ -44,9 +45,10 @@ MODULE_PARM_DESC(debug, "Debug level (0-4)");
>>>  
>>>  /* 
>>> =
>>>   *  Local hardware I/O functions:
>>> -
>>> -   read/write via codec layer (registers are located in the master device)
>>> -   
>>> = */
>>> + *
>>> + *  read/write via codec layer (registers are located in the master device)
>>> + * 
>>> =
>>> + */
>>>  
>>>  /* read and write functions */
>>>  static u8 zr36050_read(struct zr36050 *ptr, u16 reg)
>>> @@ -81,9 +83,10 @@ static void zr36050_write(struct zr36050 *ptr, u16 reg, 
>>> u8 value)
>>>  
>>>  /* 
>>> =
>>>   *  Local helper function:
>>> -
>>> -   status read
>>> -   
>>> = */
>>> + *
>>> + *  status read
>>> + * 
>>> =
>>> + */
>>>  
>>>  /* status is kept in datastructure */
>>>  static u8 zr36050_read_status1(struct zr36050 *ptr)
>>> @@ -96,9 +99,10 @@ static u8 zr36050_read_status1(struct zr36050 *ptr)
>>>  
>>>  /* 
>>> =
>>>   *  Local helper function:
>>> -
>>> -   scale factor read
>>> -   
>>> = */
>>> + *
>>> + *  scale factor read
>>> + * 
>>> =
>>> + */
>>>  
>>>  /* scale factor is kept in datastructure */
>>>  static u16 zr36050_read_scalefactor(struct zr36050 *ptr)
>>> @@ -113,9 +117,10 @@ static u16 zr36050_read_scalefactor(struct zr36050 
>>> *ptr)
>>>  
>>>  /* 
>>> =
>>>   *  Local helper function:
>>> -
>>> -   wait if codec is ready to proceed (end of processing) or time is over
>>> -   
>>> = */
>>> + *
>>> + *  wait if codec is ready to proceed (end of processing) or time is over
>>> + * 
>>> =

Re: [PATCH v2] staging: media: meson: vdec: declare u32 as const and static const

2021-04-12 Thread Hans Verkuil
On 10/04/2021 21:59, Mitali Borkar wrote:
> Declared 32 bit unsigned int as static constant inside a function and
> replaced u32[] {x,y} as canvas1, canvas2 in codec_mpeg12.c
> This indicates the value of canvas indexes will remain constant throughout 
> execution.
> Replaced u32 reg_base and u32 reg_name with const u32 reg_base and const
> u32 reg_name as it will contain data/registry bases to write static
> const indexes declared above and will keep track of of contiguos
> registers after each reg_base.
> This makes code look better, neater. It improves readability.
> 
> Signed-off-by: Mitali Borkar 
> ---
>  drivers/staging/media/meson/vdec/codec_mpeg12.c | 5 +++--

Also change drivers/staging/media/meson/vdec/codec_h264.c.

It's a nice improvement, so let's do this for both callers of 
amvdec_set_canvases().

Regards,

Hans

>  drivers/staging/media/meson/vdec/vdec_helpers.c | 2 +-
>  drivers/staging/media/meson/vdec/vdec_helpers.h | 2 +-
>  3 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/media/meson/vdec/codec_mpeg12.c 
> b/drivers/staging/media/meson/vdec/codec_mpeg12.c
> index 21e93a13356c..861d8584f22f 100644
> --- a/drivers/staging/media/meson/vdec/codec_mpeg12.c
> +++ b/drivers/staging/media/meson/vdec/codec_mpeg12.c
> @@ -65,6 +65,8 @@ static int codec_mpeg12_start(struct amvdec_session *sess)
>   struct amvdec_core *core = sess->core;
>   struct codec_mpeg12 *mpeg12;
>   int ret;
> + static const u32 canvas1[] = { AV_SCRATCH_0, 0 };
> + static const u32 canvas2[] = { 8, 0 }
>  
>   mpeg12 = kzalloc(sizeof(*mpeg12), GFP_KERNEL);
>   if (!mpeg12)
> @@ -80,8 +82,7 @@ static int codec_mpeg12_start(struct amvdec_session *sess)
>   goto free_mpeg12;
>   }
>  
> - ret = amvdec_set_canvases(sess, (u32[]){ AV_SCRATCH_0, 0 },
> -   (u32[]){ 8, 0 });
> + ret = amvdec_set_canvases(sess, canvas1, canvas2);
>   if (ret)
>   goto free_workspace;
>  
> diff --git a/drivers/staging/media/meson/vdec/vdec_helpers.c 
> b/drivers/staging/media/meson/vdec/vdec_helpers.c
> index 7f07a9175815..df5c27266c44 100644
> --- a/drivers/staging/media/meson/vdec/vdec_helpers.c
> +++ b/drivers/staging/media/meson/vdec/vdec_helpers.c
> @@ -177,7 +177,7 @@ static int set_canvas_nv12m(struct amvdec_session *sess,
>  }
>  
>  int amvdec_set_canvases(struct amvdec_session *sess,
> - u32 reg_base[], u32 reg_num[])
> + const u32 reg_base[], const u32 reg_num[])
>  {
>   struct v4l2_m2m_buffer *buf;
>   u32 pixfmt = sess->pixfmt_cap;
> diff --git a/drivers/staging/media/meson/vdec/vdec_helpers.h 
> b/drivers/staging/media/meson/vdec/vdec_helpers.h
> index cfaed52ab526..ace8897c34fe 100644
> --- a/drivers/staging/media/meson/vdec/vdec_helpers.h
> +++ b/drivers/staging/media/meson/vdec/vdec_helpers.h
> @@ -17,7 +17,7 @@
>   * @reg_num: number of contiguous registers after each reg_base (including 
> it)
>   */
>  int amvdec_set_canvases(struct amvdec_session *sess,
> - u32 reg_base[], u32 reg_num[]);
> + const u32 reg_base[], const u32 reg_num[]);
>  
>  /* Helpers to read/write to the various IPs (DOS, PARSER) */
>  u32 amvdec_read_dos(struct amvdec_core *core, u32 reg);
> 



Re: [PATCH 1/2] media: zoran: add spaces around '<<'

2021-04-09 Thread Hans Verkuil
On 09/04/2021 17:11, Mitali Borkar wrote:
> On Fri, Apr 09, 2021 at 09:23:22AM +0200, Hans Verkuil wrote:
>> Hi Mitali,
>>
>> On 08/04/2021 22:38, Mitali Borkar wrote:
>>> Added spaces around '<<' operator to improve readability and meet linux
>>> kernel coding style.
>>> Reported by checkpatch
>>>
>>> Signed-off-by: Mitali Borkar 
>>> ---
>>>  drivers/staging/media/zoran/zr36057.h | 14 +++---
>>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/staging/media/zoran/zr36057.h 
>>> b/drivers/staging/media/zoran/zr36057.h
>>> index 71b651add35a..a2a75fd9f535 100644
>>> --- a/drivers/staging/media/zoran/zr36057.h
>>> +++ b/drivers/staging/media/zoran/zr36057.h
>>> @@ -30,13 +30,13 @@
>>>  #define ZR36057_VFESPFR_HOR_DCM  14
>>>  #define ZR36057_VFESPFR_VER_DCM  8
>>>  #define ZR36057_VFESPFR_DISP_MODE6
>>> -#define ZR36057_VFESPFR_YUV422  (0<<3)
>>> -#define ZR36057_VFESPFR_RGB888  (1<<3)
>>> -#define ZR36057_VFESPFR_RGB565  (2<<3)
>>> -#define ZR36057_VFESPFR_RGB555  (3<<3)
>>> -#define ZR36057_VFESPFR_ERR_DIF  (1<<2)
>>> -#define ZR36057_VFESPFR_PACK24  (1<<1)
>>> -#define ZR36057_VFESPFR_LITTLE_ENDIAN(1<<0)
>>> +#define ZR36057_VFESPFR_YUV422  (0 << 3)
>>> +#define ZR36057_VFESPFR_RGB888  (1 << 3)
>>> +#define ZR36057_VFESPFR_RGB565  (2 << 3)
>>> +#define ZR36057_VFESPFR_RGB555  (3 << 3)
>>> +#define ZR36057_VFESPFR_ERR_DIF  (1 << 2)
>>> +#define ZR36057_VFESPFR_PACK24  (1 << 1)
>>> +#define ZR36057_VFESPFR_LITTLE_ENDIAN(1 << 0)
>>>  
>>>  #define ZR36057_VDTR0x00c  /* Video Display "Top" Register 
>>> */
>>>  
>>>
>>
>> I looked at that header and it is very messy.
>>
>> Can you make two new patches? The first aligns every nicely, e.g. this:
>>
>> #define ZR36057_VFEHCR  0x000   /* Video Front End, Horizontal 
>> Configuration Register */
>> #define ZR36057_VFEHCR_HS_POL BIT(30)
>> #define ZR36057_VFEHCR_H_START   10
>> #define ZR36057_VFEHCR_H_END0
>> #define ZR36057_VFEHCR_HMASK0x3ff
>>
>> should become:
>>
>> /* Video Front End, Horizontal Configuration Register */
>> #define ZR36057_VFEHCR   0x000
>> #define ZR36057_VFEHCR_HS_POLBIT(30)
>> #define ZR36057_VFEHCR_H_START   10
>> #define ZR36057_VFEHCR_H_END 0
>> #define ZR36057_VFEHCR_HMASK 0x3ff
>>
>> Same for all the other register blocks. Use tabs to do the alignment
>> instead of spaces, as is currently the case.
>>
> Okay Sir, will do this.
> 
>> The second patch can replace the (0<<3) etc. to BIT(0).
>>
> Sir may I know how to write (2<<3) in BIT() form? Like I am still
> learning and not sure how to convert this. Should it be BIT(2)? But this
> is only possible for (1< 
> Thanks.
> 
>> That would be a nice cleanup of this rather messy header.
>>
>> Thanks!
>>
>>  Hans



Re: [PATCH v2] staging: media: zoran: remove and add '*' in long(multi-line) comments

2021-04-09 Thread Hans Verkuil
On 09/04/2021 12:49, Mitali Borkar wrote:
> Added '*' before every line inside long(multi-line) comments. Removed
> '*/' from end of the comment line and added to next line as per linux
> kernel coding style. Aligned '*' accordingly to make code neater.
> 
> Signed-off-by: Mitali Borkar 
> ---
> 
> Changes from v1:- Changes made in code according to linux kernel coding
> style for long(multi-line) comments.
> 
> drivers/staging/media/zoran/zr36050.c | 138 +++---
>  1 file changed, 81 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/staging/media/zoran/zr36050.c 
> b/drivers/staging/media/zoran/zr36050.c
> index 663ac2b3434e..703064009c6b 100644
> --- a/drivers/staging/media/zoran/zr36050.c
> +++ b/drivers/staging/media/zoran/zr36050.c
> @@ -25,7 +25,8 @@
>  #include "videocodec.h"
>  
>  /* it doesn't make sense to have more than 20 or so,

The coding style says that /* is on a line of its own. So change that too.

Regards,

Hans

> - * just to prevent some unwanted loops */
> + * just to prevent some unwanted loops
> + */
>  #define MAX_CODECS 20
>  
>  /* amount of chips attached via this driver */
> @@ -44,9 +45,10 @@ MODULE_PARM_DESC(debug, "Debug level (0-4)");
>  
>  /* =
>   *  Local hardware I/O functions:
> -
> -   read/write via codec layer (registers are located in the master device)
> -   = 
> */
> + *
> + *  read/write via codec layer (registers are located in the master device)
> + * =
> + */
>  
>  /* read and write functions */
>  static u8 zr36050_read(struct zr36050 *ptr, u16 reg)
> @@ -81,9 +83,10 @@ static void zr36050_write(struct zr36050 *ptr, u16 reg, u8 
> value)
>  
>  /* =
>   *  Local helper function:
> -
> -   status read
> -   = 
> */
> + *
> + *  status read
> + * =
> + */
>  
>  /* status is kept in datastructure */
>  static u8 zr36050_read_status1(struct zr36050 *ptr)
> @@ -96,9 +99,10 @@ static u8 zr36050_read_status1(struct zr36050 *ptr)
>  
>  /* =
>   *  Local helper function:
> -
> -   scale factor read
> -   = 
> */
> + *
> + *  scale factor read
> + * =
> + */
>  
>  /* scale factor is kept in datastructure */
>  static u16 zr36050_read_scalefactor(struct zr36050 *ptr)
> @@ -113,9 +117,10 @@ static u16 zr36050_read_scalefactor(struct zr36050 *ptr)
>  
>  /* =
>   *  Local helper function:
> -
> -   wait if codec is ready to proceed (end of processing) or time is over
> -   = 
> */
> + *
> + *  wait if codec is ready to proceed (end of processing) or time is over
> + * =
> + */
>  
>  static void zr36050_wait_end(struct zr36050 *ptr)
>  {
> @@ -134,9 +139,10 @@ static void zr36050_wait_end(struct zr36050 *ptr)
>  
>  /* =
>   *  Local helper function:
> -
> -   basic test of "connectivity", writes/reads to/from memory the SOF marker
> -   = 
> */
> + *
> + *  basic test of "connectivity", writes/reads to/from memory the SOF marker
> + * =
> + */
>  
>  static int zr36050_basic_test(struct zr36050 *ptr)
>  {
> @@ -175,9 +181,10 @@ static int zr36050_basic_test(struct zr36050 *ptr)
>  
>  /* =
>   *  Local helper function:
> -
> -   simple loop for pushing the init datasets
> -   = 
> */
> + *
> + *  simple loop for pushing the init datasets
> + * =
> + */
>  
>  static int zr36050_pushit(struct zr36050 *ptr, u16 startreg, u16 len, const 
> char *data)
>  {
> @@ -193,14 +200,15 @@ static int zr36050_pushit(struct zr36050 *ptr, u16 
> startreg, u16 len, const char
>  
>  /* =
>   *  Basic datasets:
> -
> -   jpeg baseline setup data (you find it on lots places in internet, or just
> -   extract it from any regular .jpg image...)
> -
> -   Could be variable, but until it's not needed it they 

Re: [PATCH] staging: media: zoran: add '*' in subsequent line

2021-04-09 Thread Hans Verkuil
Hi Mitali,

On 09/04/2021 01:05, Mitali Borkar wrote:
> Added '*' in susbsequent lines for block comments to meet linux kernel
> coding style.
> 
> Signed-off-by: Mitali Borkar 
> ---
>  drivers/staging/media/zoran/zr36050.c | 34 +--
>  1 file changed, 17 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/staging/media/zoran/zr36050.c 
> b/drivers/staging/media/zoran/zr36050.c
> index 2826f4e5d37b..663ac2b3434e 100644
> --- a/drivers/staging/media/zoran/zr36050.c
> +++ b/drivers/staging/media/zoran/zr36050.c
> @@ -25,7 +25,7 @@
>  #include "videocodec.h"
>  
>  /* it doesn't make sense to have more than 20 or so,
> -  just to prevent some unwanted loops */
> + * just to prevent some unwanted loops */

Use proper coding style for long comments:

/*
 * text
 * text
 */

checkpatch.pl warns about that, so did you run checkpatch.pl after your 
modifications
were made? After fixing checkpatch issues, always run it again to make sure the 
issue
is really fixed and not just replaced by another issue.

Regards,

Hans

>  #define MAX_CODECS 20
>  
>  /* amount of chips attached via this driver */
> @@ -43,7 +43,7 @@ MODULE_PARM_DESC(debug, "Debug level (0-4)");
>   } while (0)
>  
>  /* =
> -   Local hardware I/O functions:
> + *  Local hardware I/O functions:
>  
> read/write via codec layer (registers are located in the master device)
> = 
> */
> @@ -80,7 +80,7 @@ static void zr36050_write(struct zr36050 *ptr, u16 reg, u8 
> value)
>  }
>  
>  /* =
> -   Local helper function:
> + *  Local helper function:
>  
> status read
> = 
> */
> @@ -95,7 +95,7 @@ static u8 zr36050_read_status1(struct zr36050 *ptr)
>  }
>  
>  /* =
> -   Local helper function:
> + *  Local helper function:
>  
> scale factor read
> = 
> */
> @@ -112,7 +112,7 @@ static u16 zr36050_read_scalefactor(struct zr36050 *ptr)
>  }
>  
>  /* =
> -   Local helper function:
> + *  Local helper function:
>  
> wait if codec is ready to proceed (end of processing) or time is over
> = 
> */
> @@ -133,7 +133,7 @@ static void zr36050_wait_end(struct zr36050 *ptr)
>  }
>  
>  /* =
> -   Local helper function:
> + *  Local helper function:
>  
> basic test of "connectivity", writes/reads to/from memory the SOF marker
> = 
> */
> @@ -174,7 +174,7 @@ static int zr36050_basic_test(struct zr36050 *ptr)
>  }
>  
>  /* =
> -   Local helper function:
> + *  Local helper function:
>  
> simple loop for pushing the init datasets
> = 
> */
> @@ -192,7 +192,7 @@ static int zr36050_pushit(struct zr36050 *ptr, u16 
> startreg, u16 len, const char
>  }
>  
>  /* =
> -   Basic datasets:
> + *  Basic datasets:
>  
> jpeg baseline setup data (you find it on lots places in internet, or just
> extract it from any regular .jpg image...)
> @@ -294,7 +294,7 @@ static const char zr36050_decimation_h[8] = { 2, 1, 1, 0, 
> 0, 0, 0, 0 };
>  static const char zr36050_decimation_v[8] = { 1, 1, 1, 0, 0, 0, 0, 0 };
>  
>  /* =
> -   Local helper functions:
> + *  Local helper functions:
>  
> calculation and setup of parameter-dependent JPEG baseline segments
> (needed for compression only)
> @@ -303,7 +303,7 @@ static const char zr36050_decimation_v[8] = { 1, 1, 1, 0, 
> 0, 0, 0, 0 };
>  /* - 
> */
>  
>  /* SOF (start of frame) segment depends on width, height and sampling ratio
> -  of each color component */
> + *of each color component */
>  
>  static int zr36050_set_sof(struct zr36050 *ptr)
>  {
> @@ -334,7 +334,7 @@ static int zr36050_set_sof(struct zr36050 *ptr)
>  /* - 
> */
>  
>  /* SOS (start of scan) segment depends on the used scan components
> - of each color component */
> + *   of each color component */
>  
>  static int zr36050_set_sos(struct zr36050 *ptr)
>  

Re: [PATCH] staging: media: meson: vdec: matched alignment with parenthesis

2021-04-09 Thread Hans Verkuil
On 09/04/2021 00:19, Mitali Borkar wrote:
> Matched alignment with open parenthesis to meet linux kernel coding
> style.
> Reported by checkpatch
> 
> Signed-off-by: Mitali Borkar 
> ---
>  drivers/staging/media/meson/vdec/codec_mpeg12.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/meson/vdec/codec_mpeg12.c 
> b/drivers/staging/media/meson/vdec/codec_mpeg12.c
> index 48869cc3d973..21e93a13356c 100644
> --- a/drivers/staging/media/meson/vdec/codec_mpeg12.c
> +++ b/drivers/staging/media/meson/vdec/codec_mpeg12.c
> @@ -81,7 +81,7 @@ static int codec_mpeg12_start(struct amvdec_session *sess)
>   }
>  
>   ret = amvdec_set_canvases(sess, (u32[]){ AV_SCRATCH_0, 0 },
> - (u32[]){ 8, 0 });
> +   (u32[]){ 8, 0 });

The alignment here is because the 2nd and 3rd arguments belong together, so
the alignment indicates that. In order to keep that I would add a newline
after 'sess,' as well. Same as is done in meson/vdec/codec_h264.c.

Regards,

Hans

>   if (ret)
>   goto free_workspace;
>  
> 



Re: [PATCH] staging: media: zoran: reduce length of a line

2021-04-09 Thread Hans Verkuil
Hi Mitali,

Something to improve:

On 08/04/2021 23:21, Mitali Borkar wrote:
> Reduced length of a line which exceed the 100 columns limit by splitting
> the line into two statements and commenting it with '*'
> Reported by checkpatch.
> 
> Signed-off-by: Mitali Borkar 
> ---
>  drivers/staging/media/zoran/zr36060.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/zoran/zr36060.c 
> b/drivers/staging/media/zoran/zr36060.c
> index 4f9eb9ff2c42..035634fc1c6d 100644
> --- a/drivers/staging/media/zoran/zr36060.c
> +++ b/drivers/staging/media/zoran/zr36060.c
> @@ -249,7 +249,9 @@ static const char zr36060_ta[8] = { 0, 1, 1, 0, 0, 0, 0, 
> 0 }; //table idx's AC
>  static const char zr36060_decimation_h[8] = { 2, 1, 1, 0, 0, 0, 0, 0 };
>  static const char zr36060_decimation_v[8] = { 1, 1, 1, 0, 0, 0, 0, 0 };
>  
> -/* SOF (start of frame) segment depends on width, height and sampling ratio 
> of each color component */
> +/* SOF (start of frame) segment depends on width,
> + * height and sampling ratio of each color component
> + */

See the coding style guidelines: the preferred style for long comments is:

/*
 * text
 * text
 */

Regards,

Hans

>  static int zr36060_set_sof(struct zr36060 *ptr)
>  {
>   char sof_data[34];  // max. size of register set
> 



Re: [PATCH 1/2] media: zoran: add spaces around '<<'

2021-04-09 Thread Hans Verkuil
Hi Mitali,

On 08/04/2021 22:38, Mitali Borkar wrote:
> Added spaces around '<<' operator to improve readability and meet linux
> kernel coding style.
> Reported by checkpatch
> 
> Signed-off-by: Mitali Borkar 
> ---
>  drivers/staging/media/zoran/zr36057.h | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/media/zoran/zr36057.h 
> b/drivers/staging/media/zoran/zr36057.h
> index 71b651add35a..a2a75fd9f535 100644
> --- a/drivers/staging/media/zoran/zr36057.h
> +++ b/drivers/staging/media/zoran/zr36057.h
> @@ -30,13 +30,13 @@
>  #define ZR36057_VFESPFR_HOR_DCM  14
>  #define ZR36057_VFESPFR_VER_DCM  8
>  #define ZR36057_VFESPFR_DISP_MODE6
> -#define ZR36057_VFESPFR_YUV422  (0<<3)
> -#define ZR36057_VFESPFR_RGB888  (1<<3)
> -#define ZR36057_VFESPFR_RGB565  (2<<3)
> -#define ZR36057_VFESPFR_RGB555  (3<<3)
> -#define ZR36057_VFESPFR_ERR_DIF  (1<<2)
> -#define ZR36057_VFESPFR_PACK24  (1<<1)
> -#define ZR36057_VFESPFR_LITTLE_ENDIAN(1<<0)
> +#define ZR36057_VFESPFR_YUV422  (0 << 3)
> +#define ZR36057_VFESPFR_RGB888  (1 << 3)
> +#define ZR36057_VFESPFR_RGB565  (2 << 3)
> +#define ZR36057_VFESPFR_RGB555  (3 << 3)
> +#define ZR36057_VFESPFR_ERR_DIF  (1 << 2)
> +#define ZR36057_VFESPFR_PACK24  (1 << 1)
> +#define ZR36057_VFESPFR_LITTLE_ENDIAN(1 << 0)
>  
>  #define ZR36057_VDTR0x00c/* Video Display "Top" Register 
> */
>  
> 

I looked at that header and it is very messy.

Can you make two new patches? The first aligns every nicely, e.g. this:

#define ZR36057_VFEHCR  0x000   /* Video Front End, Horizontal 
Configuration Register */
#define ZR36057_VFEHCR_HS_POL BIT(30)
#define ZR36057_VFEHCR_H_START   10
#define ZR36057_VFEHCR_H_END0
#define ZR36057_VFEHCR_HMASK0x3ff

should become:

/* Video Front End, Horizontal Configuration Register */
#define ZR36057_VFEHCR  0x000
#define ZR36057_VFEHCR_HS_POL   BIT(30)
#define ZR36057_VFEHCR_H_START  10
#define ZR36057_VFEHCR_H_END0
#define ZR36057_VFEHCR_HMASK0x3ff

Same for all the other register blocks. Use tabs to do the alignment
instead of spaces, as is currently the case.

The second patch can replace the (0<<3) etc. to BIT(0).

That would be a nice cleanup of this rather messy header.

Thanks!

Hans


Re: [PATCH 0/7] staging: media: zoran: Eliminate camelcase

2021-04-07 Thread Hans Verkuil
Hi Zhansaya,

On 03/04/2021 20:08, Zhansaya Bagdauletkyzy wrote:
> This patchset fixes 'avoid camelcase' warning by converting local variables 
> to lowercase and separating words using '_'.
> Renaming of each variable is implemented in separate patches.
> 
> Zhansaya Bagdauletkyzy (7):
>   Rename 'HEnd' to 'h_end'
>   Rename 'VEnd' to 'v_end'
>   Rename 'DispMode' to 'disp_mode'
>   Rename 'VidWinWid' to 'vid_win_wid'
>   Rename 'VidWinHt' to 'vid_win_ht'
>   Rename 'We' to 'we'
>   Rename 'He' to 'he'
> 
>  drivers/staging/media/zoran/zoran_device.c | 48 +++---
>  1 file changed, 24 insertions(+), 24 deletions(-)
> 

Looks good. I'll take these patches.

You can use this reference to record your contributions:

https://patchwork.linuxtv.org/project/linux-media/list/?series=5052

The patch states will change to Accepted once it is merged in our media tree
here: https://git.linuxtv.org/media_tree.git/log/

I hate CamelCase, so this is a nice cleanup :-)

Regards,

Hans



Re: [PATCH 2/2] staging: media: omap4iss: align arguments with open parenthesis

2021-04-07 Thread Hans Verkuil
Hi Beatriz,

On 01/04/2021 17:07, Beatriz Martins de Carvalho wrote:
> Cleans up checks of "Alignment should match open parenthesis"
> in iss.c:96.

Looks good. I'll take this patch.

You can use this reference to record your contribution:

https://patchwork.linuxtv.org/project/linux-media/patch/475dbbe5774cbfed2d924807d8a3cfeb84b3d845.1617287509.git.martinsdecarvalhobeat...@gmail.com/

The state will change to Accepted once it is merged in our media tree
here: https://git.linuxtv.org/media_tree.git/log/

Regards,

Hans

> 
> Signed-off-by: Beatriz Martins de Carvalho 
> 
> ---
>  drivers/staging/media/omap4iss/iss.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss.c 
> b/drivers/staging/media/omap4iss/iss.c
> index e8f724dbf810..472f1837632e 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -963,7 +963,7 @@ iss_register_subdev_group(struct iss_device *iss,
>   }
>  
>   subdev = v4l2_i2c_new_subdev_board(>v4l2_dev, adapter,
> - board_info->board_info, NULL);
> +board_info->board_info, 
> NULL);
>   if (!subdev) {
>   dev_err(iss->dev, "Unable to register subdev %s\n",
>   board_info->board_info->type);
> 



Re: [PATCH] staging: axis-fifo: media/meson: remove redundant dev_err call

2021-04-07 Thread Hans Verkuil
Hi Muhammad,

On 07/04/2021 12:10, Muhammad Usama Anjum wrote:
> devm_ioremap_resource() prints error message in itself. Remove the
> dev_err call to avoid redundant error message.

Please split this up into two separate patches! They are independent
changes and these two drivers are maintained by different people as well.

The patch itself looks OK, but it really has to be two separate patches.

Regards,

Hans

> 
> Signed-off-by: Muhammad Usama Anjum 
> ---
>  drivers/staging/axis-fifo/axis-fifo.c   | 1 -
>  drivers/staging/media/meson/vdec/vdec.c | 8 ++--
>  2 files changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/staging/axis-fifo/axis-fifo.c 
> b/drivers/staging/axis-fifo/axis-fifo.c
> index 2bb1c2e9cb57..ed9281089738 100644
> --- a/drivers/staging/axis-fifo/axis-fifo.c
> +++ b/drivers/staging/axis-fifo/axis-fifo.c
> @@ -853,7 +853,6 @@ static int axis_fifo_probe(struct platform_device *pdev)
>   fifo->base_addr = devm_ioremap_resource(fifo->dt_device, r_mem);
>   if (IS_ERR(fifo->base_addr)) {
>   rc = PTR_ERR(fifo->base_addr);
> - dev_err(fifo->dt_device, "can't remap IO resource (%d)\n", rc);
>   goto err_initial;
>   }
>  
> diff --git a/drivers/staging/media/meson/vdec/vdec.c 
> b/drivers/staging/media/meson/vdec/vdec.c
> index 5d4db7a5b4b5..e51d69c4729d 100644
> --- a/drivers/staging/media/meson/vdec/vdec.c
> +++ b/drivers/staging/media/meson/vdec/vdec.c
> @@ -1008,17 +1008,13 @@ static int vdec_probe(struct platform_device *pdev)
>  
>   r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dos");
>   core->dos_base = devm_ioremap_resource(dev, r);
> - if (IS_ERR(core->dos_base)) {
> - dev_err(dev, "Couldn't remap DOS memory\n");
> + if (IS_ERR(core->dos_base))
>   return PTR_ERR(core->dos_base);
> - }
>  
>   r = platform_get_resource_byname(pdev, IORESOURCE_MEM, "esparser");
>   core->esparser_base = devm_ioremap_resource(dev, r);
> - if (IS_ERR(core->esparser_base)) {
> - dev_err(dev, "Couldn't remap ESPARSER memory\n");
> + if (IS_ERR(core->esparser_base))
>   return PTR_ERR(core->esparser_base);
> - }
>  
>   core->regmap_ao =
>   syscon_regmap_lookup_by_phandle(dev->of_node,
> 



Re: [PATCH] media: platform: sti: Fix rumtime PM imbalance in regs_show

2021-04-07 Thread Hans Verkuil
On 07/04/2021 07:43, Dinghao Liu wrote:
> pm_runtime_get_sync() will increase the rumtime PM counter
> even it returns an error. Thus a pairing decrement is needed
> to prevent refcount leak. Fix this by replacing this API with
> pm_runtime_resume_and_get(), which will not change the runtime
> PM counter on error.

Nice that a new function was created for this. Good news.

Just a heads up: if you make more patches like this, make sure you
fix the typo 'rumtime' to 'runtime'. I'll fix it manually, no need
to repost. And 'rumtime' does sound tasty!

Regards,

Hans

> 
> Signed-off-by: Dinghao Liu 
> ---
>  drivers/media/platform/sti/bdisp/bdisp-debug.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-debug.c 
> b/drivers/media/platform/sti/bdisp/bdisp-debug.c
> index 2b270093009c..a27f638df11c 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-debug.c
> +++ b/drivers/media/platform/sti/bdisp/bdisp-debug.c
> @@ -480,7 +480,7 @@ static int regs_show(struct seq_file *s, void *data)
>   int ret;
>   unsigned int i;
>  
> - ret = pm_runtime_get_sync(bdisp->dev);
> + ret = pm_runtime_resume_and_get(bdisp->dev);
>   if (ret < 0) {
>   seq_puts(s, "Cannot wake up IP\n");
>   return 0;
> 



Re: [PATCH 1/2] staging: media: omap4iss: Ending line with argument

2021-04-07 Thread Hans Verkuil
Hi Beatriz,

I'm now reviewing staging/media patches instead of Greg KH. See Vaishali's
email from today: "Sending patches for the drivers/staging/media".

On 01/04/2021 17:07, Beatriz Martins de Carvalho wrote:
> Remove checkpatch check "CHECK: Lines should not end with a '('" with
> argument present in next line and reorganize characters so the lines
> are under 100 columns
> 
> Signed-off-by: Beatriz Martins de Carvalho 
> 
> ---
>  drivers/staging/media/omap4iss/iss.c | 46 +---
>  1 file changed, 22 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/staging/media/omap4iss/iss.c 
> b/drivers/staging/media/omap4iss/iss.c
> index dae9073e7d3c..e8f724dbf810 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -559,9 +559,10 @@ static int iss_reset(struct iss_device *iss)
>   iss_reg_set(iss, OMAP4_ISS_MEM_TOP, ISS_HL_SYSCONFIG,
>   ISS_HL_SYSCONFIG_SOFTRESET);
>  
> - timeout = iss_poll_condition_timeout(
> - !(iss_reg_read(iss, OMAP4_ISS_MEM_TOP, ISS_HL_SYSCONFIG) &
> - ISS_HL_SYSCONFIG_SOFTRESET), 1000, 10, 100);
> + timeout = iss_poll_condition_timeout(!(iss_reg_read(iss,
> + OMAP4_ISS_MEM_TOP, 
> ISS_HL_SYSCONFIG)
> + & 
> ISS_HL_SYSCONFIG_SOFTRESET),
> + 1000, 10, 100);
>   if (timeout) {
>   dev_err(iss->dev, "ISS reset timeout\n");
>   return -ETIMEDOUT;
> @@ -583,9 +584,10 @@ static int iss_isp_reset(struct iss_device *iss)
>  
>   iss_reg_set(iss, OMAP4_ISS_MEM_ISP_SYS1, ISP5_CTRL, ISP5_CTRL_MSTANDBY);
>  
> - timeout = iss_poll_condition_timeout(
> - iss_reg_read(iss, OMAP4_ISS_MEM_ISP_SYS1, ISP5_CTRL) &
> - ISP5_CTRL_MSTANDBY_WAIT, 100, 1000, 1500);
> + timeout = iss_poll_condition_timeout(iss_reg_read(iss,
> +   
> OMAP4_ISS_MEM_ISP_SYS1, ISP5_CTRL)
> +   & 
> ISP5_CTRL_MSTANDBY_WAIT, 100,
> +   1000, 1500);
>   if (timeout) {
>   dev_err(iss->dev, "ISP5 standby timeout\n");
>   return -ETIMEDOUT;
> @@ -595,9 +597,10 @@ static int iss_isp_reset(struct iss_device *iss)
>   iss_reg_set(iss, OMAP4_ISS_MEM_ISP_SYS1, ISP5_SYSCONFIG,
>   ISP5_SYSCONFIG_SOFTRESET);
>  
> - timeout = iss_poll_condition_timeout(
> - !(iss_reg_read(iss, OMAP4_ISS_MEM_ISP_SYS1, ISP5_SYSCONFIG) &
> - ISP5_SYSCONFIG_SOFTRESET), 100, 1000, 1500);
> + timeout = iss_poll_condition_timeout(!(iss_reg_read(iss, 
> OMAP4_ISS_MEM_ISP_SYS1,
> + ISP5_SYSCONFIG) &
> + 
> ISP5_SYSCONFIG_SOFTRESET), 100,
> + 1000, 1500);

As several other people already commented, these changes do not improve 
readability.
Just leave this code alone, it's good enough. Even splitting up the condition 
into
a separate function would degrade readability since that would make it harder to
discover the exact condition that will be polled for.

Not everything that checkpatch.pl flags is necessarily bad code :-)

>   if (timeout) {
>   dev_err(iss->dev, "ISP5 reset timeout\n");
>   return -ETIMEDOUT;
> @@ -1104,33 +1107,28 @@ static int iss_create_links(struct iss_device *iss)
>   }
>  
>   /* Connect the submodules. */
> - ret = media_create_pad_link(
> - >csi2a.subdev.entity, CSI2_PAD_SOURCE,
> - >ipipeif.subdev.entity, IPIPEIF_PAD_SINK, 0);
> + ret = media_create_pad_link(>csi2a.subdev.entity, CSI2_PAD_SOURCE,
> + >ipipeif.subdev.entity, 
> IPIPEIF_PAD_SINK, 0);
>   if (ret < 0)
>   return ret;
>  
> - ret = media_create_pad_link(
> - >csi2b.subdev.entity, CSI2_PAD_SOURCE,
> - >ipipeif.subdev.entity, IPIPEIF_PAD_SINK, 0);
> + ret = media_create_pad_link(>csi2b.subdev.entity, CSI2_PAD_SOURCE,
> + >ipipeif.subdev.entity, 
> IPIPEIF_PAD_SINK, 0);
>   if (ret < 0)
>   return ret;
>  
> - ret = media_create_pad_link(
> - >ipipeif.subdev.entity, IPIPEIF_PAD_SOURCE_VP,
> - >resizer.subdev.entity, RESIZER_PAD_SINK, 0);
> + ret = media_create_pad_link(>ipipeif.subdev.entity, 
> IPIPEIF_PAD_SOURCE_VP,
> + >resizer.subdev.entity, 
> RESIZER_PAD_SINK, 0);
>   if (ret < 0)
>   return ret;
>  
> - ret = media_create_pad_link(
> - >ipipeif.subdev.entity, 

Re: [PATCH] media: Fix compilation error

2021-04-07 Thread Hans Verkuil
On 02/04/2021 09:40, Bixuan Cui wrote:
> Fix the error:
> 
> drivers/staging/media/tegra-video/vi.c:1180:4:
> error: implicit declaration of function 'host1x_syncpt_free' 
> [-Werror,-Wimplicit-function-declaration]

Against what tree is this being built? The mainline kernel doesn't have
host1x_syncpt_put, only host1x_syncpt_free.

Also, the subject line is very vague, something like this is much more 
descriptive:

[PATCH] media: tegra-video: replace host1x_syncpt_free by host1x_syncpt_put

Regards,

Hans

> 
> Fixes: 3028a00c55bf ('gpu: host1x: Cleanup and refcounting for syncpoints')
> Reported-by: Hulk Robot 
> Signed-off-by: Bixuan Cui 
> ---
>  drivers/staging/media/tegra-video/vi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/tegra-video/vi.c 
> b/drivers/staging/media/tegra-video/vi.c
> index 7e0cb5529b49..df5ca3596470 100644
> --- a/drivers/staging/media/tegra-video/vi.c
> +++ b/drivers/staging/media/tegra-video/vi.c
> @@ -1177,7 +1177,7 @@ static int tegra_channel_host1x_syncpt_init(struct 
> tegra_vi_channel *chan)
>   mw_sp = host1x_syncpt_request(>client, flags);
>   if (!mw_sp) {
>   dev_err(vi->dev, "failed to request memory ack 
> syncpoint\n");
> - host1x_syncpt_free(fs_sp);
> + host1x_syncpt_put(fs_sp);
>   ret = -ENOMEM;
>   goto free_syncpts;
>   }
> 



Re: [PATCH v2 00/30] media: atmel: atmel-isc: add support for xisc

2021-04-07 Thread Hans Verkuil
Hi Eugen,

On 05/04/2021 17:50, Eugen Hristev wrote:
> Hello,
> 
> This series adds support for a variant of the ISC named XISC.
> This block is present in the product named sama7g5.
> 
> I started by moving code around, the code which was specialized for sama5d2
> type of ISC, to have it inside the dedicated sama5d2 file.
> 
> I added several new pipeline elements to the code base, which would be common
> to sama5d2 and the new sama7g5, but only used by the new style pipeline.
> 
> I separated the input and output formats on a per-product separate array.
> 
> I added the new sama7g5 compatible driver for the xisc, which is similar with
> the sama5d2, but with differences in terms of DT, clocks and callbacks to
> specific operations.
> 
> I added the binding for the xisc by copying and modifying the existing
> isc one. I know that it has to be converted to yaml, and I will do that if
> it looks good.

This series looks good to me.

One thing that can be improved in a v3 is a short explanation of the various
abbreviations: CBV, RLP, HIS, DPC, etc.

Regards,

Hans

> 
> Feedback is appreciated.
> Thanks,
> Eugen
> 
> Changes in v2:
> - Fixed krobot warnings with W=1 regarding functions with no prototype
> - Fixed new sama7g5 driver to use the new subdev fwnode API in kernel 5.12. 
> my driver was
> based on old 5.10 style API.
> 
> Eugen Hristev (30):
>   media: atmel: atmel-isc: specialize gamma table into product specific
>   media: atmel: atmel-isc: specialize driver name constant
>   media: atmel: atmel-isc: add checks for limiting frame sizes
>   media: atmel: atmel-isc: specialize max width and max height
>   media: atmel: atmel-isc: specialize dma cfg
>   media: atmel: atmel-isc: extract CSC submodule config into separate
> function
>   media: atmel: atmel-isc-base: add id to clock debug message
>   media: atmel: atmel-isc: create register offsets struct
>   media: atmel: atmel-isc: extract CBC submodule config into separate
> function
>   media: atmel: atmel-isc: add CBC to the reg offsets struct
>   media: atmel: atmel-isc: add SUB422 and SUB420 to register offsets
>   media: atmel: atmel-isc: add RLP to register offsets
>   media: atmel: atmel-isc: add HIS to register offsets
>   media: atmel: atmel-isc: add DMA to register offsets
>   media: atmel: atmel-isc: add support for version register
>   media: atmel: atmel-isc: add his_entry to register offsets
>   media: atmel: atmel-isc: add register description for additional
> modules
>   media: atmel: atmel-isc: extend pipeline with extra modules
>   media: atmel: atmel-isc: add CC initialization function
>   media: atmel: atmel-isc: create product specific v4l2 controls config
>   media: atmel: atmel-isc: create callback for DPC submodule product
> specific
>   media: atmel: atmel-isc: create callback for GAM submodule product
> specific
>   media: atmel: atmel-isc: create callback for RLP submodule product
> specific
>   media: atmel: atmel-isc: move the formats list into product specific
> code
>   media: atmel: atmel-isc: create an adapt pipeline callback for product
> specific
>   media: atmel: atmel-isc-regs: add additional fields for sama7g5 type
> pipeline
>   media: atmel: atmel-isc-base: add support for more formats and
> additional pipeline modules
>   dt-bindings: media: atmel: add microchip-xisc binding
>   media: atmel: atmel-isc-sama5d2: remove duplicate define
>   media: atmel: atmel-isc: add microchip-xisc driver
> 
>  .../bindings/media/microchip-xisc.txt |  64 ++
>  drivers/media/platform/Makefile   |   1 +
>  drivers/media/platform/atmel/Kconfig  |  11 +
>  drivers/media/platform/atmel/Makefile |   2 +
>  drivers/media/platform/atmel/atmel-isc-base.c | 381 ---
>  drivers/media/platform/atmel/atmel-isc-regs.h | 133 +++-
>  drivers/media/platform/atmel/atmel-isc.h  | 122 +++-
>  .../media/platform/atmel/atmel-sama5d2-isc.c  | 311 -
>  .../media/platform/atmel/atmel-sama7g5-isc.c  | 643 ++
>  9 files changed, 1391 insertions(+), 277 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/media/microchip-xisc.txt
>  create mode 100644 drivers/media/platform/atmel/atmel-sama7g5-isc.c
> 



Re: [PATCH v5 3/3] media: i2c: Introduce a driver for the Techwell TW9900 decoder

2021-04-06 Thread Hans Verkuil
Hi Maxime,

Some comments below:

On 01/04/2021 09:08, Maxime Chevallier wrote:
> The Techwell video decoder supports PAL, NTSC and SECAM input formats,
> and outputs a BT.656 signal.
> 
> This commit adds support for this device, with basic support for NTSC
> and PAL, along with brightness and contrast controls.
> 
> The TW9900 is capable of doing automatic standard detection, this is
> implemented with support for PAL and NTSC autodetection.
> 
> Signed-off-by: Maxime Chevallier 
> ---
> v1 -> v2: Set the media entity type to decoder, and implement the
> s_std/g_std ops
> 
> V2 ->V3 : Fix coding-style issues, and remove the use of the bulk API
> for regulators. Make the driver select the media-controller and
> V4L2-subdev APIs.
> 
> V3->V4: Fix a warning about an uninitialized ret variable in probe()
> 
> V4->V5: Added .querystd() and .g_tvnorms(), dropped the .open() and
> unified the g_fmt() / s_fmt().
> 
>  MAINTAINERS|   6 +
>  drivers/media/i2c/Kconfig  |  11 +
>  drivers/media/i2c/Makefile |   1 +
>  drivers/media/i2c/tw9900.c | 664 +
>  4 files changed, 682 insertions(+)
>  create mode 100644 drivers/media/i2c/tw9900.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d92f85ca831d..d2e57e174b51 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17549,6 +17549,12 @@ L:   linux-me...@vger.kernel.org
>  S:   Maintained
>  F:   drivers/media/rc/ttusbir.c
>  
> +TECHWELL TW9900 VIDEO DECODER
> +M:   Maxime Chevallier 
> +L:   linux-me...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/media/i2c/tw9900.c
> +
>  TECHWELL TW9910 VIDEO DECODER
>  L:   linux-me...@vger.kernel.org
>  S:   Orphan
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 462c0e059754..2dbcee42a915 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -426,6 +426,17 @@ config VIDEO_TW2804
> To compile this driver as a module, choose M here: the
> module will be called tw2804.
>  
> +config VIDEO_TW9900
> + tristate "Techwell TW9900 video decoder"
> + depends on VIDEO_V4L2 && I2C
> + select MEDIA_CONTROLLER
> + select VIDEO_V4L2_SUBDEV_API
> + help
> +   Support for the Techwell tw9900 multi-standard video decoder.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called tw9900.
> +
>  config VIDEO_TW9903
>   tristate "Techwell TW9903 video decoder"
>   depends on VIDEO_V4L2 && I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 0c067beca066..3cc81e00b7da 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -49,6 +49,7 @@ obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
>  obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
>  obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
>  obj-$(CONFIG_VIDEO_TW2804) += tw2804.o
> +obj-$(CONFIG_VIDEO_TW9900) += tw9900.o
>  obj-$(CONFIG_VIDEO_TW9903) += tw9903.o
>  obj-$(CONFIG_VIDEO_TW9906) += tw9906.o
>  obj-$(CONFIG_VIDEO_TW9910) += tw9910.o
> diff --git a/drivers/media/i2c/tw9900.c b/drivers/media/i2c/tw9900.c
> new file mode 100644
> index ..d7a3be4f3daa
> --- /dev/null
> +++ b/drivers/media/i2c/tw9900.c
> @@ -0,0 +1,664 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for the Techwell TW9900 multi-standard video decoder.
> + *
> + * Copyright (C) 2018 Fuzhou Rockchip Electronics Co., Ltd.
> + * Copyright (C) 2020 Maxime Chevallier 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TW9900_REG_CHIP_ID   0x00
> +#define TW9900_REG_CHIP_STATUS   0x01
> +#define TW9900_REG_CHIP_STATUS_VLOCK 0x08
> +#define TW9900_REG_CHIP_STATUS_VDLOSS0x80
> +#define TW9900_REG_OUT_FMT_CTL   0x03
> +#define TW9900_REG_OUT_FMT_CTL_STANDBY   0xA7
> +#define TW9900_REG_OUT_FMT_CTL_STREAMING 0xA0
> +#define TW9900_REG_CKHY_HSDLY0x04
> +#define TW9900_REG_OUT_CTRL_I0x05
> +#define TW9900_REG_ANALOG_CTL0x06
> +#define TW9900_REG_CROP_HI   0x07
> +#define TW9900_REG_VDELAY_LO 0x08
> +#define TW9900_REG_VACTIVE_LO0x09
> +#define TW9900_REG_HACTIVE_LO0x0B
> +#define TW9900_REG_CNTRL10x0C
> +#define TW9900_REG_BRIGHT_CTL0x10
> +#define TW9900_REG_CONTRAST_CTL  0x11
> +#define TW9900_REG_VBI_CNTL  0x19
> +#define TW9900_REG_ANAL_CTL_II   0x1A
> +#define TW9900_REG_OUT_CTRL_II   0x1B
> +#define TW9900_REG_STD_SEL   0x1C
> +#defineTW9900_REG_STD_SEL_AUTODETECT_IN_PROGRESS BIT(7)
> +#define TW9900_REG_STDR  0x1D
> +#define TW9900_REG_MISSCNT   0x26
> +#define TW9900_REG_MISC_CTL_II   0x2F
> +#define TW9900_REG_VVBI  0x55
> +
> +#define TW9900_CHIP_ID   0x00
> +
> +#define VSYNC_POLL_INTERVAL_MS   20
> +#define VSYNC_WAIT_MAX_POLLS 50
> +
> +#define TW9900_STD_NTSC_M0

Re: [PATCH v8 02/13] dt-bindings: media: nxp,imx8mq-vpu: Update the bindings for G2 support

2021-04-06 Thread Hans Verkuil
On 01/04/2021 17:59, Benjamin Gaignard wrote:
> Introducing G2 hevc video decoder lead to modify the bindings to allow
> to get one node per VPUs.

Introducing the G2 hevc video decoder requires modifications of the bindings to 
allow
one node per VPU.

> VPUs share one hardware control block which is provided as a phandle on
> an syscon.

an -> a

> Each node got now one reg and one interrupt.

got now -> has now

> Add a compatible for G2 hardware block: nxp,imx8mq-vpu-g2.
> 
> To be compatible with older DT the driver is still capable to use 'ctrl'

use -> use the

> reg-name even if it is deprecated now.

Regards,

Hans

> 
> Signed-off-by: Benjamin Gaignard 
> Reviewed-by: Rob Herring 
> Reviewed-by: Philipp Zabel 
> ---
> version 7:
> - Add Rob and Philipp reviewed-by tag
> - Change syscon phandle name to nxp,imx8m-vpu-ctrl (remove 'q' to be
>   usable for iMX8MM too)
> 
> version 5:
> - This version doesn't break the backward compatibilty between kernel
>   and DT.
> 
>  .../bindings/media/nxp,imx8mq-vpu.yaml| 53 ---
>  1 file changed, 34 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml 
> b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
> index 762be3f96ce9..18e7d40a5f24 100644
> --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
> +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml
> @@ -15,22 +15,18 @@ description:
>  
>  properties:
>compatible:
> -const: nxp,imx8mq-vpu
> +oneOf:
> +  - const: nxp,imx8mq-vpu
> +  - const: nxp,imx8mq-vpu-g2
>  
>reg:
> -maxItems: 3
> -
> -  reg-names:
> -items:
> -  - const: g1
> -  - const: g2
> -  - const: ctrl
> +maxItems: 1
>  
>interrupts:
> -maxItems: 2
> +maxItems: 1
>  
>interrupt-names:
> -items:
> +oneOf:
>- const: g1
>- const: g2
>  
> @@ -46,14 +42,18 @@ properties:
>power-domains:
>  maxItems: 1
>  
> +  nxp,imx8m-vpu-ctrl:
> +description: Specifies a phandle to syscon VPU hardware control block
> +$ref: "/schemas/types.yaml#/definitions/phandle"
> +
>  required:
>- compatible
>- reg
> -  - reg-names
>- interrupts
>- interrupt-names
>- clocks
>- clock-names
> +  - nxp,imx8m-vpu-ctrl
>  
>  additionalProperties: false
>  
> @@ -62,18 +62,33 @@ examples:
>  #include 
>  #include 
>  
> -vpu: video-codec@3830 {
> +vpu_ctrl: syscon@3832 {
> + compatible = "nxp,imx8mq-vpu-ctrl", "syscon";
> + reg = <0x3832 0x1>;
> +};
> +
> +vpu_g1: video-codec@3830 {
>  compatible = "nxp,imx8mq-vpu";
> -reg = <0x3830 0x1>,
> -  <0x3831 0x1>,
> -  <0x3832 0x1>;
> -reg-names = "g1", "g2", "ctrl";
> -interrupts = ,
> - ;
> -interrupt-names = "g1", "g2";
> +reg = <0x3830 0x1>;
> +interrupts = ;
> +interrupt-names = "g1";
> +clocks = < IMX8MQ_CLK_VPU_G1_ROOT>,
> + < IMX8MQ_CLK_VPU_G2_ROOT>,
> + < IMX8MQ_CLK_VPU_DEC_ROOT>;
> +clock-names = "g1", "g2", "bus";
> +power-domains = <_vpu>;
> +nxp,imx8m-vpu-ctrl = <_ctrl>;
> +};
> +
> +vpu_g2: video-codec@3831 {
> +compatible = "nxp,imx8mq-vpu-g2";
> +reg = <0x3830 0x1>;
> +interrupts = ;
> +interrupt-names = "g2";
>  clocks = < IMX8MQ_CLK_VPU_G1_ROOT>,
>   < IMX8MQ_CLK_VPU_G2_ROOT>,
>   < IMX8MQ_CLK_VPU_DEC_ROOT>;
>  clock-names = "g1", "g2", "bus";
>  power-domains = <_vpu>;
> +nxp,imx8m-vpu-ctrl = <_ctrl>;
>  };
> 



Re: [PATCH v8 01/13] dt-bindings: mfd: Add 'nxp,imx8mq-vpu-ctrl' to syscon list

2021-04-06 Thread Hans Verkuil
Hi Benjamin,

The commit logs in this series have a few too many grammatical
mistakes. And since I want some other changes as well, I'll just
review the text so it can be fixed in v9.

On 01/04/2021 17:59, Benjamin Gaignard wrote:
> Add 'nxp,imx8mq-vpu-ctrl' in the list of possible syscon.

in -> to

> It will used to access to the VPU control registers.

to the -> the

Regards,

Hans

> 
> Signed-off-by: Benjamin Gaignard 
> Acked-by: Rob Herring 
> Acked-by: Lee Jones 
> ---
> version 8:
>  - Add Lee ack
> 
> version 7:
>  - Add Rob ack
> 
>  Documentation/devicetree/bindings/mfd/syscon.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml 
> b/Documentation/devicetree/bindings/mfd/syscon.yaml
> index f14ae6da0068..ae22c4730613 100644
> --- a/Documentation/devicetree/bindings/mfd/syscon.yaml
> +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
> @@ -44,6 +44,7 @@ properties:
>- hisilicon,peri-subctrl
>- microchip,sparx5-cpu-syscon
>- mstar,msc313-pmsleep
> +  - nxp,imx8mq-vpu-ctrl
>- rockchip,px30-qos
>- rockchip,rk3066-qos
>- rockchip,rk3288-qos
> 



Re: [PATCH v4,2/3] arm64: dts: mt8173: Separating mtk-vcodec-enc device node

2021-04-06 Thread Hans Verkuil
Hi Irui,

On 25/03/2021 13:26, Irui Wang wrote:
> There are two separate hardware encoder blocks inside MT8173.
> Split the current mtk-vcodec-enc node to match the hardware architecture.

I've accepted patches 1 & 3, so this patch can be merged by whoever maintains 
these dts
files.

Regards,

Hans

> 
> Acked-by: Tiffany Lin 
> Signed-off-by: Hsin-Yi Wang 
> Signed-off-by: Maoguang Meng 
> Signed-off-by: Irui Wang 
> ---
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi | 60 
>  1 file changed, 31 insertions(+), 29 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 7fa870e4386a..f5950e9fc51d 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -1458,14 +1458,11 @@
>   clock-names = "apb", "smi";
>   };
>  
> - vcodec_enc: vcodec@18002000 {
> + vcodec_enc_avc: vcodec@18002000 {
>   compatible = "mediatek,mt8173-vcodec-enc";
> - reg = <0 0x18002000 0 0x1000>,  /* VENC_SYS */
> -   <0 0x19002000 0 0x1000>;  /* VENC_LT_SYS */
> - interrupts = ,
> -  ;
> - mediatek,larb = <>,
> - <>;
> + reg = <0 0x18002000 0 0x1000>;  /* VENC_SYS */
> + interrupts = ;
> + mediatek,larb = <>;
>   iommus = < M4U_PORT_VENC_RCPU>,
>< M4U_PORT_VENC_REC>,
>< M4U_PORT_VENC_BSDMA>,
> @@ -1476,29 +1473,12 @@
>< M4U_PORT_VENC_REF_LUMA>,
>< M4U_PORT_VENC_REF_CHROMA>,
>< M4U_PORT_VENC_NBM_RDMA>,
> -  < M4U_PORT_VENC_NBM_WDMA>,
> -  < M4U_PORT_VENC_RCPU_SET2>,
> -  < M4U_PORT_VENC_REC_FRM_SET2>,
> -  < M4U_PORT_VENC_BSDMA_SET2>,
> -  < M4U_PORT_VENC_SV_COMA_SET2>,
> -  < M4U_PORT_VENC_RD_COMA_SET2>,
> -  < M4U_PORT_VENC_CUR_LUMA_SET2>,
> -  < M4U_PORT_VENC_CUR_CHROMA_SET2>,
> -  < M4U_PORT_VENC_REF_LUMA_SET2>,
> -  < M4U_PORT_VENC_REC_CHROMA_SET2>;
> +  < M4U_PORT_VENC_NBM_WDMA>;
>   mediatek,vpu = <>;
> - clocks = < CLK_TOP_VENCPLL_D2>,
> -  < CLK_TOP_VENC_SEL>,
> -  < CLK_TOP_UNIVPLL1_D2>,
> -  < CLK_TOP_VENC_LT_SEL>;
> - clock-names = "venc_sel_src",
> -   "venc_sel",
> -   "venc_lt_sel_src",
> -   "venc_lt_sel";
> - assigned-clocks = < CLK_TOP_VENC_SEL>,
> -   < CLK_TOP_VENC_LT_SEL>;
> - assigned-clock-parents = < CLK_TOP_VCODECPLL>,
> -  < 
> CLK_TOP_VCODECPLL_370P5>;
> + clocks = < CLK_TOP_VENC_SEL>;
> + clock-names = "venc_sel";
> + assigned-clocks = < CLK_TOP_VENC_SEL>;
> + assigned-clock-parents = < CLK_TOP_VCODECPLL>;
>   };
>  
>   jpegdec: jpegdec@18004000 {
> @@ -1530,5 +1510,27 @@
>< CLK_VENCLT_CKE0>;
>   clock-names = "apb", "smi";
>   };
> +
> + vcodec_enc_vp8: vcodec@19002000 {
> + compatible = "mediatek,mt8173-vcodec-enc-vp8";
> + reg =  <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */
> + interrupts = ;
> + iommus = < M4U_PORT_VENC_RCPU_SET2>,
> +  < M4U_PORT_VENC_REC_FRM_SET2>,
> +  < M4U_PORT_VENC_BSDMA_SET2>,
> +  < M4U_PORT_VENC_SV_COMA_SET2>,
> +  < M4U_PORT_VENC_RD_COMA_SET2>,
> +  < M4U_PORT_VENC_CUR_LUMA_SET2>,
> +  < M4U_PORT_VENC_CUR_CHROMA_SET2>,
> +  < M4U_PORT_VENC_REF_LUMA_SET2>,
> +  < M4U_PORT_VENC_REC_CHROMA_SET2>;
> + mediatek,larb = <>;
> + mediatek,vpu = <>;
> + clocks = < CLK_TOP_VENC_LT_SEL>;
> + clock-names = "venc_lt_sel";
> + assigned-clocks = < CLK_TOP_VENC_LT_SEL>;
> + assigned-clock-parents =
> +  < 

Re: [PATCH v5 04/10] media: uapi: mpeg2: Split sequence and picture parameters

2021-04-06 Thread Hans Verkuil
On 03/04/2021 20:07, Ezequiel Garcia wrote:
> Typically, bitstreams are composed of a sequence header,
> followed by a number of picture header and picture coding extension
> headers. Each picture can be composed by a number of slices.

by -> of

> 
> Let's split the MPEG-2 uAPI to follow these semantics more closely,
> allowing more usage flexibility. Having these controls splitted

splitted -> split up

> allows applications to set a sequence control at the beginning
> of a sequence, and then set a picture control for each frame.
> 
> While here add padding fields where needed, and document
> the uAPI header thoroughly.
> 
> Note that the V4L2_CTRL_TYPE_{} defines had to be moved because
> it clashes with existing ones. This is not really an issue
> since they will be re-defined when the controls are moved
> out of staging.
> 
> Signed-off-by: Ezequiel Garcia 
> Tested-by: Jonas Karlman 
> ---
>  .../media/v4l/ext-ctrls-codec.rst | 47 ++---
>  .../media/v4l/pixfmt-compressed.rst   |  5 +-
>  .../media/v4l/vidioc-queryctrl.rst| 12 +++
>  .../media/videodev2.h.rst.exceptions  |  2 +
>  drivers/media/v4l2-core/v4l2-ctrls.c  | 57 ---
>  drivers/staging/media/hantro/hantro_drv.c | 10 ++
>  .../media/hantro/hantro_g1_mpeg2_dec.c| 14 +--
>  .../media/hantro/rk3399_vpu_hw_mpeg2_dec.c| 14 +--
>  drivers/staging/media/sunxi/cedrus/cedrus.c   | 12 +++
>  drivers/staging/media/sunxi/cedrus/cedrus.h   |  2 +
>  .../staging/media/sunxi/cedrus/cedrus_dec.c   |  4 +
>  .../staging/media/sunxi/cedrus/cedrus_mpeg2.c |  8 +-
>  include/media/mpeg2-ctrls.h   | 97 +++
>  include/media/v4l2-ctrls.h|  4 +
>  14 files changed, 228 insertions(+), 60 deletions(-)
> 
> diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst 
> b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> index 7d5ac7fb6579..8a0d6139db34 100644
> --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> @@ -1603,14 +1603,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>  * - __u32
>- ``data_bit_offset``
>- Offset (in bits) to the video data in the current slice data.
> -* - struct :c:type:`v4l2_mpeg2_sequence`
> -  - ``sequence``
> -  - Structure with MPEG-2 sequence metadata, merging relevant fields from
> - the sequence header and sequence extension parts of the bitstream.
> -* - struct :c:type:`v4l2_mpeg2_picture`
> -  - ``picture``
> -  - Structure with MPEG-2 picture metadata, merging relevant fields from
> - the picture header and picture coding extension parts of the bitstream.
>  * - __u64
>- ``backward_ref_ts``
>- Timestamp of the V4L2 capture buffer to use as backward reference, 
> used
> @@ -1628,14 +1620,28 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>  * - __u32
>- ``quantiser_scale_code``
>- Code used to determine the quantization scale to use for the IDCT.
> +* - __u8
> +  - ``reserved``
> +  - Applications and drivers must set this to zero.
>  
> -.. c:type:: v4l2_mpeg2_sequence
> +``V4L2_CID_MPEG_VIDEO_MPEG2_SEQUENCE (struct)``
> +Specifies the sequence parameters (as extracted from the bitstream) for 
> the
> +associated MPEG-2 slice data. This includes fields matching the syntax
> +elements from the sequence header and sequence extension parts of the
> +bitstream as specified by :ref:`mpeg2part2`.
> +
> +.. note::
> +
> +   This compound control is not yet part of the public kernel API and
> +   it is expected to change.
> +
> +.. c:type:: v4l2_ctrl_mpeg2_sequence
>  
>  .. cssclass:: longtable
>  
>  .. tabularcolumns:: |p{1.4cm}|p{6.5cm}|p{9.4cm}|
>  
> -.. flat-table:: struct v4l2_mpeg2_sequence
> +.. flat-table:: struct v4l2_ctrl_mpeg2_sequence
>  :header-rows:  0
>  :stub-columns: 0
>  :widths:   1 1 2
> @@ -1657,6 +1663,9 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>  * - __u8
>- ``chroma_format``
>- The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4).
> +* - __u8
> +  - ``reserved``
> +  - Applications and drivers must set this to zero.
>  * - __u32
>- ``flags``
>- See :ref:`MPEG-2 Sequence Flags `.
> @@ -1677,7 +1686,18 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>- Indication that all the frames for the sequence are progressive 
> instead
>   of interlaced.
>  
> -.. c:type:: v4l2_mpeg2_picture
> +``V4L2_CID_MPEG_VIDEO_MPEG2_PICTURE (struct)``
> +Specifies the picture parameters (as extracted from the bitstream) for 
> the
> +associated MPEG-2 slice data. This includes fields matching the syntax
> +elements from the picture header and picture coding extension parts of 
> the
> +bitstream as specified by :ref:`mpeg2part2`.
> 

Re: [PATCH v5 03/10] media: uapi: mpeg2: Cleanup flags

2021-04-06 Thread Hans Verkuil
On 03/04/2021 20:07, Ezequiel Garcia wrote:
> Our current MPEG-2 uAPI uses 1-byte fields for MPEG-2
> boolean syntax elements. Clean these by adding a 'flags'
> field and flag macro for each boolean syntax element.
> 
> A follow-up change will refactor this uAPI so we don't need
> to add padding fields just yet.
> 
> Signed-off-by: Ezequiel Garcia 
> Tested-by: Jonas Karlman 
> ---
>  .../media/v4l/ext-ctrls-codec.rst |  77 +-
>  drivers/media/v4l2-core/v4l2-async-core.c | 880 ++

This doesn't belong in this patch!

Regards,

Hans

>  drivers/media/v4l2-core/v4l2-ctrls.c  |  14 +-
>  .../media/hantro/hantro_g1_mpeg2_dec.c|  76 +-
>  .../media/hantro/rk3399_vpu_hw_mpeg2_dec.c|  76 +-
>  .../staging/media/sunxi/cedrus/cedrus_mpeg2.c |  38 +-
>  include/media/mpeg2-ctrls.h   |  36 +-
>  7 files changed, 1055 insertions(+), 142 deletions(-)
>  create mode 100644 drivers/media/v4l2-core/v4l2-async-core.c
> 
> diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst 
> b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> index d9546f0aa2e8..7d5ac7fb6579 100644
> --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> @@ -1654,13 +1654,28 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>- ``profile_and_level_indication``
>- The current profile and level indication as extracted from the
>   bitstream.
> -* - __u8
> -  - ``progressive_sequence``
> -  - Indication that all the frames for the sequence are progressive 
> instead
> - of interlaced.
>  * - __u8
>- ``chroma_format``
>- The chrominance sub-sampling format (1: 4:2:0, 2: 4:2:2, 3: 4:4:4).
> +* - __u32
> +  - ``flags``
> +  - See :ref:`MPEG-2 Sequence Flags `.
> +
> +.. _mpeg2_sequence_flags:
> +
> +``MPEG-2 Sequence Flags``
> +
> +.. cssclass:: longtable
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 1 2
> +
> +* - ``V4L2_MPEG2_SEQ_FLAG_PROGRESSIVE``
> +  - 0x0001
> +  - Indication that all the frames for the sequence are progressive 
> instead
> + of interlaced.
>  
>  .. c:type:: v4l2_mpeg2_picture
>  
> @@ -1693,29 +1708,45 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>- ``picture_structure``
>- Picture structure (1: interlaced top field, 2: interlaced bottom 
> field,
>   3: progressive frame).
> -* - __u8
> -  - ``top_field_first``
> -  - If set to 1 and interlaced stream, top field is output first.
> -* - __u8
> -  - ``frame_pred_frame_dct``
> -  - If set to 1, only frame-DCT and frame prediction are used.
> -* - __u8
> -  - ``concealment_motion_vectors``
> -  -  If set to 1, motion vectors are coded for intra macroblocks.
> -* - __u8
> -  - ``q_scale_type``
> +* - __u32
> +  - ``flags``
> +  - See :ref:`MPEG-2 Picture Flags `.
> +
> +
> +.. _mpeg2_picture_flags:
> +
> +``MPEG-2 Picture Flags``
> +
> +.. cssclass:: longtable
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 1 2
> +
> +* - ``V4L2_MPEG2_PIC_FLAG_TOP_FIELD_FIRST``
> +  - 0x0001
> +  - If set and it's an interlaced stream, top field is output first.
> +* - ``V4L2_MPEG2_PIC_FLAG_FRAME_PRED_DCT``
> +  - 0x0002
> +  - If set only frame-DCT and frame prediction are used.
> +* - ``V4L2_MPEG2_PIC_FLAG_CONCEALMENT_MV``
> +  - 0x0004
> +  -  If set motion vectors are coded for intra macroblocks.
> +* - ``V4L2_MPEG2_PIC_FLAG_Q_SCALE_TYPE``
> +  - 0x0008
>- This flag affects the inverse quantization process.
> -* - __u8
> -  - ``intra_vlc_format``
> +* - ``V4L2_MPEG2_PIC_FLAG_INTRA_VLC``
> +  - 0x0010
>- This flag affects the decoding of transform coefficient data.
> -* - __u8
> -  - ``alternate_scan``
> +* - ``V4L2_MPEG2_PIC_FLAG_ALT_SCAN``
> +  - 0x0020
>- This flag affects the decoding of transform coefficient data.
> -* - __u8
> -  - ``repeat_first_field``
> +* - ``V4L2_MPEG2_PIC_FLAG_REPEAT_FIRST``
> +  - 0x0040
>- This flag affects the decoding process of progressive frames.
> -* - __u16
> -  - ``progressive_frame``
> +* - ``V4L2_MPEG2_PIC_FLAG_PROGRESSIVE``
> +  - 0x0080
>- Indicates whether the current frame is progressive.
>  
>  .. raw:: latex
> diff --git a/drivers/media/v4l2-core/v4l2-async-core.c 
> b/drivers/media/v4l2-core/v4l2-async-core.c
> new file mode 100644
> index ..cd9e78c63791
> --- /dev/null
> +++ b/drivers/media/v4l2-core/v4l2-async-core.c
> @@ -0,0 +1,880 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * V4L2 asynchronous subdevice registration API
> + *
> + * Copyright (C) 2012-2013, Guennadi Liakhovetski 
> + */
> +
> +#include 

Re: [PATCH v5 02/10] media: uapi: mpeg2: rework quantisation matrices semantics

2021-04-06 Thread Hans Verkuil
On 03/04/2021 20:07, Ezequiel Garcia wrote:
> As stated in the MPEG-2 specification, section 6.3.7 "Quant matrix
> extension":
> 
>   Each quantisation matrix has a default set of values. When a
>   sequence_header_code is decoded all matrices shall be reset to
>   their default values. User defined matrices may be downloaded
>   and this can occur in a sequence_header() or in a
>   quant_matrix_extension().
> 
> The load_intra_quantiser_matrix syntax elements are transmitted
> in the bistream headers, signalling that a quantisation matrix

bistream -> bitstream

> needs to be loaded and used for pictures transmitted afterwards
> (until the matrices are reset).
> 
> This "load" semantics are implemented in the V4L2 interface
> without the need of any "load" flags: passing the control
> is effectively a load.
> 
> Therefore, rework the V4L2_CID_MPEG_VIDEO_MPEG2_QUANTISATION
> semantics to match the MPEG-2 semantics. Quantisation matrices
> values are now initialized by the V4L2 control core to their
> reset default value, and applications are expected to reset
> their values as specified.
> 
> The quantisation control is therefore optional, and used to
> load bitstream-defined values in the quantisation matrices.
> 
> Signed-off-by: Ezequiel Garcia 
> Co-developed-by: Nicolas Dufresne 
> Signed-off-by: Nicolas Dufresne 
> ---
>  .../media/v4l/ext-ctrls-codec.rst | 17 -
>  drivers/media/v4l2-core/v4l2-ctrls.c  | 21 ++
>  .../staging/media/sunxi/cedrus/cedrus_mpeg2.c | 38 +--
>  include/media/mpeg2-ctrls.h   |  5 ---
>  4 files changed, 23 insertions(+), 58 deletions(-)
> 
> diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst 
> b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> index 151d1c676b6e..d9546f0aa2e8 100644
> --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> @@ -1746,23 +1746,6 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>  :stub-columns: 0
>  :widths:   1 1 2
>  
> -* - __u8
> -  - ``load_intra_quantiser_matrix``
> -  - One bit to indicate whether to load the ``intra_quantiser_matrix`` 
> data.
> -* - __u8
> -  - ``load_non_intra_quantiser_matrix``
> -  - One bit to indicate whether to load the 
> ``non_intra_quantiser_matrix``
> - data.
> -* - __u8
> -  - ``load_chroma_intra_quantiser_matrix``
> -  - One bit to indicate whether to load the
> - ``chroma_intra_quantiser_matrix`` data, only relevant for non-4:2:0 YUV
> - formats.
> -* - __u8
> -  - ``load_chroma_non_intra_quantiser_matrix``
> -  - One bit to indicate whether to load the
> - ``chroma_non_intra_quantiser_matrix`` data, only relevant for non-4:2:0
> - YUV formats.
>  * - __u8
>- ``intra_quantiser_matrix[64]``
>- The quantisation matrix coefficients for intra-coded frames, in 
> zigzag
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 74f5ca1a5f6c..5d92a2b33a6e 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -57,6 +57,18 @@ static bool is_new_manual(const struct v4l2_ctrl *master)
>   return master->is_auto && master->val == master->manual_mode_value;
>  }
>  
> +/* Default MPEG-2 quantisation coefficients, from the specification. */

Default -> Default intra

> +static const u8 mpeg2_intra_quant_matrix[64] = {
> + 8,  16, 16, 19, 16, 19, 22, 22,
> + 22, 22, 22, 22, 26, 24, 26, 27,
> + 27, 27, 26, 26, 26, 26, 27, 27,
> + 27, 29, 29, 29, 34, 34, 34, 29,
> + 29, 29, 27, 27, 29, 29, 32, 32,
> + 34, 34, 37, 38, 37, 35, 35, 34,
> + 35, 38, 38, 40, 40, 40, 48, 48,
> + 46, 46, 56, 56, 58, 69, 69, 83
> +};
> +
>  /* Returns NULL or a character pointer array containing the menu for
> the given control ID. The pointer array ends with a NULL pointer.
> An empty string signifies a menu entry that is invalid. This allows
> @@ -1656,6 +1668,7 @@ static void std_init_compound(const struct v4l2_ctrl 
> *ctrl, u32 idx,
> union v4l2_ctrl_ptr ptr)
>  {
>   struct v4l2_ctrl_mpeg2_slice_params *p_mpeg2_slice_params;
> + struct v4l2_ctrl_mpeg2_quantisation *p_mpeg2_quant;
>   struct v4l2_ctrl_vp8_frame *p_vp8_frame;
>   struct v4l2_ctrl_fwht_params *p_fwht_params;
>   void *p = ptr.p + idx * ctrl->elem_size;
> @@ -1680,6 +1693,14 @@ static void std_init_compound(const struct v4l2_ctrl 
> *ctrl, u32 idx,
>   p_mpeg2_slice_params->picture.picture_coding_type =
>   V4L2_MPEG2_PICTURE_CODING_TYPE_I;
>   break;
> + case V4L2_CTRL_TYPE_MPEG2_QUANTISATION:
> + p_mpeg2_quant = p;
> +
> + memcpy(p_mpeg2_quant->intra_quantiser_matrix,
> +mpeg2_intra_quant_matrix,
> +   

Re: [PATCH] media: em28xx: fix memory leak

2021-04-06 Thread Hans Verkuil
On 06/04/2021 11:44, Muhammad Usama Anjum wrote:
> On Wed, 2021-03-31 at 13:22 +0500, Muhammad Usama Anjum wrote:
>> On Wed, 2021-03-24 at 23:07 +0500, Muhammad Usama Anjum wrote:
>>> If some error occurs, URB buffers should also be freed. If they aren't
>>> freed with the dvb here, the em28xx_dvb_fini call doesn't frees the URB
>>> buffers as dvb is set to NULL. The function in which error occurs should
>>> do all the cleanup for the allocations it had done.
>>>
>>> Tested the patch with the reproducer provided by syzbot. This patch
>>> fixes the memleak.
>>>
>>> Reported-by: syzbot+889397c820fa56adf...@syzkaller.appspotmail.com
>>> Signed-off-by: Muhammad Usama Anjum 
>>> ---
>>> Resending the same path as some email addresses were missing from the
>>> earlier email.
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:1a4431a5 Merge tag 'afs-fixes-20210315' of git://git.kerne..
>>> git tree:   upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=11013a7cd0
>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=ff6b8b2e9d5a1227
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=889397c820fa56adf25d
>>> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1559ae3ad0
>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=176985c6d0
>>>
>>>  drivers/media/usb/em28xx/em28xx-dvb.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
>>> b/drivers/media/usb/em28xx/em28xx-dvb.c
>>> index 526424279637..471bd74667e3 100644
>>> --- a/drivers/media/usb/em28xx/em28xx-dvb.c
>>> +++ b/drivers/media/usb/em28xx/em28xx-dvb.c
>>> @@ -2010,6 +2010,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
>>> return result;
>>>  
>>>  out_free:
>>> +   em28xx_uninit_usb_xfer(dev, EM28XX_DIGITAL_MODE);
>>> kfree(dvb);
>>> dev->dvb = NULL;
>>> goto ret;
>>
>> I'd received the following notice and waiting for the review:
>> On Thu, 2021-03-25 at 09:06 +, Patchwork wrote:
>>> Hello,
>>>
>>> The following patch (submitted by you) has been updated in Patchwork:
>>>
>>>  * linux-media: media: em28xx: fix memory leak
>>>  - 
>>> http://patchwork.linuxtv.org/project/linux-media/patch/20210324180753.GA410359@LEGION/
>>>  - for: Linux Media kernel patches
>>>
> This patch has been accepted. This bug was introduced by 27ba0dac.
> Will it be backported and submitted for inclusion in stable release by
> maintainer automatically?

That might not happen since there was no 'Fixes:' tag. Without that it
will depend on the stable tree maintainers whether they'll pick it up or not.

Regards,

Hans


Re: [PATCH] media: pvrusb2: fix warning in pvr2_i2c_core_done

2021-04-06 Thread Hans Verkuil
On 01/04/2021 14:33, Anirudh Rayabharam wrote:
> syzbot has reported the following warning in pvr2_i2c_done:
> 
>   sysfs group 'power' not found for kobject '1-0043'
> 
> When the device is disconnected (pvr_hdw_disconnect), the i2c adapter is
> not unregistered along with the USB and vl42 teardown. As part of the

vl42 -> v4l2

> USB device disconnect, the sysfs files of the subdevices are also
> deleted. So, by the time pvr_i2c_core_done is called by
> pvr_context_destroy, the sysfs files have been deleted.
> 
> To fix this, unregister the i2c adapter too in pvr_hdw_disconnect. Make
> the device deregistration code shared by calling pvr_hdw_disconnect from
> pvr2_hdw_destory.

destory -> destroy

> 
> Reported-and-tested-by: syzbot+e74a998ca8f1df9cc...@syzkaller.appspotmail.com
> Signed-off-by: Anirudh Rayabharam 
> ---
>  drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c 
> b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> index f4a727918e35..791227787ff5 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c
> @@ -2676,9 +2676,7 @@ void pvr2_hdw_destroy(struct pvr2_hdw *hdw)
>   pvr2_stream_destroy(hdw->vid_stream);
>   hdw->vid_stream = NULL;
>   }
> - pvr2_i2c_core_done(hdw);
> - v4l2_device_unregister(>v4l2_dev);

I think this should still remain since pvr2_hdw_disconnect() doesn't call
v4l2_device_unregister().

Can you test that with syzbot?

Regards,

Hans

> - pvr2_hdw_remove_usb_stuff(hdw);
> + pvr2_hdw_disconnect(hdw);
>   mutex_lock(_unit_mtx);
>   do {
>   if ((hdw->unit_number >= 0) &&
> @@ -2705,6 +2703,7 @@ void pvr2_hdw_disconnect(struct pvr2_hdw *hdw)
>  {
>   pvr2_trace(PVR2_TRACE_INIT,"pvr2_hdw_disconnect(hdw=%p)",hdw);
>   LOCK_TAKE(hdw->big_lock);
> + pvr2_i2c_core_done(hdw);
>   LOCK_TAKE(hdw->ctl_lock);
>   pvr2_hdw_remove_usb_stuff(hdw);
>   LOCK_GIVE(hdw->ctl_lock);
> 



Re: [PATCH] media: VIDEO_IMX8_JPEG should depend on ARCH_MXC and not default to m

2021-04-06 Thread Hans Verkuil
Hi Geert,

On 31/03/2021 10:17, Geert Uytterhoeven wrote:
> The i.MX8 QXP/QM integrated JPEG encoder/decoder is only present on
> Freescale/NXP i.MX8 QXP and QM SoCs.  Hence add a dependency on
> ARCH_MXC, to prevent asking the user about this driver when configuring
> a kernel without i.MX8 support.
> 
> Drop the "default m" (which means "default y" if CONFIG_MODULES is not
> enabled), as merely enabling CONFIG_COMPILE_TEST should not enable
> additional code.

You do not actually drop 'default m' in the patch. Either the patch or the
commit message is wrong.

Regards,

Hans

> 
> Fixes: 2db16c6ed72ce644 ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG 
> Encoder/Decoder")
> Signed-off-by: Geert Uytterhoeven 
> ---
>  drivers/media/platform/imx-jpeg/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/media/platform/imx-jpeg/Kconfig 
> b/drivers/media/platform/imx-jpeg/Kconfig
> index d875f7c88cdad125..0e3269d06ded30ec 100644
> --- a/drivers/media/platform/imx-jpeg/Kconfig
> +++ b/drivers/media/platform/imx-jpeg/Kconfig
> @@ -1,6 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0
>  config VIDEO_IMX8_JPEG
>   tristate "IMX8 JPEG Encoder/Decoder"
> + depends on ARCH_MXC || COMPILE_TEST
>   depends on VIDEO_DEV && VIDEO_V4L2
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_MEM2MEM_DEV
> 



Re: [PATCH] media: usb: Remove duplicate declares

2021-04-06 Thread Hans Verkuil
Please specify in the subject line which driver this patch changes.

I also would prefer that this is split into two patches, one for each driver.

Just saying 'media: usb:' makes it look like you have a media/usb subsystem 
patch,
but that's not the case. Very confusing for code reviewers.

Regards,

Hans

On 27/03/2021 08:42, Wan Jiabing wrote:
> struct cx231xx has been declared at 146th line.
> struct em28xx has been declared at 219th line.
> Remove the duplicate.
> 
> Signed-off-by: Wan Jiabing 
> ---
>  drivers/media/usb/cx231xx/cx231xx.h | 2 --
>  drivers/media/usb/em28xx/em28xx.h   | 2 --
>  2 files changed, 4 deletions(-)
> 
> diff --git a/drivers/media/usb/cx231xx/cx231xx.h 
> b/drivers/media/usb/cx231xx/cx231xx.h
> index b32eab641793..6929e4d97067 100644
> --- a/drivers/media/usb/cx231xx/cx231xx.h
> +++ b/drivers/media/usb/cx231xx/cx231xx.h
> @@ -425,8 +425,6 @@ struct cx231xx_audio {
>   u16 end_point_addr;
>  };
>  
> -struct cx231xx;
> -
>  /*/
>  /* set/get i2c */
>  /* 00--1Mb/s, 01-400kb/s, 10--100kb/s, 11--5Mb/s */
> diff --git a/drivers/media/usb/em28xx/em28xx.h 
> b/drivers/media/usb/em28xx/em28xx.h
> index 6648e11f1271..43227111d410 100644
> --- a/drivers/media/usb/em28xx/em28xx.h
> +++ b/drivers/media/usb/em28xx/em28xx.h
> @@ -628,8 +628,6 @@ struct em28xx_audio {
>   atomic_t   stream_started;  /* stream should be running if true */
>  };
>  
> -struct em28xx;
> -
>  enum em28xx_i2c_algo_type {
>   EM28XX_I2C_ALGO_EM28XX = 0,
>   EM28XX_I2C_ALGO_EM2800,
> 



Re: [PATCH v9 17/22] media: docs: Document the behaviour of uvcdriver

2021-03-27 Thread Hans Verkuil
On 27/03/2021 13:01, Ricardo Ribalda wrote:
> Hi Hans
> 
> Thanks for your review!
> 
> On Sat, Mar 27, 2021 at 12:19 PM Hans Verkuil  
> wrote:
>>
>> On 26/03/2021 10:58, Ricardo Ribalda wrote:
>>> The uvc driver relies on the camera firmware to keep the control states
>>> and therefore is not capable of changing an inactive control.
>>>
>>> Allow returning -EACESS in those cases.
>>
>> -EACCES
> 
> This british people that like to have a lot of double consonants :)
> 
> I have updated the series at:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/ribalda/linux.git/log/?h=uvc-compliance-v10

For v10:

Reviewed-by: Hans Verkuil 

Thanks!

Hans

> 
> Will not post until there is more feedback to avoid spamming the list.
> 
> Thanks :)
> 
>>
>>>
>>> Signed-off-by: Ricardo Ribalda 
>>> ---
>>>  Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst  | 5 +
>>>  Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst | 5 +
>>>  2 files changed, 10 insertions(+)
>>>
>>> diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst 
>>> b/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst
>>> index 4f1bed53fad5..8c0a203385c2 100644
>>> --- a/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst
>>> +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst
>>> @@ -95,3 +95,8 @@ EBUSY
>>>
>>>  EACCES
>>>  Attempt to set a read-only control or to get a write-only control.
>>> +
>>> +Or if there is an attempt to set an inactive control and the driver is
>>> +not capable of keeping the new value until the control is active again.
>>
>> keeping: 'caching' or 'storing' are better words, I think.
>>
>>> +This is the case for drivers that do not use the standard control
>>> +framework and rely purely on the hardware to keep the controls' state.
>>
>> I would drop that last sentence. It is not relevant information to the users 
>> of
>> the API.
>>
>>> diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst 
>>> b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
>>> index b9c62affbb5a..bb7de7a25241 100644
>>> --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
>>> +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
>>> @@ -438,3 +438,8 @@ EACCES
>>>
>>>  Or the ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but 
>>> the
>>>  device does not support requests.
>>> +
>>> +Or if there is an attempt to set an inactive control and the driver is
>>> +not capable of keeping the new value until the control is active again.
>>> +This is the case for drivers that do not use the standard control
>>> +framework and rely purely on the hardware to keep the controls' state.
>>
>> Same comments as above.
>>
>>>
>>
>> Regards,
>>
>> Hans
> 
> 
> 



Re: [PATCH v9 16/22] media: uvcvideo: Return -EACCES to inactive controls

2021-03-27 Thread Hans Verkuil
On 26/03/2021 10:58, Ricardo Ribalda wrote:
> If a control is inactive return -EACCES to let the userspace know that
> the value will not be applied automatically when the control is active
> again.
> 
> Suggested-by: Hans Verkuil 
> Signed-off-by: Ricardo Ribalda 

Reviewed-by: Hans Verkuil 

> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 71 +---
>  1 file changed, 48 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index bcebf9d1a46f..d9d4add1e813 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1082,13 +1082,36 @@ static const char *uvc_map_get_name(const struct 
> uvc_control_mapping *map)
>   return "Unknown Control";
>  }
>  
> +static bool uvc_ctrl_is_inactive(struct uvc_video_chain *chain,
> +  struct uvc_control *ctrl,
> +  struct uvc_control_mapping *mapping)
> +{
> + struct uvc_control_mapping *master_map = NULL;
> + struct uvc_control *master_ctrl = NULL;
> + s32 val;
> + int ret;
> +
> + if (!mapping->master_id)
> + return false;
> +
> + __uvc_find_control(ctrl->entity, mapping->master_id, _map,
> +_ctrl, 0);
> +
> + if (!master_ctrl || !(master_ctrl->info.flags & UVC_CTRL_FLAG_GET_CUR))
> + return false;
> +
> + ret = __uvc_ctrl_get(chain, master_ctrl, master_map, );
> + if (ret < 0 || val == mapping->master_manual)
> + return false;
> +
> + return true;
> +}
> +
>  static int __uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
>   struct uvc_control *ctrl,
>   struct uvc_control_mapping *mapping,
>   struct v4l2_queryctrl *v4l2_ctrl)
>  {
> - struct uvc_control_mapping *master_map = NULL;
> - struct uvc_control *master_ctrl = NULL;
>   const struct uvc_menu_info *menu;
>   unsigned int i;
>  
> @@ -1104,18 +1127,8 @@ static int __uvc_query_v4l2_ctrl(struct 
> uvc_video_chain *chain,
>   if (!(ctrl->info.flags & UVC_CTRL_FLAG_SET_CUR))
>   v4l2_ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>  
> - if (mapping->master_id)
> - __uvc_find_control(ctrl->entity, mapping->master_id,
> -_map, _ctrl, 0);
> - if (master_ctrl && (master_ctrl->info.flags & UVC_CTRL_FLAG_GET_CUR)) {
> - s32 val;
> - int ret = __uvc_ctrl_get(chain, master_ctrl, master_map, );
> - if (ret < 0)
> - return ret;
> -
> - if (val != mapping->master_manual)
> - v4l2_ctrl->flags |= V4L2_CTRL_FLAG_INACTIVE;
> - }
> + if (uvc_ctrl_is_inactive(chain, ctrl, mapping))
> + v4l2_ctrl->flags |= V4L2_CTRL_FLAG_INACTIVE;
>  
>   if (!ctrl->cached) {
>   int ret = uvc_ctrl_populate_cache(chain, ctrl);
> @@ -1638,25 +1651,37 @@ static int uvc_ctrl_commit_entity(struct uvc_device 
> *dev,
>   return 0;
>  }
>  
> -static int uvc_ctrl_find_ctrlidx(struct uvc_entity *entity,
> +static int uvc_ctrl_commit_error(struct uvc_video_chain *chain,
> +  struct uvc_entity *entity,
>struct v4l2_ext_controls *ctrls,
> -  struct uvc_control *uvc_control)
> +  struct uvc_control *err_control,
> +  int ret)
>  {
>   struct uvc_control_mapping *mapping;
>   struct uvc_control *ctrl_found;
>   unsigned int i;
>  
> - if (!entity)
> - return ctrls->count;
> + if (!entity) {
> + ctrls->error_idx = ctrls->count;
> + return ret;
> + }
>  
>   for (i = 0; i < ctrls->count; i++) {
>   __uvc_find_control(entity, ctrls->controls[i].id, ,
>  _found, 0);
> - if (uvc_control == ctrl_found)
> - return i;
> + if (err_control == ctrl_found)
> + break;
>   }
> + ctrls->error_idx = i;
> +
> + /* We could not find the control that failed. */
> + if (i == ctrls->count)
> + return ret;
>  
> - return ctrls->count;
> + if (uvc_ctrl_is_inactive(chain, err_control, mapping))
> + return -EACCES;
> +
> + return ret;
>  }
>  
>  int __uvc_ctrl_commit(struct uvc_fh *handle, int rollback,
> @@ -1679,8 +1704,8 @@ int __uvc_ctrl_commit(struct uvc_fh *handle, int 
> rollback,
>   uvc_ctrl_send_events(handle, ctrls->controls, ctrls->count);
>  done:
>   if (ret < 0 && ctrls)
> - ctrls->error_idx = uvc_ctrl_find_ctrlidx(entity, ctrls,
> -  err_ctrl);
> + ret = uvc_ctrl_commit_error(chain, entity, ctrls, err_ctrl,
> + ret);
>   mutex_unlock(>ctrl_mutex);
>   return ret;
>  }
> 



Re: [PATCH v9 18/22] media: uvcvideo: Downgrade control error messages

2021-03-27 Thread Hans Verkuil
On 26/03/2021 10:58, Ricardo Ribalda wrote:
> Convert the error into a debug message, so they are still valid for
> debugging but do not fill dmesg.
> 
> Signed-off-by: Ricardo Ribalda 

Reviewed-by: Hans Verkuil 

> ---
>  drivers/media/usb/uvc/uvc_video.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_video.c 
> b/drivers/media/usb/uvc/uvc_video.c
> index ea2903dc3252..b63c073ec30e 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -76,7 +76,7 @@ int uvc_query_ctrl(struct uvc_device *dev, u8 query, u8 
> unit,
>   if (likely(ret == size))
>   return 0;
>  
> - dev_err(>udev->dev,
> + dev_dbg(>udev->dev,
>   "Failed to query (%s) UVC control %u on unit %u: %d (exp. 
> %u).\n",
>   uvc_query_name(query), cs, unit, ret, size);
>  
> 



Re: [PATCH v9 17/22] media: docs: Document the behaviour of uvcdriver

2021-03-27 Thread Hans Verkuil
On 26/03/2021 10:58, Ricardo Ribalda wrote:
> The uvc driver relies on the camera firmware to keep the control states
> and therefore is not capable of changing an inactive control.
> 
> Allow returning -EACESS in those cases.

-EACCES

> 
> Signed-off-by: Ricardo Ribalda 
> ---
>  Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst  | 5 +
>  Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst | 5 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst 
> b/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst
> index 4f1bed53fad5..8c0a203385c2 100644
> --- a/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst
> +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ctrl.rst
> @@ -95,3 +95,8 @@ EBUSY
>  
>  EACCES
>  Attempt to set a read-only control or to get a write-only control.
> +
> +Or if there is an attempt to set an inactive control and the driver is
> +not capable of keeping the new value until the control is active again.

keeping: 'caching' or 'storing' are better words, I think.

> +This is the case for drivers that do not use the standard control
> +framework and rely purely on the hardware to keep the controls' state.

I would drop that last sentence. It is not relevant information to the users of
the API.

> diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst 
> b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
> index b9c62affbb5a..bb7de7a25241 100644
> --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
> +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst
> @@ -438,3 +438,8 @@ EACCES
>  
>  Or the ``which`` field was set to ``V4L2_CTRL_WHICH_REQUEST_VAL`` but the
>  device does not support requests.
> +
> +Or if there is an attempt to set an inactive control and the driver is
> +not capable of keeping the new value until the control is active again.
> +This is the case for drivers that do not use the standard control
> +framework and rely purely on the hardware to keep the controls' state.

Same comments as above.

> 

Regards,

Hans


Re: [PATCH v5 0/5] Add r8a77965 DRIF support

2021-03-27 Thread Hans Verkuil
Hi Laurent,

On 21/10/2020 23:43, Laurent Pinchart wrote:
> Hi Fabrizio,
> 
> On Wed, Oct 21, 2020 at 02:53:27PM +0100, Fabrizio Castro wrote:
>> Dear All,
>>
>> this series is to add DRIF support for the r8a77965
>> (a.k.a. R-Car M3-N). Version 5 fixes a warning reported
>> by 'make dt_binding_check', as reported by Rob.
> 
> Patch 1/5 to 4/5 taken in my tree, I'll send a pull request to
> linux-media when the merge window closes. I expect Geert to handle 5/5.

Patch 5 has been merged, but patches 1-4 aren't. I don't think there
was a PR for it. For some reason these patches are delegated to me in
patchwork. I've now delegated them to you for further processing.

Regards,

Hans

> 
>> Fabrizio Castro (5):
>>   MAINTAINERS: Update MAINTAINERS for Renesas DRIF driver
>>   media: dt-bindings: media: renesas,drif: Convert to json-schema
>>   media: dt-bindings: media: renesas,drif: Add r8a77990 support
>>   media: dt-bindings: media: renesas,drif: Add r8a77965 support
>>   arm64: dts: r8a77965: Add DRIF support
>>
>>  .../bindings/media/renesas,drif.txt   | 177 ---
>>  .../bindings/media/renesas,drif.yaml  | 279 ++
>>  MAINTAINERS   |   4 +-
>>  arch/arm64/boot/dts/renesas/r8a77965.dtsi | 120 
>>  4 files changed, 401 insertions(+), 179 deletions(-)
>>  delete mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
>>  create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.yaml
> 



Re: [PATCH v2] media: sq905.c: fix uninitialized variable

2021-03-27 Thread Hans Verkuil
Hi Alaa,

FYI: this patch has already been applied to the media_tree master git repo:

https://patchwork.linuxtv.org/project/linux-media/patch/2c46832a-99a8-73bf-ec85-085052f8b...@xs4all.nl/

That's good enough for this issue so I am marking this patch as Obsolete in
our patchwork.

On 26/03/2021 22:02, Alaa Emad wrote:
> Reported-by: syzbot+a4e309017a5f3a24c...@syzkaller.appspotmail.com
> Signed-off-by: Alaa Emad 
> 
> ---
> Changes in v2:
>   - Fix the error occured because of pervious fix.
> ---
>  drivers/media/usb/gspca/sq905.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/usb/gspca/sq905.c b/drivers/media/usb/gspca/sq905.c
> index 97799cfb832e..57206dd2e1a0 100644
> --- a/drivers/media/usb/gspca/sq905.c
> +++ b/drivers/media/usb/gspca/sq905.c
> @@ -157,8 +157,8 @@ static int sq905_ack_frame(struct gspca_dev *gspca_dev)
>  static int
>  sq905_read_data(struct gspca_dev *gspca_dev, u8 *data, int size, int 
> need_lock)
>  {
> - int ret;
> - int act_len;
> + int ret;
> + int act_len;
>  
>   gspca_dev->usb_buf[0] = '\0';
>   if (need_lock)
> @@ -180,8 +180,8 @@ sq905_read_data(struct gspca_dev *gspca_dev, u8 *data, 
> int size, int need_lock)
>  data, size, _len, SQ905_DATA_TIMEOUT);
>  
>   /* successful, it returns 0, otherwise  negative */
> - if (ret < 0 || act_len != size) {
> - pr_err("bulk read fail (%d) len %d/%d\n", ret, act_len, size);
> + if (ret < 0 || act_len != size) {
> +pr_err("bulk read fail (%d) len %d/%d\n", ret, ret < 0 ? -1 : 
> act_len, size);

General note: it looks like you are replacing tab characters with spaces.
Make sure you configure your editor not to do that.

Regards,

Hans

>   return -EIO;
>   }
>   return 0;
> 



Re: [PATCH 1/2] media: v4l2-core: ignore native time32 ioctls on 64-bit

2021-03-25 Thread Hans Verkuil
On 21/03/2021 09:50, Hans Verkuil wrote:
> Hi Arnd,



>> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
>> b/drivers/media/v4l2-core/v4l2-subdev.c
>> index 336133dbc759..9f5573d3b857 100644
>> --- a/drivers/media/v4l2-core/v4l2-subdev.c
>> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
>> @@ -428,7 +428,7 @@ static long subdev_do_ioctl(struct file *file, unsigned 
>> int cmd, void *arg)
>>  
>>  return v4l2_event_dequeue(vfh, arg, file->f_flags & O_NONBLOCK);
>>  
>> -#ifdef CONFIG_COMPAT_32BIT_TIME
>> +#if !defined(CONFIG_64BIT) && defined(CONFIG_COMPAT_32BIT_TIME)
>>  case VIDIOC_DQEVENT_TIME32: {
>>  struct v4l2_event_time32 *ev32 = arg;
>>  struct v4l2_event ev = { };
>>
> 
> This chunk doesn't apply since there is no '#ifdef CONFIG_COMPAT_32BIT_TIME' 
> in
> either the mainline kernel or the media_tree master branch.
> 
> Are we missing a patch for v4l2-subdev.c?

Ping!

Hans

> 
> Regards,
> 
>   Hans
> 



Re: [PATCH v5 3/5] v4l: Add HDR10 static metadata controls

2021-03-22 Thread Hans Verkuil
On 22/03/2021 13:56, Stanimir Varbanov wrote:
> Hi Hans,
> 
> On 3/16/21 2:16 PM, Hans Verkuil wrote:
>> On 09/02/2021 17:24, Stanimir Varbanov wrote:
>>> Introduce Content light level and Mastering display colour
>>> volume Colorimetry compound controls with relevant payload
>>> structures and validation.
>>>
>>> Signed-off-by: Stanimir Varbanov 
>>> ---
>>>  drivers/media/v4l2-core/v4l2-ctrls.c | 67 
>>>  include/media/v4l2-ctrls.h   |  4 ++
>>>  include/uapi/linux/v4l2-controls.h   | 31 +
>>>  include/uapi/linux/videodev2.h   |  3 ++
>>>  4 files changed, 105 insertions(+)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
>>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>>> index 335cf354f51b..8bd3cf0e1e4f 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>>> @@ -1205,6 +1205,8 @@ const char *v4l2_ctrl_get_name(u32 id)
>>> /* Colorimetry controls */
>>> /* Keep the order of the 'case's the same as in v4l2-controls.h! */
>>> case V4L2_CID_COLORIMETRY_CLASS:return "Colorimetry Controls";
>>> +   case V4L2_CID_COLORIMETRY_HDR10_CLL_INFO:   return "HDR10 
>>> Content Light Info";
>>> +   case V4L2_CID_COLORIMETRY_HDR10_MASTERING_DISPLAY:  return "HDR10 
>>> Mastering Display";
>>> default:
>>> return NULL;
>>> }
>>> @@ -1491,6 +1493,12 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
>>> v4l2_ctrl_type *type,
>>> *type = V4L2_CTRL_TYPE_AREA;
>>> *flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>> break;
>>> +   case V4L2_CID_COLORIMETRY_HDR10_CLL_INFO:
>>> +   *type = V4L2_CTRL_TYPE_HDR10_CLL_INFO;
>>> +   break;
>>> +   case V4L2_CID_COLORIMETRY_HDR10_MASTERING_DISPLAY:
>>> +   *type = V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY;
>>> +   break;
>>> default:
>>> *type = V4L2_CTRL_TYPE_INTEGER;
>>> break;
>>> @@ -1786,6 +1794,12 @@ static void std_log(const struct v4l2_ctrl *ctrl)
>>> case V4L2_CTRL_TYPE_FWHT_PARAMS:
>>> pr_cont("FWHT_PARAMS");
>>> break;
>>> +   case V4L2_CTRL_TYPE_HDR10_CLL_INFO:
>>> +   pr_cont("HDR10_CLL_INFO");
>>> +   break;
>>> +   case V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY:
>>> +   pr_cont("HDR10_MASTERING_DISPLAY");
>>> +   break;
>>> default:
>>> pr_cont("unknown type %d", ctrl->type);
>>> break;
>>> @@ -1838,6 +1852,7 @@ static int std_validate_compound(const struct 
>>> v4l2_ctrl *ctrl, u32 idx,
>>> struct v4l2_ctrl_hevc_sps *p_hevc_sps;
>>> struct v4l2_ctrl_hevc_pps *p_hevc_pps;
>>> struct v4l2_ctrl_hevc_slice_params *p_hevc_slice_params;
>>> +   struct v4l2_ctrl_hdr10_mastering_display *p_hdr10_mastering;
>>> struct v4l2_area *area;
>>> void *p = ptr.p + idx * ctrl->elem_size;
>>> unsigned int i;
>>> @@ -2133,6 +2148,52 @@ static int std_validate_compound(const struct 
>>> v4l2_ctrl *ctrl, u32 idx,
>>> zero_padding(*p_hevc_slice_params);
>>> break;
>>>  
>>> +   case V4L2_CTRL_TYPE_HDR10_CLL_INFO:
>>> +   break;
>>> +
>>> +   case V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY:
>>> +   p_hdr10_mastering = p;
>>> +
>>> +   for (i = 0; i < 3; ++i) {
>>> +   if (p_hdr10_mastering->display_primaries_x[i] <
>>> +   V4L2_HDR10_MASTERING_PRIMARIES_X_LOW ||
>>> +   p_hdr10_mastering->display_primaries_x[i] >
>>> +   V4L2_HDR10_MASTERING_PRIMARIES_X_HIGH ||
>>> +   p_hdr10_mastering->display_primaries_y[i] <
>>> +   V4L2_HDR10_MASTERING_PRIMARIES_Y_LOW ||
>>> +   p_hdr10_mastering->display_primaries_y[i] >
>>> +   V4L2_HDR10_MASTERING_PRIMARIES_Y_HIGH)
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   if (p_hdr10_mastering->white_point_x <
>>> +  

Re: [PATCH 8/8] videobuf2: handle non-contiguous DMA allocations

2021-03-22 Thread Hans Verkuil
On 02/03/2021 01:46, Sergey Senozhatsky wrote:
> This adds support for new noncontiguous DMA API, which
> requires allocators to have two execution branches: one
> for the current API, and one for the new one.
> 
> Signed-off-by: Sergey Senozhatsky 
> [hch: untested conversion to the ne API]
> Signed-off-by: Christoph Hellwig 
> ---
>  .../common/videobuf2/videobuf2-dma-contig.c   | 141 +++---
>  1 file changed, 117 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c 
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 1e218bc440c6..d6a9f7b682f3 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -42,8 +43,14 @@ struct vb2_dc_buf {
>   struct dma_buf_attachment   *db_attach;
>  
>   struct vb2_buffer   *vb;
> + unsigned intnon_coherent_mem:1;

Just use a bool here.

>  };
>  
> +static bool vb2_dc_is_coherent(struct vb2_dc_buf *buf)
> +{
> + return !buf->non_coherent_mem;
> +}

I would just drop this 'helper' function. Testing against buf->non_coherent_mem
seems perfectly understandable to me. And better than negating that bool in
this helper function.

You can choose to invert non_coherent_mem: i.e. add a coherent_mem bool instead
of a non_coherent_mem bool if you think that is easier to understand. It's set
in just one place (alloc), so that's easy enough.

Calling it 'bool is_coherent;' would perhaps be the easiest to understand.

> +
>  /*/
>  /*scatterlist table functions*/
>  /*/
> @@ -78,12 +85,21 @@ static void *vb2_dc_cookie(struct vb2_buffer *vb, void 
> *buf_priv)
>  static void *vb2_dc_vaddr(struct vb2_buffer *vb, void *buf_priv)
>  {
>   struct vb2_dc_buf *buf = buf_priv;
> - struct dma_buf_map map;
> - int ret;
>  
> - if (!buf->vaddr && buf->db_attach) {
> - ret = dma_buf_vmap(buf->db_attach->dmabuf, );
> - buf->vaddr = ret ? NULL : map.vaddr;
> + if (buf->vaddr)
> + return buf->vaddr;
> +
> + if (buf->db_attach) {
> + struct dma_buf_map map;
> +
> + if (!dma_buf_vmap(buf->db_attach->dmabuf, ))
> + buf->vaddr = map.vaddr;
> + }
> +
> + if (!vb2_dc_is_coherent(buf)) {
> + buf->vaddr = dma_vmap_noncontiguous(buf->dev,
> + buf->size,
> + buf->dma_sgt);
>   }
>  
>   return buf->vaddr;
> @@ -101,13 +117,26 @@ static void vb2_dc_prepare(void *buf_priv)
>   struct vb2_dc_buf *buf = buf_priv;
>   struct sg_table *sgt = buf->dma_sgt;
>  
> + /* This takes care of DMABUF and user-enforced cache sync hint */
>   if (buf->vb->skip_cache_sync_on_prepare)
>   return;
>  
> + /*
> +  * Coherent MMAP buffers do not need to be synced, unlike coherent
> +  * USERPTR and non-coherent MMAP buffers.
> +  */
> + if (buf->vb->memory == V4L2_MEMORY_MMAP && vb2_dc_is_coherent(buf))
> + return;
> +
>   if (!sgt)
>   return;
>  
> + /* For both USERPTR and non-coherent MMAP */
>   dma_sync_sgtable_for_device(buf->dev, sgt, buf->dma_dir);
> +
> + /* Non-coherrent MMAP only */

Typo: coherrent -> coherent

> + if (!vb2_dc_is_coherent(buf) && buf->vaddr)
> + flush_kernel_vmap_range(buf->vaddr, buf->size);
>  }
>  
>  static void vb2_dc_finish(void *buf_priv)
> @@ -115,19 +144,46 @@ static void vb2_dc_finish(void *buf_priv)
>   struct vb2_dc_buf *buf = buf_priv;
>   struct sg_table *sgt = buf->dma_sgt;
>  
> + /* This takes care of DMABUF and user-enforced cache sync hint */
>   if (buf->vb->skip_cache_sync_on_finish)
>   return;
>  
> + /*
> +  * Coherent MMAP buffers do not need to be synced, unlike coherent
> +  * USERPTR and non-coherent MMAP buffers.
> +  */
> + if (buf->vb->memory == V4L2_MEMORY_MMAP && vb2_dc_is_coherent(buf))
> + return;
> +
>   if (!sgt)
>   return;
>  
> + /* For both USERPTR and non-coherent MMAP */
>   dma_sync_sgtable_for_cpu(buf->dev, sgt, buf->dma_dir);
> +
> + /* Non-coherrent MMAP only */

Same typo.

> + if (!vb2_dc_is_coherent(buf) && buf->vaddr)
> + invalidate_kernel_vmap_range(buf->vaddr, buf->size);
>  }
>  
>  /*/
>  /*callbacks for MMAP buffers */
>  /*/
>  
> +static void __vb2_dc_put(struct vb2_dc_buf *buf)
> +{
> + if (vb2_dc_is_coherent(buf)) {
> + dma_free_attrs(buf->dev, buf->size, buf->cookie,
> + 

Re: [PATCH 7/8] videobuf2: handle V4L2_FLAG_MEMORY_NON_COHERENT flag

2021-03-22 Thread Hans Verkuil
On 02/03/2021 01:46, Sergey Senozhatsky wrote:
> This patch lets user-space to request a non-coherent memory
> allocation during CREATE_BUFS and REQBUFS ioctl calls.
> 
> = CREATE_BUFS
> 
>   struct v4l2_create_buffers has seven 4-byte reserved areas,
>   so reserved[0] is renamed to ->flags. The struct, thus, now
>   has six reserved 4-byte regions.
> 
> = CREATE_BUFS32
> 
>   struct v4l2_create_buffers32 has seven 4-byte reserved areas,
>   so reserved[0] is renamed to ->flags. The struct, thus, now
>   has six reserved 4-byte regions.
> 
> = REQBUFS
> 
>  We use one bit of a ->reserved[1] member of struct v4l2_requestbuffers,
>  which is now renamed to ->flags. Unlike v4l2_create_buffers, struct
>  v4l2_requestbuffers does not have enough reserved room. Therefore for
>  backward compatibility  ->reserved and ->flags were put into anonymous
>  union.
> 
> Signed-off-by: Sergey Senozhatsky 
> ---
>  .../media/v4l/vidioc-create-bufs.rst  |  7 ++-
>  .../media/v4l/vidioc-reqbufs.rst  | 11 +--
>  .../media/common/videobuf2/videobuf2-core.c   |  6 ++
>  .../media/common/videobuf2/videobuf2-v4l2.c   | 19 ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  9 -
>  drivers/media/v4l2-core/v4l2-ioctl.c  |  5 +
>  include/uapi/linux/videodev2.h| 11 +--
>  7 files changed, 55 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst 
> b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst
> index b06e5b528e11..132c8b612a94 100644
> --- a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst
> +++ b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst
> @@ -113,7 +113,12 @@ than the number requested.
>   ``V4L2_MEMORY_MMAP`` and ``format.type`` to the buffer type.
>  
>  * - __u32
> -  - ``reserved``\ [7]
> +  - ``flags``
> +  - Specifies additional buffer management attributes.
> + See :ref:`memory-flags`.
> +
> +* - __u32
> +  - ``reserved``\ [6]
>- A place holder for future extensions. Drivers and applications
>   must set the array to zero.
>  
> diff --git a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst 
> b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> index 950e7ec1aac5..80ea48acea84 100644
> --- a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> +++ b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> @@ -104,10 +104,17 @@ aborting or finishing any DMA in progress, an implicit
>   ``V4L2_MEMORY_MMAP`` and ``type`` set to the buffer type. This will
>   free any previously allocated buffers, so this is typically something
>   that will be done at the start of the application.
> +* - union {
> +  - (anonymous)
> +* - __u32
> +  - ``flags``
> +  - Specifies additional buffer management attributes.
> + See :ref:`memory-flags`.
>  * - __u32
>- ``reserved``\ [1]
> -  - A place holder for future extensions. Drivers and applications
> - must set the array to zero.
> +  - Kept for backwards compatibility. Use ``flags`` instead.
> +* - }
> +  -
>  
>  .. tabularcolumns:: |p{6.1cm}|p{2.2cm}|p{8.7cm}|
>  
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index 7040b7f47133..5906a48e7757 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -768,6 +768,9 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory 
> memory,
>   unsigned int i;
>   int ret;
>  
> + if (flags & V4L2_FLAG_MEMORY_NON_COHERENT)
> + coherent_mem = false;
> +

I think it is better if this is done at the bool coherent_mem declaration:

bool coherent_mem = !(flags & V4L2_FLAG_MEMORY_NON_COHERENT);

>   if (q->streaming) {
>   dprintk(q, 1, "streaming active\n");
>   return -EBUSY;
> @@ -911,6 +914,9 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
> vb2_memory memory,
>   bool coherent_mem = true;
>   int ret;
>  
> + if (flags & V4L2_FLAG_MEMORY_NON_COHERENT)
> + coherent_mem = false;
> +

Ditto.

Regards,

Hans

>   if (q->num_buffers == VB2_MAX_FRAME) {
>   dprintk(q, 1, "maximum number of buffers already allocated\n");
>   return -ENOBUFS;
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 1166d5a9291a..f6a8dcc1b5c6 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -692,12 +692,22 @@ static void fill_buf_caps(struct vb2_queue *q, u32 
> *caps)
>  #endif
>  }
>  
> +static void validate_coherency_flags(struct vb2_queue *q,
> +  int memory,
> +  unsigned 

Re: [PATCH 7/8] videobuf2: handle V4L2_FLAG_MEMORY_NON_COHERENT flag

2021-03-22 Thread Hans Verkuil
On 02/03/2021 01:46, Sergey Senozhatsky wrote:
> This patch lets user-space to request a non-coherent memory
> allocation during CREATE_BUFS and REQBUFS ioctl calls.
> 
> = CREATE_BUFS
> 
>   struct v4l2_create_buffers has seven 4-byte reserved areas,
>   so reserved[0] is renamed to ->flags. The struct, thus, now
>   has six reserved 4-byte regions.
> 
> = CREATE_BUFS32
> 
>   struct v4l2_create_buffers32 has seven 4-byte reserved areas,
>   so reserved[0] is renamed to ->flags. The struct, thus, now
>   has six reserved 4-byte regions.
> 
> = REQBUFS
> 
>  We use one bit of a ->reserved[1] member of struct v4l2_requestbuffers,
>  which is now renamed to ->flags. Unlike v4l2_create_buffers, struct
>  v4l2_requestbuffers does not have enough reserved room. Therefore for
>  backward compatibility  ->reserved and ->flags were put into anonymous
>  union.
> 
> Signed-off-by: Sergey Senozhatsky 
> ---
>  .../media/v4l/vidioc-create-bufs.rst  |  7 ++-
>  .../media/v4l/vidioc-reqbufs.rst  | 11 +--
>  .../media/common/videobuf2/videobuf2-core.c   |  6 ++
>  .../media/common/videobuf2/videobuf2-v4l2.c   | 19 ---
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  9 -
>  drivers/media/v4l2-core/v4l2-ioctl.c  |  5 +
>  include/uapi/linux/videodev2.h| 11 +--
>  7 files changed, 55 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst 
> b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst
> index b06e5b528e11..132c8b612a94 100644
> --- a/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst
> +++ b/Documentation/userspace-api/media/v4l/vidioc-create-bufs.rst
> @@ -113,7 +113,12 @@ than the number requested.
>   ``V4L2_MEMORY_MMAP`` and ``format.type`` to the buffer type.
>  
>  * - __u32
> -  - ``reserved``\ [7]
> +  - ``flags``
> +  - Specifies additional buffer management attributes.
> + See :ref:`memory-flags`.
> +
> +* - __u32
> +  - ``reserved``\ [6]
>- A place holder for future extensions. Drivers and applications
>   must set the array to zero.
>  
> diff --git a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst 
> b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> index 950e7ec1aac5..80ea48acea84 100644
> --- a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> +++ b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> @@ -104,10 +104,17 @@ aborting or finishing any DMA in progress, an implicit
>   ``V4L2_MEMORY_MMAP`` and ``type`` set to the buffer type. This will
>   free any previously allocated buffers, so this is typically something
>   that will be done at the start of the application.
> +* - union {
> +  - (anonymous)
> +* - __u32
> +  - ``flags``
> +  - Specifies additional buffer management attributes.
> + See :ref:`memory-flags`.
>  * - __u32
>- ``reserved``\ [1]
> -  - A place holder for future extensions. Drivers and applications
> - must set the array to zero.
> +  - Kept for backwards compatibility. Use ``flags`` instead.
> +* - }
> +  -

I would do this differently. Replace the __u32 reserved[1] by:

__u8 flags;
__u8 reserved[3];

We only need a single bit for flags, so this way we still have a few reserved 
bytes
available.

>  
>  .. tabularcolumns:: |p{6.1cm}|p{2.2cm}|p{8.7cm}|
>  
> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
> b/drivers/media/common/videobuf2/videobuf2-core.c
> index 7040b7f47133..5906a48e7757 100644
> --- a/drivers/media/common/videobuf2/videobuf2-core.c
> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
> @@ -768,6 +768,9 @@ int vb2_core_reqbufs(struct vb2_queue *q, enum vb2_memory 
> memory,
>   unsigned int i;
>   int ret;
>  
> + if (flags & V4L2_FLAG_MEMORY_NON_COHERENT)
> + coherent_mem = false;
> +
>   if (q->streaming) {
>   dprintk(q, 1, "streaming active\n");
>   return -EBUSY;
> @@ -911,6 +914,9 @@ int vb2_core_create_bufs(struct vb2_queue *q, enum 
> vb2_memory memory,
>   bool coherent_mem = true;
>   int ret;
>  
> + if (flags & V4L2_FLAG_MEMORY_NON_COHERENT)
> + coherent_mem = false;
> +
>   if (q->num_buffers == VB2_MAX_FRAME) {
>   dprintk(q, 1, "maximum number of buffers already allocated\n");
>   return -ENOBUFS;
> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c 
> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> index 1166d5a9291a..f6a8dcc1b5c6 100644
> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> @@ -692,12 +692,22 @@ static void fill_buf_caps(struct vb2_queue *q, u32 
> *caps)
>  #endif
>  }
>  
> +static void validate_coherency_flags(struct vb2_queue *q,

This should validate flags in general, not just the single 

Re: [PATCH 5/8] videobuf2: add V4L2_FLAG_MEMORY_NON_COHERENT flag

2021-03-22 Thread Hans Verkuil
On 02/03/2021 01:46, Sergey Senozhatsky wrote:
> By setting or clearing V4L2_FLAG_MEMORY_NON_COHERENT flag
> user-space should be able to hint vb2 that either a non-coherent
> (if supported) or coherent memory should be used for the buffer
> allocation.
> 
> The patch set also adds a corresponding capability flag:
> fill_buf_caps() reports V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
> when queue supports user-space cache management hints.

Hmm, this paragraph is probably outdated (copy and paste?) since this
capability already exists.

> 
> Signed-off-by: Sergey Senozhatsky 
> ---
>  .../userspace-api/media/v4l/buffer.rst| 40 ++-
>  .../media/v4l/vidioc-reqbufs.rst  |  5 ++-
>  include/uapi/linux/videodev2.h|  2 +
>  3 files changed, 43 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/userspace-api/media/v4l/buffer.rst 
> b/Documentation/userspace-api/media/v4l/buffer.rst
> index 1b0fdc160533..a39852d6174f 100644
> --- a/Documentation/userspace-api/media/v4l/buffer.rst
> +++ b/Documentation/userspace-api/media/v4l/buffer.rst
> @@ -676,8 +676,6 @@ Buffer Flags
>  
>  \normalsize
>  
> -.. _memory-flags:
> -
>  enum v4l2_memory
>  
>  
> @@ -701,6 +699,44 @@ enum v4l2_memory
>- 4
>- The buffer is used for :ref:`DMA shared buffer ` I/O.
>  
> +.. _memory-flags:
> +
> +Memory Consistency Flags
> +
> +
> +.. raw:: latex
> +
> +\small
> +
> +.. tabularcolumns:: |p{7.0cm}|p{2.1cm}|p{8.4cm}|
> +
> +.. cssclass:: longtable
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   3 1 4
> +
> +* .. _`V4L2-FLAG-MEMORY-NON-COHERENT`:
> +
> +  - ``V4L2_FLAG_MEMORY_NON_COHERENT``

Rename this to V4L2_MEMORY_FLAG_NON_COHERENT: this is consistent with
V4L2_FMT_FLAG_ and V4L2_BUF_FLAG_.

> +  - 0x0001
> +  - A buffer is allocated either in coherent (it will be automatically
> + coherent between the CPU and the bus) or non-coherent memory. The
> + latter can provide performance gains, for instance the CPU cache
> + sync/flush operations can be avoided if the buffer is accessed by the
> + corresponding device only and the CPU does not read/write to/from that
> + buffer. However, this requires extra care from the driver -- it must
> + guarantee memory consistency by issuing a cache flush/sync when
> + consistency is needed. If this flag is set V4L2 will attempt to
> + allocate the buffer in non-coherent memory. The flag takes effect
> + only if the buffer is used for :ref:`memory mapping ` I/O and the
> + queue reports the :ref:`V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS
> + ` capability.
> +
> +.. raw:: latex
> +
> +\normalsize
>  
>  Timecodes
>  =
> diff --git a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst 
> b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> index c1c88e00b106..950e7ec1aac5 100644
> --- a/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> +++ b/Documentation/userspace-api/media/v4l/vidioc-reqbufs.rst
> @@ -154,8 +154,9 @@ aborting or finishing any DMA in progress, an implicit
>- This capability is set by the driver to indicate that the queue 
> supports
>  cache and memory management hints. However, it's only valid when the
>  queue is used for :ref:`memory mapping ` streaming I/O. See
> -:ref:`V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 
> ` and
> -:ref:`V4L2_BUF_FLAG_NO_CACHE_CLEAN `.
> +:ref:`V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 
> `,
> +:ref:`V4L2_BUF_FLAG_NO_CACHE_CLEAN ` 
> and
> +:ref:`V4L2_FLAG_MEMORY_NON_COHERENT `.
>  
>  Return Value
>  
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 79dbde3bcf8d..b1d4171fe50b 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -954,6 +954,8 @@ struct v4l2_requestbuffers {
>   __u32   reserved[1];
>  };
>  
> +#define V4L2_FLAG_MEMORY_NON_COHERENT(1 << 0)
> +
>  /* capabilities for struct v4l2_requestbuffers and v4l2_create_buffers */
>  #define V4L2_BUF_CAP_SUPPORTS_MMAP   (1 << 0)
>  #define V4L2_BUF_CAP_SUPPORTS_USERPTR(1 << 1)
> 

Regards,

Hans


Re: [PATCH] media/pci: Assign value when defining variables

2021-03-21 Thread Hans Verkuil
Hi zuoqilin,

On 17/03/2021 04:08, zuoqil...@163.com wrote:
> From: zuoqilin 
> 
> When defining variables and assigning values can be done at the same time.

For future reference: add the name of the driver to the prefix. Saying
'media/pci:' suggests that you patch multiple PCI drivers in that directory.
But 'media/pci/pt1:' indicates that you patch only the pt1 driver.

I've updated the subject, so no need to repost, but remember this for next
time :-)

Regards,

Hans

> 
> Signed-off-by: zuoqilin 
> ---
>  drivers/media/pci/pt1/pt1.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/pci/pt1/pt1.c b/drivers/media/pci/pt1/pt1.c
> index 72b191c..f2aa368 100644
> --- a/drivers/media/pci/pt1/pt1.c
> +++ b/drivers/media/pci/pt1/pt1.c
> @@ -334,8 +334,7 @@ static int pt1_sync(struct pt1 *pt1)
>  static u64 pt1_identify(struct pt1 *pt1)
>  {
>   int i;
> - u64 id;
> - id = 0;
> + u64 id = 0;
>   for (i = 0; i < 57; i++) {
>   id |= (u64)(pt1_read_reg(pt1, 0) >> 30 & 1) << i;
>   pt1_write_reg(pt1, 0, 0x0008);
> @@ -1122,8 +1121,7 @@ static int pt1_i2c_end(struct pt1 *pt1, int addr)
>  
>  static void pt1_i2c_begin(struct pt1 *pt1, int *addrp)
>  {
> - int addr;
> - addr = 0;
> + int addr = 0;
>  
>   pt1_i2c_emit(pt1, addr, 0, 0, 1, 1, addr /* itself */);
>   addr = addr + 1;
> 



Re: [PATCH 1/2] media: v4l2-core: ignore native time32 ioctls on 64-bit

2021-03-21 Thread Hans Verkuil
Hi Arnd,

On 18/03/2021 14:43, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> Syzbot found that passing ioctl command 0xc0505609 into a 64-bit
> kernel from a 32-bit process causes uninitialized kernel memory to
> get passed to drivers instead of the user space data:
> 
> BUG: KMSAN: uninit-value in check_array_args 
> drivers/media/v4l2-core/v4l2-ioctl.c:3041 [inline]
> BUG: KMSAN: uninit-value in video_usercopy+0x1631/0x3d30 
> drivers/media/v4l2-core/v4l2-ioctl.c:3315
> CPU: 0 PID: 19595 Comm: syz-executor.4 Not tainted 5.11.0-rc7-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:79 [inline]
>  dump_stack+0x21c/0x280 lib/dump_stack.c:120
>  kmsan_report+0xfb/0x1e0 mm/kmsan/kmsan_report.c:118
>  __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197
>  check_array_args drivers/media/v4l2-core/v4l2-ioctl.c:3041 [inline]
>  video_usercopy+0x1631/0x3d30 drivers/media/v4l2-core/v4l2-ioctl.c:3315
>  video_ioctl2+0x9f/0xb0 drivers/media/v4l2-core/v4l2-ioctl.c:3391
>  v4l2_ioctl+0x255/0x290 drivers/media/v4l2-core/v4l2-dev.c:360
>  v4l2_compat_ioctl32+0x2c6/0x370 
> drivers/media/v4l2-core/v4l2-compat-ioctl32.c:1248
>  __do_compat_sys_ioctl fs/ioctl.c:842 [inline]
>  __se_compat_sys_ioctl+0x53d/0x1100 fs/ioctl.c:793
>  __ia32_compat_sys_ioctl+0x4a/0x70 fs/ioctl.c:793
>  do_syscall_32_irqs_on arch/x86/entry/common.c:79 [inline]
>  __do_fast_syscall_32+0x102/0x160 arch/x86/entry/common.c:141
>  do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:166
>  do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:209
>  entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
> 
> The time32 commands are defined but were never meant to be called on
> 64-bit machines, as those have always used time64 interfaces.  I missed
> this in my patch that introduced the time64 handling on 32-bit platforms.
> 
> The problem in this case is the mismatch of one function checking for
> the numeric value of the command and another function checking for the
> type of process (native vs compat) instead, with the result being that
> for this combination, nothing gets copied into the buffer at all.
> 
> Avoid this by only trying to convert the time32 commands when running
> on a 32-bit kernel where these are defined in a meaningful way.
> 
> Fixes: 577c89b0ce72 ("media: v4l2-core: fix v4l2_buffer handling for time64 
> ABI")
> Reported-by: syzbot+142888ffec98ab194...@syzkaller.appspotmail.com
> Tested-by: Hans Verkuil 
> Signed-off-by: Arnd Bergmann 
> ---
> This patch adds two more changes than the version that Hans tested
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c  | 6 +++---
>  drivers/media/v4l2-core/v4l2-subdev.c | 2 +-
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 31d1342e61e8..2b1bb68dc27f 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -3115,7 +3115,7 @@ static int check_array_args(unsigned int cmd, void 
> *parg, size_t *array_size,
>  static unsigned int video_translate_cmd(unsigned int cmd)
>  {
>   switch (cmd) {
> -#ifdef CONFIG_COMPAT_32BIT_TIME
> +#if !defined(CONFIG_64BIT) && defined(CONFIG_COMPAT_32BIT_TIME)
>   case VIDIOC_DQEVENT_TIME32:
>   return VIDIOC_DQEVENT;
>   case VIDIOC_QUERYBUF_TIME32:
> @@ -3169,7 +3169,7 @@ static int video_get_user(void __user *arg, void *parg,
>   err = v4l2_compat_get_user(arg, parg, cmd);
>   } else {
>   switch (cmd) {
> -#ifdef CONFIG_COMPAT_32BIT_TIME
> +#if !defined(CONFIG_64BIT) && defined(CONFIG_COMPAT_32BIT_TIME)
>   case VIDIOC_QUERYBUF_TIME32:
>   case VIDIOC_QBUF_TIME32:
>   case VIDIOC_DQBUF_TIME32:
> @@ -3224,7 +3224,7 @@ static int video_put_user(void __user *arg, void *parg,
>   return v4l2_compat_put_user(arg, parg, cmd);
>  
>   switch (cmd) {
> -#ifdef CONFIG_COMPAT_32BIT_TIME
> +#if !defined(CONFIG_64BIT) && defined(CONFIG_COMPAT_32BIT_TIME)
>   case VIDIOC_DQEVENT_TIME32: {
>   struct v4l2_event *ev = parg;
>   struct v4l2_event_time32 ev32;
> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c 
> b/drivers/media/v4l2-core/v4l2-subdev.c
> index 336133dbc759..9f5573d3b857 100644
> --- a/drivers/media/v4l2-core/v4l2-subdev.c
> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> @@ -428,7 +428,7 @@ static long subdev_do_ioctl(struct file *file, unsigned 
> int cmd, void *arg)
>  
>   return v4l2_event_dequeue(vfh, arg, file->f_flags & O_NONBL

Re: [PATCH 2/2] media: radio: RDA5807: Added driver

2021-03-21 Thread Hans Verkuil
Hi Maarten,

Thank you for this patch.

Before I can accept this driver I have to see the output of v4l2-compliance -r 
/dev/radioX.

That utility is part of the v4l-utils git repo:

git://linuxtv.org/v4l-utils.git

Compile it from the master branch of that repo, don't rely on the version
distributed by distros since that's typically too old.

The compliance test must pass without failures and preferably without warnings.

Some more comments below:

On 02/03/2021 15:42, Paul Cercueil wrote:
> From: Maarten ter Huurne 
> 
> Add a driver to support the RDA5807 FM radio I2C chip from Unisoc
> Communications.
> 
> Tested and working with fmtools 2.x.
> 
> Signed-off-by: Maarten ter Huurne 
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/media/radio/Kconfig |  12 +
>  drivers/media/radio/Makefile|   1 +
>  drivers/media/radio/radio-rda5807.c | 920 
>  3 files changed, 933 insertions(+)
>  create mode 100644 drivers/media/radio/radio-rda5807.c
> 
> diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
> index d29e29645e04..323faa7d3d52 100644
> --- a/drivers/media/radio/Kconfig
> +++ b/drivers/media/radio/Kconfig
> @@ -81,6 +81,18 @@ config RADIO_MAXIRADIO
> To compile this driver as a module, choose M here: the
> module will be called radio-maxiradio.
>  
> +config RADIO_RDA5807
> + tristate "RDA5807 I2C FM radio support"
> + depends on I2C && VIDEO_V4L2
> + select REGMAP_I2C
> + select PM
> + help
> +   Say Y here if you want to use the RDA5807 FM receiver connected to
> +   an I2C bus.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called radio-rda5807.
> +
>  config RADIO_SHARK
>   tristate "Griffin radioSHARK USB radio receiver"
>   depends on USB
> diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
> index 53c7ae135460..a85ccab640b0 100644
> --- a/drivers/media/radio/Makefile
> +++ b/drivers/media/radio/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_RADIO_SI4713) += si4713/
>  obj-$(CONFIG_USB_MR800) += radio-mr800.o
>  obj-$(CONFIG_USB_KEENE) += radio-keene.o
>  obj-$(CONFIG_USB_MA901) += radio-ma901.o
> +obj-$(CONFIG_RADIO_RDA5807) += radio-rda5807.o
>  obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
>  obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
>  obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
> diff --git a/drivers/media/radio/radio-rda5807.c 
> b/drivers/media/radio/radio-rda5807.c
> new file mode 100644
> index ..0f7796ca2575
> --- /dev/null
> +++ b/drivers/media/radio/radio-rda5807.c
> @@ -0,0 +1,920 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * radio-rda5807.c - Driver for using the RDA5807 FM tuner chip via I2C
> + *
> + * Copyright (c) 2011 Maarten ter Huurne 
> + * Copyright (c) 2021 Paul Cercueil 
> + *
> + * Many thanks to Jérôme Veres for his command line radio application that
> + * demonstrates how the chip can be controlled via I2C.
> + *
> + * Also thanks to Marcos Paulo de Souza for several patches to this driver.
> + *
> + * The RDA5807 has three ways of accessing registers:
> + * - I2C address 0x10: sequential access, RDA5800 style
> + * - I2C address 0x11: random access
> + * - I2C address 0x60: sequential access, TEA5767 compatible
> + *
> + * This driver only supports random access to the registers.
> + */
> +
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +
> +enum rda5807_reg {
> + RDA5807_REG_CHIPID  = 0x00,
> + RDA5807_REG_CTRL= 0x02,
> + RDA5807_REG_CHAN= 0x03,
> + RDA5807_REG_IOCFG   = 0x04,
> + RDA5807_REG_INPUT   = 0x05,
> + RDA5807_REG_BAND= 0x07,
> + RDA5807_REG_SEEKRES = 0x0A,
> + RDA5807_REG_SIGNAL  = 0x0B,
> +};
> +
> +#define RDA5807_CTRL_DHIZBIT(15)
> +#define RDA5807_CTRL_DMUTE   BIT(14)
> +#define RDA5807_CTRL_MONOBIT(13)
> +#define RDA5807_CTRL_BASSBIT(12)
> +#define RDA5807_CTRL_SEEKUP  BIT(9)
> +#define RDA5807_CTRL_SEEKBIT(8)
> +#define RDA5807_CTRL_SKMODE  BIT(7)
> +#define RDA5807_CTRL_CLKMODE GENMASK(6, 4)
> +#define RDA5807_CTRL_SOFTRESET   BIT(1)
> +#define RDA5807_CTRL_ENABLE  BIT(0)
> +
> +#define RDA5807_CHAN_WRCHAN  GENMASK(15, 6)
> +#define RDA5807_CHAN_TUNEBIT(4)
> +#define RDA5807_CHAN_BANDGENMASK(3, 2)
> +#define RDA5807_CHAN_SPACE   GENMASK(1, 0)
> +
> +#define RDA5807_IOCFG_DEEMPHASIS BIT(11)
> +#define RDA5807_IOCFG_I2S_EN BIT(6)
> +
> +#define RDA5807_INPUT_LNA_PORT   GENMASK(7, 6)
> +#define RDA5807_INPUT_LNA_ICSEL  GENMASK(5, 4)
> +#define RDA5807_INPUT_VOLUME GENMASK(3, 0)
> +
> +#define 

Re: [PATCH] v4l2-ctrls: Fix h264 hierarchical coding type menu ctrl

2021-03-20 Thread Hans Verkuil
On 20/03/2021 12:53, Stanimir Varbanov wrote:
> Kindly ping for review.

Weird, it was marked as 'Under Review' in patchwork, but it wasn't delegated
to anyone.

I've changed it to 'New' and delegated it to myself.

It looks good and I'll pick it up next time I collect 'various fixes' in a PR.
Probably next week.

Regards,

Hans

> 
> On 3/3/21 12:42 AM, Stanimir Varbanov wrote:
>> Add a name of the menu and fill control type.
>>
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  drivers/media/v4l2-core/v4l2-ctrls.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
>> b/drivers/media/v4l2-core/v4l2-ctrls.c
>> index 016cf6204cbb..5d99e2294335 100644
>> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
>> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
>> @@ -421,6 +421,11 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>>  "Annex B Start Code",
>>  NULL,
>>  };
>> +static const char * const h264_hierarchical_coding_type[] = {
>> +"Hier Coding B",
>> +"Hier Coding P",
>> +NULL,
>> +};
>>  static const char * const mpeg_mpeg2_level[] = {
>>  "Low",
>>  "Main",
>> @@ -697,6 +702,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>>  return h264_decode_mode;
>>  case V4L2_CID_STATELESS_H264_START_CODE:
>>  return h264_start_code;
>> +case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_TYPE:
>> +return h264_hierarchical_coding_type;
>>  case V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL:
>>  return mpeg_mpeg2_level;
>>  case V4L2_CID_MPEG_VIDEO_MPEG2_PROFILE:
>> @@ -1326,6 +1333,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
>> v4l2_ctrl_type *type,
>>  case V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC:
>>  case V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE:
>>  case V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE:
>> +case V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_TYPE:
>>  case V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL:
>>  case V4L2_CID_MPEG_VIDEO_MPEG2_PROFILE:
>>  case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
>>
> 



Re: [PATCH v8 15/19] media: uvcvideo: Set error_idx during ctrl_commit errors

2021-03-20 Thread Hans Verkuil
On 19/03/2021 18:09, Ricardo Ribalda wrote:
> If we have an error setting a control, return the affected control in
> the error_idx field.
> 
> Signed-off-by: Ricardo Ribalda 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 42 ++--
>  drivers/media/usb/uvc/uvc_v4l2.c |  2 +-
>  drivers/media/usb/uvc/uvcvideo.h | 10 +++-
>  3 files changed, 40 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 24fd5afc4e4f..bcebf9d1a46f 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1586,7 +1586,7 @@ int uvc_ctrl_begin(struct uvc_video_chain *chain)
>  }
>  
>  static int uvc_ctrl_commit_entity(struct uvc_device *dev,
> - struct uvc_entity *entity, int rollback)
> + struct uvc_entity *entity, int rollback, struct uvc_control **err_ctrl)
>  {
>   struct uvc_control *ctrl;
>   unsigned int i;
> @@ -1628,31 +1628,59 @@ static int uvc_ctrl_commit_entity(struct uvc_device 
> *dev,
>  
>   ctrl->dirty = 0;
>  
> - if (ret < 0)
> + if (ret < 0) {
> + if (err_ctrl)
> + *err_ctrl = ctrl;
>   return ret;
> + }
>   }
>  
>   return 0;
>  }
>  
> +static int uvc_ctrl_find_ctrlidx(struct uvc_entity *entity,
> +  struct v4l2_ext_controls *ctrls,
> +  struct uvc_control *uvc_control)
> +{
> + struct uvc_control_mapping *mapping;
> + struct uvc_control *ctrl_found;
> + unsigned int i;
> +
> + if (!entity)
> + return ctrls->count;
> +
> + for (i = 0; i < ctrls->count; i++) {
> + __uvc_find_control(entity, ctrls->controls[i].id, ,
> +_found, 0);
> + if (uvc_control == ctrl_found)
> + return i;
> + }
> +
> + return ctrls->count;
> +}
> +
>  int __uvc_ctrl_commit(struct uvc_fh *handle, int rollback,
> -   const struct v4l2_ext_control *xctrls,
> -   unsigned int xctrls_count)
> +   struct v4l2_ext_controls *ctrls)
>  {
>   struct uvc_video_chain *chain = handle->chain;
> + struct uvc_control *err_ctrl;
>   struct uvc_entity *entity;
>   int ret = 0;
>  
>   /* Find the control. */
>   list_for_each_entry(entity, >entities, chain) {
> - ret = uvc_ctrl_commit_entity(chain->dev, entity, rollback);
> + ret = uvc_ctrl_commit_entity(chain->dev, entity, rollback,
> +  _ctrl);
>   if (ret < 0)
>   goto done;
>   }
>  
>   if (!rollback)
> - uvc_ctrl_send_events(handle, xctrls, xctrls_count);
> + uvc_ctrl_send_events(handle, ctrls->controls, ctrls->count);
>  done:
> + if (ret < 0 && ctrls)
> + ctrls->error_idx = uvc_ctrl_find_ctrlidx(entity, ctrls,
> +  err_ctrl);
>   mutex_unlock(>ctrl_mutex);
>   return ret;
>  }
> @@ -2110,7 +2138,7 @@ int uvc_ctrl_restore_values(struct uvc_device *dev)
>   ctrl->dirty = 1;
>   }
>  
> - ret = uvc_ctrl_commit_entity(dev, entity, 0);
> + ret = uvc_ctrl_commit_entity(dev, entity, 0, NULL);
>   if (ret < 0)
>   return ret;
>   }
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index a3ee1dc003fc..8d8b12a4db34 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -1088,7 +1088,7 @@ static int uvc_ioctl_s_try_ext_ctrls(struct uvc_fh 
> *handle,
>   ctrls->error_idx = 0;
>  
>   if (ioctl == VIDIOC_S_EXT_CTRLS)
> - return uvc_ctrl_commit(handle, ctrls->controls, ctrls->count);
> + return uvc_ctrl_commit(handle, ctrls);
>   else
>   return uvc_ctrl_rollback(handle);
>  }
> diff --git a/drivers/media/usb/uvc/uvcvideo.h 
> b/drivers/media/usb/uvc/uvcvideo.h
> index 9471c342a310..0313b30f0cea 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -887,17 +887,15 @@ void uvc_ctrl_status_event(struct uvc_video_chain 
> *chain,
>  
>  int uvc_ctrl_begin(struct uvc_video_chain *chain);
>  int __uvc_ctrl_commit(struct uvc_fh *handle, int rollback

Re: [PATCH v8 05/19] media: uvcvideo: Remove s_ctrl and g_ctrl

2021-03-20 Thread Hans Verkuil
On 19/03/2021 18:08, Ricardo Ribalda wrote:
> If we do not implement these callback the framework will call the ext_ctrl
> callbaks instead, which are a superset of this functions.

callbaks -> callbacks

With that changed you can add my:

Reviewed-by: Hans Verkuil 

Regards,

Hans

> 
> Suggested-by: Hans Verkuil 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_v4l2.c | 56 
>  1 file changed, 56 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index 47b0e3224205..ac98869d5a05 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -983,60 +983,6 @@ static int uvc_ioctl_query_ext_ctrl(struct file *file, 
> void *fh,
>   return 0;
>  }
>  
> -static int uvc_ioctl_g_ctrl(struct file *file, void *fh,
> - struct v4l2_control *ctrl)
> -{
> - struct uvc_fh *handle = fh;
> - struct uvc_video_chain *chain = handle->chain;
> - struct v4l2_ext_control xctrl;
> - int ret;
> -
> - memset(, 0, sizeof(xctrl));
> - xctrl.id = ctrl->id;
> -
> - ret = uvc_ctrl_begin(chain);
> - if (ret < 0)
> - return ret;
> -
> - ret = uvc_ctrl_get(chain, );
> - uvc_ctrl_rollback(handle);
> - if (ret < 0)
> - return ret;
> -
> - ctrl->value = xctrl.value;
> - return 0;
> -}
> -
> -static int uvc_ioctl_s_ctrl(struct file *file, void *fh,
> - struct v4l2_control *ctrl)
> -{
> - struct uvc_fh *handle = fh;
> - struct uvc_video_chain *chain = handle->chain;
> - struct v4l2_ext_control xctrl;
> - int ret;
> -
> - memset(, 0, sizeof(xctrl));
> - xctrl.id = ctrl->id;
> - xctrl.value = ctrl->value;
> -
> - ret = uvc_ctrl_begin(chain);
> - if (ret < 0)
> - return ret;
> -
> - ret = uvc_ctrl_set(handle, );
> - if (ret < 0) {
> - uvc_ctrl_rollback(handle);
> - return ret;
> - }
> -
> - ret = uvc_ctrl_commit(handle, , 1);
> - if (ret < 0)
> - return ret;
> -
> - ctrl->value = xctrl.value;
> - return 0;
> -}
> -
>  static int uvc_ioctl_g_ext_ctrls(struct file *file, void *fh,
>struct v4l2_ext_controls *ctrls)
>  {
> @@ -1522,8 +1468,6 @@ const struct v4l2_ioctl_ops uvc_ioctl_ops = {
>   .vidioc_s_input = uvc_ioctl_s_input,
>   .vidioc_queryctrl = uvc_ioctl_queryctrl,
>   .vidioc_query_ext_ctrl = uvc_ioctl_query_ext_ctrl,
> - .vidioc_g_ctrl = uvc_ioctl_g_ctrl,
> - .vidioc_s_ctrl = uvc_ioctl_s_ctrl,
>   .vidioc_g_ext_ctrls = uvc_ioctl_g_ext_ctrls,
>   .vidioc_s_ext_ctrls = uvc_ioctl_s_ext_ctrls,
>   .vidioc_try_ext_ctrls = uvc_ioctl_try_ext_ctrls,
> 



Re: [PATCH v8 04/19] media: v4l2-ioctl: S_CTRL output the right value

2021-03-20 Thread Hans Verkuil
On 19/03/2021 18:08, Ricardo Ribalda wrote:
> If the driver does not implement s_ctrl, but it does implement
> s_ext_ctrls, we convert the call.
> 
> When that happens we have also to convert back the response from
> s_ext_ctrls.
> 
> Fixes v4l2_compliance:
> Control ioctls (Input 0):
>   fail: v4l2-test-controls.cpp(411): returned control value out 
> of range
>   fail: v4l2-test-controls.cpp(507): invalid control 00980900
>   test VIDIOC_G/S_CTRL: FAIL
> 
> Fixes: 35ea11ff8471 ("V4L/DVB (8430): videodev: move some functions from 
> v4l2-dev.h to v4l2-common.h or v4l2-ioctl.h")
> Signed-off-by: Ricardo Ribalda 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 7b5ebdd329e8..b8f73a48872b 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -2266,6 +2266,7 @@ static int v4l_s_ctrl(const struct v4l2_ioctl_ops *ops,
>   test_bit(V4L2_FL_USES_V4L2_FH, >flags) ? fh : NULL;
>   struct v4l2_ext_controls ctrls;
>   struct v4l2_ext_control ctrl;
> + int ret;
>  
>   if (vfh && vfh->ctrl_handler)
>   return v4l2_s_ctrl(vfh, vfh->ctrl_handler, p);
> @@ -2281,9 +2282,11 @@ static int v4l_s_ctrl(const struct v4l2_ioctl_ops *ops,
>   ctrls.controls = 
>   ctrl.id = p->id;
>   ctrl.value = p->value;
> - if (check_ext_ctrls(, VIDIOC_S_CTRL))
> - return ops->vidioc_s_ext_ctrls(file, fh, );
> - return -EINVAL;
> + if (!check_ext_ctrls(, VIDIOC_S_CTRL))
> + return -EINVAL;
> + ret = ops->vidioc_s_ext_ctrls(file, fh, );
> + p->value = ctrl.value;
> + return ret;
>  }
>  
>  static int v4l_g_ext_ctrls(const struct v4l2_ioctl_ops *ops,
> 



Re: [PATCH v7 13/17] media: uvcvideo: Return -EACCES to inactive controls

2021-03-19 Thread Hans Verkuil
On 19/03/2021 10:49, Ricardo Ribalda wrote:
> Hi Hans
> 
> Thanks for testing this.
> 
> 
> 
> 
> On Fri, Mar 19, 2021 at 10:10 AM Hans Verkuil  
> wrote:
>>
>> On 18/03/2021 21:29, Ricardo Ribalda wrote:
>>> If a control is inactive return -EACCES to let the userspace know that
>>> the value will not be applied automatically when the control is active
>>> again.
>>>
>>> Reviewed-by: Hans Verkuil 
>>> Suggested-by: Hans Verkuil 
>>> Signed-off-by: Ricardo Ribalda 
>>> ---
>>>  drivers/media/usb/uvc/uvc_ctrl.c | 68 ++--
>>>  drivers/media/usb/uvc/uvc_v4l2.c | 11 +-
>>>  drivers/media/usb/uvc/uvcvideo.h |  2 +-
>>>  3 files changed, 58 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
>>> b/drivers/media/usb/uvc/uvc_ctrl.c
>>> index 24fd5afc4e4f..1ec8333811bc 100644
>>> --- a/drivers/media/usb/uvc/uvc_ctrl.c
>>> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
>>> @@ -1046,8 +1046,33 @@ static int uvc_query_v4l2_class(struct 
>>> uvc_video_chain *chain, u32 req_id,
>>>   return 0;
>>>  }
>>>
>>> +static bool uvc_ctrl_is_inactive(struct uvc_video_chain *chain,
>>> +  struct uvc_control *ctrl,
>>> +  struct uvc_control_mapping *mapping)
>>> +{
>>> + struct uvc_control_mapping *master_map = NULL;
>>> + struct uvc_control *master_ctrl = NULL;
>>> + s32 val;
>>> + int ret;
>>> +
>>> + if (!mapping->master_id)
>>> + return false;
>>> +
>>> + __uvc_find_control(ctrl->entity, mapping->master_id, _map,
>>> +_ctrl, 0);
>>> +
>>> + if (!master_ctrl || !(master_ctrl->info.flags & 
>>> UVC_CTRL_FLAG_GET_CUR))
>>> + return false;
>>> +
>>> + ret = __uvc_ctrl_get(chain, master_ctrl, master_map, );
>>> + if (ret < 0 || val == mapping->master_manual)
>>> + return false;
>>> +
>>> + return true;
>>> +}
>>
>> This doesn't work. The problem is that you need to test the new value for the
>> master control against master_manual, and you are testing against the old 
>> value.
>>
>> So for my uvc camera I have this situation after boot:
>>
>>   auto_exposure 0x009a0901 (menu)   : min=0 max=3 default=3 
>> value=3 (Aperture Priority Mode)
>> 1: Manual Mode
>> 3: Aperture Priority Mode
>>  exposure_time_absolute 0x009a0902 (int): min=3 max=2047 step=1 
>> default=250 value=250 flags=inactive
>>
>> But trying to change both auto_exposure to manual AND set the new 
>> exposure_time_absolute
>> will fail:
>>
>> $ v4l2-ctl -c auto_exposure=1,exposure_time_absolute=251
>> VIDIOC_S_EXT_CTRLS: failed: Permission denied
>> Error setting controls: Permission denied
>>
>> This works though with the uvc driver as is currently in the kernel.
>>
>> Unfortunately, this is not something that is explicitly tested in 
>> v4l2-compliance.
>>
> 
> Can you try dropping this patch and relaying on  media: uvcvideo: Set
> error_idx during ctrl_commit errors ?

That doesn't work all that well. The uvc_query_ctrl() function is problematic:

1) It can return -EILSEQ where -EACCES is expected. Not a big deal, EACCES makes
   more sense here anyway.

2) It can return error code 6 (Invalid control), and then it returns -EIO. I'm 
not
   entirely clear why I get code 6, I haven't dug deep enough for that. If I
   change that to EACCES, then v4l2-compliance passes, but...

3) This function keeps spamming the "Failed to query (%s) UVC control %u on 
unit %u: %d (exp. %u).\n"
   error in the kernel log. In all fairness, the current kernel driver does the 
same, but
   with this patch it no longer does.

I think the uvc driver really has to check this. It doesn't have to be during 
the
validation step in uvc_ctrl_check_access(), it is fine if this check happens 
during
the commit phase.

I checked the UVC 1.5 spec and in 4.2.2.1.4 (Exposure Time (Absolute) Control) 
it says:

  When the Auto-Exposure Mode control is in Auto mode or Aperture Priority mode 
attempts
  to programmatically set this control shall result in a protocol STALL and an 
error code
  of bRequestErrorCode = “Wrong state”.

So the uvc driver should just detect this and avoid writing this control in 
such a case.

Re: [PATCH v7 13/17] media: uvcvideo: Return -EACCES to inactive controls

2021-03-19 Thread Hans Verkuil
On 18/03/2021 21:29, Ricardo Ribalda wrote:
> If a control is inactive return -EACCES to let the userspace know that
> the value will not be applied automatically when the control is active
> again.
> 
> Reviewed-by: Hans Verkuil 
> Suggested-by: Hans Verkuil 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 68 ++--
>  drivers/media/usb/uvc/uvc_v4l2.c | 11 +-
>  drivers/media/usb/uvc/uvcvideo.h |  2 +-
>  3 files changed, 58 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 24fd5afc4e4f..1ec8333811bc 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1046,8 +1046,33 @@ static int uvc_query_v4l2_class(struct uvc_video_chain 
> *chain, u32 req_id,
>   return 0;
>  }
>  
> +static bool uvc_ctrl_is_inactive(struct uvc_video_chain *chain,
> +  struct uvc_control *ctrl,
> +  struct uvc_control_mapping *mapping)
> +{
> + struct uvc_control_mapping *master_map = NULL;
> + struct uvc_control *master_ctrl = NULL;
> + s32 val;
> + int ret;
> +
> + if (!mapping->master_id)
> + return false;
> +
> + __uvc_find_control(ctrl->entity, mapping->master_id, _map,
> +_ctrl, 0);
> +
> + if (!master_ctrl || !(master_ctrl->info.flags & UVC_CTRL_FLAG_GET_CUR))
> + return false;
> +
> + ret = __uvc_ctrl_get(chain, master_ctrl, master_map, );
> + if (ret < 0 || val == mapping->master_manual)
> + return false;
> +
> + return true;
> +}

This doesn't work. The problem is that you need to test the new value for the
master control against master_manual, and you are testing against the old value.

So for my uvc camera I have this situation after boot:

  auto_exposure 0x009a0901 (menu)   : min=0 max=3 default=3 
value=3 (Aperture Priority Mode)
1: Manual Mode
3: Aperture Priority Mode
 exposure_time_absolute 0x009a0902 (int): min=3 max=2047 step=1 
default=250 value=250 flags=inactive

But trying to change both auto_exposure to manual AND set the new 
exposure_time_absolute
will fail:

$ v4l2-ctl -c auto_exposure=1,exposure_time_absolute=251
VIDIOC_S_EXT_CTRLS: failed: Permission denied
Error setting controls: Permission denied

This works though with the uvc driver as is currently in the kernel.

Unfortunately, this is not something that is explicitly tested in 
v4l2-compliance.

Regards,

Hans

> +
>  int uvc_ctrl_is_accessible(struct uvc_video_chain *chain, u32 v4l2_id,
> -bool read)
> +unsigned long ioctl)
>  {
>   struct uvc_control_mapping *mapping;
>   struct uvc_control *ctrl;
> @@ -1059,11 +1084,26 @@ int uvc_ctrl_is_accessible(struct uvc_video_chain 
> *chain, u32 v4l2_id,
>   if (!ctrl)
>   return -EINVAL;
>  
> - if (!(ctrl->info.flags & UVC_CTRL_FLAG_GET_CUR) && read)
> - return -EACCES;
> -
> - if (!(ctrl->info.flags & UVC_CTRL_FLAG_SET_CUR) && !read)
> - return -EACCES;
> + switch (ioctl) {
> + case VIDIOC_G_CTRL:
> + case VIDIOC_G_EXT_CTRLS:
> + if (!(ctrl->info.flags & UVC_CTRL_FLAG_GET_CUR))
> + return -EACCES;
> + break;
> + case VIDIOC_S_EXT_CTRLS:
> + case VIDIOC_S_CTRL:
> + if (!(ctrl->info.flags & UVC_CTRL_FLAG_SET_CUR))
> + return -EACCES;
> + if (uvc_ctrl_is_inactive(chain, ctrl, mapping))
> + return -EACCES;
> + break;
> + case VIDIOC_TRY_EXT_CTRLS:
> + if (!(ctrl->info.flags & UVC_CTRL_FLAG_SET_CUR))
> + return -EACCES;
> + break;
> + default:
> + return -EINVAL;
> + }
>  
>   return 0;
>  }
> @@ -1087,8 +1127,6 @@ static int __uvc_query_v4l2_ctrl(struct uvc_video_chain 
> *chain,
>   struct uvc_control_mapping *mapping,
>   struct v4l2_queryctrl *v4l2_ctrl)
>  {
> - struct uvc_control_mapping *master_map = NULL;
> - struct uvc_control *master_ctrl = NULL;
>   const struct uvc_menu_info *menu;
>   unsigned int i;
>  
> @@ -1104,18 +1142,8 @@ static int __uvc_query_v4l2_ctrl(struct 
> uvc_video_chain *chain,
>   if (!(ctrl->info.flags & UVC_CTRL_FLAG_SET_CUR))
>   v4l2_ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>  
> -  

Re: [PATCH v7 01/17] media: v4l2-ioctl: Fix check_ext_ctrls

2021-03-19 Thread Hans Verkuil
On 18/03/2021 21:29, Ricardo Ribalda wrote:
> Drivers that do not use the ctrl-framework use this function instead.
> 
> Fix the following issues:
> 
> - Do not check for multiple classes when getting the DEF_VAL.
> - Return -EINVAL for request_api calls
> - Default value cannot be changed, return EINVAL as soon as possible.
> - Return the right error_idx
> [If an error is found when validating the list of controls passed with
> VIDIOC_G_EXT_CTRLS, then error_idx shall be set to ctrls->count to
> indicate to userspace that no actual hardware was touched.
> It would have been much nicer of course if error_idx could point to the
> control index that failed the validation, but sadly that's not how the
> API was designed.]
> 
> Fixes v4l2-compliance:
> Control ioctls (Input 0):
> warn: v4l2-test-controls.cpp(834): error_idx should be equal to count
> warn: v4l2-test-controls.cpp(855): error_idx should be equal to count
>   fail: v4l2-test-controls.cpp(813): doioctl(node, 
> VIDIOC_G_EXT_CTRLS, )
>   test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
> Buffer ioctls (Input 0):
>   fail: v4l2-test-buffers.cpp(1994): ret != EINVAL && ret != 
> EBADR && ret != ENOTTY
>   test Requests: FAIL
> 
> Cc: sta...@vger.kernel.org
> Fixes: 6fa6f831f095 ("media: v4l2-ctrls: add core request support")
> Suggested-by: Hans Verkuil 
> Reviewed-by: Hans Verkuil 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 59 ++--
>  1 file changed, 38 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 31d1342e61e8..ccd21b4d9c72 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -908,7 +908,7 @@ static void v4l_print_default(const void *arg, bool 
> write_only)
>   pr_cont("driver-specific ioctl\n");
>  }
>  
> -static int check_ext_ctrls(struct v4l2_ext_controls *c, int allow_priv)
> +static bool check_ext_ctrls(struct v4l2_ext_controls *c, unsigned long ioctl)
>  {
>   __u32 i;
>  
> @@ -917,23 +917,40 @@ static int check_ext_ctrls(struct v4l2_ext_controls *c, 
> int allow_priv)
>   for (i = 0; i < c->count; i++)
>   c->controls[i].reserved2[0] = 0;
>  
> - /* V4L2_CID_PRIVATE_BASE cannot be used as control class
> -when using extended controls.
> -Only when passed in through VIDIOC_G_CTRL and VIDIOC_S_CTRL
> -is it allowed for backwards compatibility.
> -  */
> - if (!allow_priv && c->which == V4L2_CID_PRIVATE_BASE)
> - return 0;
> - if (!c->which)
> - return 1;
> + switch (c->which) {
> + case V4L2_CID_PRIVATE_BASE:
> + /*
> +  * V4L2_CID_PRIVATE_BASE cannot be used as control class
> +  * when using extended controls.
> +  * Only when passed in through VIDIOC_G_CTRL and VIDIOC_S_CTRL
> +  * is it allowed for backwards compatibility.
> +  */
> + if (ioctl == VIDIOC_G_CTRL || ioctl == VIDIOC_S_CROP)

S_CROP -> S_CTRL :-)

Regards,

Hans

> + return false;
> + break;
> + case V4L2_CTRL_WHICH_DEF_VAL:
> + /* Default value cannot be changed */
> + if (ioctl == VIDIOC_S_EXT_CTRLS ||
> + ioctl == VIDIOC_TRY_EXT_CTRLS) {
> + c->error_idx = c->count;
> + return false;
> + }
> + return true;
> + case V4L2_CTRL_WHICH_CUR_VAL:
> + return true;
> + case V4L2_CTRL_WHICH_REQUEST_VAL:
> + c->error_idx = c->count;
> + return false;
> + }
> +
>   /* Check that all controls are from the same control class. */
>   for (i = 0; i < c->count; i++) {
>   if (V4L2_CTRL_ID2WHICH(c->controls[i].id) != c->which) {
> - c->error_idx = i;
> - return 0;
> + c->error_idx = ioctl == VIDIOC_TRY_EXT_CTRLS ? i : 
> c->count;
> + return false;
>   }
>   }
> - return 1;
> + return true;
>  }
>  
>  static int check_fmt(struct file *file, enum v4l2_buf_type type)
> @@ -2229,7 +2246,7 @@ static int v4l_g_ctrl(const struct v4l2_ioctl_ops *ops,
>   ctrls.controls = 
>   ctrl.id = p->id;
>   ctrl.value = p->value;
> - if (check_ext_ctrls(, 1)) {
> + if (check_ext_ctrls(, VIDIOC_G_CTRL)) {
>   

Re: [PATCH v7 15/17] media: uvcvideo: Refactor __uvc_ctrl_commit

2021-03-19 Thread Hans Verkuil
On 18/03/2021 21:29, Ricardo Ribalda wrote:
> Take a v4l2_ext_controls instead of an array of controls, this way we
> can access the error_idx in future changes.
> 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_ctrl.c |  5 ++---
>  drivers/media/usb/uvc/uvc_v4l2.c |  8 ++--
>  drivers/media/usb/uvc/uvcvideo.h | 10 --
>  3 files changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 1ec8333811bc..fb8155ca0c0d 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1664,8 +1664,7 @@ static int uvc_ctrl_commit_entity(struct uvc_device 
> *dev,
>  }
>  
>  int __uvc_ctrl_commit(struct uvc_fh *handle, int rollback,
> -   const struct v4l2_ext_control *xctrls,
> -   unsigned int xctrls_count)
> +   struct v4l2_ext_controls *ctrls)
>  {
>   struct uvc_video_chain *chain = handle->chain;
>   struct uvc_entity *entity;
> @@ -1679,7 +1678,7 @@ int __uvc_ctrl_commit(struct uvc_fh *handle, int 
> rollback,
>   }
>  
>   if (!rollback)
> - uvc_ctrl_send_events(handle, xctrls, xctrls_count);
> + uvc_ctrl_send_events(handle, ctrls->controls, ctrls->count);
>  done:
>   mutex_unlock(>ctrl_mutex);
>   return ret;
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index ddebdeb5a81b..ea2c41b04664 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -1025,6 +1025,10 @@ static int uvc_ioctl_s_ctrl(struct file *file, void 
> *fh,
>   struct uvc_fh *handle = fh;
>   struct uvc_video_chain *chain = handle->chain;
>   struct v4l2_ext_control xctrl;
> + struct v4l2_ext_controls ctrls = {
> + .count = 1,
> + .controls = ,
> + };

Rather than creating this extra ctrls struct, I think this can be simplified by 
just
removing uvc_ioctl_s_ctrl and uvc_ioctl_g_ctrl altogether. The v4l2-ioctl.c 
source
will call vidioc_g/s_ext_ctrls if the driver doesn't provide vidioc_g/s_ctrl 
ops.

Let's just simplify this by adding another patch before this one that just 
removes
uvc_ioctl_s_ctrl and uvc_ioctl_g_ctrl.

Otherwise this patch looks good.

Regards,

Hans

>   int ret;
>  
>   ret = uvc_ctrl_is_accessible(chain, ctrl->id, VIDIOC_S_CTRL);
> @@ -1045,7 +1049,7 @@ static int uvc_ioctl_s_ctrl(struct file *file, void *fh,
>   return ret;
>   }
>  
> - ret = uvc_ctrl_commit(handle, , 1);
> + ret = uvc_ctrl_commit(handle, );
>   if (ret < 0)
>   return ret;
>  
> @@ -1149,7 +1153,7 @@ static int uvc_ioctl_s_try_ext_ctrls(struct uvc_fh 
> *handle,
>   ctrls->error_idx = 0;
>  
>   if (ioctl == VIDIOC_S_EXT_CTRLS)
> - return uvc_ctrl_commit(handle, ctrls->controls, ctrls->count);
> + return uvc_ctrl_commit(handle, ctrls);
>   else
>   return uvc_ctrl_rollback(handle);
>  }
> diff --git a/drivers/media/usb/uvc/uvcvideo.h 
> b/drivers/media/usb/uvc/uvcvideo.h
> index a93aeedb5499..4e7b6da3c6d2 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -887,17 +887,15 @@ void uvc_ctrl_status_event(struct uvc_video_chain 
> *chain,
>  
>  int uvc_ctrl_begin(struct uvc_video_chain *chain);
>  int __uvc_ctrl_commit(struct uvc_fh *handle, int rollback,
> -   const struct v4l2_ext_control *xctrls,
> -   unsigned int xctrls_count);
> +   struct v4l2_ext_controls *ctrls);
>  static inline int uvc_ctrl_commit(struct uvc_fh *handle,
> -   const struct v4l2_ext_control *xctrls,
> -   unsigned int xctrls_count)
> +   struct v4l2_ext_controls *ctrls)
>  {
> - return __uvc_ctrl_commit(handle, 0, xctrls, xctrls_count);
> + return __uvc_ctrl_commit(handle, 0, ctrls);
>  }
>  static inline int uvc_ctrl_rollback(struct uvc_fh *handle)
>  {
> - return __uvc_ctrl_commit(handle, 1, NULL, 0);
> + return __uvc_ctrl_commit(handle, 1, NULL);
>  }
>  
>  int uvc_ctrl_get(struct uvc_video_chain *chain, struct v4l2_ext_control 
> *xctrl);
> 



Re: [PATCH v7 07/17] media: uvcvideo: Add support for V4L2_CTRL_TYPE_CTRL_CLASS

2021-03-19 Thread Hans Verkuil
On 18/03/2021 21:29, Ricardo Ribalda wrote:
> Create all the class controls for the device defined controls.
> 
> Fixes v4l2-compliance:
> Control ioctls (Input 0):
>   fail: v4l2-test-controls.cpp(216): missing control class for 
> class 0098
>   fail: v4l2-test-controls.cpp(216): missing control tclass for 
> class 009a
>   test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: FAIL
> 
> Signed-off-by: Ricardo Ribalda 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 94 
>  drivers/media/usb/uvc/uvcvideo.h |  5 ++
>  2 files changed, 99 insertions(+)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index b75da65115ef..ba14733db757 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -357,6 +357,15 @@ static const struct uvc_control_info uvc_ctrls[] = {
>   },
>  };
>  
> +static const struct uvc_control_class uvc_control_class[] = {
> + {
> + .id = V4L2_CID_CAMERA_CLASS,
> + },
> + {
> + .id = V4L2_CID_USER_CLASS,
> + },
> +};
> +
>  static const struct uvc_menu_info power_line_frequency_controls[] = {
>   { 0, "Disabled" },
>   { 1, "50 Hz" },
> @@ -1024,6 +1033,49 @@ static int __uvc_ctrl_get(struct uvc_video_chain 
> *chain,
>   return 0;
>  }
>  
> +static int __uvc_query_v4l2_class(struct uvc_video_chain *chain, u32 req_id,
> +   u32 found_id)
> +{
> + bool find_next = req_id & V4L2_CTRL_FLAG_NEXT_CTRL;
> + unsigned int i;
> +
> + req_id &= V4L2_CTRL_ID_MASK;
> +
> + for (i = 0; i < ARRAY_SIZE(uvc_control_class); i++) {
> + if (!(chain->ctrl_class_bitmap & BIT(i)))
> + continue;
> + if (!find_next) {
> + if (uvc_control_class[i].id == req_id)
> + return i;
> + continue;
> + }
> + if (uvc_control_class[i].id > req_id &&
> + uvc_control_class[i].id < found_id)
> + return i;
> + }
> +
> + return -ENODEV;
> +}
> +
> +static int uvc_query_v4l2_class(struct uvc_video_chain *chain, u32 req_id,
> + u32 found_id, struct v4l2_queryctrl *v4l2_ctrl)
> +{
> + int idx;
> +
> + idx = __uvc_query_v4l2_class(chain, req_id, found_id);
> + if (idx < 0)
> + return -ENODEV;
> +
> + memset(v4l2_ctrl, 0, sizeof(*v4l2_ctrl));
> + v4l2_ctrl->id = uvc_control_class[idx].id;
> + strscpy(v4l2_ctrl->name, v4l2_ctrl_get_name(v4l2_ctrl->id),
> + sizeof(v4l2_ctrl->name));
> + v4l2_ctrl->type = V4L2_CTRL_TYPE_CTRL_CLASS;
> + v4l2_ctrl->flags = V4L2_CTRL_FLAG_WRITE_ONLY
> +| V4L2_CTRL_FLAG_READ_ONLY;
> + return 0;
> +}
> +
>  static int __uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
>   struct uvc_control *ctrl,
>   struct uvc_control_mapping *mapping,
> @@ -1127,12 +1179,31 @@ int uvc_query_v4l2_ctrl(struct uvc_video_chain *chain,
>   if (ret < 0)
>   return -ERESTARTSYS;
>  
> + /* Check if the ctrl is a know class */
> + if (!(v4l2_ctrl->id & V4L2_CTRL_FLAG_NEXT_CTRL)) {
> + ret = uvc_query_v4l2_class(chain, v4l2_ctrl->id, 0, v4l2_ctrl);
> + if (!ret)
> + goto done;
> + }
> +
>   ctrl = uvc_find_control(chain, v4l2_ctrl->id, );
>   if (ctrl == NULL) {
>   ret = -EINVAL;
>   goto done;
>   }
>  
> + /*
> +  * If we're enumerating control with V4L2_CTRL_FLAG_NEXT_CTRL, check if
> +  * a class should be inserted between the previous control and the one
> +  * we have just found.
> +  */
> + if (v4l2_ctrl->id & V4L2_CTRL_FLAG_NEXT_CTRL) {
> + ret = uvc_query_v4l2_class(chain, v4l2_ctrl->id, mapping->id,
> +v4l2_ctrl);
> + if (!ret)
> + goto done;
> + }
> +
>   ret = __uvc_query_v4l2_ctrl(chain, ctrl, mapping, v4l2_ctrl);
>  done:
>   mutex_unlock(>ctrl_mutex);
> @@ -1426,6 +1497,11 @@ static int uvc_ctrl_add_event(struct 
> v4l2_subscribed_event *sev, unsigned elems)
>   if (ret < 0)
>   return -ERESTARTSYS;
>  
> + if (__uvc_query_v4l2_class(handle->chain, sev->id, 0) >= 0) {
> + 

Re: [PATCH v6 00/17] uvcvideo: Fix v4l2-compliance errors

2021-03-18 Thread Hans Verkuil
On 17/03/2021 17:44, Ricardo Ribalda wrote:
> v4l2-compliance -m /dev/media0 -a -f
> Total for uvcvideo device /dev/media0: 8, Succeeded: 6, Failed: 2, Warnings: 0
> Total for uvcvideo device /dev/video0: 54, Succeeded: 50, Failed: 4, 
> Warnings: 2
> Total for uvcvideo device /dev/video1: 46, Succeeded: 46, Failed: 0, 
> Warnings: 0
> Grand Total for uvcvideo device /dev/media0: 108, Succeeded: 102,
> Failed: 6, Warnings: 2
> 
> After fixing all of them we go down to:
> 
> Total for uvcvideo device /dev/media0: 8, Succeeded: 8, Failed: 0, Warnings: 0
> Total for uvcvideo device /dev/video0: 54, Succeeded: 54, Failed: 0, 
> Warnings: 0
> Total for uvcvideo device /dev/video1: 46, Succeeded: 46, Failed: 0, 
> Warnings: 0
> Grand Total for uvcvideo device /dev/media0: 108, Succeeded: 108,
> Failed: 0, Warnings: 0
> 
> YES, NO MORE WARNINGS :)
> 
> Note that we depend on:
> https://patchwork.linuxtv.org/project/linux-media/patch/20210315172531.101694-1-riba...@chromium.org/
> 
> With Hans patch we can also pass v4l2-compliance -s.

There is one remaining issue: if uvc_ioctl_s_try_ext_ctrls() calls 
uvc_ctrl_commit
and the 'commit' fails for a certain control, then you want error_idx to be the
index of the failing control. This is obviously something that v4l2-compliance 
cannot
test since it would rely on a buggy uvc HW implementation. But I can test it by
dropping patch 16/17: that should force the commit to fail and then I can verify
error_idx.

Regards,

Hans

> 
> Changelog  from v5 (Thanks to Hans)
> - Move more checks to framework
> - Rewrite the framework check_ext_ctrls
> - Rewrite ctrl_is_inactive
> - Add function ctrl_is_accessible
> - Use ioctl name instead of boolean values
> 
> Hans Verkuil (1):
>   uvc: use vb2 ioctl and fop helpers
> 
> Ricardo Ribalda (16):
>   media: v4l2-ioctl: check_ext_ctrls: Fix multiclass
> V4L2_CTRL_WHICH_DEF_VAL
>   media: v4l2-ioctl: check_ext_ctrls: Return -EINVAL on
> V4L2_CTRL_WHICH_REQUEST_VAL
>   media: v4l2-ioctl: check_ext_ctrls: Return the right error_idx
>   media: v4l2-ioctl: check_ext_ctrls: Fix V4L2_CTRL_WHICH_DEF_VAL
>   media: pvrusb2: Do not check for V4L2_CTRL_WHICH_DEF_VAL
>   media: uvcvideo: Do not check for V4L2_CTRL_WHICH_DEF_VAL
>   media: uvcvideo: Set capability in s_param
>   media: uvcvideo: Return -EIO for control errors
>   media: uvcvideo: refactor __uvc_ctrl_add_mapping
>   media: uvcvideo: Add support for V4L2_CTRL_TYPE_CTRL_CLASS
>   media: uvcvideo: Use dev->name for querycap()
>   media: uvcvideo: Set unique vdev name based in type
>   media: uvcvideo: Increase the size of UVC_METADATA_BUF_SIZE
>   media: uvcvideo: Use control names from framework
>   media: uvcvideo: Check controls flags before accessing them
>   media: uvcvideo: Return -EACCES to inactive controls
> 
>  drivers/media/usb/pvrusb2/pvrusb2-v4l2.c |   4 -
>  drivers/media/usb/uvc/uvc_ctrl.c | 284 ++
>  drivers/media/usb/uvc/uvc_driver.c   |  22 +-
>  drivers/media/usb/uvc/uvc_metadata.c |   8 +-
>  drivers/media/usb/uvc/uvc_queue.c| 143 -
>  drivers/media/usb/uvc/uvc_v4l2.c | 352 +--
>  drivers/media/usb/uvc/uvc_video.c|  13 +-
>  drivers/media/usb/uvc/uvcvideo.h |  43 +--
>  drivers/media/v4l2-core/v4l2-ioctl.c |  59 ++--
>  9 files changed, 366 insertions(+), 562 deletions(-)
> 



Re: [PATCH v6 16/17] media: uvcvideo: Return -EACCES to inactive controls

2021-03-18 Thread Hans Verkuil
On 18/03/2021 08:39, Hans Verkuil wrote:
> Hi Ricardo,
> 
> On 17/03/2021 17:45, Ricardo Ribalda wrote:
>> If a control is inactive return -EACCES to let the userspace know that
>> the value will not be applied automatically when the control is active
>> again.

Note that this needs to be documented in vidioc-g-ext-ctrls.rst and
vidioc-g-ctrl.rst as well. Currently setting inactive controls shouldn't
return EACCES, but this has now changed.

Regards,

Hans

>>
>> Signed-off-by: Ricardo Ribalda 
>> Suggested-by: Hans Verkuil 
> 
> In several of the patches in this series you added 'Suggested-by' or 
> 'Credit-to'.
> Please use  so Cisco gets the credit as well :-)
> 
>> ---
>>  drivers/media/usb/uvc/uvc_ctrl.c | 73 +---
>>  drivers/media/usb/uvc/uvc_v4l2.c | 11 -
>>  drivers/media/usb/uvc/uvcvideo.h |  3 +-
>>  3 files changed, 69 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
>> b/drivers/media/usb/uvc/uvc_ctrl.c
>> index af1d4d9b8afb..26d3494b401b 100644
>> --- a/drivers/media/usb/uvc/uvc_ctrl.c
>> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
>> @@ -1046,10 +1046,62 @@ static int uvc_query_v4l2_class(struct 
>> uvc_video_chain *chain, u32 req_id,
>>  return 0;
>>  }
>>  
>> -int uvc_ctrl_is_accesible(struct uvc_video_chain *chain, u32 v4l2_id, bool 
>> read)
>> +static bool uvc_ctrl_is_inactive(struct uvc_video_chain *chain,
>> + struct uvc_control *ctrl,
>> + struct uvc_control_mapping *mapping)
>> +{
>> +struct uvc_control_mapping *master_map = NULL;
>> +struct uvc_control *master_ctrl = NULL;
>> +s32 val;
>> +int ret;
>> +
>> +if (!mapping->master_id)
>> +return false;
>> +
>> +__uvc_find_control(ctrl->entity, mapping->master_id, _map,
>> +   _ctrl, 0);
>> +
>> +if (!master_ctrl || !(master_ctrl->info.flags & UVC_CTRL_FLAG_GET_CUR))
>> +return false;
>> +
>> +ret = __uvc_ctrl_get(chain, master_ctrl, master_map, );
>> +if (ret < 0 || val == mapping->master_manual)
>> +return false;
>> +
>> +return true;
>> +}
>> +
>> +int uvc_ctrl_is_accesible(struct uvc_video_chain *chain, u32 v4l2_id,
> 
> Same typo: accesible -> accessible
> 
>> +  unsigned long ioctl)
>>  {
>>  struct uvc_control_mapping *mapping;
>>  struct uvc_control *ctrl;
>> +bool read, try;
>> +
>> +switch (ioctl) {
>> +case VIDIOC_G_EXT_CTRLS:
>> +read = true;
>> +try = false;
>> +break;
>> +case VIDIOC_S_EXT_CTRLS:
>> +read = false;
>> +try = false;
>> +break;
>> +case VIDIOC_TRY_EXT_CTRLS:
>> +read = false;
>> +try = true;
>> +break;
>> +case VIDIOC_G_CTRL:
>> +read = true;
>> +try = false;
>> +break;
>> +case VIDIOC_S_CTRL:
>> +read = false;
>> +try = false;
>> +break;
>> +default:
>> +return -EINVAL;
>> +}
> 
> That's ugly. Just remove the bools and switch and just check the ioctl 
> below...
> 
>>  
>>  if (__uvc_query_v4l2_class(chain, v4l2_id, 0) >= 0)
>>  return -EACCES;
>> @@ -1064,6 +1116,9 @@ int uvc_ctrl_is_accesible(struct uvc_video_chain 
>> *chain, u32 v4l2_id, bool read)
>>  if (!(ctrl->info.flags & UVC_CTRL_FLAG_SET_CUR) && !read)
>>  return -EACCES;
>>  
>> +if (!read && !try && uvc_ctrl_is_inactive(chain, ctrl, mapping))
> 
> and this becomes:
> 
>   if ((ioctl == VIDIOC_S_EXT_CTRLS || ioctl == VIDIOC_S_CTRL) &&
>   uvc_ctrl_is_inactive(chain, ctrl, mapping))
> 
> Much, much simpler!
> 
>> +return -EACCES;
>> +
>>  return 0;
>>  }
>>  
>> @@ -1086,8 +1141,6 @@ static int __uvc_query_v4l2_ctrl(struct 
>> uvc_video_chain *chain,
>>  struct uvc_control_mapping *mapping,
>>  struct v4l2_queryctrl *v4l2_ctrl)
>>  {
>> -struct uvc_control_mapping *master_map = NULL;
>> -struct uvc_control *master_ctrl = NULL;
>>  const struct uvc_menu_info *menu;
>>  unsigned int i;
>>  
>> @@ -1103,18 +1156,8 @@ static int __uvc_quer

Re: [PATCH v6 11/17] media: uvcvideo: Use dev->name for querycap()

2021-03-18 Thread Hans Verkuil
On 17/03/2021 17:45, Ricardo Ribalda wrote:
> Use the device name for the card name instead of vdev->name.
> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_v4l2.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index 397217171bbb..dd10cb9361fa 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -617,13 +617,12 @@ static int uvc_v4l2_release(struct file *file)
>  static int uvc_ioctl_querycap(struct file *file, void *fh,
> struct v4l2_capability *cap)
>  {
> - struct video_device *vdev = video_devdata(file);
>   struct uvc_fh *handle = file->private_data;
>   struct uvc_video_chain *chain = handle->chain;
>   struct uvc_streaming *stream = handle->stream;
>  
>   strscpy(cap->driver, "uvcvideo", sizeof(cap->driver));
> - strscpy(cap->card, vdev->name, sizeof(cap->card));
> + strscpy(cap->card, handle->stream->dev->name, sizeof(cap->card));
>   usb_make_path(stream->dev->udev, cap->bus_info, sizeof(cap->bus_info));
>   cap->capabilities = V4L2_CAP_DEVICE_CAPS | V4L2_CAP_STREAMING
> | chain->caps;
> 

You forgot to update querycap in uvc_metadata.c as well:

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/usb/uvc/uvc_metadata.c 
b/drivers/media/usb/uvc/uvc_metadata.c
index 849d8e5ab75d..d3aab22f91ce 100644
--- a/drivers/media/usb/uvc/uvc_metadata.c
+++ b/drivers/media/usb/uvc/uvc_metadata.c
@@ -30,7 +30,7 @@ static int uvc_meta_v4l2_querycap(struct file *file, void *fh,
struct uvc_video_chain *chain = stream->chain;

strscpy(cap->driver, "uvcvideo", sizeof(cap->driver));
-   strscpy(cap->card, vfh->vdev->name, sizeof(cap->card));
+   strscpy(cap->card, stream->dev->name, sizeof(cap->card));
usb_make_path(stream->dev->udev, cap->bus_info, sizeof(cap->bus_info));
cap->capabilities = V4L2_CAP_DEVICE_CAPS | V4L2_CAP_STREAMING
  | chain->caps;

With this change both video and metadata card names are the same, as you would
expect.

Regards,

Hans


Re: [PATCH v6 01/17] media: v4l2-ioctl: check_ext_ctrls: Fix multiclass V4L2_CTRL_WHICH_DEF_VAL

2021-03-18 Thread Hans Verkuil
On 18/03/2021 08:17, Ricardo Ribalda wrote:
> Hi Hans
> 
> Can I merge 1-3, but leave 4 as a separate one? It helps to tell a
> story for 5 and  6.

I really prefer it as a single patch. All four patches are basically a single 
big fix
for v4l2-ioctl.c where the code for drivers that do not use the control 
framework had
become very outdated. Fixing it in a single patch helps backporting to stable, 
and
it is easier to review and see everything that had to be done to fix this.

In this case I wondered when I was reviewing patch 1 why 
V4L2_CTRL_WHICH_DEF_VAL was
just accepted without checking for S/TRY_EXT_CTRLS. Basically patch 1 is a 
broken fix
w.r.t. DEF_VAL until patch 4, which really fixes it.

Just do it all in a single patch, splitting it up doesn't work in this 
particular case.

Regards,

Hans

> 
> Thanks
> 
> On Thu, Mar 18, 2021 at 8:14 AM Hans Verkuil  wrote:
>>
>> Hi Ricardo,
>>
>> On 17/03/2021 17:44, Ricardo Ribalda wrote:
>>> Drivers that do not use the ctrl-framework use this function instead.
>>>
>>> - Do not check for multiple classes when getting the DEF_VAL.
>>>
>>> Fixes v4l2-compliance:
>>> Control ioctls (Input 0):
>>>   fail: v4l2-test-controls.cpp(813): doioctl(node, 
>>> VIDIOC_G_EXT_CTRLS, )
>>>   test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
>>
>> Can you merge patches 1-4 into a single patch? It's really one big fix since
>> this code was never updated when new 'which' values were added. So keeping it
>> together is, for once, actually preferred.
>>
>> You can add my:
>>
>> Reviewed-by: Hans Verkuil 
>>
>> after these 4 patches are merged. It looks much nicer now.
>>
>> Regards,
>>
>> Hans
>>
>>>
>>> Cc: sta...@vger.kernel.org
>>> Fixes: 6fa6f831f095 ("media: v4l2-ctrls: add core request support")
>>> Suggested-by: Hans Verkuil 
>>> Signed-off-by: Ricardo Ribalda 
>>> Reviewed-by: Laurent Pinchart 
>>> ---
>>>  drivers/media/v4l2-core/v4l2-ioctl.c | 47 
>>>  1 file changed, 27 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
>>> b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> index 31d1342e61e8..403f957a1012 100644
>>> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
>>> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
>>> @@ -908,7 +908,7 @@ static void v4l_print_default(const void *arg, bool 
>>> write_only)
>>>   pr_cont("driver-specific ioctl\n");
>>>  }
>>>
>>> -static int check_ext_ctrls(struct v4l2_ext_controls *c, int allow_priv)
>>> +static bool check_ext_ctrls(struct v4l2_ext_controls *c, unsigned long 
>>> ioctl)
>>>  {
>>>   __u32 i;
>>>
>>> @@ -917,23 +917,30 @@ static int check_ext_ctrls(struct v4l2_ext_controls 
>>> *c, int allow_priv)
>>>   for (i = 0; i < c->count; i++)
>>>   c->controls[i].reserved2[0] = 0;
>>>
>>> - /* V4L2_CID_PRIVATE_BASE cannot be used as control class
>>> -when using extended controls.
>>> -Only when passed in through VIDIOC_G_CTRL and VIDIOC_S_CTRL
>>> -is it allowed for backwards compatibility.
>>> -  */
>>> - if (!allow_priv && c->which == V4L2_CID_PRIVATE_BASE)
>>> - return 0;
>>> - if (!c->which)
>>> - return 1;
>>> + switch (c->which) {
>>> + case V4L2_CID_PRIVATE_BASE:
>>> + /*
>>> +  * V4L2_CID_PRIVATE_BASE cannot be used as control class
>>> +  * when using extended controls.
>>> +  * Only when passed in through VIDIOC_G_CTRL and VIDIOC_S_CTRL
>>> +  * is it allowed for backwards compatibility.
>>> +  */
>>> + if (ioctl == VIDIOC_G_CTRL || ioctl == VIDIOC_S_CROP)
>>> + return false;
>>> + break;
>>> + case V4L2_CTRL_WHICH_DEF_VAL:
>>> + case V4L2_CTRL_WHICH_CUR_VAL:
>>> + return true;
>>> + }
>>> +
>>>   /* Check that all controls are from the same control class. */
>>>   for (i = 0; i < c->count; i++) {
>>>   if (V4L2_CTRL_ID2WHICH(c->controls[i].id) != c->which) {
>>>   c->error_idx = i;
>>> - return 0;
>>> + return f

Re: [PATCH v6 16/17] media: uvcvideo: Return -EACCES to inactive controls

2021-03-18 Thread Hans Verkuil
Hi Ricardo,

On 17/03/2021 17:45, Ricardo Ribalda wrote:
> If a control is inactive return -EACCES to let the userspace know that
> the value will not be applied automatically when the control is active
> again.
> 
> Signed-off-by: Ricardo Ribalda 
> Suggested-by: Hans Verkuil 

In several of the patches in this series you added 'Suggested-by' or 
'Credit-to'.
Please use  so Cisco gets the credit as well :-)

> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 73 +---
>  drivers/media/usb/uvc/uvc_v4l2.c | 11 -
>  drivers/media/usb/uvc/uvcvideo.h |  3 +-
>  3 files changed, 69 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index af1d4d9b8afb..26d3494b401b 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1046,10 +1046,62 @@ static int uvc_query_v4l2_class(struct 
> uvc_video_chain *chain, u32 req_id,
>   return 0;
>  }
>  
> -int uvc_ctrl_is_accesible(struct uvc_video_chain *chain, u32 v4l2_id, bool 
> read)
> +static bool uvc_ctrl_is_inactive(struct uvc_video_chain *chain,
> +  struct uvc_control *ctrl,
> +  struct uvc_control_mapping *mapping)
> +{
> + struct uvc_control_mapping *master_map = NULL;
> + struct uvc_control *master_ctrl = NULL;
> + s32 val;
> + int ret;
> +
> + if (!mapping->master_id)
> + return false;
> +
> + __uvc_find_control(ctrl->entity, mapping->master_id, _map,
> +_ctrl, 0);
> +
> + if (!master_ctrl || !(master_ctrl->info.flags & UVC_CTRL_FLAG_GET_CUR))
> + return false;
> +
> + ret = __uvc_ctrl_get(chain, master_ctrl, master_map, );
> + if (ret < 0 || val == mapping->master_manual)
> + return false;
> +
> + return true;
> +}
> +
> +int uvc_ctrl_is_accesible(struct uvc_video_chain *chain, u32 v4l2_id,

Same typo: accesible -> accessible

> +   unsigned long ioctl)
>  {
>   struct uvc_control_mapping *mapping;
>   struct uvc_control *ctrl;
> + bool read, try;
> +
> + switch (ioctl) {
> + case VIDIOC_G_EXT_CTRLS:
> + read = true;
> + try = false;
> + break;
> + case VIDIOC_S_EXT_CTRLS:
> + read = false;
> + try = false;
> + break;
> + case VIDIOC_TRY_EXT_CTRLS:
> + read = false;
> + try = true;
> + break;
> + case VIDIOC_G_CTRL:
> + read = true;
> + try = false;
> + break;
> + case VIDIOC_S_CTRL:
> + read = false;
> + try = false;
> + break;
> + default:
> + return -EINVAL;
> + }

That's ugly. Just remove the bools and switch and just check the ioctl below...

>  
>   if (__uvc_query_v4l2_class(chain, v4l2_id, 0) >= 0)
>   return -EACCES;
> @@ -1064,6 +1116,9 @@ int uvc_ctrl_is_accesible(struct uvc_video_chain 
> *chain, u32 v4l2_id, bool read)
>   if (!(ctrl->info.flags & UVC_CTRL_FLAG_SET_CUR) && !read)
>   return -EACCES;
>  
> + if (!read && !try && uvc_ctrl_is_inactive(chain, ctrl, mapping))

and this becomes:

if ((ioctl == VIDIOC_S_EXT_CTRLS || ioctl == VIDIOC_S_CTRL) &&
uvc_ctrl_is_inactive(chain, ctrl, mapping))

Much, much simpler!

> + return -EACCES;
> +
>   return 0;
>  }
>  
> @@ -1086,8 +1141,6 @@ static int __uvc_query_v4l2_ctrl(struct uvc_video_chain 
> *chain,
>   struct uvc_control_mapping *mapping,
>   struct v4l2_queryctrl *v4l2_ctrl)
>  {
> - struct uvc_control_mapping *master_map = NULL;
> - struct uvc_control *master_ctrl = NULL;
>   const struct uvc_menu_info *menu;
>   unsigned int i;
>  
> @@ -1103,18 +1156,8 @@ static int __uvc_query_v4l2_ctrl(struct 
> uvc_video_chain *chain,
>   if (!(ctrl->info.flags & UVC_CTRL_FLAG_SET_CUR))
>   v4l2_ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>  
> - if (mapping->master_id)
> - __uvc_find_control(ctrl->entity, mapping->master_id,
> -_map, _ctrl, 0);
> - if (master_ctrl && (master_ctrl->info.flags & UVC_CTRL_FLAG_GET_CUR)) {
> - s32 val;
> - int ret = __uvc_ctrl_get(chain, master_ctrl, master_map, );
> - if (ret < 0)
> - return ret;
> -
> - if (val != mapping->master_manual)
> -   

Re: [PATCH v6 15/17] media: uvcvideo: Check controls flags before accessing them

2021-03-18 Thread Hans Verkuil
On 17/03/2021 17:45, Ricardo Ribalda wrote:
> We can figure out if reading/writing a set of controls can fail without
> accessing them by checking their flags.
> 
> This way we can honor the API closer:
> 
> If an error is found when validating the list of controls passed with
> VIDIOC_G_EXT_CTRLS, then error_idx shall be set to ctrls->count to
> indicate to userspace that no actual hardware was touched.
> 
> Fixes v4l2-compliance:
> Control ioctls (Input 0):
>   warn: v4l2-test-controls.cpp(765): g_ext_ctrls(0) invalid 
> error_idx 0
> fail: v4l2-test-controls.cpp(645): invalid error index write 
> only control
> test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
> 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 21 +
>  drivers/media/usb/uvc/uvc_v4l2.c | 39 
>  drivers/media/usb/uvc/uvcvideo.h |  1 +
>  3 files changed, 56 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 929e70dff11a..af1d4d9b8afb 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1046,6 +1046,27 @@ static int uvc_query_v4l2_class(struct uvc_video_chain 
> *chain, u32 req_id,
>   return 0;
>  }
>  
> +int uvc_ctrl_is_accesible(struct uvc_video_chain *chain, u32 v4l2_id, bool 
> read)

accesible -> accessible

With that typo fixed you can add my:

Reviewed-by: Hans Verkuil 

Thanks!

Hans

> +{
> + struct uvc_control_mapping *mapping;
> + struct uvc_control *ctrl;
> +
> + if (__uvc_query_v4l2_class(chain, v4l2_id, 0) >= 0)
> + return -EACCES;
> +
> + ctrl = uvc_find_control(chain, v4l2_id, );
> + if (!ctrl)
> + return -EINVAL;
> +
> + if (!(ctrl->info.flags & UVC_CTRL_FLAG_GET_CUR) && read)
> + return -EACCES;
> +
> + if (!(ctrl->info.flags & UVC_CTRL_FLAG_SET_CUR) && !read)
> + return -EACCES;
> +
> + return 0;
> +}
> +
>  static const char *uvc_map_get_name(const struct uvc_control_mapping *map)
>  {
>   const char *name;
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index ed262f61e6a6..ce55b4bff687 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -1045,6 +1045,26 @@ static int uvc_ioctl_s_ctrl(struct file *file, void 
> *fh,
>   return 0;
>  }
>  
> +static int uvc_ctrl_check_access(struct uvc_video_chain *chain,
> +  struct v4l2_ext_controls *ctrls,
> +  unsigned long ioctl)
> +{
> + struct v4l2_ext_control *ctrl = ctrls->controls;
> + unsigned int i;
> + int ret = 0;
> +
> + for (i = 0; i < ctrls->count; ++ctrl, ++i) {
> + ret = uvc_ctrl_is_accesible(chain, ctrl->id,
> + ioctl == VIDIOC_G_EXT_CTRLS);
> + if (ret)
> + break;
> + }
> +
> + ctrls->error_idx = ioctl == VIDIOC_TRY_EXT_CTRLS ? i : ctrls->count;
> +
> + return ret;
> +}
> +
>  static int uvc_ioctl_g_ext_ctrls(struct file *file, void *fh,
>struct v4l2_ext_controls *ctrls)
>  {
> @@ -1054,6 +1074,10 @@ static int uvc_ioctl_g_ext_ctrls(struct file *file, 
> void *fh,
>   unsigned int i;
>   int ret;
>  
> + ret = uvc_ctrl_check_access(chain, ctrls, VIDIOC_G_EXT_CTRLS);
> + if (ret < 0)
> + return ret;
> +
>   if (ctrls->which == V4L2_CTRL_WHICH_DEF_VAL) {
>   for (i = 0; i < ctrls->count; ++ctrl, ++i) {
>   struct v4l2_queryctrl qc = { .id = ctrl->id };
> @@ -1090,13 +1114,17 @@ static int uvc_ioctl_g_ext_ctrls(struct file *file, 
> void *fh,
>  
>  static int uvc_ioctl_s_try_ext_ctrls(struct uvc_fh *handle,
>struct v4l2_ext_controls *ctrls,
> -  bool commit)
> +  unsigned long ioctl)
>  {
>   struct v4l2_ext_control *ctrl = ctrls->controls;
>   struct uvc_video_chain *chain = handle->chain;
>   unsigned int i;
>   int ret;
>  
> + ret = uvc_ctrl_check_access(chain, ctrls, ioctl);
> + if (ret < 0)
> + return ret;
> +
>   ret = uvc_ctrl_begin(chain);
>   if (ret < 0)
>   return ret;
> @@ -1105,14 +1133,15 @@ static int uvc_ioctl_s_try_ext_ctrls(struct uvc_fh 
> *handle,
>   ret

Re: [PATCH v6 09/17] media: uvcvideo: refactor __uvc_ctrl_add_mapping

2021-03-18 Thread Hans Verkuil
On 17/03/2021 17:45, Ricardo Ribalda wrote:
> Pass the chain instead of the device. We want to keed the reference to

keed -> keep

With that typo fixed you can add my:

Reviewed-by: Hans Verkuil 

Thanks!

Hans

> the chain that controls belong to.
> 
> We need to delay the initialization of the controls after the chains
> have been initialized.
> 
> This is a cleanup needed for the next patches.
> 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_ctrl.c   | 41 --
>  drivers/media/usb/uvc/uvc_driver.c |  8 +++---
>  2 files changed, 32 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index b3dde98499f4..b75da65115ef 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -2057,7 +2057,7 @@ static int uvc_ctrl_add_info(struct uvc_device *dev, 
> struct uvc_control *ctrl,
>  /*
>   * Add a control mapping to a given control.
>   */
> -static int __uvc_ctrl_add_mapping(struct uvc_device *dev,
> +static int __uvc_ctrl_add_mapping(struct uvc_video_chain *chain,
>   struct uvc_control *ctrl, const struct uvc_control_mapping *mapping)
>  {
>   struct uvc_control_mapping *map;
> @@ -2086,7 +2086,7 @@ static int __uvc_ctrl_add_mapping(struct uvc_device 
> *dev,
>   map->set = uvc_set_le_value;
>  
>   list_add_tail(>list, >info.mappings);
> - uvc_dbg(dev, CONTROL, "Adding mapping '%s' to control %pUl/%u\n",
> + uvc_dbg(chain->dev, CONTROL, "Adding mapping '%s' to control %pUl/%u\n",
>   map->name, ctrl->info.entity, ctrl->info.selector);
>  
>   return 0;
> @@ -2168,7 +2168,7 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain *chain,
>   goto done;
>   }
>  
> - ret = __uvc_ctrl_add_mapping(dev, ctrl, mapping);
> + ret = __uvc_ctrl_add_mapping(chain, ctrl, mapping);
>   if (ret < 0)
>   atomic_dec(>nmappings);
>  
> @@ -2244,7 +2244,8 @@ static void uvc_ctrl_prune_entity(struct uvc_device 
> *dev,
>   * Add control information and hardcoded stock control mappings to the given
>   * device.
>   */
> -static void uvc_ctrl_init_ctrl(struct uvc_device *dev, struct uvc_control 
> *ctrl)
> +static void uvc_ctrl_init_ctrl(struct uvc_video_chain *chain,
> +struct uvc_control *ctrl)
>  {
>   const struct uvc_control_info *info = uvc_ctrls;
>   const struct uvc_control_info *iend = info + ARRAY_SIZE(uvc_ctrls);
> @@ -2263,14 +2264,14 @@ static void uvc_ctrl_init_ctrl(struct uvc_device 
> *dev, struct uvc_control *ctrl)
>   for (; info < iend; ++info) {
>   if (uvc_entity_match_guid(ctrl->entity, info->entity) &&
>   ctrl->index == info->index) {
> - uvc_ctrl_add_info(dev, ctrl, info);
> + uvc_ctrl_add_info(chain->dev, ctrl, info);
>   /*
>* Retrieve control flags from the device. Ignore errors
>* and work with default flag values from the uvc_ctrl
>* array when the device doesn't properly implement
>* GET_INFO on standard controls.
>*/
> - uvc_ctrl_get_flags(dev, ctrl, >info);
> + uvc_ctrl_get_flags(chain->dev, ctrl, >info);
>   break;
>}
>   }
> @@ -2281,22 +2282,20 @@ static void uvc_ctrl_init_ctrl(struct uvc_device 
> *dev, struct uvc_control *ctrl)
>   for (; mapping < mend; ++mapping) {
>   if (uvc_entity_match_guid(ctrl->entity, mapping->entity) &&
>   ctrl->info.selector == mapping->selector)
> - __uvc_ctrl_add_mapping(dev, ctrl, mapping);
> + __uvc_ctrl_add_mapping(chain, ctrl, mapping);
>   }
>  }
>  
>  /*
>   * Initialize device controls.
>   */
> -int uvc_ctrl_init_device(struct uvc_device *dev)
> +static int uvc_ctrl_init_chain(struct uvc_video_chain *chain)
>  {
>   struct uvc_entity *entity;
>   unsigned int i;
>  
> - INIT_WORK(>async_ctrl.work, uvc_ctrl_status_event_work);
> -
>   /* Walk the entities list and instantiate controls */
> - list_for_each_entry(entity, >entities, list) {
> + list_for_each_entry(entity, >entities, chain) {
>   struct uvc_control *ctrl;
>   unsigned int bControlSize = 0, ncontrols;
>   u8 *bmControls = NULL;
&g

Re: [PATCH v6 05/17] media: pvrusb2: Do not check for V4L2_CTRL_WHICH_DEF_VAL

2021-03-18 Thread Hans Verkuil
On 17/03/2021 17:44, Ricardo Ribalda wrote:
> The framework already checks for us if V4L2_CTRL_WHICH_DEF_VAL is
> written.
> 
> Cc: Mike Isely 
> Signed-off-by: Ricardo Ribalda 

Reviewed-by: Hans Verkuil 

Thanks!

Hans

> ---
>  drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c 
> b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> index 9657c1883311..c04ab7258d64 100644
> --- a/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> +++ b/drivers/media/usb/pvrusb2/pvrusb2-v4l2.c
> @@ -640,10 +640,6 @@ static int pvr2_s_ext_ctrls(struct file *file, void 
> *priv,
>   unsigned int idx;
>   int ret;
>  
> - /* Default value cannot be changed */
> - if (ctls->which == V4L2_CTRL_WHICH_DEF_VAL)
> - return -EINVAL;
> -
>   ret = 0;
>   for (idx = 0; idx < ctls->count; idx++) {
>   ctrl = ctls->controls + idx;
> 



Re: [PATCH v6 06/17] media: uvcvideo: Do not check for V4L2_CTRL_WHICH_DEF_VAL

2021-03-18 Thread Hans Verkuil
On 17/03/2021 17:45, Ricardo Ribalda wrote:
> The framework already checks for us if V4L2_CTRL_WHICH_DEF_VAL is
> written.
> 
> Signed-off-by: Ricardo Ribalda 

Reviewed-by: Hans Verkuil 

Thanks!

Hans

> ---
>  drivers/media/usb/uvc/uvc_v4l2.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index 252136cc885c..47b0e3224205 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -1089,10 +1089,6 @@ static int uvc_ioctl_s_try_ext_ctrls(struct uvc_fh 
> *handle,
>   unsigned int i;
>   int ret;
>  
> - /* Default value cannot be changed */
> - if (ctrls->which == V4L2_CTRL_WHICH_DEF_VAL)
> - return -EINVAL;
> -
>   ret = uvc_ctrl_begin(chain);
>   if (ret < 0)
>   return ret;
> 



Re: [PATCH v6 01/17] media: v4l2-ioctl: check_ext_ctrls: Fix multiclass V4L2_CTRL_WHICH_DEF_VAL

2021-03-18 Thread Hans Verkuil
Hi Ricardo,

On 17/03/2021 17:44, Ricardo Ribalda wrote:
> Drivers that do not use the ctrl-framework use this function instead.
> 
> - Do not check for multiple classes when getting the DEF_VAL.
> 
> Fixes v4l2-compliance:
> Control ioctls (Input 0):
>   fail: v4l2-test-controls.cpp(813): doioctl(node, 
> VIDIOC_G_EXT_CTRLS, )
>   test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL

Can you merge patches 1-4 into a single patch? It's really one big fix since
this code was never updated when new 'which' values were added. So keeping it
together is, for once, actually preferred.

You can add my:

Reviewed-by: Hans Verkuil 

after these 4 patches are merged. It looks much nicer now.

Regards,

Hans

> 
> Cc: sta...@vger.kernel.org
> Fixes: 6fa6f831f095 ("media: v4l2-ctrls: add core request support")
> Suggested-by: Hans Verkuil 
> Signed-off-by: Ricardo Ribalda 
> Reviewed-by: Laurent Pinchart 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 47 
>  1 file changed, 27 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 31d1342e61e8..403f957a1012 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -908,7 +908,7 @@ static void v4l_print_default(const void *arg, bool 
> write_only)
>   pr_cont("driver-specific ioctl\n");
>  }
>  
> -static int check_ext_ctrls(struct v4l2_ext_controls *c, int allow_priv)
> +static bool check_ext_ctrls(struct v4l2_ext_controls *c, unsigned long ioctl)
>  {
>   __u32 i;
>  
> @@ -917,23 +917,30 @@ static int check_ext_ctrls(struct v4l2_ext_controls *c, 
> int allow_priv)
>   for (i = 0; i < c->count; i++)
>   c->controls[i].reserved2[0] = 0;
>  
> - /* V4L2_CID_PRIVATE_BASE cannot be used as control class
> -when using extended controls.
> -Only when passed in through VIDIOC_G_CTRL and VIDIOC_S_CTRL
> -is it allowed for backwards compatibility.
> -  */
> - if (!allow_priv && c->which == V4L2_CID_PRIVATE_BASE)
> - return 0;
> - if (!c->which)
> - return 1;
> + switch (c->which) {
> + case V4L2_CID_PRIVATE_BASE:
> + /*
> +  * V4L2_CID_PRIVATE_BASE cannot be used as control class
> +  * when using extended controls.
> +  * Only when passed in through VIDIOC_G_CTRL and VIDIOC_S_CTRL
> +  * is it allowed for backwards compatibility.
> +  */
> + if (ioctl == VIDIOC_G_CTRL || ioctl == VIDIOC_S_CROP)
> + return false;
> + break;
> + case V4L2_CTRL_WHICH_DEF_VAL:
> + case V4L2_CTRL_WHICH_CUR_VAL:
> + return true;
> + }
> +
>   /* Check that all controls are from the same control class. */
>   for (i = 0; i < c->count; i++) {
>   if (V4L2_CTRL_ID2WHICH(c->controls[i].id) != c->which) {
>   c->error_idx = i;
> - return 0;
> + return false;
>   }
>   }
> - return 1;
> + return true;
>  }
>  
>  static int check_fmt(struct file *file, enum v4l2_buf_type type)
> @@ -2229,7 +2236,7 @@ static int v4l_g_ctrl(const struct v4l2_ioctl_ops *ops,
>   ctrls.controls = 
>   ctrl.id = p->id;
>   ctrl.value = p->value;
> - if (check_ext_ctrls(, 1)) {
> + if (check_ext_ctrls(, VIDIOC_G_CTRL)) {
>   int ret = ops->vidioc_g_ext_ctrls(file, fh, );
>  
>   if (ret == 0)
> @@ -2263,7 +2270,7 @@ static int v4l_s_ctrl(const struct v4l2_ioctl_ops *ops,
>   ctrls.controls = 
>   ctrl.id = p->id;
>   ctrl.value = p->value;
> - if (check_ext_ctrls(, 1))
> + if (check_ext_ctrls(, VIDIOC_S_CTRL))
>   return ops->vidioc_s_ext_ctrls(file, fh, );
>   return -EINVAL;
>  }
> @@ -2285,8 +2292,8 @@ static int v4l_g_ext_ctrls(const struct v4l2_ioctl_ops 
> *ops,
>   vfd, vfd->v4l2_dev->mdev, p);
>   if (ops->vidioc_g_ext_ctrls == NULL)
>   return -ENOTTY;
> - return check_ext_ctrls(p, 0) ? ops->vidioc_g_ext_ctrls(file, fh, p) :
> - -EINVAL;
> + return check_ext_ctrls(p, VIDIOC_G_EXT_CTRLS) ?
> + ops->vidioc_g_ext_ctrls(file, fh, p) : -EINVAL;
>  }
>  
>  static int v4l_s_ext_ctrls(const struct v4l2_ioctl_ops *ops,
> @@ -2306,8 +2313,8 @@ static int v4l_s_ext_ctrls(const struct v4l2_ioctl_ops 
> *ops,
>   

Re: [PATCH v5 12/13] media: v4l2-ioctl: Set error_idx to the right value

2021-03-17 Thread Hans Verkuil
On 16/03/2021 19:00, Ricardo Ribalda wrote:
> If an error is found when validating the list of controls passed with
> VIDIOC_G_EXT_CTRLS, then error_idx shall be set to ctrls->count to
> indicate to userspace that no actual hardware was touched.
> 
> It would have been much nicer of course if error_idx could point to the
> control index that failed the validation, but sadly that's not how the
> API was designed.
> 
> Fixes v4l2-compliance:
> Control ioctls (Input 0):
>   warn: v4l2-test-controls.cpp(834): error_idx should be equal to count
>   warn: v4l2-test-controls.cpp(855): error_idx should be equal to count
>   test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> 
> Fixes: 6fa6f831f095 ("media: v4l2-ctrls: add core request support")
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 9406e90ff805..936ae21a0e0e 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -2294,8 +2294,12 @@ static int v4l_g_ext_ctrls(const struct v4l2_ioctl_ops 
> *ops,
>   vfd, vfd->v4l2_dev->mdev, p);
>   if (ops->vidioc_g_ext_ctrls == NULL)
>   return -ENOTTY;
> - return check_ext_ctrls(p, 0) ? ops->vidioc_g_ext_ctrls(file, fh, p) :
> - -EINVAL;
> +
> + if (check_ext_ctrls(p, 0))
> + return ops->vidioc_g_ext_ctrls(file, fh, p);
> +
> + p->error_idx = p->count;
> + return -EINVAL;
>  }
>  
>  static int v4l_s_ext_ctrls(const struct v4l2_ioctl_ops *ops,
> @@ -2315,8 +2319,11 @@ static int v4l_s_ext_ctrls(const struct v4l2_ioctl_ops 
> *ops,
>   vfd, vfd->v4l2_dev->mdev, p);
>   if (ops->vidioc_s_ext_ctrls == NULL)
>   return -ENOTTY;
> - return check_ext_ctrls(p, 0) ? ops->vidioc_s_ext_ctrls(file, fh, p) :
> - -EINVAL;
> + if (check_ext_ctrls(p, 0))
> + return ops->vidioc_s_ext_ctrls(file, fh, p);
> +
> + p->error_idx = p->count;
> + return -EINVAL;
>  }
>  
>  static int v4l_try_ext_ctrls(const struct v4l2_ioctl_ops *ops,
> 

No, this patch is wrong. In all cases where check_ext_ctrls() is called the
code had already set error_idx to count. The real culprit is check_ext_ctrls()
that sets error_idx to the index of the failing control. But it can only do that
for the TRY ioctl.

In my review of patch 1 I mentioned that adding a bool is_get is a good idea.
I now this that it is best to pass the ioctl (G/S/TRY_EXT_CTRLS) instead and
based on that set error_idx here. In fact, if v4l_g/s_ctrl pass G/S_CTRL as the
ioctl argument to check_ext_ctrls(), then the allow_priv argument can be dropped
as well, since that can be decided based on the ioctl for which this function is
called.

Regards,

Hans


Re: [PATCH v5 11/13] media: uvcvideo: Use control names from framework

2021-03-17 Thread Hans Verkuil
On 16/03/2021 19:00, Ricardo Ribalda wrote:
> The framework already contains a map of IDs to names, lets use it when
> possible.
> 
> Signed-off-by: Ricardo Ribalda 
> Suggested-by: Hans Verkuil 

Reviewed-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 57 
>  drivers/media/usb/uvc/uvc_v4l2.c |  8 -
>  drivers/media/usb/uvc/uvcvideo.h |  2 +-
>  3 files changed, 30 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 98614e1be829..efbdd49ad8ec 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -436,7 +436,6 @@ static void uvc_ctrl_set_rel_speed(struct 
> uvc_control_mapping *mapping,
>  static const struct uvc_control_mapping uvc_ctrl_mappings[] = {
>   {
>   .id = V4L2_CID_BRIGHTNESS,
> - .name   = "Brightness",
>   .entity = UVC_GUID_UVC_PROCESSING,
>   .selector   = UVC_PU_BRIGHTNESS_CONTROL,
>   .size   = 16,
> @@ -446,7 +445,6 @@ static const struct uvc_control_mapping 
> uvc_ctrl_mappings[] = {
>   },
>   {
>   .id = V4L2_CID_CONTRAST,
> - .name   = "Contrast",
>   .entity = UVC_GUID_UVC_PROCESSING,
>   .selector   = UVC_PU_CONTRAST_CONTROL,
>   .size   = 16,
> @@ -456,7 +454,6 @@ static const struct uvc_control_mapping 
> uvc_ctrl_mappings[] = {
>   },
>   {
>   .id = V4L2_CID_HUE,
> - .name   = "Hue",
>   .entity = UVC_GUID_UVC_PROCESSING,
>   .selector   = UVC_PU_HUE_CONTROL,
>   .size   = 16,
> @@ -468,7 +465,6 @@ static const struct uvc_control_mapping 
> uvc_ctrl_mappings[] = {
>   },
>   {
>   .id = V4L2_CID_SATURATION,
> - .name   = "Saturation",
>   .entity = UVC_GUID_UVC_PROCESSING,
>   .selector   = UVC_PU_SATURATION_CONTROL,
>   .size   = 16,
> @@ -478,7 +474,6 @@ static const struct uvc_control_mapping 
> uvc_ctrl_mappings[] = {
>   },
>   {
>   .id = V4L2_CID_SHARPNESS,
> - .name   = "Sharpness",
>   .entity = UVC_GUID_UVC_PROCESSING,
>   .selector   = UVC_PU_SHARPNESS_CONTROL,
>   .size   = 16,
> @@ -488,7 +483,6 @@ static const struct uvc_control_mapping 
> uvc_ctrl_mappings[] = {
>   },
>   {
>   .id = V4L2_CID_GAMMA,
> - .name   = "Gamma",
>   .entity = UVC_GUID_UVC_PROCESSING,
>   .selector   = UVC_PU_GAMMA_CONTROL,
>   .size   = 16,
> @@ -498,7 +492,6 @@ static const struct uvc_control_mapping 
> uvc_ctrl_mappings[] = {
>   },
>   {
>   .id = V4L2_CID_BACKLIGHT_COMPENSATION,
> - .name   = "Backlight Compensation",
>   .entity = UVC_GUID_UVC_PROCESSING,
>   .selector   = UVC_PU_BACKLIGHT_COMPENSATION_CONTROL,
>   .size   = 16,
> @@ -508,7 +501,6 @@ static const struct uvc_control_mapping 
> uvc_ctrl_mappings[] = {
>   },
>   {
>   .id = V4L2_CID_GAIN,
> - .name   = "Gain",
>   .entity = UVC_GUID_UVC_PROCESSING,
>   .selector   = UVC_PU_GAIN_CONTROL,
>   .size   = 16,
> @@ -518,7 +510,6 @@ static const struct uvc_control_mapping 
> uvc_ctrl_mappings[] = {
>   },
>   {
>   .id = V4L2_CID_POWER_LINE_FREQUENCY,
> - .name   = "Power Line Frequency",
>   .entity = UVC_GUID_UVC_PROCESSING,
>   .selector   = UVC_PU_POWER_LINE_FREQUENCY_CONTROL,
>   .size   = 2,
> @@ -530,7 +521,6 @@ static const struct uvc_control_mapping 
> uvc_ctrl_mappings[] = {
>   },
>   {
>   .id = V4L2_CID_HUE_AUTO,
> - .name   = "Hue, Auto",
>   .entity = UVC_GUID_UVC_PROCESSING,
>   .selector   = UVC_PU_HUE_AUTO_CONTROL,
>   .size   = 1,
> @@ -541,7 +531,6 @@ static const struct uvc_control_mapping 
> uvc_ctrl_m

Re: [PATCH v5 10/13] media: uvcvideo: Return -EACCES to inactive controls

2021-03-17 Thread Hans Verkuil
On 16/03/2021 19:00, Ricardo Ribalda wrote:
> If a control is inactive return -EACCES to let the userspace know that
> the value will not be applied automatically when the control is active
> again.
> 
> Signed-off-by: Ricardo Ribalda 
> Suggested-by: Hans Verkuil 
> ---
>  drivers/media/usb/uvc/uvc_ctrl.c | 17 -
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index ba14733db757..98614e1be829 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1578,6 +1578,18 @@ int uvc_ctrl_begin(struct uvc_video_chain *chain)
>   return mutex_lock_interruptible(>ctrl_mutex) ? -ERESTARTSYS : 0;
>  }
>  
> +static bool uvc_ctrl_is_inactive(struct uvc_control *ctrl)

This doesn't test if the control is inactive, it tests if it *might* be
inactive. To test if it is really inactive would require checking the value
of the master control.

> +{
> + struct uvc_control_mapping *map;
> +
> + list_for_each_entry(map, >info.mappings, list) {
> + if (map->master_id)
> + return true;
> + }
> +
> + return false;
> +}
> +
>  static int uvc_ctrl_commit_entity(struct uvc_device *dev,
>   struct uvc_entity *entity, int rollback)
>  {
> @@ -1621,8 +1633,11 @@ static int uvc_ctrl_commit_entity(struct uvc_device 
> *dev,
>  
>   ctrl->dirty = 0;
>  
> - if (ret < 0)
> + if (ret < 0) {
> + if (uvc_ctrl_is_inactive(ctrl))
> + return -EACCES;

So here you assume that if setting the control failed, and if the control
might be inactive, then it probably was inactive.

I feel a bit uncomfortable by this assumption.

Regards,

Hans

>   return ret;
> + }
>   }
>  
>   return 0;
> 



Re: [PATCH v5 09/13] media: uvcvideo: Increase the size of UVC_METADATA_BUF_SIZE

2021-03-17 Thread Hans Verkuil
On 16/03/2021 18:59, Ricardo Ribalda wrote:
> Hans has discovered that in his test device, for the H264 format
> bytesused goes up to about 570, for YUYV it will actually go up
> to a bit over 5000 bytes, and for MJPG up to about 2706 bytes.
> 
> We should also, according to V4L2_META_FMT_UVC docs, drop headers when
> the buffer is full.
> 
> Credit-to: Hans Verkuil 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_video.c | 8 +---
>  drivers/media/usb/uvc/uvcvideo.h  | 2 +-
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_video.c 
> b/drivers/media/usb/uvc/uvc_video.c
> index 25fd8aa23529..ea2903dc3252 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -1244,11 +1244,13 @@ static void uvc_video_decode_meta(struct 
> uvc_streaming *stream,
>   if (!meta_buf || length == 2)
>   return;
>  
> + /*
> +  * According to V4L2_META_FMT_UVC docs, we should drop headers when
> +  * the buffer is full.
> +  */
>   if (meta_buf->length - meta_buf->bytesused <
> - length + sizeof(meta->ns) + sizeof(meta->sof)) {
> - meta_buf->error = 1;
> + length + sizeof(meta->ns) + sizeof(meta->sof))
>   return;
> - }
>  
>   has_pts = mem[1] & UVC_STREAM_PTS;
>   has_scr = mem[1] & UVC_STREAM_SCR;
> diff --git a/drivers/media/usb/uvc/uvcvideo.h 
> b/drivers/media/usb/uvc/uvcvideo.h
> index b81d3f65e52e..a26bbec8d37b 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -527,7 +527,7 @@ struct uvc_stats_stream {
>   unsigned int max_sof;   /* Maximum STC.SOF value */
>  };
>  
> -#define UVC_METADATA_BUF_SIZE 1024
> +#define UVC_METADATA_BUF_SIZE 10240
>  
>  /**
>   * struct uvc_copy_op: Context structure to schedule asynchronous memcpy
> 

Reviewed-by: Hans Verkuil 

Thanks!

Hans


Re: [PATCH v5 07/13] media: uvcvideo: Use dev->name for querycap()

2021-03-17 Thread Hans Verkuil
On 16/03/2021 18:59, Ricardo Ribalda wrote:
> Use the device name for the card name instead of cap->card.

You mean: 'instead of vdev->name.' ?

> 
> Suggested-by: Laurent Pinchart 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_v4l2.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index e956d833ed84..d780065f3716 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -617,13 +617,12 @@ static int uvc_v4l2_release(struct file *file)
>  static int uvc_ioctl_querycap(struct file *file, void *fh,
> struct v4l2_capability *cap)
>  {
> - struct video_device *vdev = video_devdata(file);
>   struct uvc_fh *handle = file->private_data;
>   struct uvc_video_chain *chain = handle->chain;
>   struct uvc_streaming *stream = handle->stream;
>  
>   strscpy(cap->driver, "uvcvideo", sizeof(cap->driver));
> - strscpy(cap->card, vdev->name, sizeof(cap->card));
> + strscpy(cap->card, handle->stream->dev->name, sizeof(cap->card));

I don't think this is right. I get this for the video node:

Card type: Integrated IR Camera: Integrate

and this for the corresponding metadata node:

Card type: Metadata 7

But they are the same device, so I expect the same text here.

Regards,

Hans

>   usb_make_path(stream->dev->udev, cap->bus_info, sizeof(cap->bus_info));
>   cap->capabilities = V4L2_CAP_DEVICE_CAPS | V4L2_CAP_STREAMING
> | chain->caps;
> 



Re: [PATCH v5 04/13] media: uvcvideo: Check controls flags before accessing them

2021-03-17 Thread Hans Verkuil
On 16/03/2021 18:59, Ricardo Ribalda wrote:
> We can figure out if reading/writing a set of controls can fail without
> accessing them by checking their flags.
> 
> This way we can honor the API closer:
> 
> If an error is found when validating the list of controls passed with
> VIDIOC_G_EXT_CTRLS, then error_idx shall be set to ctrls->count to
> indicate to userspace that no actual hardware was touched.
> 
> Fixes v4l2-compliance:
> Control ioctls (Input 0):
>   warn: v4l2-test-controls.cpp(765): g_ext_ctrls(0) invalid 
> error_idx 0
> fail: v4l2-test-controls.cpp(645): invalid error index write 
> only control
> test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
> 
> Signed-off-by: Ricardo Ribalda 
> ---
>  drivers/media/usb/uvc/uvc_v4l2.c | 69 +++-
>  1 file changed, 51 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index 157310c0ca87..e956d833ed84 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -1040,31 +1040,54 @@ static int uvc_ioctl_s_ctrl(struct file *file, void 
> *fh,
>   return 0;
>  }
>  
> -static int uvc_ioctl_g_ext_ctrls(struct file *file, void *fh,
> -  struct v4l2_ext_controls *ctrls)
> +static int uvc_ctrl_check_access(struct uvc_video_chain *chain,
> +  struct v4l2_ext_controls *ctrls, bool read)
>  {
> - struct uvc_fh *handle = fh;
> - struct uvc_video_chain *chain = handle->chain;
>   struct v4l2_ext_control *ctrl = ctrls->controls;
>   unsigned int i;
> - int ret;
> + int ret = 0;
>  
> - if (ctrls->which == V4L2_CTRL_WHICH_DEF_VAL) {
> - for (i = 0; i < ctrls->count; ++ctrl, ++i) {
> - struct v4l2_queryctrl qc = { .id = ctrl->id };
> + for (i = 0; i < ctrls->count; ++ctrl, ++i) {
> + struct v4l2_queryctrl qc = { .id = ctrl->id };
>  
> - ret = uvc_query_v4l2_ctrl(chain, );
> - if (ret < 0) {
> - ctrls->error_idx = i;
> - return ret;
> - }
> + ret = uvc_query_v4l2_ctrl(chain, );

You can't call this. If I am not mistaken, this call can actually call
the hardware.

Instead you need to call the lower level function uvc_find_control() and
use ctrl->info to check for read/write only.

> + if (ret < 0)
> + break;
>  
> + if (ctrls->which == V4L2_CTRL_WHICH_DEF_VAL) {
>   ctrl->value = qc.default_value;

This needs to use the old code in uvc_ioctl_g_ext_ctrls() since it depends
on uvc_query_v4l2_ctrl() which accesses the hardware.

> + continue;
>   }
>  
> - return 0;
> + if (qc.flags & V4L2_CTRL_FLAG_WRITE_ONLY && read) {
> + ret = -EACCES;
> + break;
> + }
> +
> + if (qc.flags & V4L2_CTRL_FLAG_READ_ONLY && !read) {
> + ret = -EACCES;
> + break;
> + }
>   }
>  
> + ctrls->error_idx = ctrls->count;
> +
> + return ret;
> +}

So uvc_ctrl_check_access() is a good idea, but it does a bit too much.
It should just check if all controls in the list are known and check for
write/read only.

Regards,

Hans

> +
> +static int uvc_ioctl_g_ext_ctrls(struct file *file, void *fh,
> +  struct v4l2_ext_controls *ctrls)
> +{
> + struct uvc_fh *handle = fh;
> + struct uvc_video_chain *chain = handle->chain;
> + struct v4l2_ext_control *ctrl = ctrls->controls;
> + unsigned int i;
> + int ret;
> +
> + ret = uvc_ctrl_check_access(chain, ctrls, true);
> + if (ret < 0 || ctrls->which == V4L2_CTRL_WHICH_DEF_VAL)
> + return ret;
> +
>   ret = uvc_ctrl_begin(chain);
>   if (ret < 0)
>   return ret;
> @@ -1092,10 +1115,6 @@ static int uvc_ioctl_s_try_ext_ctrls(struct uvc_fh 
> *handle,
>   unsigned int i;
>   int ret;
>  
> - /* Default value cannot be changed */
> - if (ctrls->which == V4L2_CTRL_WHICH_DEF_VAL)
> - return -EINVAL;
> -
>   ret = uvc_ctrl_begin(chain);
>   if (ret < 0)
>   return ret;
> @@ -1121,6 +1140,16 @@ static int uvc_ioctl_s_ext_ctrls(struct file *file, 
> void *fh,
>struct v4l2_ext_controls *ctrls)
>  {
>   struct uvc_fh *handle = fh;
> + struct uvc_video_chain *chain = handle->chain;
> + int ret;
> +
> + /* Default value cannot be changed */
> + if (ctrls->which == V4L2_CTRL_WHICH_DEF_VAL)
> + return -EINVAL;
> +
> + ret = uvc_ctrl_check_access(chain, ctrls, false);
> + if (ret < 0)
> + return ret;
>  
>   return uvc_ioctl_s_try_ext_ctrls(handle, ctrls, true);
>  }
> @@ -1130,6 +1159,10 @@ 

Re: [PATCH v5 01/13] media: v4l2-ioctl: Fix check_ext_ctrls

2021-03-17 Thread Hans Verkuil
On 16/03/2021 18:59, Ricardo Ribalda wrote:
> Drivers that do not use the ctrl-framework use this function instead.
> 
> - Return error when handling of REQUEST_VAL.
> - Do not check for multiple classes when getting the DEF_VAL.
> 
> Fixes v4l2-compliance:
> Control ioctls (Input 0):
>   fail: v4l2-test-controls.cpp(813): doioctl(node, 
> VIDIOC_G_EXT_CTRLS, )
>   test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
> 
> Cc: sta...@vger.kernel.org
> Fixes: 6fa6f831f095 ("media: v4l2-ctrls: add core request support")
> Suggested-by: Hans Verkuil 
> Signed-off-by: Ricardo Ribalda 
> Reviewed-by: Laurent Pinchart 
> ---
>  drivers/media/v4l2-core/v4l2-ioctl.c | 25 +
>  1 file changed, 17 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
> b/drivers/media/v4l2-core/v4l2-ioctl.c
> index 31d1342e61e8..9406e90ff805 100644
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -917,15 +917,24 @@ static int check_ext_ctrls(struct v4l2_ext_controls *c, 
> int allow_priv)

allow_priv really should be a bool.

>   for (i = 0; i < c->count; i++)
>   c->controls[i].reserved2[0] = 0;
>  
> - /* V4L2_CID_PRIVATE_BASE cannot be used as control class
> -when using extended controls.
> -Only when passed in through VIDIOC_G_CTRL and VIDIOC_S_CTRL
> -is it allowed for backwards compatibility.
> -  */
> - if (!allow_priv && c->which == V4L2_CID_PRIVATE_BASE)
> - return 0;
> - if (!c->which)
> + switch (c->which) {
> + case V4L2_CID_PRIVATE_BASE:
> + /*
> +  * V4L2_CID_PRIVATE_BASE cannot be used as control class
> +  * when using extended controls.
> +  * Only when passed in through VIDIOC_G_CTRL and VIDIOC_S_CTRL
> +  * is it allowed for backwards compatibility.
> + */
> + if (!allow_priv)
> + return 0;
> + break;
> + case V4L2_CTRL_WHICH_DEF_VAL:

I think it would be better if a second bool 'is_get' argument is added that is 
true
for g_ctrl and g_ext_ctrls: then you can do a 'return is_get;' here. That way 
drivers
do not need to take care of V4L2_CTRL_WHICH_DEF_VAL for set/try.

Regards,

Hans

> + case V4L2_CTRL_WHICH_CUR_VAL:
>   return 1;
> + case V4L2_CTRL_WHICH_REQUEST_VAL:
> + return 0;
> + }
> +
>   /* Check that all controls are from the same control class. */
>   for (i = 0; i < c->count; i++) {
>   if (V4L2_CTRL_ID2WHICH(c->controls[i].id) != c->which) {
> 



Re: [syzbot] KMSAN: uninit-value in video_usercopy (2)

2021-03-16 Thread Hans Verkuil
pies nothing but returns 0.
>>>
>>> User space would be calling VIDIOC_QUERYBUF32_TIME32 here,
>>> if it's built against glibc, though with a musl based user space, you
>>> would get called with VIDIOC_QUERYBUF32.
>>
>> Or somebody fetching somebody else's credit card number will be
>> calling VIDIOC_QUERYBUF_TIME32 directly ;)
> 
> Ah of course, I forgot the ioctl command may already be fuzzed here.
> 
> When I look at
> https://syzkaller.appspot.com/text?tag=CrashLog=12bd0e3ad0
> 
> I see 0xc0585609, which would be a VIDIOC_QUERYBUF with
> size=0x58, which is the native ioctl, not the compat one. This
> is something we didn't expect to get passed into the compat ioctl
> handler, but should of course handle gracefully
> 
> If the command were to get is the 64-bit version of
> VIDIOC_QUERYBUF_TIME32 (0xc0505609), then it gets converted to
> VIDIOC_QUERYBUF by video_translate_cmd().
> If it's VIDIOC_QUERYBUF, it stays that way.
> 
> It does break down in v4l2_compat_get_user() when we get
> called with VIDIOC_QUERYBUF_TIME32, since that leads
> to not copying at all, as you guessed.
> 
> I think this should fix the case of passing
> VIDIOC_QUERYBUF_TIME32:

I tested this and I can confirm that this works.

Arnd, do you want to make a patch for this? If so, you can add my

Tested-by: Hans Verkuil 

Regards,

Hans

> 
> --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> @@ -3115,7 +3115,7 @@ static int check_array_args(unsigned int cmd,
> void *parg, size_t *array_size,
>  static unsigned int video_translate_cmd(unsigned int cmd)
>  {
> switch (cmd) {
> -#ifdef CONFIG_COMPAT_32BIT_TIME
> +#if !defined(CONFIG_64BIT) && defined(CONFIG_COMPAT_32BIT_TIME)
> case VIDIOC_DQEVENT_TIME32:
> return VIDIOC_DQEVENT;
> case VIDIOC_QUERYBUF_TIME32:
> 
>Arnd
> 



Re: [PATCH v8 1/2] media: v4l2-ctrl: add controls for long term reference.

2021-03-16 Thread Hans Verkuil
D_CODEC_BASE+231)
> +#define V4L2_CID_MPEG_VIDEO_FRAME_LTR_INDEX  
> (V4L2_CID_CODEC_BASE+232)
> +#define V4L2_CID_MPEG_VIDEO_USE_LTR_FRAMES   
> (V4L2_CID_CODEC_BASE+233)
>  
>  /* CIDs for the MPEG-2 Part 2 (H.262) codec */
>  #define V4L2_CID_MPEG_VIDEO_MPEG2_LEVEL  
> (V4L2_CID_CODEC_BASE+270)
> 

It was a long journey, but here is finally my coveted:

Reviewed-by: Hans Verkuil 

Congratulations! :-)

I assume that Stan will pick this up this series.

Regards,

Hans


Re: [PATCH v5 4/5] docs: Document CLL and Mastering display colorimetry controls

2021-03-16 Thread Hans Verkuil
 this 
> control is
>  of type ``V4L2_CTRL_TYPE_FWHT_PARAMS``.
> +* - struct :c:type:`v4l2_ctrl_hdr10_cll_info` *
> +  - ``p_hdr10_cll``
> +  - A pointer to a struct :c:type:`v4l2_ctrl_hdr10_cll_info`. Valid if 
> this control is
> +of type ``V4L2_CTRL_TYPE_HDR10_CLL_INFO``.
> +* - struct :c:type:`v4l2_ctrl_hdr10_mastering_display` *
> +  - ``p_hdr10_mastering``
> +  - A pointer to a struct :c:type:`v4l2_ctrl_hdr10_mastering_display`. 
> Valid if this control is
> +of type ``V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY``.
>  * - void *
>- ``ptr``
>- A pointer to a compound type which can be an N-dimensional array
> diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions 
> b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> index 0ed170c6e720..38b31a9b9580 100644
> --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions
> @@ -147,6 +147,8 @@ replace symbol V4L2_CTRL_TYPE_HEVC_PPS 
> :c:type:`v4l2_ctrl_type`
>  replace symbol V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS :c:type:`v4l2_ctrl_type`
>  replace symbol V4L2_CTRL_TYPE_AREA :c:type:`v4l2_ctrl_type`
>  replace symbol V4L2_CTRL_TYPE_FWHT_PARAMS :c:type:`v4l2_ctrl_type`
> +replace symbol V4L2_CTRL_TYPE_HDR10_CLL_INFO :c:type:`v4l2_ctrl_type`
> +replace symbol V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY 
> :c:type:`v4l2_ctrl_type`
>  
>  # V4L2 capability defines
>  replace define V4L2_CAP_VIDEO_CAPTURE device-capabilities
> 

After making the change suggested above, you can add my:

Reviewed-by: Hans Verkuil 

Regards,

Hans


  1   2   3   4   5   6   7   8   9   10   >