On Wed, Oct 2, 2019 at 10:58 AM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, 2 Oct 2019, Tim Harvey wrote: > > > On Tue, Oct 1, 2019 at 12:19 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > On Tue, 1 Oct 2019, Tim Harvey wrote: > > > > > > > On Thu, Sep 26, 2019 at 3:47 PM Tim Harvey <tharvey@xxxxxxxxxxxxx> wrote: > > > > > > > > > > Greetings, > > > > > > > > > > I'm running into an issue with a USB UVC Full speed camera, the > > > > > PureThermal2 [1] on an IMX6 based ARM board. > > > > > > > > > > What I find is that I get two video devices registered (the first one > > > > > is the expected device, and I'm not clear what the 2nd one is). When I > > > > > try to capture a single frame I get 'Failed to submit URB 0 (-28)' > > > > > which historically has been due to a bandwidth issue. I encounter this > > > > > on the IMX6 EHCI host as well as the OTG host when no other devices > > > > > are connected (no hubs either). I've tested with both a 4.20 kernel > > > > > and a 5.3 kernel. > > > > > > > > > > If I plug this device into another board I have based on an OcteonTX > > > > > ARM64 cpu with a fairly modern 4.14 kernel and I find that a single > > > > > video device gets registered and I can capture just fine. > > > > > > > > > > Here are some details: > > > > > lsusb reports: 1e4e:0100 Cubeternet WebCam > > > > > > > > > > working system with 4.14 kernel hot-inserting the camera: > > > > > [ 495.163276] usb 1-1.2: new full-speed USB device number 6 using xhci_hcd > > > > > [ 495.291685] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) > > > > > (1e4e:0100) > > > > > [ 495.300543] input: PureThermal (fw:v1.2.2): PureTh as > > > > > /devices/platform/soc@0/848000000000.pci/pci0000:00/0000:00:10.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input1 > > > > > [ 496.731214] usb 1-1.2: USB disconnect, device number 6 > > > > > [ 496.987294] usb 1-1.2: new full-speed USB device number 7 using xhci_hcd > > > > > [ 497.115683] uvcvideo: Found UVC 1.00 device PureThermal (fw:v1.2.2) > > > > > (1e4e:0100) > > > > > [ 497.124182] input: PureThermal (fw:v1.2.2): PureTh as > > > > > /devices/platform/soc@0/848000000000.pci/pci0000:00/0000:00:10.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input2 > > > > > > ... > > > > > > > > I'm also not clear why the device enumerates then disconnects and > > > > > enumerates again when plugged in but this happens on the system it > > > > > works on as well and I've seen similar things with other devices. > > > > > > Perhaps some process opens the camera's device file, does something to > > > cause the camera to disconnect and reconnect, but then doesn't close > > > the file. > > > > Alan, > > > > I found that the '2 devices' is because of a kernel commit in 4.16 > > that adds support for UVC metadata: 088ead2 media: uvcvideo: Add a > > metadata device node. I can comment out the call to > > uvc_meta_register() and the 2nd device goes away but the first (and > > only) v4l2 capture device still has the same issue. > > Okay, that explains that. > > > > > I have found that if I enumerate the camera through a PCIe based XHCI > > > > host controller it still registers the 2 v4l2 devices but in this case > > > > I can capture fine. So it would appear that this has something to do > > > > with the IMX6 ci_hdrc controller. The -ENOSPC is getting returned from > > > > drivers/usb/host/ehci-sched.c:iso_stream_schedule() > > > > > > > > I feel perhaps this is something basic I don't understand regarding > > > > USB URB scheduling but I don't get why it occurs on the IMX6 ci_hdrc > > > > controller on not an XHCI controller. > > > > > > It's probably related to differences between the drivers. What shows > > > up in /sys/kernel/debug/usb/devices with the camera plugged in? > > > > > > > Here's some more debugging including /sys/kernel/debug/usb/devices: > > ~# cat /sys/kernel/debug/usb/devices > > > > T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 1 > > B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 > > D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 > > P: Vendor=1d6b ProdID=0002 Rev= 5.03 > > S: Manufacturer=Linux 5.3.0-00157-g651f7f9-dirty ehci_hcd > > S: Product=EHCI Host Controller > > S: SerialNumber=ci_hdrc.0 > > C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA > > I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub > > E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms > > > > T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 > > D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 > > P: Vendor=1e4e ProdID=0100 Rev= 2.00 > > S: Manufacturer=GroupGets > > S: Product=PureThermal (fw:v1.2.2) > > S: SerialNumber=801f001c-5102-3038-3835-393400000000 > > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=100mA > > A: FirstIf#= 0 IfCount= 2 Cls=0e(video) Sub=03 Prot=00 > > I:* If#= 0 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo > > E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms > > I:* If#= 1 Alt= 0 #EPs= 0 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo > > I: If#= 1 Alt= 1 #EPs= 1 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo > > E: Ad=81(I) Atr=01(Isoc) MxPS= 962 Ivl=1ms > > So the camera is the only device on the bus (aside from the root hub). > And it asks for an 8-byte interrupt endpoint together with a 962-byte > isochronous endpoint. > > That explains the problem. ehci-hcd (the same code manages ChipIdea > controllers) doesn't do a good job of handling high-bandwidth periodic > requests for full-speed devices, particularly when isochronous and > interrupt endpoints are both present. > > > So regardless of resolution/frame-size the device is requesting 962 > > byte USB frame bandwidth which should be just fine for USB full speed > > in iso mode (max 1023). I'm not sure why the bandwidth reservation > > fails. > > Yes, that amount of data is fine for full-speed USB. But handling > full-speed devices attached to a high-speed controller isn't easy, and > ehci-hcd isn't able to make use of all the possible bandwidth. In > fact, you'd be better off attaching the camera to a full-speed USB 1.1 > controller, if one were available for your system. > > xHCI controllers, on the other hand, handle all the scheduling issues > in hardware so the driver doesn't have to deal with them. Evidently > the ones you tried don't have any trouble in this situation. > > > Apparently the RaspberryPi 4 has this same issue: > > https://github.com/raspberrypi/linux/issues/3136. The same thread > > mentions that most USB full speed devices have fall-back endpoint > > max-packet sizes that allow for reduced bandwidth reservations (but > > this camera does not). > > > > I get the same results regardless of CONFIG_USB_EHCI_TT_NEWSCHED enabled or not. > > And indeed, the same problem will occur whenever this device is > attached to an EHCI controller on a Linux-based system, unless somebody > goes to the trouble of improving the driver. (It's tremendously > complicated -- the spec puts almost all the burden on the software > rather than the hardware/firmware -- and probably not worth the effort > of trying to do it correctly. I wouldn't be surprised if adding proper > support for this would double the size of the driver.) > Alan, Thanks for explaining this - its incredibly helpful! Tim
