Messages in this thread | | | Date | Sat, 7 Jan 2023 02:11:30 +0200 | From | Laurent Pinchart <> | Subject | Re: [PATCH v4] media: uvcvideo: Fix bandwidth error for Alcor camera |
| |
Hi again,
On Tue, Nov 22, 2022 at 04:48:33PM +0800, Ai Chao wrote: > For Alcor Corp. Slave camera(1b17:6684/2017:0011), it support to output > compressed video data, and it return a wrong dwMaxPayloadTransferSize > fields. This is a fireware issue, but the manufacturer cannot provide > a const return fieldsby the fireware. For some device, it requested > 2752512 B/frame bandwidth. For normally device, it requested 3072 or 1024 > B/frame bandwidth. so we check the dwMaxPayloadTransferSize fields,if it > large than 0x1000, reset dwMaxPayloadTransferSize to 1024, and the camera > preview normally. > > Signed-off-by: Ai Chao <aichao@kylinos.cn> > > --- > change for v4 > - Change usb_match_one_id to usb_match_id > - Modify the discription > > change for v3 > - Add VID/PID 2017:0011 > > change for v2 > - Used usb_match_one_id to check VID and PID > --- > --- > drivers/media/usb/uvc/uvc_video.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/drivers/media/usb/uvc/uvc_video.c b/drivers/media/usb/uvc/uvc_video.c > index d2eb9066e4dc..75bdd71d0e5a 100644 > --- a/drivers/media/usb/uvc/uvc_video.c > +++ b/drivers/media/usb/uvc/uvc_video.c > @@ -135,6 +135,11 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream, > static const struct usb_device_id elgato_cam_link_4k = { > USB_DEVICE(0x0fd9, 0x0066) > }; > + static const struct usb_device_id alcor_corp_slave_cam[] = { > + { USB_DEVICE(0x2017, 0x0011) }, > + { USB_DEVICE(0x1b17, 0x6684) }, > + { } > + }; > struct uvc_format *format = NULL; > struct uvc_frame *frame = NULL; > unsigned int i; > @@ -234,6 +239,13 @@ static void uvc_fixup_video_ctrl(struct uvc_streaming *stream, > > ctrl->dwMaxPayloadTransferSize = bandwidth; > } > + > + /* Alcor Corp. Slave camera return wrong dwMaxPayloadTransferSize */
Let's add a bit more documentation:
/* * Another issue is with devices that report a transfer size that * greatly exceeds the maximum supported by any existing USB version. * For instance, the "Slave camera" devices from Alcor Corp. (2017:0011 * and 1b17:66B8) request 2752512 bytes per interval. */
I would also take this as an opportunity to document the previous fixup, just above the UVC_QUIRK_FIX_BANDWIDTH check, with
/* * 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) && > + (ctrl->dwMaxPayloadTransferSize > 0x1000) &&
Given that the highest bandwidth supported by high-speed, high bandwidth devices is 3072 bytes per interval, I would check
(ctrl->dwMaxPayloadTransferSize > 3072) &&
here.
> + usb_match_id(stream->dev->intf, alcor_corp_slave_cam)) {
I'm also wondering if we could enable this fixup for all devices using isochronous endpoints (as for bulk endpoints the transfer size can be higher), without checking the VID:PID. No isochronous high-speed, high-bandwidth device should have a swMaxPayloadTransferSize value higher than 3072. For super-speed devices I'm not entirely sure if the maximum transfer size covers multiple transfers in a burst. Ricardo, do you know anything about that ?
I can send a v5 that does all this.
> + ctrl->dwMaxPayloadTransferSize = 1024; > + } > } > > static size_t uvc_video_ctrl_size(struct uvc_streaming *stream)
-- Regards,
Laurent Pinchart
| |