On Wed, 25 May 2011, Sarah Sharp wrote: > The Intel Panther Point chipsets contain an EHCI and xHCI host controller > that shares some number of skew-dependent ports. These ports can be > switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX > that is controlled by registers in the xHCI PCI configuration space. The > USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled > separately from the USB 2.0 data wires. > > This switchover mechanism is there to support users who do a custom > install of certain non-Linux operating systems that don't have official > USB 3.0 support. By default, the ports are under EHCI, SuperSpeed > terminations are off, and USB 3.0 devices will show up under the EHCI > controller at reduced speeds. (This was more palatable for the marketing > folks than having completely dead USB 3.0 ports if no xHCI drivers are > available.) Users should be able to turn on xHCI by default through a > BIOS option, but users are happiest when they don't have to change random > BIOS settings. > > This patch introduces a driver method to switchover the ports from EHCI to > xHCI before the EHCI driver finishes PCI enumeration. We want to switch > the ports over before the USB core has the chance to enumerate devices > under EHCI, or boot from USB mass storage will fail if the boot device > connects under EHCI first, and then gets disconnected when the port > switches over to xHCI. > > Originally, I had hoped I could do the port switchover in the xHCI driver. > Unfortunately, I can't guarantee that the xHCI driver is loaded before the > EHCI driver, because the two hosts are on different PCI slots. (The EHCI > and UHCI/OHCI driver load issue is solved because the EHCI host is the > highest numbered function on the same PCI slot as the companion > controller, and Linux always enumerates the highest function first.) I > looked at making the EHCI driver wait for the xHCI driver through some > sort of semaphore in the USB core, but that fell apart when I started to > consider failed xHCI PCI probes and the fact that you can't rely on the > return value of request_module() to ensure xHCI driver load. > > Instead, the solution I came up was to make the EHCI driver switch over > the ports in its PCI probe function. It's not pretty, since the EHCI > driver has to search for the xHCI PCI device and then write into its > PCI configuration space, but I think it's the simplest solution. Logically, the right place to do this is in pci-quirks.c. Add whatever you need to quirk_usb_handoff_xhci(). That's where the interaction with the BIOS settings takes place already. > This patch also introduces a module parameter that allows users to choose > which ports they want to switch over, so that if a distro chooses to > blacklist the xHCI driver, they can load the EHCI driver with the port > switchover mask set to zero. A sysfs interface to switchover the ports on > demand might be a good idea, but I'm not sure if we want to expose that to > users, who may try to switchover active mass storage devices in the middle > of transfers. I don't think on-demand switching would be very useful. The port switchover mask could be implemented as a kernel parameter (and mentioned in Documentation/kernel-parameters.txt). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
