linux-kernel - Re: [PATCH v13 5/8] media: chips-media: wave5: Add the v4l2 layer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1c6c0c10-8d00-4a52-ae2f-f481c87faf54@xs4all.nl>
Date:   Mon, 16 Oct 2023 15:39:44 +0200
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Sebastian Fricke <sebastian.fricke@...labora.com>
Cc:     Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        NXP Linux Team <linux-imx@....com>,
        Conor Dooley <conor+dt@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Jackson Lee <jackson.lee@...psnmedia.com>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Shawn Guo <shawnguo@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Nas Chung <nas.chung@...psnmedia.com>,
        Fabio Estevam <festevam@...il.com>,
        linux-media@...r.kernel.org, Tomasz Figa <tfiga@...omium.org>,
        linux-kernel@...r.kernel.org,
        Nicolas Dufresne <nicolas.dufresne@...labora.com>,
        kernel@...labora.com, Robert Beckett <bob.beckett@...labora.com>,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Darren Etheridge <detheridge@...com>
Subject: Re: [PATCH v13 5/8] media: chips-media: wave5: Add the v4l2 layer

On 16/10/2023 15:35, Sebastian Fricke wrote:
> Hey Hans,
> 
> On 16.10.2023 13:57, Hans Verkuil wrote:
>> Hi Sebastian,
>>
>> On 12/10/2023 13:01, Sebastian Fricke wrote:
>>> Add the decoder and encoder implementing the v4l2
>>> API. This patch also adds the Makefile and the VIDEO_WAVE_VPU config
>>>
>>> Signed-off-by: Sebastian Fricke <sebastian.fricke@...labora.com>
>>> Signed-off-by: Nicolas Dufresne <nicolas.dufresne@...labora.com>
>>> Signed-off-by: Deborah Brouwer <deborah.brouwer@...labora.com>
>>> Signed-off-by: Robert Beckett <bob.beckett@...labora.com>
>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@...labora.com>
>>> Signed-off-by: Nas Chung <nas.chung@...psnmedia.com>
>>> ---
>>>  drivers/media/platform/chips-media/Kconfig         |    1 +
>>>  drivers/media/platform/chips-media/Makefile        |    1 +
>>>  drivers/media/platform/chips-media/wave5/Kconfig   |   12 +
>>>  drivers/media/platform/chips-media/wave5/Makefile  |   10 +
>>>  .../platform/chips-media/wave5/wave5-helper.c      |  213 +++
>>>  .../platform/chips-media/wave5/wave5-helper.h      |   31 +
>>>  .../platform/chips-media/wave5/wave5-vpu-dec.c     | 1953 ++++++++++++++++++++
>>>  .../platform/chips-media/wave5/wave5-vpu-enc.c     | 1794 ++++++++++++++++++
>>>  .../media/platform/chips-media/wave5/wave5-vpu.c   |  291 +++
>>>  .../media/platform/chips-media/wave5/wave5-vpu.h   |   83 +
>>>  .../platform/chips-media/wave5/wave5-vpuapi.h      |    2 -
>>>  11 files changed, 4389 insertions(+), 2 deletions(-)
>>>
>>
>> <snip>
>>
>>> +static int wave5_vpu_dec_create_bufs(struct file *file, void *priv,
>>> +                     struct v4l2_create_buffers *create)
>>> +{
>>> +    struct vpu_instance *inst = wave5_to_vpu_inst(priv);
>>> +    struct v4l2_format *f = &create->format;
>>> +
>>> +    /* Firmware does not support CREATE_BUFS for CAPTURE queues. */
>>> +    if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
>>> +        dev_dbg(inst->dev->dev,
>>> +            "%s: VIDIOC_CREATE_BUFS not supported on CAPTURE queues.\n",
>>> +            __func__);
>>> +        return -EOPNOTSUPP;
>>> +    }
>>> +
>>> +    return v4l2_m2m_ioctl_create_bufs(file, priv, create);
>>> +}
>>
>> Regarding the EOPNOTSUPP discussion: I discussed this some more with
>> Nicolas on irc, and we wonder if it isn't better to just drop create_bufs
>> support for the wave5 decoder altogether. Is there any point in supporting
>> it for OUTPUT but not CAPTURE?
>>
>> <snip>
>>
>>> +static const struct v4l2_ioctl_ops wave5_vpu_dec_ioctl_ops = {
>>> +    .vidioc_querycap = wave5_vpu_dec_querycap,
>>> +    .vidioc_enum_framesizes = wave5_vpu_dec_enum_framesizes,
>>> +
>>> +    .vidioc_enum_fmt_vid_cap    = wave5_vpu_dec_enum_fmt_cap,
>>> +    .vidioc_s_fmt_vid_cap_mplane = wave5_vpu_dec_s_fmt_cap,
>>> +    .vidioc_g_fmt_vid_cap_mplane = wave5_vpu_dec_g_fmt_cap,
>>> +    .vidioc_try_fmt_vid_cap_mplane = wave5_vpu_dec_try_fmt_cap,
>>> +
>>> +    .vidioc_enum_fmt_vid_out    = wave5_vpu_dec_enum_fmt_out,
>>> +    .vidioc_s_fmt_vid_out_mplane = wave5_vpu_dec_s_fmt_out,
>>> +    .vidioc_g_fmt_vid_out_mplane = wave5_vpu_g_fmt_out,
>>> +    .vidioc_try_fmt_vid_out_mplane = wave5_vpu_dec_try_fmt_out,
>>> +
>>> +    .vidioc_g_selection = wave5_vpu_dec_g_selection,
>>> +    .vidioc_s_selection = wave5_vpu_dec_s_selection,
>>> +
>>> +    .vidioc_reqbufs = v4l2_m2m_ioctl_reqbufs,
>>> +    .vidioc_querybuf = v4l2_m2m_ioctl_querybuf,
>>> +    .vidioc_create_bufs = wave5_vpu_dec_create_bufs,
>>
>> So this would just be dropped.
>>
>>> +    .vidioc_prepare_buf = v4l2_m2m_ioctl_prepare_buf,
>>> +    .vidioc_qbuf = v4l2_m2m_ioctl_qbuf,
>>> +    .vidioc_expbuf = v4l2_m2m_ioctl_expbuf,
>>> +    .vidioc_dqbuf = v4l2_m2m_ioctl_dqbuf,
>>> +    .vidioc_streamon = v4l2_m2m_ioctl_streamon,
>>> +    .vidioc_streamoff = v4l2_m2m_ioctl_streamoff,
>>> +
>>> +    .vidioc_try_decoder_cmd = v4l2_m2m_ioctl_try_decoder_cmd,
>>> +    .vidioc_decoder_cmd = wave5_vpu_dec_decoder_cmd,
>>> +
>>> +    .vidioc_subscribe_event = wave5_vpu_subscribe_event,
>>> +    .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
>>> +};
>>
>> This also means there is no need to document the new EOPNOTSUPP error
>> code in VIDIOC_CREATE_BUFS, or to modify v4l2-compliance.
>>
>> You *do* need to add a comment somewhere explaining why you don't
>> support this ioctl. I think it would be best to do that right after
>> '.vidioc_reqbufs = v4l2_m2m_ioctl_reqbufs,'.
> 
> So, besides this issue would you judge the v4l2 layer of the driver to
> be ready? Do you want a reviewed by tag for it or would you take it like
> this as well?

No, it looks good. Please note though that patch 6/8 (dt-bindings) still
needs an Acked/Reviewed-by from the device tree maintainers.

There was a comment on it from Krzysztof.

Regards,

	Hans

> 
>>
>> Regards,
>>
>>     Hans
> 
> Sincerly,
> Sebastian
>> _______________________________________________
>> Kernel mailing list -- kernel@...lman.collabora.com
>> To unsubscribe send an email to kernel-leave@...lman.collabora.com