Extensible Host Controller Interface: Difference between revisions

Revision as of 12:33, 15 January 2020

Revision as of 17:33, 2 June 2020

Line 1:

{{short description|Computer interface specification}}

{{Redirect|XHCI|the radio station|XHCI-FM}}

{{short description|Computer interface specification}}

{{More footnotes|date=April 2014}}

'''eXtensible Host Controller Interface''' ('''xHCI''') is a computer interface specification that defines a register-level description of a host controller for [[Universal Serial Bus]] (USB), which is capable of interfacing with USB 1.x, 2.0, and 3.x compatible devices. The specification is also referred to as the [[USB 3.0]] host controller specification.

Line 26:

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 connector|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 reduces the need for periodic device polling by allowing a USB 3.0 or later device to notify the host controller when it has data available to read, and moves the management of polling USB 2.0 and 1.1 devices that use interrupt transactions from the CPU-driven USB driver to the USB host controller. EHCI, OHCI, and UHCI host controllers would automatically handle polling for the CPU if there are no changes that need to be made and if no device has any interrupts to send but they all rely on the CPU to set the schedule up for the controllers.<ref>{{cite web|url=ftp://ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf |title=UHCI11D.DOC |website=Ftp.netbsd.org |format=PDF |date= |accessdate=2017-01-09}}</ref><ref>{{cite web |url=http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/ehci-specification-for-usb.pdf |title=Archived copy |accessdate=2014-07-02 |url-status=dead |archiveurl=https://web.archive.org/web/20150810175253/http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/ehci-specification-for-usb.pdf |archivedate=2015-08-10 }} </ref><ref>[ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf] {{dead link|date=January 2017}}</ref> If any USB device using interrupt transactions does have data to send, then an xHCI host controller will send an interrupt to notify the CPU that there is a USB interrupt transaction that needs handling. Since the CPU no longer has to manage the polling of the USB bus, it can spend more time in low power states.

* The xHCI does not require 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.) resides in the software of the [[host controller | host-controller]] driver (HCD). Trying to apply the standard hardware IO virtualization technique - replicating I/O interface registers - to the legacy USB host controller interface is problematic because critical state that must be managed across [[virtual machine]]s (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:

* direct-Assignment of individual USB devices (irrespective of their ___location in the bus topology) to any VM

Line 76:

==== xHCI 1.0 ====

* ''xHCI 1.0'': First public release, May 21, 2010. <br />Specified USB data rates of ''1.5&nbsp;Mbit/s'' (''Low-speed''), ''12&nbsp;Mbit/s'' (''Full-speed''), ''480&nbsp;Mbit/s'' (''High-speed'') and ''5&nbsp;Gbit/s'' (''SuperSpeed'').

* ''xHCI 1.0, errata files 1-4'': Released inon January 17, 2011. <br />Incorporated initial review feedback from larger 1.0 public audience, Save-Restore clarifications, and Hardware LPM support.

* ''xHCI 1.0, errata files 1-6'': Released inon March 18, 2011. <br />Clarifications.

* ''xHCI 1.0, errata files 1-7'': Released inon June 13, 2011. <br />Clarifications.

==== xHCI 1.1 ====

Line 84:

==== xHCI 1.2 ====

* ''xHCI 1.2'': Dated May 2019. Specified USB 3.2 data rates of ''10&nbsp;Gbit/s'' (''SuperSpeedPlus Gen1x2'') and ''20&nbsp;Gbit/s'' (''SuperSpeedPlus Gen2x2'').<ref>https://www.intel.com/content/www/us/en/products/docs/io/universal-serial-bus/extensible-host-controler-interface-usb-xhci.html</ref>.

==References==