Linux/Unix编程

开发平台：
Unix_Linux

ehci.txt：源码内容
							26-Apr-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
compatible with the USB 1.1 standard. It defines three transfer speeds:
    - "High Speed" 480 Mbit/sec (60 MByte/sec)
    - "Full Speed" 12 Mbit/sec (1.5 MByte/sec)
    - "Low Speed" 1.5 Mbit/sec
USB 1.1 only addressed full speed and low speed.  High speed devices
can be used on USB 1.1 systems, but they slow down to USB 1.1 speeds. 
USB 1.1 devices may also be used on USB 2.0 systems.  When plugged
into an EHCI controller, they are given to a USB 1.1 "companion"
controller, which is a OHCI or UHCI controller as normally used with
such devices.  When USB 1.1 devices plug into USB 2.0 hubs, they
interact with the EHCI controller through a "Transaction Translator"
(TT) in the hub, which turns low or full speed transactions into
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.
At this writing, high speed devices are finally beginning to appear.
While usb-storage devices have been available for some time (working
quite speedily on the 2.4 version of this driver), hubs have only
very recently become available.
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,
but those changes haven't needed to really change the basic "usbcore"
APIs exposed to USB device drivers.
- David Brownell
  <dbrownell@users.sourceforge.net>
FUNCTIONALITY
This driver is regularly tested on x86 hardware, and has also been
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.
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.
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
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.
The EHCI root hub code should hand 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.
There are some issues with power management; suspend/resume doesn't
behave quite right at the moment.
USE BY
Assuming you have an EHCI controller (on a PCI card or motherboard)
and have compiled this driver as a module, load this like:
    # modprobe ehci-hcd
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.
Module parameters (pass to "modprobe") include:
    log2_irq_thresh (default 0):
	Log2 of default interrupt delay, in microframes.  The default
	value is 0, indicating 1 microframe (125 usec).  Maximum value
	is 6, indicating 2^6 = 64 microframes.  This controls how often
	the EHCI controller can issue interrupts.
The EHCI interrupt handler just acknowledges interrupts and schedules
a tasklet to handle whatever needs handling.  That keeps latencies low,
no matter how often interrupts are issued.
Device drivers shouldn't care whether they're running over EHCI or not,
but they may want to check for "usb_device->speed == USB_SPEED_HIGH".
High speed devices can do things that full speed (or low speed) ones
can't, such as "high bandwidth" periodic (interrupt or ISO) transfers.
Also, some values in device descriptors (such as polling intervals for
periodic transfers) use different encodings when operating at high speed.
PERFORMANCE
USB 2.0 throughput is gated by two main factors:  how fast the host
controller can process requests, and how fast devices can respond to
them.  The 480 Mbit/sec "raw transfer rate" is obeyed by all devices,
but aggregate throughput is also affected by issues like delays between
individual high speed packets, driver intelligence, and of course the
overall system load.  Latency is also a performance concern.
Bulk transfers are most often used where throughput is an issue.  It's
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.
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
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
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.
There's a minimum latency of one microframe (125 usec) for the host
to receive interrupts from the EHCI controller indicating completion
of requests.  That latency is tunable; there's a module option.  By
default ehci-hcd driver uses the minimum latency, which means that if
you issue a control or bulk request you can often expect to learn that
it completed in less than 250 usec (depending on transfer size).
Software Performance
To get even 20 MByte/sec transfer rates, Linux-USB device drivers will
need to keep the EHCI queue full.  That means issuing large requests,
or using bulk queuing if a series of small requests needs to be issued.
When drivers don't do that, their performance results will show it.
In typical situations, a usb_bulk_msg() loop writing out 4 KB chunks is
going to waste more than half the USB 2.0 bandwidth.  Delays between the
I/O completion and the driver issuing the next request will take longer
than the I/O.  If that same loop used 16 KB chunks, it'd be better; a
sequence of 128 KB chunks would waste a lot less.
But rather than depending on such large I/O buffers to make synchronous
I/O be efficient, it's better to just queue all several (bulk) requests
to the HC, and wait for them all to complete (or be canceled on error).
Such URB queuing should work with all the USB 1.1 HC drivers too.
TBD:  Interrupt and ISO transfer performance issues.  Those periodic
transfers are fully scheduled, so the main issue is likely to be how
to trigger "high bandwidth" modes.

						