Download Usb Universal Host Controller Driver ((HOT))
Erminia Mckissack
USB (Universal Serial Bus) is a hardware and protocolspecification for interconnecting various devices to a hostcontroller. We supply a USB stack that implements the USBprotocol and allows user-written class drivers tocommunicate with USB devices.
Please note that USB, unlike other standards like VGA or PCI, is agnostic of the hardware interface to the system bus (and, by extension, to the operating system). Such an interface is provided by one or more USB host controllers and is defined by the appropriate documentation. Therefore, one should not expect this text to discuss specifics or code samples (e.g., as one finds in the wiki entries about VGA or PCI) detailing how the operating system initiates and maintains communication with USB devices. Although such information may be found on wiki entries discussing a particular Host Controller Driver, those wiki entries assume an understanding of the concepts and terms discussed here.
In designing USB 2.0, the USB-IF insisted on a single implementation. That single implementation is Intel's Enhanced Host Controller Interface (EHCI). However, even though the USB 2.0 specification requires that a USB 2.0 interface support USB 1.0 devices, this doesn't mean that the EHCI must support USB 1.0 devices, and in fact, it doesn't. Each EHCI host controller is accompanied by (usually several) UHCI and/or OHCI host controllers. When a USB 1.0 device is attached, the EHCI simply hands control over to a companion controller. Refer to figure 1 for a simple block diagram implementation of this behavior. Therefore, the system programmer must support all three standards in order to support USB 2.0.
The EHCI host controller only handles USB 1.0 devices if they are attached indirectly through a USB 2.0 hub. The specifics of handling USB 1.0 devices attached to a USB 2.0 hub are briefly discussed and illustrated in the hubs section, and in more detail in the wiki entry for USB Hubs. Note that some newer chipsets like the Intel 5-series chipsets do not have companion controllers at all and instead have internal "rate matching" hubs that all USB devices go through.
Like its predecessor USB 2.0, USB 3.0 has only one host controller specification: Intel's eXtensible Host Controller Interface. Unlike its predecessor EHCI, however, xHCI controllers can and do interface with USB 1.0 and 2.0 devices without the use of companion controllers. Even on early hardware where there was both an EHCI and xHCI controller included (so that OSes which did not yet support xHCI could still use at least some USB devices), ports attached to the EHCI controller could generally be "re-routed" to the xHCI controller, and the EHCI controller disabled entirely.
Also unlike its predecessors, xHCI was designed with some degree of forwards compatibility, so that revisions to the USB specification can be made without designing a new host controller interface (for instance, USB 3.1 and 3.2 add new speeds, with only minor updates to the specification to match them.) Unfortunately, this means that xHCI bears only a passing resemblance to the controllers that came before it, and make it challenging to write drivers for.
The USB is a polled bus, meaning the host controller must initiate all transfers. Do not mistake this to mean that the system software must poll the USB. The host controller takes care of polling the bus and can be programmed to issue interrupts to the OS whenever the bus needs attention.
But what happens when a full- or low-speed device is connected to the high-speed hub in figure 5? If the EHCI controller were to relinquish ownership of the port, the high-speed devices will no longer be able to operate at high-speed, if at all, as in figure 6. Instead, the host controller and the hub support a special type of transaction called a split transaction. A split transaction involves only the host controller and a high-speed hub; it is transparent to any devices. This scheme of using split-transaction to support low- and full-speed devices on a high-speed hub is illustrated in figure 7.
A USB system contains only one USB host. The host interfaces with the USB interconnect via a host controller. The host includes an embedded hub called the root hub which provides one or more attachment points, or ports.
The host controller gives bulk data transfers low priority; they are generally only processed when bandwidth is available, however software may not assume that a control transfer will be processed before a bulk transfer. If multiple bulk transfers are pending, the host controller may begin moving bulk transfers over the bus according to an implementation-dependent policy. The system software may vary the bus time made available for a bulk transfer to a specific endpoint.
Frames and microframes are mostly a physical-layer detail and should not be confused with any of the previous concepts. Frames and microframes do not correspond to any packet or transaction; in fact, several transactions usually take place during one (micro)frame. The host controller issues a start-of-frame (SOF) packet at the beginning of every (micro)frame. The remainder of the (micro)frame is available for the host controller to carry out transactions. A transaction may not take place if it cannot be completed in the same (micro)frame (because otherwise the next SOF packet would interrupt the transaction).
It is important to realize that the host controller may rearrange transactions to make better use of the available bandwidth. Of course, two transactions through the same pipe must occur in the correct order, but the transactions of two separate transfers may be reordered at the host controller's discretion. Consider a pending bulk transfer and two pending control transfers. The host could potentially reorder the transfers on the bus as in Figure 11.
The host controller never retries a transaction with an isochronous endpoint. If a transaction with a high-speed, high-bandwidth interrupt endpoint fails, the host controller may retry the transaction during the same (micro)frame if the maximum number of transactions per (micro)frame has not been reached. Otherwise, the transaction is retried at the next period.
Asynchronous source endpoints imply their data rate by the number of samples produced per (micro)frame. Asynchronous sink endpoints must provide explicit feedback to the source endpoint. When the source endpoint is the host, it is the responsibility of the device driver to process the explicit feedback properly. This feedback allows the host and device to make slight adjustments to the data rate in order to compensate for any clock drift.
The address field is 7 bits wide and illustrated below. Each possible value may only indicate a single function. Address zero is reserved as the default address and cannot be assigned to any function. All functions must respond to the default address upon reset and power-up until the host assigns the function a specific address. Therefore, one host controller can support up to 127 devices at one time.
Isochronous transfers are the only type of transfers whose transactions do not have a handshake phase. Isochronous transfers should only use DATA0 PIDs, however the host controller must support DATA1 PIDs as well, even though isochronous transfers do not use a data synchronization bit mechanism.
The USB device framework is the thing that makes USB support so appealing. The transfer types and USB protocol are well-designed, of course, but the USB device framework defines standard device states that all devices must support, as well as standard requests and responses that allow the host to retrieve more than enough information about a device to determine the correct device driver and report information about the device even if the correct device driver isn't available (e.g, the manufacturer's name, the product's name, etc).
As a request for a data transfer moves from the device driver, through the USB Driver, and through the USB Hub Driver, the request gains all the information needed for the host controller to generate the appropriate transactions on the bus. However, depending on the host controller, this information needs to be formatted in a certain way and added for scheduling by the host controller.
Additionally, host controller drivers are loaded by the PCI subsystem when a corresponding host controller is discovered during PCI enumeration. The host controller driver is thus also responsible for initializing the host controller and perhaps loading the USB Hub Driver and the USB driver. Combined, the USB driver, USB hub driver, and the host controller driver make up a USB subsystem.
df19127ead