About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / usb / ehci.txt

Custom Search

Based on kernel version 4.16.1. Page generated on 2018-04-09 11:53 EST.

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

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.