linux/Documentation/usb/ehci.txt
<<
ue="4ue="4ue//spa.6.ue/spa. class="lxr_search">ue="ue="4ue="4ue="4typ Searchue="4ue//spa.6.="4< ue/input typ u="4< < <1//a>27-Dec-2002 < <2//a>u< <3//a>The EHCI driver is used to talk to high speed USB 2.0 devices usingu< <4//a>USB 2.0-capable host controller hardware. The USB 2.0 standard isu< <5//a>compa vble with the USB 1.1 standard. It defines three transfer speeds:u< <6//a>u< <7//a>4< <- "High Speed" 480 Mbit/sec (60 MByte/sec)u< <8//a>4< <- "Full Speed" 12 Mbit/sec (1.5 MByte/sec)u< <9//a>4< <- "Low Speed" 1.5 Mbit/secu< v2a>u< 11//a>USB 1.1 only addressed full speed and low speed. High speed devicesu< 12//a>ca. be used on>USB 1.1 systems, but they slow down to USB 1.1 speeds.u< 13v2a>u< 14//a>USB 1.1 devices may also be used on>USB 2.0 systems. When pluggedu< 15//a>into a. EHCI controller, they are given to a USB 1.1 "companv2."u< 16//a>controller, which is a OHCI or UHCI controller as normally used withu< 17//a>such devices. When USB 1.1 devices plug into USB 2.0 hubs, theyu< 18//a>interac with the EHCI controller through a "Transac v2. Translator"u< 19//a>(TT) in the hub, which turns low or full speed transac v2.s into < 2 v2a>high speed "split transac v2.s" that d2.' waste transfer bandwidth.u< 21v2a>u< 22//a>At this writing, this driver has been seen to work with implementa v2.su< 23v2a>of EHCI from (in alphabe vcal order): Intel, NEC, Philips, and VIA.u< 24//a>Other EHCI implementa v2.s are becoming available from other vendors;u< 25//a>you should expect this driver to work with them too.u< 26//a>u< 27//a>While usb-storage devices have been available since mid-2001 (workingu< 28//a>quite speedily on the 2.4 versv2. of this driver), hubs have onlyu< 29//a>been available since late 2001, and other kinds of high speed devicesu< 3 v2a>appear to be on hold until more systems come with USB 2.0 built-in.u< 31v2a>Such new systems have been available since early 2002, and becam muchu< 32//a>more typvcal in the second half of 2002.u< 33v2a>u< 34//a>Note that USB 2.0 support involves more tha. just EHCI. It requiresu< 35//a>other cha.ges to the Linux-USB core APIs, including the hub driver,u< 36//a>but those cha.ges have.' needed to really cha.ge the basic "usbcore"u< 37//a>APIs exposed to USB device drivers.u< 38v2a>u< 39//a>- David Brownellu< 40//a>4<<dbrownell@users.sourceforge.net>u< 41v2a>u< 42//a>u< 43v2a>FUNCTIONALITYu< 44//a>u< 45//a>This driver is regularly tested on>x86 hardware, and has also beenu< 46//a>used on>PPC hardware so big/little endianness issues should be gone.u< 47//a>It's believed to do all the right PCI magic so that I/O works even onu< 48v2a>systems with interesting DMA mapping issues.u< 49//a>u< 50//a>Transfer Typesu< 51v2a>u< 52//a>At this writing the driver should comfortably handle all control, bulk,u< 53v2a>and interrupt transfers, including requests to USB 1.1 devices throughu< 54//a>transac v2. translators (TTs) in USB 2.0 hubs. But you may find bugs.u< 55v2a>u< 56//a>High Speed Isochronous (ISO) transfer support is also func v2.al, butu< 57//a>at this writing no Linux drivers have been using that support.u< 58v2a>u< 59//a>Full Speed Isochronous transfer support, through transac v2. translators,u< 60//a>is not yet available. Note that split transac v2. support for ISOu< 61//a>transfers ca.' share much code with the code for high speed ISO transfers,u< 62//a>since EHCI represents these with a different data structure. So for now,u< 63//a>most USB audio and video devices ca.' be connected to high speed buses.u< 64//a>u< 65v2a>Driver Behavioru< 66//a>u< 67//a>Transfers of all types ca. be queued. This means that control transfersu< 68v2a>from a driver 2. one interface (or through usbfs) w2.' interfere withu< 69//a>ones from another driver, and that interrupt transfers ca. use periodsu< 70v2a>of one frame without risking data loss due to interrupt processing costs.u< 71v2a>u< 72//a>The EHCI root hub code hands off USB 1.1 devices to its companv2.u< 73//a>controller. This driver does.' need to know anything about thoseu< 74//a>drivers; a OHCI or UHCI driver that works already does.' need to cha.geu< 75v2a>just because the EHCI driver is also present.u< 76//a>u< 77//a>There are some issues with power management; suspend/resume does.' u< 78//a>behave quite right at the moment.u< 79//a>u< 80v2a>Also, some shortcuts have been taken with the scheduling periodicu< 81//a>transac v2.s (interrupt and isochronous transfers). These place someu< 82//a>limits on the number 2f periodic transac v2.s that ca. be scheduled,u< 83v2a>and prevent use 2f polling intervals 2f less tha. one frame.u< 84//a>u< 85v2a>u< 86//a>USE BYu< 87v2a>u< 88//a>Assuming you have a. EHCI controller (on a PCI card or motherboard)u< 89v2a>and have compiled this driver as a module, load this like:u< 9 v2a>u< 91//a>4< <# modprobe ehci-hcdu< 92//a>u< 93v2a>and remove it by:u< 94//a>u< 95//a>4< <# rmmod ehci-hcdu< 96//a>u< 97v2a>You should also have a driver for a "companv2. controller", such asu< 98//a>"ohci-hcd" or "uhci-hcd". I. case 2f any trouble with the EHCI driver,u< 99v2a>remove its module and then the driver for that companv2. controller willu<100//a>take over (at lower speed) all the devices that were previously handledu<101//a>by the EHCI driver.u<102//a>u<103v2a>Module parameters (pass to "modprobe") include:u<104//a>u<105//a>4< <106//a>4< <<<<<107//a>4< <<<<< is 0, indicating 1 microframe (125 usec). Maximum< u<108//a>4< <<<<<109//a>4< <<<<<1 v2a>u<111//a>If you're using this driver on a 2.5 kernel, and you've enabled USBu<112//a>debugging support, you'll see three files in the "sysfs" directory foru<113v2a>any EHCI controller:u<114//a>u<115//a>4< <<<<<"async" dumps the asynchronous schedule, used for controlu<116//a>4< <<<<<<<<<<<<<117//a>4< <<<<<<<<<<<<<118//a>4< <<<<<<<<<<<<<119//a>4< <<<<<"periodic" dumps the periodic schedule, used for interruptu<120//a>4< <<<<<<<<<<<<<121//a>4< <<<<<"registers" show controller register state, andu<122//a>u<123//a>The contents of those files ca. help identify driver problems.u<124//a>u<125v2a>u<126//a>Device drivers should.' care whether they're running over EHCI or not,u<127//a>but they may want to check for "usb_device->speed == USB_SPEED_HIGH".u<128//a>High speed devices ca. do things that full speed (or low speed) onesu<129//a>ca.' , such as "high bandwidth" periodic (interrupt or ISO) transfers.u<130v2a>Also, some s in device descriptors (such as polling intervals foru<131v2a>periodic transfers) use different encodings when operating at high speed.u<132//a>u<133v2a>However, do make a point of testing device drivers through USB 2.0 hubs.u<134//a>Those hubs report some failures, such as disconnectv2.s, differently whenu<135//a>transac v2. translators are i. use; some drivers have been seen to behaveu<136//a>badly when they see different faults tha. OHCI or UHCI report.u<137v2a>u<138v2a>u<139//a>PERFORMANCEu<14 v2a>u<141//a>USB 2.0 throughput is gated by two main factors: how fast the hostu<142//a>controller ca. process requests, and how fast devices ca. respond to <143v2a>them. The 480 Mbit/sec "raw transfer rate" is obeyed by all devices,u<144//a>but aggregate throughput is also affected by issues like delays betweenu<145//a>individual high speed packets, driver intelligence, and of course theu<146//a>overall system load. Latency is also a performance concern.u<147v2a>u<148v2a>Bulk transfers are most often used where throughput is a. issue. It'su<149//a>good to keep in mind that bulk transfers are always in 512 byte packets,u<150//a>and at most 13 of those fit into one USB 2.0 microframe. Eight USB 2.0u<151v2a>microframes fit in a USB 1.1 frame; a microframe is 1 msec/8 = 125 usec.u<152//a>u<153v2a>So more tha. 50 MByte/sec is available for bulk transfers, when bothu<154//a>hardware and device driver software allow it. Periodic transfer modesu<155v2a>(isochronous and interrupt) allow the larger packet sizes which let youu<156//a>approach the quoted 480 MBit/sec transfer rate.u<157v2a>u<158v2a>Hardware Performanceu<159//a>u<160//a>At this writing, individual USB 2.0 devices tend to max out at aroundu<161//a>20 MByte/sec transfer rates. This is of course subject to cha.ge;u<162//a>and some devices now go faster, while others go slower.u<163v2a>u<164//a>The first NEC implementa v2. of EHCI seems to have a hardware bottlenecku<165v2a>at around 28 MByte/sec aggregate transfer rate. While this is clearlyu<166//a>enough for a single device at 20 MByte/sec, putting three such devicesu<167//a>onto one bus does not get you 60 MByte/sec. The issue appears to beu<168v2a>that the controller hardware w2.' do concurrent USB and PCI access,u<169//a>so that it's only trying six (or maybe seven) USB transac v2.s eachu<170v2a>microframe rather than thirteen. (Seems like a reasonable trade 2ffu<171v2a>for a product that beat all the others to market by over a year!)u<172//a>u<173//a>It's expected that newer implementa v2.s will better this, throwingu<174//a>more silicon real estate at the problem so that new motherboard chipu<175v2a>sets will get closer to that 60 MByte/sec target. That includes anu<176//a>updated implementa v2. from NEC, as well as other vendors' silicon.u<177v2a>u<178//a>There's a minimum<179//a>to receive interrupts from the EHCI controller indicating completv2.u<180v2a>of requests. That latency is tunable; there's a module v2.. Byu<181//a>default ehci-hcd driver uses the minimum<182//a>you issue a control or bulk request you ca. often expect to learn thatu<183v2a>it completed in less tha. 250 usec (depending 2. transfer size).u<184//a>u<185v2a>Software Performanceu<186//a>u<187v2a>To get even 20 MByte/sec transfer rates, Linux-USB device drivers willu<188//a>need to keep the EHCI queue full. That means issuing large requests,u<189v2a>or using bulk queuing if a series of small requests needs to be issued.u<19 v2a>When drivers d2.' do that, their performance results will show it.u<191v2a>u<192//a>In typvcal situatv2.s, a<193v2a>going to waste more tha. half the USB 2.0 bandwidth. Delays between theu<194//a>I/O completv2. and the driver issuing the next request will take longeru<195//a>than the I/O. If that same loop used 16 KB chunks, it'd be better; au<196//a>sequence of 128 KB chunks would waste a lot less.u<197v2a>u<198v2a>But rather than depending 2. such large I/O buffers to make synchronousu<199v2a>I/O be efficient, it's better to just queue up several (bulk) requestsu<200//a>to the HC, and wait for them all to complete (or be canceled on>error).u<201v2a>Such URB queuing should work with all the USB 1.1 HC drivers too.u<202//a>u<203v2a>In the Linux 2.5 kernels, new usb_sg_*() api calls have been defined; theyu<204//a>queue all the buffers from a scatterlist. They also use scatterlist DMAu<205//a>mapping (which might apply an IOMMU) and IRQ reductv2., all of which willu<206//a>help make high speed transfers run as fast as they can.u<207v2a>u<208v2a>u<209//a>TBD: Interrupt and ISO transfer performance issues. Those periodicu<2 v2a>transfers are fully scheduled, so the main issue is likely to be howu<211//a>to trigger "high bandwidth" modes.u<212//a>u<213v2a>TBD: More tha. standard 80% periodic bandwidth alloca v2. is possvbleu<214//a>through sysfs uframe_periodic_max parameter. Describe that.u<215//a> The original LXR software by the LXR community//a>, this experimental versv2. by lxr@linux.no//a>. //div6./div class="subfooter"> lxr.linux.no kindly hosted by Redpill Linpro AS//a>, provider 2f Linux consulting and operati2.s services since 1995. //div6. //body6.//html6.