kernel/linux.git/drivers/usb/gadget/function/uvc_queue.c, branch v6.19.11

usb: gadget: uvc: retry vb2_reqbufs() with vb_vmalloc_memops if use_sg fail

2026-01-14T15:03:18+00:00

Based on the reality[1][2] that vb2_dma_sg_alloc() can't alloc buffer with device DMA limits, those device will always get below error: "swiotlb buffer is full (sz: 393216 bytes), total 65536 (slots), used 2358 (slots)" and the uvc gadget function can't work at all. The videobuf2-dma-sg.c driver doesn't has a formal improve about this issue till now. For UVC gadget, the videobuf2 subsystem doesn't do dma_map() on vmalloc returned big buffer when allocate the video buffers, however, it do it for dma_sg returned buffer. So the issue happens for vb2_dma_sg_alloc(). To workaround the issue, lets retry vb2_reqbufs() with vb_vmalloc_memops if it fails to allocate buffer with vb2_dma_sg_memops. If use vmalloced buffer, UVC gadget will allocate some small buffers for each usb_request to do dma transfer, then uvc driver will memcopy data from big buffer to small buffer. Link[1]: https://lore.kernel.org/linux-media/20230828075420.2009568-1-anle.pan@nxp.com/ Link[2]: https://lore.kernel.org/linux-media/20230914145812.12851-1-hui.fang@nxp.com/ Signed-off-by: Xu Yang Reviewed-by: Frank Li Link: https://patch.msgid.link/20260113-uvc-gadget-fix-patch-v2-4-62950ef5bcb5@nxp.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: fix req_payload_size calculation

2026-01-14T15:03:17+00:00

Current req_payload_size calculation has 2 issue: (1) When the first time calculate req_payload_size for all the buffers, reqs_per_frame = 0 will be the divisor of DIV_ROUND_UP(). So the result is undefined. This happens because VIDIOC_STREAMON is always executed after VIDIOC_QBUF. So video->reqs_per_frame will be 0 until VIDIOC_STREAMON is run. (2) The buf->req_payload_size may be bigger than max_req_size. Take YUYV pixel format as example: If bInterval = 1, video->interval = 666666, high-speed: video->reqs_per_frame = 666666 / 1250 = 534 720p: buf->req_payload_size = 1843200 / 534 = 3452 1080p: buf->req_payload_size = 4147200 / 534 = 7766 Based on such req_payload_size, the controller can't run normally. To fix above issue, assign max_req_size to buf->req_payload_size when video->reqs_per_frame = 0. And limit buf->req_payload_size to video->req_size if it's large than video->req_size. Since max_req_size is used at many place, add it to struct uvc_video and set the value once endpoint is enabled. Fixes: 98ad03291560 ("usb: gadget: uvc: set req_length based on payload by nreqs instead of req_size") Cc: stable@vger.kernel.org Reviewed-by: Frank Li Signed-off-by: Xu Yang Link: https://patch.msgid.link/20260113-uvc-gadget-fix-patch-v2-1-62950ef5bcb5@nxp.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: drop vb2_ops_wait_prepare/finish

2025-02-03T15:28:42+00:00

Since commit 88785982a19d ("media: vb2: use lock if wait_prepare/finish are NULL") it is no longer needed to set the wait_prepare/finish vb2_ops callbacks as long as the lock field in vb2_queue is set. Since the vb2_ops_wait_prepare/finish callbacks already rely on that field, we can safely drop these callbacks. This simplifies the code and this is a step towards the goal of deleting these callbacks. Signed-off-by: Hans Verkuil Cc: Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org Link: https://lore.kernel.org/r/2fb746b8-31c4-44e0-bf7b-7a0758edf52a@xs4all.nl Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: set nbuffers to minimum STREAMING_MIN_BUFFERS in uvc_queue_setup

2024-10-17T06:42:23+00:00

