aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/host/ehci-pci.c
diff options
context:
space:
mode:
authorSarah Sharp <sarah.a.sharp@linux.intel.com>2011-02-22 12:57:15 -0500
committerSarah Sharp <sarah.a.sharp@linux.intel.com>2011-05-27 15:07:36 -0400
commit69e848c2090aebba5698a1620604c7dccb448684 (patch)
treec39dd3d0e30a9f6eb3c332c03eeeb6d5a2ff098c /drivers/usb/host/ehci-pci.c
parent7fe4fc881d1340f17396f52c836e597dadadea42 (diff)
Intel xhci: Support EHCI/xHCI port switching.
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. Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI. The PCI quirks code will run before any other PCI probe function is called, so this avoids the issue with boot devices. Another issue is with BIOS behavior during system resume from hibernate. If the BIOS doesn't support xHCI, it may switch the devices under EHCI to allow use of the USB keyboard, mice, and mass storage devices. It's supposed to remember the value of the port routing registers and switch them back when the OS attempts to take control of the xHCI host controller, but we all know not to trust BIOS writers. Make both the xHCI driver and the EHCI driver attempt to switchover the ports in their PCI resume functions. We can't guarantee which PCI device will be resumed first, so this avoids any race conditions. Writing a '1' to an already set port switchover bit or a '0' to a cleared port switchover bit should have no effect. The xHCI PCI configuration registers will be documented in the EDS-level chipset spec, which is not public yet. I have permission from legal and the Intel chipset group to release this patch early to allow good Linux support at product launch. I've tried to document the registers as much as possible, so please let me know if anything is unclear. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Diffstat (limited to 'drivers/usb/host/ehci-pci.c')
-rw-r--r--drivers/usb/host/ehci-pci.c39
1 files changed, 39 insertions, 0 deletions
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 660b80a75cac..1102ce65a3a9 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -348,11 +348,50 @@ static int ehci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup)
348 return rc; 348 return rc;
349} 349}
350 350
351static bool usb_is_intel_switchable_ehci(struct pci_dev *pdev)
352{
353 return pdev->class == PCI_CLASS_SERIAL_USB_EHCI &&
354 pdev->vendor == PCI_VENDOR_ID_INTEL &&
355 pdev->device == 0x1E26;
356}
357
358static void ehci_enable_xhci_companion(void)
359{
360 struct pci_dev *companion = NULL;
361
362 /* The xHCI and EHCI controllers are not on the same PCI slot */
363 for_each_pci_dev(companion) {
364 if (!usb_is_intel_switchable_xhci(companion))
365 continue;
366 usb_enable_xhci_ports(companion);
367 return;
368 }
369}
370
351static int ehci_pci_resume(struct usb_hcd *hcd, bool hibernated) 371static int ehci_pci_resume(struct usb_hcd *hcd, bool hibernated)
352{ 372{
353 struct ehci_hcd *ehci = hcd_to_ehci(hcd); 373 struct ehci_hcd *ehci = hcd_to_ehci(hcd);
354 struct pci_dev *pdev = to_pci_dev(hcd->self.controller); 374 struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
355 375
376 /* The BIOS on systems with the Intel Panther Point chipset may or may
377 * not support xHCI natively. That means that during system resume, it
378 * may switch the ports back to EHCI so that users can use their
379 * keyboard to select a kernel from GRUB after resume from hibernate.
380 *
381 * The BIOS is supposed to remember whether the OS had xHCI ports
382 * enabled before resume, and switch the ports back to xHCI when the
383 * BIOS/OS semaphore is written, but we all know we can't trust BIOS
384 * writers.
385 *
386 * Unconditionally switch the ports back to xHCI after a system resume.
387 * We can't tell whether the EHCI or xHCI controller will be resumed
388 * first, so we have to do the port switchover in both drivers. Writing
389 * a '1' to the port switchover registers should have no effect if the
390 * port was already switched over.
391 */
392 if (usb_is_intel_switchable_ehci(pdev))
393 ehci_enable_xhci_companion();
394
356 // maybe restore FLADJ 395 // maybe restore FLADJ
357 396
358 if (time_before(jiffies, ehci->next_statechange)) 397 if (time_before(jiffies, ehci->next_statechange))