On 05/16/2018 04:55 AM, 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.
Isochronous has been a problem for me for 2 years. I am using a rare 3D
stereo camera from Etron and had Isochronous problems and recently I
have discovered that the Logitech Brio also has what appears to be the
same issue. The Logitech Brio is the first Logitech USB3 camera that
uses Isochronous mode and you can do a search and find that linux users
are having problems with it.
My suggestion would be for the USB3 team to order several Logitech Brio
cameras and debug the Isochronous problems. My company paid for someone
to try and debug the problem and we came up with a patch that we sent to
Mathias but it was not accepted because the change was not well
understood. I can probably buy cameras for Mathias if he is interested,
you only need 2 to get started, would like to see 5 or more running
simultaneously.
The people at Etron also discovered that if you plug Isochronous cameras
into a hub with a Genesys Logic - GL3520 controller then it for some
reason masks the problem and allows multiple cameras to work.
Unfortunately this USB hub is extremely rare and I only found it in this
StarTech ST7300USBME hub. Also it doesn't work flawlessly but I have
tested it with 5 cameras.
My all Intel motherboard and chipset machines work perfect with MS
Windows but not with Linux so it is hard to blame the hardware.
Curt
--
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
