XHCI: set up HC to pass over ports to EHCI/UHCI/OHCI

[erdmann]

Hallo,
according to:
http://blogs.msdn.com/b/usbcoreblog/archive/2010/09/23/reasons-to-avoid-companion-controllers.aspx

there are 2 ways for HW designers to offer USB 1.x/USB 2.0 support on "USB3.0 ports".

Suppose I want to add support to an OS that does not yet have XHCI support. As a first step I only want to set up the XHCI controller so that it hands over any "USB3.0 ports" so that USB 1.x/USB 2.0 devices are supported via either the corresponding companion controller(s) (EHCI and subsequently UHCI/OHCI, first picture) or where necessary via port handoff in case of the "mixed port solution" (second picture) when they are plugged into such a "USB 3.0 port".

What would I have to do ? How do I have to set the XHCI HC's operational registers/port registers ?
The XHCI spec is unfortunately not very specfic on how to achieve this.

Thanks to any help.

[Barry Twycross]

The XHCI spec says nothing about this as its nothing to do with XHCI.

This depends entirely on your chipset or your board implementation. You need to check the documentation for the system to work out how to switch the multiplexor ("mux") to switch the ports over.

When the port is switched to the companion controller, the XHCI just doesn't see anything plugged into it, so the XHCI is irrelevant at this point.

In the systems I've worked on, the chipset implemented a mux on some ports, and there were PCI config space writes needed to switch them from one controller to the other. The chipset didn't have muxes on some of the other ports, so there was an external mux layed down on the board, that was controlled by GPIOs. Neither of these muxes really had anything to do with the XHCI, so they would properly be handled by the chipset or board init functions.

[erdmann]

Thanks for the answer. That does not sound like there would be a universal solution ...

OK, it has nothing to do with XHCI but the EHCI spec had Information on how to hand over ports to the companion UHCI/OHCI Controller, either globally for all ports or per port. That's why I thought I would also find that info in the XHCI spec.

With Windows7, the "USB 3.0 ports" on my system are not usuable with USB 2.0 / USB 1.x devices at all.
Guess they are not set up on System init to operate via the companion Controller ...
I'll try to find the chipset spec ...

[Barry Twycross]

EHCI was designed to run with companion controllers from the start. An EHCI controller was supplied with companion controllers, as EHCI never had the capability to do full or low speed. So the mux ability was built into the EHCI spec.

XHCI was designed as a standalone 4 speed controller from the start. I'm surprised the article (written 3 years after USB 3 came out) even mentioned the concept of companion controllers. There was never any hint I saw anywhere that this was an acceptable solution.

I thought the implementation I worked on was quite oddball, and no one else had ever done something similar. The one I worked on only used the companion controller because of concerns over the limited number of devices the first generation XHCI controller could support. The architecture was abandoned with the second generation which could support more devices.

The chipset vendors would include EHCI controller for use with legacy OSs which didn't have an XHCI controller. When booting a legacy OS, the chipset init routines would mux to the EHCI controller, when booting a modern OS (with XHCI driver), the chipset init routines could mux to the XHCI (or leave it to the first stage init of the modern OS).

It sounds like Windows 7 is a legacy OS in this case, I think it was only Win 8 which had XHCI support. There maybe some BIOS setting somewhere which would give Win 7 the ports as EHCI. That is if the chipset even supports it.