From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: linux-media@vger.kernel.org, Ai Chao <aichao@kylinos.cn>,
Jackie Liu <liuyun01@kylinos.cn>
Subject: Re: [PATCH v5] media: uvcvideo: Fix bandwidth error for Alcor camera
Date: Tue, 17 Jan 2023 16:18:29 +0200 [thread overview]
Message-ID: <Y8auNeu1qFygIxUt@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CANiDSCvhXdyFuA2y2Sob4yx2=RK+uuCBJ2r_jBc+L4aZABLwPw@mail.gmail.com>
Hi Ricardo,
On Tue, Jan 17, 2023 at 03:08:07PM +0100, Ricardo Ribalda wrote:
> On Sun, 15 Jan 2023 at 22:17, Laurent Pinchart wrote:
> >
> > From: Ai Chao <aichao@kylinos.cn>
> >
> > The Alcor Corp. Slave camera (1b17:6684 and 2017:0011) returns a wrong
> > dwMaxPayloadTransferSize value for compressed formats. Valid values are
> > typically up to 3072 bytes per interval (for high-speed, high-bandwidth
> > devices), and those faulty devices request 2752512 bytes per interval.
> > This is a firmware issue, but the manufacturer cannot provide a fixed
> > firmware.
> >
> > Fix this by checking the dwMaxPayloadTransferSize field, and hardcoding
> > a value of 1024 if it exceeds 3072 for compressed formats transferred
> > over isochronous endpoints. While at it, document the other quirk that
> > handles a bandwidth issue for uncompressed formats.
> >
> > Signed-off-by: Ai Chao <aichao@kylinos.cn>
> > ---
> > I have dropped the Reviewed-by tags as the patch has changed
> > significantly.
> >
> > Ricardo, do you know if the 3072 bytes limit is fine with super-speed
> > devices, or does it need to be increased ?
> Tried with a couple of super-speed:
>
> If I print: ctrl->dwMaxPayloadTransferSize
>
> [ 237.269972] drivers/media/usb/uvc/uvc_video.c:239 bw 3072
> [ 175.761041] drivers/media/usb/uvc/uvc_video.c:239 bw 3060
>
> Format YUYV stall when I cap the dwMaxPayloadTransferSize to 1024, but
> works fine with MJPEG and even NV12
>
> How does it sound to cap dwMaxPayloadTransferSize to 3072 for
> superspeed and 1024 for high speed?
Won't you still run out of bandwidth when using multiple cameras
concurrently ? Is it the interval that is shorter with SS, or the
maximum bytes per interval that is larger ?
> > ---
> > drivers/media/usb/uvc/uvc_video.c | 31 +++++++++++++++++++++++++++++++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c
> > index d4b023d4de7c..c6351d3b24cf 100644
> > --- a/drivers/media/usb/uvc/uvc_video.c
> > +++ b/drivers/media/usb/uvc/uvc_video.c
> > @@ -200,6 +200,20 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
> > if ((ctrl->dwMaxPayloadTransferSize & 0xffff0000) == 0xffff0000)
> > ctrl->dwMaxPayloadTransferSize &= ~0xffff0000;
> >
> > + /*
> > + * Many devices report an incorrect dwMaxPayloadTransferSize value. The
> > + * most common issue is devices requesting the maximum possible USB
> > + * bandwidth (3072 bytes per interval for high-speed, high-bandwidth
> > + * isochronous endpoints) while they actually require less, preventing
> > + * multiple cameras from being used at the same time due to bandwidth
> > + * overallocation.
> > + *
> > + * For those devices, replace the dwMaxPayloadTransferSize value based
> > + * on an estimation calculated from the frame format and size. This is
> > + * only possible for uncompressed formats, as not enough information is
> > + * available to reliably estimate the bandwidth requirements for
> > + * compressed formats.
> > + */
> > if (!(format->flags & UVC_FMT_FLAG_COMPRESSED) &&
> > stream->dev->quirks & UVC_QUIRK_FIX_BANDWIDTH &&
> > stream->intf->num_altsetting > 1) {
> > @@ -236,6 +250,23 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream,
> >
> > ctrl->dwMaxPayloadTransferSize = bandwidth;
> > }
> > +
> > + /*
> > + * Another issue is with devices that report a transfer size that
> > + * greatly exceeds the maximum supported by any existing USB version
> > + * for isochronous transfers. For instance, the "Slave camera" devices
> > + * from Alcor Corp. (2017:0011 and 1b17:66B8) request 2752512 bytes per
> > + * interval.
> > + *
> > + * For uncompressed formats, this can be addressed by the FIX_BANDWIDTH
> > + * quirk, but for compressed format we can't meaningfully estimate the
> > + * required bandwidth. Just hardcode it to 1024 bytes per interval,
> > + * which should be large enough for compressed formats.
> > + */
> > + if ((format->flags & UVC_FMT_FLAG_COMPRESSED) &&
> > + ctrl->dwMaxPayloadTransferSize > 3072 &&
> > + stream->intf->num_altsetting > 1)
> > + ctrl->dwMaxPayloadTransferSize = 1024;
> > }
> >
> > static size_t uvc_video_ctrl_size(struct uvc_streaming *stream)
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2023-01-17 14:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-15 21:17 [PATCH v5] media: uvcvideo: Fix bandwidth error for Alcor camera Laurent Pinchart
2023-01-16 14:14 ` Ricardo Ribalda
2023-01-16 14:40 ` Laurent Pinchart
2023-01-17 14:08 ` Ricardo Ribalda
2023-01-17 14:18 ` Laurent Pinchart [this message]
2023-01-17 14:38 ` Ricardo Ribalda
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=Y8auNeu1qFygIxUt@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=aichao@kylinos.cn \
--cc=linux-media@vger.kernel.org \
--cc=liuyun01@kylinos.cn \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.