From: Mathias Nyman <mathias.nyman@linux.intel.com>
To: Michael Tretter <m.tretter@pengutronix.de>
Cc: Philipp Zabel <philipp.zabel@gmail.com>,
linux-usb <linux-usb@vger.kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Sascha Hauer <kernel@pengutronix.de>
Subject: Not enough bandwidth with Magewell XI100DUSB-HDMI
Date: Tue, 10 Apr 2018 18:22:03 +0300 [thread overview]
Message-ID: <31257288-a0eb-3893-8ef9-325d68663f9b@linux.intel.com> (raw)
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
next prev reply other threads:[~2018-04-10 15:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=31257288-a0eb-3893-8ef9-325d68663f9b@linux.intel.com \
--to=mathias.nyman@linux.intel.com \
--cc=kernel@pengutronix.de \
--cc=linux-usb@vger.kernel.org \
--cc=m.tretter@pengutronix.de \
--cc=p.zabel@pengutronix.de \
--cc=philipp.zabel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).