Extensible Host Controller Interface: Difference between revisions

Content deleted Content added
Power efficiency: - small typo
Simplified driver architecture: Why would a high-speed device be routed to UHCI or OHCI unless EHCI was not present? Also, USB 1.x devices are automatically considered USB 2 devices.
Line 34:
 
=== Simplified driver architecture ===
The EHCI utilizes OHCI or UHCI controllers as “companion controllers”, where USB 2 devices are managed through the EHCI stack, and the port logic of the EHCI allows a USB 1low-speed or 2full-speed USB device to be routed to a port of a “companion” UHCI or OHCI controller, where the USBlow-speed 1or andfull-speed 2USB devices are managed through the respective UHCI or OHCI stack. For example, a USB 2 PCIe host controller card that presents 4 USB “Standard A” connectors typically presents one 4-port EHCI and two 2-port OHCI controllers to system software. When a USBhigh-speed 2USB device is attached to any of the 4 connectors, the device is managed through one of the 4 root hub ports of the EHCI controller. If a USBlow-speed 1or full-speed USB device is attached to connectors 1 or 2, theyit will be routed to the root hub ports of one of the OHCI controllers for management, and USBlow-speed 1and full-speed USB devices attached to connectors 3 or 4 will be routed to the root hub ports of the other OHCI controller. The EHCI dependence on separate host controllers for high-speed USB 1devices and 2the group of low-speed and full-speed USB devices results in complex interactions and dependencies between the EHCI and OHCI/UHCI drivers.
* The xHCI architecture eliminates the need for companion controllers and their separate driver stacks.
* The incorporation of the schedule, bandwidth management, and USB device address assignment functions, that were previously performed by the driver in to the xHCI hardware enable a simpler, leaner, lower latency software stack for the xHCI.