Lines Matching +full:early +full:- +full:to +full:- +full:mid
5 27-Dec-2002
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
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
16 can be used on USB 1.1 systems, but they slow down to USB 1.1 speeds.
19 into an EHCI controller, they are given to a USB 1.1 "companion"
26 At this writing, this driver has been seen to work with implementations
29 you should expect this driver to work with them too.
31 While usb-storage devices have been available since mid-2001 (working
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
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.
43 - David Brownell
52 It's believed to do all the right PCI magic so that I/O works even on
56 --------------
59 and interrupt transfers, including requests to USB 1.1 devices through
69 most USB audio and video devices can't be connected to high speed buses.
72 ---------------
77 of one frame without risking data loss due to interrupt processing costs.
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
99 # modprobe ehci-hcd
103 # rmmod ehci-hcd
106 "ohci-hcd" or "uhci-hcd". In case of any trouble with the EHCI driver,
111 Module parameters (pass to "modprobe") include:
127 usb-storage doing disk I/O; watch the request queues!)
138 but they may want to check for "usb_device->speed == USB_SPEED_HIGH".
146 transaction translators are in use; some drivers have been seen to behave
154 controller can process requests, and how fast devices can respond to
161 good to keep in mind that bulk transfers are always in 512 byte packets,
171 --------------------
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;
177 The first NEC implementation of EHCI seems to have a hardware bottleneck
180 onto one bus does not get you 60 MByte/sec. The issue appears to be
184 for a product that beat all the others to market by over a year!)
188 sets will get closer to that 60 MByte/sec target. That includes an
192 to receive interrupts from the EHCI controller indicating completion
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
199 --------------------
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.
207 going to waste more than half the USB 2.0 bandwidth. Delays between the
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).
225 transfers are fully scheduled, so the main issue is likely to be how
226 to trigger "high bandwidth" modes.