Not enough bandwidth with Magewell XI100DUSB-HDMI

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 16.02.2018 15:28, Michael Tretter wrote:
> Hi Mathias,
> 
> On Mon, 29 Jan 2018 14:02:57 +0200, Mathias Nyman wrote:
>> On 19.01.2018 22:12, Philipp Zabel wrote:
>>> Hi,
>>>
>>> On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter
>>> <m.tretter@pengutronix.de> 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.

Thanks
Mathias
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html