Commit a3160899 authored by David Brownell's avatar David Brownell Committed by Greg Kroah-Hartman

[PATCH] Documentation/usb/{o,u}hci.txt

This updates the EHCI and OHCI writeups.  OHCI hadn't been
updated forever.
parent 1ca9a28a
26-Apr-2002
23-Aug-2002
The EHCI driver is used to talk to high speed USB 2.0 devices using
USB 2.0-capable host controller hardware. The USB 2.0 standard is
......@@ -21,11 +21,15 @@ high speed "split transactions" that don't waste transfer bandwidth.
At this writing, this driver has been seen to work with implementations
of EHCI from (in alphabetical order): Intel, NEC, Philips, and VIA.
Other EHCI implementations are becoming available from other vendors;
you should expect this driver to work with them too.
At this writing, high speed devices are finally beginning to appear.
While usb-storage devices have been available for some time (working
While usb-storage devices have been available since mid-2001 (working
quite speedily on the 2.4 version of this driver), hubs have only
very recently become available.
been available since late 2001, and other kinds of high speed devices
appear to be on hold until more systems come with USB 2.0 built-in.
Such new systems have been available since early 2002, and became much
more typical in the second half of 2002.
Note that USB 2.0 support involves more than just EHCI. It requires
other changes to the Linux-USB core APIs, including the hub driver,
......@@ -43,26 +47,25 @@ used on PPC hardware so big/little endianness issues should be gone.
It's believed to do all the right PCI magic so that I/O works even on
systems with interesting DMA mapping issues.
At this writing the driver should comfortably handle all control and bulk
transfers, including requests to USB 1.1 devices through transaction
translators (TTs) in USB 2.0 hubs. However, there some situations where
the hub driver needs to clear TT error state, which it doesn't yet do.
At this writing the driver should comfortably handle all control, bulk,
and interrupt transfers, including requests to USB 1.1 devices through
transaction translators (TTs) in USB 2.0 hubs.
Interrupt transfer support is newly functional and not yet as robust as
control and bulk traffic. As yet there is no support for split transaction
scheduling for interrupt transfers, which means among other things that
connecting USB 1.1 hubs, keyboards, and mice to USB 2.0 hubs won't work.
Connect them to USB 1.1 hubs, or to a root hub.
High Speed Isochronous (ISO) transfer support is also functional, but
at this writing no Linux drivers have been using that support.
Isochronous (ISO) transfer support is also newly functional. No production
high speed devices are available which would need it (though high quality
webcams are in the works!). Note that split transaction support for ISO
Full Speed Isochronous transfer support, through transaction translators,
is not yet available. Note that split transaction support for ISO
transfers can't share much code with the code for high speed ISO transfers,
since EHCI represents these with a different data structure. So for now,
most USB audio and video devices have the same restrictions as hubs, mice,
and keyboards: don't connect them using high speed USB hubs.
most USB audio and video devices can't be connected to high speed buses.
The EHCI root hub code should hand off USB 1.1 devices to its companion
Transfers of all types can be queued. This means that control transfers
from a driver on one interface (or through usbfs) won't interfere with
ones from another driver, and that interrupt transfers can use periods
of one frame without risking data loss due to interrupt processing costs.
The EHCI root hub code hands off USB 1.1 devices to its companion
controller. This driver doesn't need to know anything about those
drivers; a OHCI or UHCI driver that works already doesn't need to change
just because the EHCI driver is also present.
......@@ -70,6 +73,11 @@ just because the EHCI driver is also present.
There are some issues with power management; suspend/resume doesn't
behave quite right at the moment.
Also, some shortcuts have been taken with the scheduling periodic
transactions (interrupt and isochronous transfers). These place some
limits on the number of periodic transactions that can be scheduled,
and prevent use of polling intervals of less than one frame.
USE BY
......@@ -83,10 +91,10 @@ and remove it by:
# rmmod ehci-hcd
You should also have a driver for a "companion controller", such as
"ohci-hcd", "usb-ohci", "usb-uhci", or "uhci". In case of any trouble
with the EHCI driver, remove its module and then the driver for that
companion controller will take over (at lower speed) all the devices
that were previously handled by the EHCI driver.
"ohci-hcd" or "uhci-hcd". In case of any trouble with the EHCI driver,
remove its module and then the driver for that companion controller will
take over (at lower speed) all the devices that were previously handled
by the EHCI driver.
Module parameters (pass to "modprobe") include:
......@@ -122,13 +130,18 @@ good to keep in mind that bulk transfers are always in 512 byte packets,
and at most 13 of those fit into one USB 2.0 microframe. Eight USB 2.0
microframes fit in a USB 1.1 frame; a microframe is 1 msec/8 = 125 usec.
So more than 50 MByte/sec is available for bulk transfers, when both
hardware and device driver software allow it. Periodic transfer modes
(isochronous and interrupt) allow the larger packet sizes which let you
approach the quoted 480 MBit/sec transfer rate.
Hardware Performance
At this writing, individual USB 2.0 devices tend to max out at around
20 MByte/sec transfer rates. This is of course subject to change;
and some devices now go faster, while others go slower.
The NEC implementation of EHCI seems to have a hardware bottleneck
The first NEC implementation of EHCI seems to have a hardware bottleneck
at around 28 MByte/sec aggregate transfer rate. While this is clearly
enough for a single device at 20 MByte/sec, putting three such devices
onto one bus does not get you 60 MByte/sec. The issue appears to be
......@@ -136,9 +149,11 @@ that the controller hardware won't do concurrent USB and PCI access,
so that it's only trying six (or maybe seven) USB transactions each
microframe rather than thirteen. (Seems like a reasonable trade off
for a product that beat all the others to market by over a year!)
It's expected that newer implementations will better this, throwing
more silicon real estate at the problem so that new motherboard chip
sets will get closer to that 60 MByte/sec target.
sets will get closer to that 60 MByte/sec target. That includes an
updated implementation from NEC, as well as other vendors' silicon.
There's a minimum latency of one microframe (125 usec) for the host
to receive interrupts from the EHCI controller indicating completion
......
The OHCI HCD layer is a simple but nearly complete implementation of what the
USB people would call a HCD for the OHCI.
(ISO coming soon, Bulk, INT u. CTRL transfers enabled)
It is based on Linus Torvalds UHCI code and Gregory Smith OHCI fragments (0.03 source tree).
The layer (functions) on top of it, is for interfacing to the alternate-usb device-drivers.
- Roman Weissgaerber <weissg@vienna.at>
* v4.0 1999/08/18 removed all dummy eds, unlink unused eds, code cleanup, bulk transfers
* v2.1 1999/05/09 ep_addr correction, code cleanup
* v0.2.0 1999/05/04
* everything has been moved into 2 files (ohci-hcd.c, ohci-hub-root.c and headers)
* virtual root hub is now an option,
* memory allocation based on kmalloc and kfree now, simple Bus error handling,
* INT and CTRL transfers enabled, Bulk included but disabled, ISO needs completion
*
* from Linus Torvalds (uhci.c): APM (not tested); hub, usb_device, bus and related stuff
* from Greg Smith (ohci.c): better reset ohci-controller handling, hub
*
* v0.1.0 1999/04/27 initial release
to remove the module try:
rmmod usb-ohci
Features:
- virtual root hub, all basic hub descriptors and commands (state: complete)
this is an option now (v0.2.0)
#define CONFIG_USB_OHCI_VROOTHUB includes the virtual hub code, (VROOTHUB)
default is with.
(at the moment: the Virtual Root Hub is included automatically)
files: ohci-root-hub.c, ohci-root-hub.h
- Endpoint Descriptor (ED) handling more static approach
(EDs should be allocated in parallel to the SET CONFIGURATION command and they live
as long as the function (device) is alive or another configuration is chosen.
In the HCD layer the EDs has to be allocated manually either by calling a subroutine
or by sending a USB root hub vendor specific command to the virtual root hub.
At the alternate linux usb stack EDs will be added (allocated) at their first use.
ED will be unlinked from the HC chains if they are not busy.
files: ohci-hcd.c ohci-hcd.h
routines: (do not use for drivers, use the top layer alternate usb commands instead)
int usb_ohci_add_ep(struct ohci * ohci, unsigned int ep_addr1,
int interval, int load, f_handler handler, int ep_size, int speed)
adds an endpoint, (if the endpoint already exists some parameters will be updated)
int usb_ohci_rm_ep( )
removes an endpoint and all pending TDs of that EP
usb_ohci_rm_function( )
removes all Endpoints of a function (device)
- Transfer Descriptors (TD): handling and allocation of TDs is transparent to the upper layers
The HCD takes care of TDs and EDs memory allocation whereas the upper layers (UBSD ...) has
to take care of buffer allocation.
files: ohci-hcd.c ohci-hcd.h
There is one basic command for all types of bus transfers (INT, BULK, ISO, CTRL):
int ohci_trans_req(struct ohci * ohci, hcd_ed, int ctrl_len, void *ctrl, void * data, int data_len, __OHCI_BAG lw0, __OHCI_BAG lw1)
CTRL: ctrl, ctrl_len ... cmd buffer
data, data_len ... data buffer (in or out)
INT, BULK: ctrl = NULL, ctrl_len=0,
data, data_len ... data buffer (in or out)
ISO: tbd
There is no buffer reinsertion done by the internal HCD function.
(The interface layer does this for a INT-pipe on request.)
If you want a transfer then you have to
provide buffers by sending ohci_trans_req requests. As they are queued as TDs on an ED
you can send as many as you like. They should come back by the callback f_handler in
the same order (for each endpoint, not globally) If an error occurs all
queued transfers of an endpoint will return unsent. They will be marked with an error status.
e.g double-buffering for int transfers:
ohci_trans_req(ohci, ep_addr, 0, NULL, data0, data0_len, 0,0)
ohci_trans_req(ohci, ep_addr, 0, NULL, data1, data1_len, 0,0)
and when a data0 packet returns by the callback f_handler requeue it:
ohci_trans_req(ohci, ep_addr, 0, NULL, data0, data0_len, 0,0)
and when a data1 packet returns by the callback f_handler requeue it:
ohci_trans_req(ohci, ep_addr, 0, NULL, data1, data1_len, 0,0)
lw0, lw1 are private fields for upper layers for ids or fine grained handlers.
The alternate usb uses them for dev_id and usb_device_irq handler.
- Done list handling: returns the requests (callback f_handler in ED) and does
some error handling, root-hub request dequeuing
(files: ohci-done-list.c in ohci-hcd.c now(v0.2.0))
23-Aug-2002
The "ohci-hcd" driver is a USB Host Controller Driver (HCD) that is derived
from the "usb-ohci" driver from the 2.4 kernel series. The "usb-ohci" code
was written primarily by Roman Weissgaerber <weissg@vienna.at> but with
contributions from many others (read its copyright/licencing header).
It supports the "Open Host Controller Interface" (OHCI), which standardizes
hardware register protocols used to talk to USB 1.1 host controllers. As
compared to the earlier "Universal Host Controller Interface" (UHCI) from
Intel, it pushes more intelligence into the hardware. USB 1.1 controllers
from vendors other than Intel and VIA generally use OHCI.
Changes since the 2.4 kernel include
- improved robustness; bugfixes; and less overhead
- supports the updated and simplified usbcore APIs
- interrupt transfers can be larger, and can be queued
- less code, by using the upper level "hcd" framework
- supports some non-PCI implementations of OHCI
- ... more
The "ohci-hcd" driver handles all USB 1.1 transfer types. Transfers of all
types can be queued. That was also true in "usb-ohci", except for interrupt
transfers. Previously, using periods of one frame would risk data loss due
to overhead in IRQ processing. When interrupt transfers are queued, those
risks can be minimized by making sure the hardware always has transfers to
work on while the OS is getting around to the relevant IRQ processing.
- David Brownell
<dbrownell@users.sourceforge.net>
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment