Posted by Jason at Sun Jun 27 19:20:01 2010

Hi, from the version 0.96, it seems that the xHCI only detect the scheduling over/under run. Does it means that the system software takes care the bandwidth allocation within each microframe?

Posted by Sarah Sharp at Mon Jun 28 00:05:31 2010

The xHCI hardware does all the scheduling, not the software.  When a device is configured, the xHCI driver sets up a "device" context with information about each endpoint used, and the host controller uses that to set up the schedule.

So if a periodic endpoint is included in the device context, the host controller will use the polling interval in the device context to set up the periodic schedule.  If it can't fit the endpoint into the schedule, it gives a bandwidth error when the configuration is installed.

This is different than the current system, that gives a bandwidth error when urb_submit() is called.  Now the driver can get a bandwidth error when it tries to install a new alternate interface setting with usb_set_interface().

Posted by Jason at Wed Jul 7 20:06:12 2010

Hi, Thanks for you explanation about xHCI scheduling. However, I still not very clear about the periodic scheduling. From EHCI, there are two pointer with one pointed to periodic TRB lists, and the other pointed to asynchronous TRB lists. In xHCI, there are no such pointer. The only information xHCI hardware has is Device Context. So, my guess is xHCI hardware has to parse all Device Context during the first 80% of micro-frame for periodic scheduling, and re-parse it for the asynchronous scheduling. Is this correct? If it is correct, I think this kind of may wast a little memory access bandwidth.

Posted by castor at Wed Aug 11 07:27:21 2010

Pretty interesting ... XHCI looks like it has a completely different "debug" interface than was defined for EHCI.  Any plans for supporting early printk in the linux XHCI stack?

Can you find out how to get the EHCI early printk stuff working on P/H 55 chipset systems?  The rate matching hubs built into the chipsets seem to get in the way so that there's no way to get to the  debug ports.

According to the docs: "• When a Debug Port Device is detected the PCH EHCI will bypass the
integrated Rate Matching Hub and connect directly to the port and the DPD.)." but we don't seem to see this happen.

Thanks!!

Posted by Jason at Thu Sep 9 23:42:16 2010

The xHC define a very uniform mechanism of Command Ring and Transfer Ring. Why the mechanism of Event Ring is different? Is it because the producer is xHC and the consumer is S/W? Or any special reason? Thanks.

Posted by Sarah Sharp at Fri Sep 10 10:15:43 2010

Jason:  Yes, I think the event ring is set up differently because the hardware is the producer for that ring.  Having a segment table may be easier for hardware than trying to dynamically figure out if the ring has been expanded.

Posted by Jason at Wed Sep 15 20:30:08 2010

Hi,
On pp108 of xHCI revision 1.0, the paragraph after 3rd note states that the Stopped Transfer Event was conditional be generated depends on natural boundary of TD. However, the next paragraph states that xHC should generate Stopped Transfer Event "every time" a Transfer Ring is stopped with a Stop Endpoint Command. Is these two paragraph conflict?

Posted by Sarah Sharp at Thu Sep 16 12:45:15 2010

Jason:

When an endpoint ring is stopped, a command completion event for the Stop Endpoint command is always generated.  Depending on where the xHC is in processing a TD, it may also generate a Stopped Transfer Event.  So you'll always get a command completion event on the event ring, and you may get the transfer event also.

Yes, that paragraph is a bit confusing.  You might want to pass on the question to xhcisupport@intel.com.

Posted by Howard at Mon Sep 20 01:39:58 2010

It's interesting that why the SlotId was given by the hardware (xHC) instead of system software. My understanding, that the system software can also handle this smoothly, like that in early version of HCI. Is there any special reason for this kind of mechanism? Thanks.

Posted by Sarah Sharp at Mon Sep 20 19:33:06 2010

Howard: The hardware assigns the slot ID for virtualization reasons.  If the VM is sharing an xHCI host controller across guests, it can ensure that each guest doesn't stomp on the other's slots.  There's other things in the spec that can be explained by the need for virtualization, like the fact that the xHCI host assigns the device addresses, not software.

Posted by Jason at Wed Sep 29 02:17:08 2010

Sarah: From the above response to Howard, I think the device address should be assigned by software. Per xHCI specification version 1.0 pp 92, the second dot explain that the software should prepare a InputContext with several field be defined. Device Address is one of them. So, I think the device address should be assigned by software, and then the xHC issue a SET_ADDR command to device per address assigned in InputContext. Please correct me if I am wrong. Thanks again.

By the way, we mail some questions to xhcisupport@intel.com, but no response until now(1 weeks passed by). Do you know any other channel to ask questions, or it normal. :)

Posted by Sunil at Wed Oct 6 01:27:27 2010

