How to Map Ports for Add-in Host Controllers

This post has been republished via RSS; it originally appeared at: Microsoft USB Blog articles.

My name is Jane Lawrence, and in this blog post, Philip Ries and I will describe the details of the Busport-0048 Windows Logo Kit (WLK) requirement that has been in effect since Dec 1, 2010. The Busport-0048 requirement states “ xHCI add-in cards must map USB 3.0 and USB 2.0 ports consistently ”. The requirement targets manufacturers of USB xHCI add-in host controllers. An add-in host controller is a card that is not integrated onto the motherboard. In this blog post, we will describe a case study that includes two theoretical examples of the add-in controller designs (one approved and the other with the disallowed configuration).

The goal of the Busport-0048 requirement is for add-in host controllers to provide information to the USB driver stack about the ports available on the controller in a consistent way. Based on the information, the USB driver stack manages the ports appropriately. For systems with embedded controllers, there is a similar WLK requirement (Sysfund-226); however, the method for obtaining the information is different because integrated controllers use Advanced Configuration and Power Interface (ACPI) to define port mapping. The xHCI specification outlines an example of an embedded controller that uses ACPI information to communicate the port mapping. The example does not provide details about how that mapping should be reported by add-in controllers, which is the focus of our post.

Design Considerations for Add-in Host Controllers

If your add-in host controller does not contain an internal hub (integrated or embedded, defined in the xHCI specification), then you should follow the xHCI specification to map the ports. In certain scenarios, there might be a need to design add-in cards with hubs to allow for more external ports or as a way to support USB Low, Full and High Speed. . The Busport-0048 requirement describes an intuitive default mapping that allows internal hubs.  In the absence of ACPI, that mapping should be followed by hardware and assumed by software. ACPI is required for describing more complex port mapping such as:

• Multiple integrated hubs
• USB 2.0 embedded hubs
• Mixed-tier USB 2.0 ports
• USB 3.0 embedded hubs with their upstream ports connected to arbitrary root hub ports

The design to meet the Busport-0048 requirement becomes complex, if your add-in host controller implements integrated hubs, embedded hubs, or both. In those cases, consider the following:

• The host controller can have only one integrated hub.
• If there is an integrated hub, its root hub port must be the only USB 2.0 port on the root hub.
• Embedded hubs must be USB 3.0 hubs, and the two upstream ports of each embedded hub must connect to a single connector in the current mapping.

To begin mapping ports to connectors, provide a default mapping as follows for your reference:

• If there is no integrated hub, identify all the root hub ports as “External Ports”.
• If there is an integrated hub, identify all downstream ports except the integrated hub’s port as “External Ports”.
• Map ports that are labeled as “External Ports” to connectors temporarily ignoring any embedded hubs. (See xHCI specification, section 4.24.2.2)

Case Study: Configuration for Add-in Host Controllers

This case study describes the example outlined in Appendix D in the xHCI specification.

Figure 1: Disallowed Configuration for an Add-in Host Controller

The port mapping illustrated in Figure 1 violates the Busport-0048 requirement because of the following reasons:

• The USB 2.0 ports that are identified as “External Ports” are on multiple tiers. P1 is on a tier 1 hub and P2 is on a tier 2 hub.
• External ports must map to connectors in a way that the lowest USB 2.0 external port shares a connector with the lowest USB 3.0 external port, and so on. In the preceding illustration, notice that P1 does not share a connector with P6.
• Similarly, the embedded hub connects to an incorrect pair of ports (P4 and P6). The embedded hub must connect to ports, which in the absence of an embedded hub form a connector.

To avoid software malfunction, the port mappings (in the example) must be described in ACPI when the controller is embedded in the system.

The following diagram modifies the previous example and shows a valid port mapping.

Figure 2: Allowed Configuration for an Add-in Host Controller

In Figure 2, the port mappings meet the Busport-0048 requirement.

• The lowest numbered USB 2.0 port (P1) is paired with the lowest numbered USB 3.0 port (P6). The next lower ports are paired together (P2/P7) and connect to the embedded hub.
• All External Ports map to conceptual connectors. An additional layer called “Connector Mapping Before Embedded Hubs” shows the conceptual connectors, which may then connect either to an embedded hub, directly to an exposed connector, or to an embedded peripheral device (not used in this example). Notice that these conceptual connectors don’t actually exist in software or hardware.  They are a guideline to assist with pairing the right ports before connecting the embedded hub.

Another thing to point out is that the upstream ports of the embedded USB 3.0 hub should be marked as non-removable by setting a field in the hub descriptor of the integrated hub. For the USB 2.0 portion, set the DeviceRemovable field of the hub descriptor; for the USB 3.0 portion, set the DR field of the PORTSC register for HCP3.

The Windows Logo Kit team is updating the details of the Busport-0048 requirement to include the full design details for add-in host controllers with internal hubs. We encourage you to read the final requirement for additional information. In the meantime, we hope this post has provided more clarity about how to ensure that your design complies with the requirement.

Thanks for reading!

Jane Lawrence (USB WLK Program Manager) & Philip Ries (USB Developer)