127-Dec-2002 2 3The EHCI driver is used to talk to high speed USB 2.0 devices using 4USB 2.0-capable host controller hardware. The USB 2.0 standard is 5compatible with the USB 1.1 standard. It defines three transfer speeds: 6 7 - "High Speed" 480 Mbit/sec (60 MByte/sec) 8 - "Full Speed" 12 Mbit/sec (1.5 MByte/sec) 9 - "Low Speed" 1.5 Mbit/sec 10 11USB 1.1 only addressed full speed and low speed. High speed devices 12can be used on USB 1.1 systems, but they slow down to USB 1.1 speeds. 13 14USB 1.1 devices may also be used on USB 2.0 systems. When plugged 15into an EHCI controller, they are given to a USB 1.1 "companion" 16controller, which is a OHCI or UHCI controller as normally used with 17such devices. When USB 1.1 devices plug into USB 2.0 hubs, they 18interact with the EHCI controller through a "Transaction Translator" 19(TT) in the hub, which turns low or full speed transactions into 20high speed "split transactions" that don't waste transfer bandwidth. 21 22At this writing, this driver has been seen to work with implementations 23of EHCI from (in alphabetical order): Intel, NEC, Philips, and VIA. 24Other EHCI implementations are becoming available from other vendors; 25you should expect this driver to work with them too. 26 27While usb-storage devices have been available since mid-2001 (working 28quite speedily on the 2.4 version of this driver), hubs have only 29been available since late 2001, and other kinds of high speed devices 30appear to be on hold until more systems come with USB 2.0 built-in. 31Such new systems have been available since early 2002, and became much 32more typical in the second half of 2002. 33 34Note that USB 2.0 support involves more than just EHCI. It requires 35other changes to the Linux-USB core APIs, including the hub driver, 36but those changes haven't needed to really change the basic "usbcore" 37APIs exposed to USB device drivers. 38 39- David Brownell 40 <dbrownell@users.sourceforge.net> 41 42 43FUNCTIONALITY 44 45This driver is regularly tested on x86 hardware, and has also been 46used on PPC hardware so big/little endianness issues should be gone. 47It's believed to do all the right PCI magic so that I/O works even on 48systems with interesting DMA mapping issues. 49 50Transfer Types 51 52At this writing the driver should comfortably handle all control, bulk, 53and interrupt transfers, including requests to USB 1.1 devices through 54transaction translators (TTs) in USB 2.0 hubs. But you may find bugs. 55 56High Speed Isochronous (ISO) transfer support is also functional, but 57at this writing no Linux drivers have been using that support. 58 59Full Speed Isochronous transfer support, through transaction translators, 60is not yet available. Note that split transaction support for ISO 61transfers can't share much code with the code for high speed ISO transfers, 62since EHCI represents these with a different data structure. So for now, 63most USB audio and video devices can't be connected to high speed buses. 64 65Driver Behavior 66 67Transfers of all types can be queued. This means that control transfers 68from a driver on one interface (or through usbfs) won't interfere with 69ones from another driver, and that interrupt transfers can use periods 70of one frame without risking data loss due to interrupt processing costs. 71 72The EHCI root hub code hands off USB 1.1 devices to its companion 73controller. This driver doesn't need to know anything about those 74drivers; a OHCI or UHCI driver that works already doesn't need to change 75just because the EHCI driver is also present. 76 77There are some issues with power management; suspend/resume doesn't 78behave quite right at the moment. 79 80Also, some shortcuts have been taken with the scheduling periodic 81transactions (interrupt and isochronous transfers). These place some 82limits on the number of periodic transactions that can be scheduled, 83and prevent use of polling intervals of less than one frame. 84 85 86USE BY 87 88Assuming you have an EHCI controller (on a PCI card or motherboard) 89and have compiled this driver as a module, load this like: 90 91 # modprobe ehci-hcd 92 93and remove it by: 94 95 # rmmod ehci-hcd 96 97You should also have a driver for a "companion controller", such as 98"ohci-hcd" or "uhci-hcd". In case of any trouble with the EHCI driver, 99remove its module and then the driver for that companion controller will 100take over (at lower speed) all the devices that were previously handled 101by the EHCI driver. 102 103Module parameters (pass to "modprobe") include: 104 105 log2_irq_thresh (default 0): 106 Log2 of default interrupt delay, in microframes. The default 107 value is 0, indicating 1 microframe (125 usec). Maximum value 108 is 6, indicating 2^6 = 64 microframes. This controls how often 109 the EHCI controller can issue interrupts. 110 111If you're using this driver on a 2.5 kernel, and you've enabled USB 112debugging support, you'll see three files in the "sysfs" directory for 113any EHCI controller: 114 115 "async" dumps the asynchronous schedule, used for control 116 and bulk transfers. Shows each active qh and the qtds 117 pending, usually one qtd per urb. (Look at it with 118 usb-storage doing disk I/O; watch the request queues!) 119 "periodic" dumps the periodic schedule, used for interrupt 120 and isochronous transfers. Doesn't show qtds. 121 "registers" show controller register state, and 122 123The contents of those files can help identify driver problems. 124 125 126Device drivers shouldn't care whether they're running over EHCI or not, 127but they may want to check for "usb_device->speed == USB_SPEED_HIGH". 128High speed devices can do things that full speed (or low speed) ones 129can't, such as "high bandwidth" periodic (interrupt or ISO) transfers. 130Also, some values in device descriptors (such as polling intervals for 131periodic transfers) use different encodings when operating at high speed. 132 133However, do make a point of testing device drivers through USB 2.0 hubs. 134Those hubs report some failures, such as disconnections, differently when 135transaction translators are in use; some drivers have been seen to behave 136badly when they see different faults than OHCI or UHCI report. 137 138 139PERFORMANCE 140 141USB 2.0 throughput is gated by two main factors: how fast the host 142controller can process requests, and how fast devices can respond to 143them. The 480 Mbit/sec "raw transfer rate" is obeyed by all devices, 144but aggregate throughput is also affected by issues like delays between 145individual high speed packets, driver intelligence, and of course the 146overall system load. Latency is also a performance concern. 147 148Bulk transfers are most often used where throughput is an issue. It's 149good to keep in mind that bulk transfers are always in 512 byte packets, 150and at most 13 of those fit into one USB 2.0 microframe. Eight USB 2.0 151microframes fit in a USB 1.1 frame; a microframe is 1 msec/8 = 125 usec. 152 153So more than 50 MByte/sec is available for bulk transfers, when both 154hardware and device driver software allow it. Periodic transfer modes 155(isochronous and interrupt) allow the larger packet sizes which let you 156approach the quoted 480 MBit/sec transfer rate. 157 158Hardware Performance 159 160At this writing, individual USB 2.0 devices tend to max out at around 16120 MByte/sec transfer rates. This is of course subject to change; 162and some devices now go faster, while others go slower. 163 164The first NEC implementation of EHCI seems to have a hardware bottleneck 165at around 28 MByte/sec aggregate transfer rate. While this is clearly 166enough for a single device at 20 MByte/sec, putting three such devices 167onto one bus does not get you 60 MByte/sec. The issue appears to be 168that the controller hardware won't do concurrent USB and PCI access, 169so that it's only trying six (or maybe seven) USB transactions each 170microframe rather than thirteen. (Seems like a reasonable trade off 171for a product that beat all the others to market by over a year!) 172 173It's expected that newer implementations will better this, throwing 174more silicon real estate at the problem so that new motherboard chip 175sets will get closer to that 60 MByte/sec target. That includes an 176updated implementation from NEC, as well as other vendors' silicon. 177 178There's a minimum latency of one microframe (125 usec) for the host 179to receive interrupts from the EHCI controller indicating completion 180of requests. That latency is tunable; there's a module option. By 181default ehci-hcd driver uses the minimum latency, which means that if 182you issue a control or bulk request you can often expect to learn that 183it completed in less than 250 usec (depending on transfer size). 184 185Software Performance 186 187To get even 20 MByte/sec transfer rates, Linux-USB device drivers will 188need to keep the EHCI queue full. That means issuing large requests, 189or using bulk queuing if a series of small requests needs to be issued. 190When drivers don't do that, their performance results will show it. 191 192In typical situations, a usb_bulk_msg() loop writing out 4 KB chunks is 193going to waste more than half the USB 2.0 bandwidth. Delays between the 194I/O completion and the driver issuing the next request will take longer 195than the I/O. If that same loop used 16 KB chunks, it'd be better; a 196sequence of 128 KB chunks would waste a lot less. 197 198But rather than depending on such large I/O buffers to make synchronous 199I/O be efficient, it's better to just queue up several (bulk) requests 200to the HC, and wait for them all to complete (or be canceled on error). 201Such URB queuing should work with all the USB 1.1 HC drivers too. 202 203In the Linux 2.5 kernels, new usb_sg_*() api calls have been defined; they 204queue all the buffers from a scatterlist. They also use scatterlist DMA 205mapping (which might apply an IOMMU) and IRQ reduction, all of which will 206help make high speed transfers run as fast as they can. 207 208 209TBD: Interrupt and ISO transfer performance issues. Those periodic 210transfers are fully scheduled, so the main issue is likely to be how 211to trigger "high bandwidth" modes. 212 213TBD: More than standard 80% periodic bandwidth allocation is possible 214through sysfs uframe_periodic_max parameter. Describe that. 215