Hi,Sarah
I'm confusing about the set_addr command for usb3.0 device.usb2.0 devices use address 0 to set address usb3.0 devices use route string.
Could you give an example of route string for real device ?
Thanks.

Posted by Jason at Thu Oct 14 22:13:55 2010

Hi, Sharh
  In xHCI 1.0, 4.11.2.5 (pp162), it says that the software should NOT schedule Isoch TD with FrameID greater than 895ms ahead of MFINDEX. Do you know why 895ms defined?

  Another question is about TD fragment defined in 4.11.7.1. We are not very clear about it's usage. Do you know any reason to give this requirements?

Thanks very much in advance.

Posted by GENE at Mon Nov 8 02:03:38 2010

Sorry for bothering you. I have some questions about Linux UASP driver.
  I have bought a USB3.0 device that announced its UASP-supporting can increase read/write speed up to 20%. (This Product is CyberSLIM S1-U3 "Turbo" SATAII HDD USB3.0 External Enclosure) .
  When I plug this device into a normal USB3.0 port with NEC chip, everything works fine. But I can't see my OS probe the uas.ko module (UASP driver). Before I plug this device, I have updated my kernel to 2.6.36 with UASP driver.

Also I use "lsmod" commad in the command line and it show
------------------------------------------------------
Module  Size  Used by
uas 7999  0
usb_storage 33282  1
xhci_hcd   57341  0
------------------------------------------------------

How to force to use "uas.ko" (UASP driver) when I plug this UASP device?
Would you tell me which device can be supported by "uas.ko" (UASP driver) in Linux kernel 2.6.36?

ps.My OS is Ubuntu10.10.
CyberSLIM S1-U3 "Turbo" SATAII HDD USB3.0 External Enclosure
Product URL : http://www.cyberslim.com.tw/front/bin/ptlist.phtml?Category=123707

Thank you.

Posted by Shane at Thu Mar 31 21:08:14 2011

Sarah, First of all thank you for implementing this in Linux.  Since you are the one who made the driver I was hoping you might be able to give me some direction on how host to host with a crossover cable is supposed to work?  I have searched and searched on the internet and can't find anything on how to do this.  I have looked through both the USB 3.0 spec and the xhci spec and couldn't find anything in there either.  Even if I could get a link with information that would be a tremendous help.

Sincerely.
Shane

Posted by Sarah Sharp at Mon Apr 4 20:25:33 2011

Shane: I'm not sure what you mean by "cross over cable".  Are you talking about a USB debug cable?  An OTG cable?  Because USB in general (and USB 3.0 specifically) is not set up to allow host-to-host communication.  It's a host-driven protocol, by design, with one host and one (or more) slave devices.  Even with OTG, a device that can be either a host or a device will switch to being just a USB device if it's plugged into a regular host.  You can't ever have two hosts plugged into the same cable.

Posted by Hien Dang at Fri Nov 11 08:42:18 2011

Hi Sarah,

I looked at the code in the URL link above and observed that they were written in 2008. Are they still good as today or you have newer version somewhere?

Also, what do the files in the Core directory do? I read your README file but still could not understand it.

Thanks,

Hien

Posted by tony at Fri Jan 20 08:27:35 2012

Hi Sarah
Thanks  for your work.
Does your driver support otg on pc side or allow crossover cable kind of bridge between usb 3.0 pc's.This mysterious crossover cable usb 3.0 (debug cable) is referred to on Microsoft's site which implies that any two pcs with usb 3.0 host can be joined together.

http://msdn.microsoft.com/en-us/library/hh439372%28v=vs.85%29.aspx

This mentions the crossover cable and host to host links presumably by one becoming a device.

http://www.lvr.com/usb3faq.htm#ca_direct

These people sell one.
http://www.datapro.net/products/usb-3-0-super-speed-a-a-cable-crossover-strict.html
and also dell
<a href="http://accessories.us.dell.com/sna/productdetail.aspx?c=us&l=en&s=k12&cs=26&sku=a3875053#Overview">http://accessories.us.dell.com/sna/productdetail.aspx?c=us&l=en&s=k12&cs=26&sku=a3875053#Overview</a>
I have tried to find it in the specs no results
only came across intel patent

<a href="http://www.google.com/patents?id=lw3SAAAAEBAJ&printsec=frontcover&dq=20100169511&hl=en&sa=X&ei=f4MZT47ROpOIhQetkLnHDA&ved=0CDQQ6AEwAA">http://www.google.com/patents?id=lw3SAAAAEBAJ&printsec=frontcover&dq=20100169511&hl=en&sa=X&ei=f4MZT47ROpOIhQetkLnHDA&ved=0CDQQ6AEwAA</a>

Do you know anymore ?
Thanks
Tony