Extensible Host Controller Interface: Difference between revisions

Revision as of 05:08, 20 December 2011

Revision as of 21:47, 11 January 2012

Line 17:

* The xHCI architecture was designed to support all USB speeds, including SuperSpeed (5 Gb/s) and future speeds, under a single driver stack.

=== Power Efficiency ===

When USB was originally developed in 1995, it was targeted at desktop platforms to stem the proliferation of connectors that were appearing on PCs, e.g. PS-2, Serial Port, Parallel Port, Game Port, etc., and host power consumption was not an important consideration at the time. Since then, mobile platforms have become the platform of choice, and their batteries have made power consumption a key consideration. The architectures of the legacy USB host controllers (OHCI, UHCI, and EHCI) were very similar in that the “schedule” for the transactions to be performed on the USB were built by software in host memory, and the host controller hardware would continuously read the schedules to determine what transactions needed to be driven on the USB, and when, even if no data was moved. Additionally, in the case of reads from the device, the device was polled each schedule interval, even if there was no data to read.

* The xHCI eliminates host memory based USB transaction schedules, enabling zero host memory activity when there is no USB data movement.

* The xHCI eliminates the periodic device polling for reads by requiring the device notify the host controller when it has data available to read.

* The xHCI alsodoes not requires that implementations provide support for all advanced USB 2 and 3 power management features, including USB 2 LPM, USB 3 U1 and U2 states, HERD, LTM, Function Wake, etc. But these features are required to realize all of the advantages of xHCI.

=== Virtualization Support ===

Legacy USB host controller architectures exhibit some serious shortcomings when applied to virtualized environments. Legacy USB host controller interfaces define a relatively simple hardware data pump; where critical state related to overall bus management (Bandwidth allocation, Address assignment, etc.) reside in the software of the host controller driver. Trying to apply the standard hardware IO virtualization technique, of replicating IO interface registers, to the legacy USB host controller interface is problematic because critical state that must be managed across Virtual Machines (VMs) is not available to hardware. The xHCI architecture moves the control of this critical state into hardware, enabling USB resource management across VMs. The xHCI virtualization features also provide for: