Documentation/usb/ehci.rst

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