* Not enough bandwidth with Magewell XI100DUSB-HDMI
@ 2018-01-19 20:12 ` Philipp Zabel
2018-01-29 12:02 ` Mathias Nyman
0 siblings, 1 reply; 13+ messages in thread
From: Philipp Zabel @ 2018-01-19 20:12 UTC (permalink / raw)
To: Michael Tretter; +Cc: Mathias Nyman, linux-usb, Philipp Zabel, Sascha Hauer
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<----------
xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
---------->8----------
regards
Philipp
---
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
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;
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Not enough bandwidth with Magewell XI100DUSB-HDMI
@ 2018-01-29 12:02 ` Mathias Nyman
2018-02-16 13:28 ` Michael Tretter
0 siblings, 1 reply; 13+ messages in thread
From: Mathias Nyman @ 2018-01-29 12:02 UTC (permalink / raw)
To: Philipp Zabel, Michael Tretter; +Cc: linux-usb, Philipp Zabel, Sascha Hauer
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.
-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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Not enough bandwidth with Magewell XI100DUSB-HDMI
@ 2018-02-16 13:28 ` Michael Tretter
2018-02-20 13:29 ` Mathias Nyman
0 siblings, 1 reply; 13+ messages in thread
From: Michael Tretter @ 2018-02-16 13:28 UTC (permalink / raw)
To: Mathias Nyman; +Cc: Philipp Zabel, linux-usb, Philipp Zabel, Sascha Hauer
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.
Michael
---
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Not enough bandwidth with Magewell XI100DUSB-HDMI
@ 2018-02-20 13:29 ` Mathias Nyman
2018-04-09 8:21 ` Michael Tretter
0 siblings, 1 reply; 13+ messages in thread
From: Mathias Nyman @ 2018-02-20 13:29 UTC (permalink / raw)
To: Michael Tretter; +Cc: Philipp Zabel, linux-usb, Philipp Zabel, Sascha Hauer
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Not enough bandwidth with Magewell XI100DUSB-HDMI
@ 2018-04-09 8:21 ` Michael Tretter
2018-04-10 15:22 ` Mathias Nyman
0 siblings, 1 reply; 13+ messages in thread
From: Michael Tretter @ 2018-04-09 8:21 UTC (permalink / raw)
To: Mathias Nyman; +Cc: Philipp Zabel, linux-usb, Philipp Zabel, Sascha Hauer
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@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.
Did you have time to unbox and test the Magewell device?
Michael
---
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Not enough bandwidth with Magewell XI100DUSB-HDMI
@ 2018-04-10 15:22 ` Mathias Nyman
2018-05-15 9:22 ` Michael Tretter
0 siblings, 1 reply; 13+ messages in thread
From: Mathias Nyman @ 2018-04-10 15:22 UTC (permalink / raw)
To: Michael Tretter; +Cc: Philipp Zabel, linux-usb, Philipp Zabel, Sascha Hauer
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@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.
>
> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Not enough bandwidth with Magewell XI100DUSB-HDMI
@ 2018-05-15 9:22 ` Michael Tretter
2018-05-16 11:55 ` Mathias Nyman
0 siblings, 1 reply; 13+ messages in thread
From: Michael Tretter @ 2018-05-15 9:22 UTC (permalink / raw)
To: Mathias Nyman; +Cc: Philipp Zabel, linux-usb, Philipp Zabel, kernel
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@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.
> >
> > 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?
Michael
---
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Not enough bandwidth with Magewell XI100DUSB-HDMI
@ 2018-05-16 11:55 ` Mathias Nyman
2018-05-21 22:03 ` Curt Meyers
0 siblings, 1 reply; 13+ messages in thread
From: Mathias Nyman @ 2018-05-16 11:55 UTC (permalink / raw)
To: Michael Tretter
Cc: Philipp Zabel, linux-usb, Philipp Zabel, kernel, Xing, Zhengjun
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@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.
>>>
>>> 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.
-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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Not enough bandwidth with Magewell XI100DUSB-HDMI
@ 2018-05-21 22:03 ` Curt Meyers
2019-06-24 14:40 ` Philipp Zabel
0 siblings, 1 reply; 13+ messages in thread
From: Curt Meyers @ 2018-05-21 22:03 UTC (permalink / raw)
To: Mathias Nyman, Michael Tretter
Cc: Philipp Zabel, linux-usb, Philipp Zabel, kernel, Xing, Zhengjun
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@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.
>>>>
>>>> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
2018-05-21 22:03 ` Curt Meyers
@ 2019-06-24 14:40 ` Philipp Zabel
2019-06-26 15:01 ` Philipp Zabel
0 siblings, 1 reply; 13+ messages in thread
From: Philipp Zabel @ 2019-06-24 14:40 UTC (permalink / raw)
To: Curt Meyers, Mathias Nyman, Michael Tretter
Cc: Philipp Zabel, linux-usb, kernel, Xing, Zhengjun
Hi,
On Mon, 2018-05-21 at 15:03 -0700, Curt Meyers wrote:
> 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@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.
> > > > >
> > > > > 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.
The Oculus Sensor devices contain Etron controllers as well (eSP770).
> 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.
Does anybody have new information about this issue? I tested last week
on v5.2-rc5, and the issue still persists unchanged (and forcing MEL=0
still helps).
regards
Philipp
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Not enough bandwidth with Magewell XI100DUSB-HDMI
2019-06-24 14:40 ` Philipp Zabel
@ 2019-06-26 15:01 ` Philipp Zabel
0 siblings, 0 replies; 13+ messages in thread
From: Philipp Zabel @ 2019-06-26 15:01 UTC (permalink / raw)
To: Curt Meyers, Mathias Nyman, Michael Tretter
Cc: linux-usb, kernel, Philipp Zabel, Xing, Zhengjun
On Mon, 2019-06-24 at 16:40 +0200, Philipp Zabel wrote:
> Hi,
>
> On Mon, 2018-05-21 at 15:03 -0700, Curt Meyers wrote:
> > 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@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.
> > > > > >
> > > > > > 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.
>
> The Oculus Sensor devices contain Etron controllers as well (eSP770).
>
> > 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.
>
> Does anybody have new information about this issue? I tested last week
> on v5.2-rc5, and the issue still persists unchanged (and forcing MEL=0
> still helps).
>
> regards
> Philipp
FTR, Michael pointed out that 0472bf06c6fd ("xhci: Prevent U1/U2 link pm
states if exit latency is too long") solves the problem for him, but in
my case the ESIT < MEL checks do not trigger:
----------8<----------
From: Philipp Zabel <philipp.zabel@gmail.com>
Subject: [PATCH] HACK: usb: xhci: always set MEL to 0
This allows to stream from multiple Oculus Sensors simultaneously on a
Lenovo T450s.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
---
Jun 26 08:24:25 ped kernel: usb 2-2: new SuperSpeed Gen 1 USB device number 3 using xhci_hcd
Jun 26 08:24:26 ped kernel: usb 2-2: New USB device found, idVendor=2833, idProduct=0211, bcdDevice= 0.00
Jun 26 08:24:26 ped kernel: usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 26 08:24:26 ped kernel: usb 2-2: Product: Rift Sensor
Jun 26 08:24:26 ped kernel: usb 2-2: Manufacturer: Oculus VR
Jun 26 08:24:26 ped kernel: usb 2-2: SerialNumber: WMTD3034300BCT
Jun 26 08:24:26 ped kernel: uvcvideo: Found UVC 1.00 device Rift Sensor (2833:0211)
Jun 26 08:24:26 ped kernel: xhci_hcd 0000:00:14.0: add ep 0x83, slot id 5, new drop flags = 0x0, new add flags = 0x80
Jun 26 08:24:26 ped kernel: xhci_hcd 0000:00:14.0: xhci_check_bandwidth called for udev 00000000919e8856
Jun 26 08:24:26 ped kernel: usb 2-2: xhci_calculate_u1_timeout: service interval = 128000000
Jun 26 08:24:26 ped kernel: usb 2-2: xhci_calculate_u1_timeout: max exit latency = 10000
Jun 26 08:24:26 ped kernel: usb 2-2: Hub-initiated U1 disabled due to long timeout 134400 ms
Jun 26 08:24:26 ped kernel: usb 2-2: xhci_change_max_exit_latency: MEL = 10 µs, but using 0
Jun 26 08:24:26 ped kernel: usb 2-2: xhci_calculate_u2_timeout: service interval = 128000000
Jun 26 08:24:26 ped kernel: usb 2-2: xhci_calculate_u2_timeout: max exit latency = 512000
Jun 26 08:24:26 ped kernel: usb 2-2: Hub-initiated U2 disabled due to long timeout 500 ms
Jun 26 08:24:26 ped kernel: usb 2-2: xhci_change_max_exit_latency: MEL = 512 µs, but using 0
---
drivers/usb/host/xhci.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 3f79f35d0b19..ef26285eb7a6 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4212,7 +4212,9 @@ 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);
+ dev_dbg(&udev->dev, "%s: MEL = %u µs, but using 0\n", __func__,
+ 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,
@@ -4549,6 +4551,10 @@ static u16 xhci_calculate_u1_timeout(struct xhci_hcd *xhci,
/* Prevent U1 if service interval is shorter than U1 exit latency */
if (usb_endpoint_xfer_int(desc) || usb_endpoint_xfer_isoc(desc)) {
+ dev_dbg(&udev->dev, "%s: service interval = %lu\n", __func__,
+ (unsigned long)xhci_service_interval_to_ns(desc));
+ dev_dbg(&udev->dev, "%s: max exit latency = %lu\n", __func__,
+ (unsigned long)udev->u1_params.mel);
if (xhci_service_interval_to_ns(desc) <= udev->u1_params.mel) {
dev_dbg(&udev->dev, "Disable U1, ESIT shorter than exit latency\n");
return USB3_LPM_DISABLED;
@@ -4613,6 +4619,10 @@ static u16 xhci_calculate_u2_timeout(struct xhci_hcd *xhci,
/* Prevent U2 if service interval is shorter than U2 exit latency */
if (usb_endpoint_xfer_int(desc) || usb_endpoint_xfer_isoc(desc)) {
+ dev_dbg(&udev->dev, "%s: service interval = %lu\n", __func__,
+ (unsigned long)xhci_service_interval_to_ns(desc));
+ dev_dbg(&udev->dev, "%s: max exit latency = %lu\n", __func__,
+ (unsigned long)udev->u2_params.mel);
if (xhci_service_interval_to_ns(desc) <= udev->u2_params.mel) {
dev_dbg(&udev->dev, "Disable U2, ESIT shorter than exit latency\n");
return USB3_LPM_DISABLED;
--
2.20.1
---------->8----------
regards
Philipp
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Not enough bandwidth with Magewell XI100DUSB-HDMI
@ 2018-06-27 9:16 Michael Tretter
0 siblings, 0 replies; 13+ messages in thread
From: Michael Tretter @ 2018-06-27 9:16 UTC (permalink / raw)
To: Xing, Zhengjun
Cc: Mathias Nyman, Philipp Zabel, linux-usb, Philipp Zabel, kernel
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@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.
> >>>
> >>> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Not enough bandwidth with Magewell XI100DUSB-HDMI
@ 2018-02-20 14:08 Michael Tretter
0 siblings, 0 replies; 13+ messages in thread
From: Michael Tretter @ 2018-02-20 14:08 UTC (permalink / raw)
To: Mathias Nyman; +Cc: Philipp Zabel, linux-usb, Philipp Zabel, Sascha Hauer
Hi Mathias,
On Tue, 20 Feb 2018 15:29:28 +0200, Mathias Nyman wrote:
> 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.
Here are the step by step instructions:
1. Connect Magewell device to USB 3.0 port.
2. Start using the created audio input to configure the isoch endpoint.
I use pulseaudio (which should autodetect the device) and GStreamer for
that, but anything should work.
gst-launch-1.0 \
pulsesrc device='alsa_input.usb-Magewell_XI100DUSB-HDMI_A201170218035-02.analog-stereo' ! \
fakesink
3. Connect another USB device, e.g., a USB Stick, but it does not
matter, to another port of the same controller.
Expected behavior:
usb 3-1: new high-speed USB device number 6 using xhci_hcd
usb 3-1: New USB device found, idVendor=0951, idProduct=1665
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-1: Product: DataTraveler 2.0
usb 3-1: Manufacturer: Kingston
usb 3-1: SerialNumber: 60A44C413F39F0B116229916
usb-storage 3-1:1.0: USB Mass Storage device detected
Actual behavior:
usb 3-1: new high-speed USB device number 7 using xhci_hcd
usb 3-1: New USB device found, idVendor=0951, idProduct=1665
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-1: Product: DataTraveler 2.0
usb 3-1: Manufacturer: Kingston
usb 3-1: SerialNumber: 60A44C413F39F0B116229916
usb 3-1: Not enough bandwidth for new device state.
usb 3-1: can't set config #1, error -28
lsusb actually lists the device, but the block device does not show up.
I hope this is useful.
Michael
---
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-06-26 15:01 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20180117174638.7e1b375d@litschi.hi.pengutronix.de>
[not found] ` <0cb1a3e6-7a34-0357-95f6-f0615defbe1b@linux.intel.com>
[not found] ` <20180119141022.2f18a677@litschi.hi.pengutronix.de>
2018-01-19 20:12 ` Not enough bandwidth with Magewell XI100DUSB-HDMI Philipp Zabel
2018-01-29 12:02 ` Mathias Nyman
2018-02-16 13:28 ` Michael Tretter
2018-02-20 13:29 ` Mathias Nyman
2018-04-09 8:21 ` Michael Tretter
2018-04-10 15:22 ` Mathias Nyman
2018-05-15 9:22 ` Michael Tretter
2018-05-16 11:55 ` Mathias Nyman
2018-05-21 22:03 ` Curt Meyers
2019-06-24 14:40 ` Philipp Zabel
2019-06-26 15:01 ` Philipp Zabel
2018-02-20 14:08 Michael Tretter
2018-06-27 9:16 Michael Tretter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).