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.
-Mathias
--
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
