linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Tretter <m.tretter@pengutronix.de>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
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, 20 Feb 2018 15:08:14 +0100	[thread overview]
Message-ID: <20180220150814.56913a0b@litschi.hi.pengutronix.de> (raw)

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

             reply	other threads:[~2018-02-20 14:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-20 14:08 Michael Tretter [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-06-27  9:16 Not enough bandwidth with Magewell XI100DUSB-HDMI Michael Tretter
     [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     ` 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

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=20180220150814.56913a0b@litschi.hi.pengutronix.de \
    --to=m.tretter@pengutronix.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@linux.intel.com \
    --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).