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