From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Hans de Goede <hansg@kernel.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] media: uvcvideo: Avoid partial metadata buffers
Date: Fri, 17 Apr 2026 00:35:32 +0300 [thread overview]
Message-ID: <20260416213532.GF1824072@killaraus.ideasonboard.com> (raw)
In-Reply-To: <20260415-uvc-meta-partial-v1-2-a0acc79a6300@chromium.org>
Hi Ricardo,
Thank you for the patch.
On Wed, Apr 15, 2026 at 03:59:58PM +0000, Ricardo Ribalda wrote:
> If the metadata queue that is empty receives a new buffer while we are
> in the middle of processing a frame, the first metadata buffer will
> contain partial information.
>
> Avoid this by tracking the state of the metadata buffer and making sure
> that it is in sync with the data buffer.
>
> Now that we are at it, simplify the code a bit by not getting a metadata
> buffer if there is no data buffer ready.
>
> Fixes: 088ead255245 ("media: uvcvideo: Add a metadata device node")
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/media/usb/uvc/uvc_video.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> index 4feb3699f520..f339d6d19a39 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -1517,6 +1517,8 @@ static void uvc_video_next_buffers(struct uvc_streaming *stream,
> *meta_buf);
> }
> *video_buf = uvc_queue_next_buffer(&stream->queue, *video_buf);
> + if (*video_buf && *meta_buf)
> + (*meta_buf)->state = UVC_BUF_STATE_ACTIVE;
> }
>
> static void uvc_video_decode_isoc(struct uvc_urb *uvc_urb,
> @@ -1718,9 +1720,23 @@ static void uvc_video_complete(struct urb *urb)
>
> buf = uvc_queue_get_current_buffer(queue);
>
> - if (vb2_qmeta)
> + if (buf && vb2_qmeta)
> buf_meta = uvc_queue_get_current_buffer(qmeta);
>
> + /*
> + * Avoid partial metadata buffers, by making sure that the data buffer
> + * and metadata buffer state is in sync.
> + *
> + * A new (QUEUED) buffer is only allowed to become ACTIVE if we are also
> + * at the start of a new data buffer.
> + */
> + if (buf_meta && buf_meta->state == UVC_BUF_STATE_QUEUED) {
> + if (buf->state != UVC_BUF_STATE_QUEUED)
> + buf_meta = NULL;
> + else
> + buf_meta->state = UVC_BUF_STATE_ACTIVE;
> + }
> +
This creates a different logic for video buffers and metadata buffers.
Wouldn't it be better to use the same logic, and transition the metadata
buffer to the ACTIVE state when we detect the beginning of a new frame ?
> /* Re-initialise the URB async work. */
> uvc_urb->async_operations = 0;
>
--
Regards,
Laurent Pinchart
prev parent reply other threads:[~2026-04-16 21:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-15 15:59 [PATCH 0/2] media: uvcvideo: Avoid partial metadata buffers Ricardo Ribalda
2026-04-15 15:59 ` [PATCH 1/2] media: uvcvideo: Do not open code uvc_queue_get_current_buffer Ricardo Ribalda
2026-04-16 21:22 ` Laurent Pinchart
2026-04-15 15:59 ` [PATCH 2/2] media: uvcvideo: Avoid partial metadata buffers Ricardo Ribalda
2026-04-16 21:35 ` Laurent Pinchart [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260416213532.GF1824072@killaraus.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=guennadi.liakhovetski@intel.com \
--cc=hansg@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=ribalda@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox