[PATCH v14 35/56] media: cedrus: Stop direct calls to queue num_buffers field

Benjamin Gaignard benjamin.gaignard at collabora.com
Thu Nov 9 07:54:19 PST 2023


Le 09/11/2023 à 16:48, Andrzej Pietrasiewicz a écrit :
> Hi Paul,
>
> W dniu 9.11.2023 o 15:14, Paul Kocialkowski pisze:
>> Hi Andrzej,
>>
>> On Thu 09 Nov 23, 12:27, Andrzej Pietrasiewicz wrote:
>>> Hi Paul,
>>>
>>> W dniu 31.10.2023 o 17:30, Benjamin Gaignard pisze:
>>>> Use vb2_get_num_buffers() to avoid using queue num_buffers field 
>>>> directly.
>>>> This allows us to change how the number of buffers is computed in the
>>>> future.
>>>>
>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard at collabora.com>
>>>> Acked-by: Paul Kocialkowski <paul.kocialkowski at bootlin.com>
>>>
>>> Given you've alaredy A-b, would you be ok with adding this sentence:
>>>
>>> "While at it, check the return value of vb2_get_buffer()."
>>>
>>> to the commit message body?
>>
>> Not only do I agree, but because this is done in a function returning 
>> void,
>> you could even:
>>
>> if (WARN_ON(!vb))
>>     continue;
>>
>> so that it doesn't go completely unnoticed.
>>
>> What do you think?
>>
>
> I'd ask Benjamin.
>
> But my take on the direction of changes is that ultimately
> there will be "holes" in the array of allocated buffers (hence the
> bitmap to track which slots are used and which are not). In other words,
> getting a NULL sometimes will be an expected situation, and a WARN() will
> not be appropriate for an expected situation.
>
> @Benjamin?

That should never happens unless you add delete buffers capability to the driver
and in this case it is normal to have holes.
Other drivers do not use WARN_ON() so I will not do it for this one.

Regards,
Benjamin

>
> Regards,
>
> Andrzej
>
>> Cheers,
>>
>> Paul
>>
>>> @Benjamin:
>>>
>>> With this change, you can add my
>>>
>>> Reviewed-by: Andrzej Pietrasiewicz <andrzej.p at collabora.com>
>>>
>>>> CC: Maxime Ripard <mripard at kernel.org>
>>>> ---
>>>>    drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 9 +++++++--
>>>>    drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 9 +++++++--
>>>>    2 files changed, 14 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c 
>>>> b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
>>>> index dfb401df138a..3e2843ef6cce 100644
>>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
>>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c
>>>> @@ -653,8 +653,13 @@ static void cedrus_h264_stop(struct cedrus_ctx 
>>>> *ctx)
>>>>        vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, 
>>>> V4L2_BUF_TYPE_VIDEO_CAPTURE);
>>>> -    for (i = 0; i < vq->num_buffers; i++) {
>>>> -        buf = vb2_to_cedrus_buffer(vb2_get_buffer(vq, i));
>>>> +    for (i = 0; i < vb2_get_num_buffers(vq); i++) {
>>>> +        struct vb2_buffer *vb = vb2_get_buffer(vq, i);
>>>> +
>>>> +        if (!vb)
>>>> +            continue;
>>>> +
>>>> +        buf = vb2_to_cedrus_buffer(vb);
>>>>            if (buf->codec.h264.mv_col_buf_size > 0) {
>>>>                dma_free_attrs(dev->dev,
>>>> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c 
>>>> b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
>>>> index fc9297232456..52e94c8f2f01 100644
>>>> --- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
>>>> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c
>>>> @@ -869,8 +869,13 @@ static void cedrus_h265_stop(struct cedrus_ctx 
>>>> *ctx)
>>>>        vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, 
>>>> V4L2_BUF_TYPE_VIDEO_CAPTURE);
>>>> -    for (i = 0; i < vq->num_buffers; i++) {
>>>> -        buf = vb2_to_cedrus_buffer(vb2_get_buffer(vq, i));
>>>> +    for (i = 0; i < vb2_get_num_buffers(vq); i++) {
>>>> +        struct vb2_buffer *vb = vb2_get_buffer(vq, i);
>>>> +
>>>> +        if (!vb)
>>>> +            continue;
>>>> +
>>>> +        buf = vb2_to_cedrus_buffer(vb);
>>>>            if (buf->codec.h265.mv_col_buf_size > 0) {
>>>>                dma_free_attrs(dev->dev,
>>>
>>
>>
>> _______________________________________________
>> Kernel mailing list -- kernel at mailman.collabora.com
>> To unsubscribe send an email to kernel-leave at mailman.collabora.com
>



More information about the linux-arm-kernel mailing list