Re: [PATCH] media: uvcvideo: Add quirk to retry SET_INTERFACE for SVBONY SV105C

[Laurent Pinchart]

On Mon, Oct 19, 2026 at 02:33:11PM +0200, Hans de Goede wrote:
> On 19-Oct-26 1:58 PM, Константин Осташов wrote:
> > On Mon, Oct 19, 2026 at 02:27:26PM +0300, Laurent Pinchart wrote:
> >> On Mon, Oct 19, 2026 at 01:21:49PM +0200, Hans de Goede wrote:
> >>> On 19-Oct-26 1:17 PM, Laurent Pinchart wrote:
> >>>> What does Windows do differently then ?
> >>>
> >>> I guess Windows always has a short-delay of at least one USB frame-time
> >>> between the VS_COMMIT and SET_INTERFACE. I think we should simply add
> >>> a flseep(1000) before the set_interface instead of adding a quirk for
> >>> this.
> >>
> >> The commit message says it doesn't help, but I can't tell if that can be
> >> trusted.
> > 
> > Fair point. I have measured both sides again.
> > 
> > Windows 11, AMD xHCI, camera on a root port, 120 stream starts with
> > ffmpeg/DirectShow (MJPEG 1920x1080, and YUYV 1920x1080 for 5 of them),
> > captured with USBPcap and an ETW trace of USBXHCI/UCX/USBHUB3:
> > 
> > - The requests are the same as on Linux: PROBE GET_CUR, SET_CUR,
> >   GET_CUR, GET_MAX, GET_MIN, SET_CUR, GET_CUR, then a 26 byte COMMIT,
> >   then SET_INTERFACE alt 6. There is nothing else in between.
> > - The SET_INTERFACE URB is submitted 22 us after the COMMIT completes.
> >   The xHCI driver first runs a Configure Endpoint command (3 ms), then
> >   queues the control transfer. That puts about 3 ms between the two
> >   requests.
> 
> When you say "then queurs the control transfer", you mean the control
> transfer for the SET_INTERFACE, right ?
> 
> I wonder if the problem is that Linux is missing this Configure Endpoint
> command ?
> 
> > - The control transfer completes successfully after 263 ms, every time
> >   (402 ms for YUYV 1920x1080). In a 100 start run, the ETW trace shows
> >   exactly 10 control transfers on the camera's EP0 per start (8 for
> >   probe/commit and 2 for SET_INTERFACE alt 6/alt 0). There was no
> >   Reset Endpoint command, and every xHCI command completed with Success.
> >   Windows does not see an error and does not retry. 0 failures out of
> >   120.
> > 
> > Linux 6.18, Raspberry Pi 4 (VL805 xHCI, camera behind the VL805's
> > internal USB 2.0 hub). I added an fsleep() right before
> > usb_set_interface() in uvc_video_start_transfer() and checked the
> > resulting gap in usbmon. 20 starts per value, MJPEG 1920x1080, auto
> > exposure:
> > >   fsleep()   COMMIT -> SET_INTERFACE (usbmon)   first SET_INTERFACE -EPROTO
> >   none          0.35 -   0.90 ms                 1/20
> >   1 ms          1.53 -   1.84 ms                 2/20
> >   5 ms          5.42 -   7.26 ms                 6/20
> >   20 ms        20.4  -  26.4  ms                 3/20
> >   100 ms      100.7  - 108.1  ms                 5/20
> >   300 ms      319.5  - 325.2  ms                 1/20
> > 
> > So a delay does not help, even one longer than the time the device
> > takes to complete the request.
> > 
> > The timing differs between failure and success. A failing
> > SET_INTERFACE completes with -EPROTO about 1 ms after it is submitted.
> > A successful one, whether the first attempt or the retry, takes about
> > 260 ms, the same as on Windows. My guess is that the device starts
> > reconfiguring right after the SETUP stage and sometimes fails to
> > answer the status stage for a few microframes before it starts
> > NAKing. The VL805 then reports a transaction error. I have no bus
> > analyzer to confirm this.
> > 
> > I also need to correct the commit message: the failure rate is not a
> > stable 80%. Today it was between 0% and 50% per series of 10 to 20
> > starts, with auto exposure failing more often than manual exposure.
> > The retry always succeeded on the first attempt.
> > 
> > With 0 out of 120 on Windows against roughly 15% per start on the Pi,
> > the difference is real. I can't tell yet whether it comes from the OS
> > or from the host controller. I haven't tested the camera with Linux
> > on a non-VL805 controller. I can do that before a v2 if it would help.
> 
> Have you tried reproducing this on a different XHCI controller then
> the one found in the Raspberry Pi 4 ?

In particular the same one as the system running windows.

> I wonder if this problem
> is specific to the VL805 xHCI controller.
> 
> Likewise have you tried reproducing this under Windows with an USB2.0
> hub in between ?

-- 
Regards,

Laurent Pinchart