We set the minimum amount of v4l2 buffers that is possibly be pending to UVCG_STREAMING_MIN_BUFFERS which is two. This way the driver will always have at least one frame pending to be encoded while the other is being enqueued in the hardware. Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20240403-uvc_request_length_by_interval-v7-7-e224bb1035f0@pengutronix.de Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: set req_length based on payload by nreqs instead of req_size

2024-10-17T06:42:22+00:00

Compressed formats generate content depending amount of data that is set in the vb2 buffer by the payload_size. When streaming those formats it is better to scatter that smaller data over all requests. This patch is doing that by introducing the calculated req_payload_size which is updated by each frame. It the uses this amount of data to fill the isoc requests instead of the video->req_size. For uncompressed formats it will not make a difference since the payload size will be equal to the imagesize. Therefore the code will have no effecta as req_payload_size will be equal to req_size. Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20240403-uvc_request_length_by_interval-v7-6-e224bb1035f0@pengutronix.de Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: set req_size and n_requests based on the frame interval

2024-10-17T06:42:22+00:00

This patch is removing the initial imprecise and limited calculation of requests needed to be used from the queue_setup callback. It instead introduces the uvc_video_prep_requests function which is called immediately before the request allocation. With the information of the usb frame interval length it is possible to calculate the number of requests needed during one frame duration. Based on the calculated number of requests and the imagesize we calculate the actual size per request. This calculation has the benefit that the frame data is equally distributed over all allocated requests. When the req_size is not in the range for the actually configured max_req_size configured for the overall bandwidth we fallback to use the max_req_size instead. Since this calculations are only important for isoc transfers we just use max_request_size for bulk and skip it. As video->req_size will be recalculated on every video_enable resetting it to 0 is not necessary anymore. Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20240403-uvc_request_length_by_interval-v7-5-e224bb1035f0@pengutronix.de Signed-off-by: Greg Kroah-Hartman

Revert "usb: gadget: uvc: limit isoc_sg to super speed gadgets"

2022-10-26T12:09:06+00:00

This reverts commit 19905240aef0181d1e6944070eb85fce75f75bcd. It was a new feature, and it doesn't even work properly yet, so revert it from this branch as it is not needed for 6.1-final. Cc: Michael Grzeschik Cc: stable Fixes: 19905240aef0 ("usb: gadget: uvc: limit isoc_sg to super speed gadgets") Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: limit isoc_sg to super speed gadgets

2022-10-25T17:06:13+00:00

The overhead of preparing sg data is high for transfers with limited payload. When transferring isoc over high-speed usb the maximum payload is rather small which is a good argument no to use sg. This patch is changing the uvc_video_encode_isoc_sg encode function only to be used for super speed gadgets. Signed-off-by: Michael Grzeschik Cc: stable Link: https://lore.kernel.org/r/20221017221141.3134818-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: fix sg handling in error case

2022-10-22T10:30:35+00:00

If there is a transmission error the buffer will be returned too early, causing a memory fault as subsequent requests for that buffer are still queued up to be sent. Refactor the error handling to wait for the final request to come in before reporting back the buffer to userspace for all transfer types (bulk/isoc/isoc_sg). This ensures userspace knows if the frame was successfully sent. Fixes: e81e7f9a0eb9 ("usb: gadget: uvc: add scatter gather support") Cc: Signed-off-by: Dan Vacura Link: https://lore.kernel.org/r/20221018215044.765044-4-w36195@motorola.com Signed-off-by: Greg Kroah-Hartman

usb: gadget: uvc: calculate the number of request depending on framesize

2022-06-10T09:50:54+00:00

The current limitation of possible number of requests being handled is dependent on the gadget speed. It makes more sense to depend on the typical frame size when calculating the number of requests. This patch is changing this and is using the previous limits as boundaries for reasonable minimum and maximum number of requests. For a 1080p jpeg encoded video stream with a maximum imagesize of e.g. 800kB with a maxburst of 8 and an multiplier of 1 the resulting number of requests is calculated to 49. 800768 1 nreqs = ------ * -------------- ~= 49 2 (1024 * 8 * 1) Tested-by: Dan Vacura Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20220529223848.105914-2-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman