Hi Zhengjun, On Wed, 16 May 2018 14:55:55 +0300, Mathias Nyman wrote: > On 15.05.2018 12:22, Michael Tretter wrote: > > Hi Mathias, > > > > On Tue, 10 Apr 2018 18:22:03 +0300, Mathias Nyman wrote: > >> On 09.04.2018 11:21, Michael Tretter wrote: > >>> On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote: > >>>> On 16.02.2018 15:28, Michael Tretter wrote: > >>>>> On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote: > >>>>>> On 19.01.2018 22:12, Philipp Zabel wrote: > >>>>>>> On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter > >>>>>>> <m.tretter@xxxxxxxxxxxxxx> wrote: > >>>>>>>> I found the old thread and it sounds exactly like my issue. Different > >>>>>>>> camera, but same xHCI controller. > >>>>>>> > >>>>>>> I have exactly the same issue with the xHCI controller of my laptop and > >>>>>>> "Oculus Sensor" USB3 isochronous mostly-UVC cameras: > >>>>>>> > >>>>>>> 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI > >>>>>>> Controller (rev 03) (prog-if 30 [XHCI]) > >>>>>>> Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller > >>>>>>> Flags: bus master, medium devsel, latency 0, IRQ 44 > >>>>>>> Memory at f2220000 (64-bit, non-prefetchable) [size=64K] > >>>>>>> Capabilities: [70] Power Management version 2 > >>>>>>> Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ > >>>>>>> Kernel driver in use: xhci_hcd > >>>>>>> Kernel modules: xhci_pci > >>>>>>> > >>>>>>> T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 > >>>>>>> D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1 > >>>>>>> P: Vendor=2833 ProdID=0211 Rev= 0.00 > >>>>>>> S: Manufacturer=Oculus VR > >>>>>>> S: Product=Rift Sensor > >>>>>>> S: SerialNumber=WMTD3034300BCT > >>>>>>> C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA > >>>>>>> A: FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00 > >>>>>>> I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo > >>>>>>> E: Ad=83(I) Atr=03(Int.) MxPS= 32 Ivl=128ms > >>>>>>> I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>>>>>> I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>>>>>> E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > >>>>>>> I: If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo > >>>>>>> E: Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us > >>>>>>> > >>>>>>> Any USB2 or USB3 device that I plug in while the first camera is streaming in > >>>>>>> altsetting 1 or 2 causes the bandwidth error. The same happens when I try to > >>>>>>> change the altsetting on an isochronous endpoint of an already plugged device. > >>>>>>> While the camera is in altsetting 0, other devices can be probed and work. > >>>>>>> > >>>>>>>> For some tests, I changed the xhci_change_max_exit_latency() function > >>>>>>>> to ignore the requested MEL and set the MEL to 0. Now the USB devices > >>>>>>>> are detected correctly. > >>>>>>> > >>>>>>> Exactly the same thing helps here, as well. With this hack, streaming from two > >>>>>>> of those cameras at the same time works without any apparent problem: > >>>>>>> > >>>>>>> ----------8<---------- > >>>>>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > >>>>>>> index 297536c9fd00..3cb4a60d8822 100644 > >>>>>>> --- a/drivers/usb/host/xhci.c > >>>>>>> +++ b/drivers/usb/host/xhci.c > >>>>>>> @@ -4025,7 +4025,7 @@ static int __maybe_unused > >>>>>>> xhci_change_max_exit_latency(struct xhci_hcd *xhci, > >>>>>>> ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG); > >>>>>>> slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx); > >>>>>>> slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT)); > >>>>>>> - slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency); > >>>>>>> + slot_ctx->dev_info2 |= cpu_to_le32(0); > >>>>>>> slot_ctx->dev_state = 0; > >>>>>>> > >>>>>>> xhci_dbg_trace(xhci, trace_xhci_dbg_context_change, > >>>>>>> ---------->8---------- > >>>>>>> > >>>>>> > >>>>>> Ok, back after a week on sickleave. > >>>>>> I'm getting the magewell capture device and try to reproduce this myself. > >>>>> > >>>>> I don't think that the issue is specific to the magewell capture > >>>>> device, but rather should be reproducible with any USB3 device with > >>>>> isochronous endpoints. > >>>>> > >>>>> Anyway, please tell me, if I can somehow help you to get this properly > >>>>> fixed. > >>>> > >>>> I'm currently looking at device reset issues after suspend, but this is on the > >>>> todo list. > >>>> > >>>> I got a magewell device, (haven't unboxed it yet) > >>>> Maybe step by step instructions to reproduce it could speed things up. > >>> > >>> Did you have time to unbox and test the Magewell device? > >>> > >> > >> This seems to always get postponed due to other work, > >> > >> I just tried it out once today on a nearby laptop, gst-launch seems to work > >> but couldn't reproduce the bandwidth issue when connecting a second usb device. > >> > >> But I haven't really tested it out properly yet. > > > > I just tested with 4.17-rc5 and the behavior remains the same. Is there > > anything else I could do to get this fixed? > > > > Briefed Zhengjun about this issue, one more brain on it. > Adding him to the thread. Where you able to reproduce the bandwidth issue with the Magewell or do you have an idea how to further investigate the problem? Michael -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
