2005-09-24 00:14:37 +00:00
|
|
|
/*
|
|
|
|
* This file contains code to reset and initialize USB host controllers.
|
|
|
|
* Some of it includes work-arounds for PCI hardware and BIOS quirks.
|
|
|
|
* It may need to run early during booting -- before USB would normally
|
|
|
|
* initialize -- to ensure that Linux doesn't use any legacy modes.
|
|
|
|
*
|
|
|
|
* Copyright (c) 1999 Martin Mares <mj@ucw.cz>
|
|
|
|
* (and others)
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
2012-04-16 17:56:47 +00:00
|
|
|
#include <linux/kconfig.h>
|
2005-09-24 00:14:37 +00:00
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <linux/delay.h>
|
2011-05-27 13:56:31 +00:00
|
|
|
#include <linux/export.h>
|
2005-09-24 00:14:37 +00:00
|
|
|
#include <linux/acpi.h>
|
2011-05-11 22:52:38 +00:00
|
|
|
#include <linux/dmi.h>
|
2006-03-25 17:01:53 +00:00
|
|
|
#include "pci-quirks.h"
|
2009-04-28 02:52:28 +00:00
|
|
|
#include "xhci-ext-caps.h"
|
2005-09-24 00:14:37 +00:00
|
|
|
|
|
|
|
|
|
|
|
#define UHCI_USBLEGSUP 0xc0 /* legacy support */
|
|
|
|
#define UHCI_USBCMD 0 /* command register */
|
|
|
|
#define UHCI_USBINTR 4 /* interrupt register */
|
2005-10-03 20:36:29 +00:00
|
|
|
#define UHCI_USBLEGSUP_RWC 0x8f00 /* the R/WC bits */
|
|
|
|
#define UHCI_USBLEGSUP_RO 0x5040 /* R/O and reserved bits */
|
|
|
|
#define UHCI_USBCMD_RUN 0x0001 /* RUN/STOP bit */
|
|
|
|
#define UHCI_USBCMD_HCRESET 0x0002 /* Host Controller reset */
|
|
|
|
#define UHCI_USBCMD_EGSM 0x0008 /* Global Suspend Mode */
|
|
|
|
#define UHCI_USBCMD_CONFIGURE 0x0040 /* Config Flag */
|
|
|
|
#define UHCI_USBINTR_RESUME 0x0002 /* Resume interrupt enable */
|
2005-09-24 00:14:37 +00:00
|
|
|
|
|
|
|
#define OHCI_CONTROL 0x04
|
|
|
|
#define OHCI_CMDSTATUS 0x08
|
|
|
|
#define OHCI_INTRSTATUS 0x0c
|
|
|
|
#define OHCI_INTRENABLE 0x10
|
|
|
|
#define OHCI_INTRDISABLE 0x14
|
2011-07-15 21:22:15 +00:00
|
|
|
#define OHCI_FMINTERVAL 0x34
|
2011-11-17 21:41:45 +00:00
|
|
|
#define OHCI_HCFS (3 << 6) /* hc functional state */
|
2011-07-15 21:22:15 +00:00
|
|
|
#define OHCI_HCR (1 << 0) /* host controller reset */
|
2005-09-24 00:14:37 +00:00
|
|
|
#define OHCI_OCR (1 << 3) /* ownership change request */
|
2005-09-23 05:43:30 +00:00
|
|
|
#define OHCI_CTRL_RWC (1 << 9) /* remote wakeup connected */
|
2005-09-24 00:14:37 +00:00
|
|
|
#define OHCI_CTRL_IR (1 << 8) /* interrupt routing */
|
|
|
|
#define OHCI_INTR_OC (1 << 30) /* ownership change */
|
|
|
|
|
|
|
|
#define EHCI_HCC_PARAMS 0x08 /* extended capabilities */
|
|
|
|
#define EHCI_USBCMD 0 /* command register */
|
|
|
|
#define EHCI_USBCMD_RUN (1 << 0) /* RUN/STOP bit */
|
|
|
|
#define EHCI_USBSTS 4 /* status register */
|
|
|
|
#define EHCI_USBSTS_HALTED (1 << 12) /* HCHalted bit */
|
|
|
|
#define EHCI_USBINTR 8 /* interrupt register */
|
2007-04-05 20:06:53 +00:00
|
|
|
#define EHCI_CONFIGFLAG 0x40 /* configured flag register */
|
2005-09-24 00:14:37 +00:00
|
|
|
#define EHCI_USBLEGSUP 0 /* legacy support register */
|
|
|
|
#define EHCI_USBLEGSUP_BIOS (1 << 16) /* BIOS semaphore */
|
|
|
|
#define EHCI_USBLEGSUP_OS (1 << 24) /* OS semaphore */
|
|
|
|
#define EHCI_USBLEGCTLSTS 4 /* legacy control/status */
|
|
|
|
#define EHCI_USBLEGCTLSTS_SOOE (1 << 13) /* SMI on ownership change */
|
|
|
|
|
2011-03-01 06:57:05 +00:00
|
|
|
/* AMD quirk use */
|
|
|
|
#define AB_REG_BAR_LOW 0xe0
|
|
|
|
#define AB_REG_BAR_HIGH 0xe1
|
|
|
|
#define AB_REG_BAR_SB700 0xf0
|
|
|
|
#define AB_INDX(addr) ((addr) + 0x00)
|
|
|
|
#define AB_DATA(addr) ((addr) + 0x04)
|
|
|
|
#define AX_INDXC 0x30
|
|
|
|
#define AX_DATAC 0x34
|
|
|
|
|
|
|
|
#define NB_PCIE_INDX_ADDR 0xe0
|
|
|
|
#define NB_PCIE_INDX_DATA 0xe4
|
|
|
|
#define PCIE_P_CNTL 0x10040
|
|
|
|
#define BIF_NB 0x10002
|
|
|
|
#define NB_PIF0_PWRDOWN_0 0x01100012
|
|
|
|
#define NB_PIF0_PWRDOWN_1 0x01100013
|
|
|
|
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
#define USB_INTEL_XUSB2PR 0xD0
|
2012-08-09 17:39:23 +00:00
|
|
|
#define USB_INTEL_USB2PRM 0xD4
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
#define USB_INTEL_USB3_PSSEN 0xD8
|
2012-08-09 17:39:23 +00:00
|
|
|
#define USB_INTEL_USB3PRM 0xDC
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
|
2013-09-16 15:47:27 +00:00
|
|
|
/*
|
|
|
|
* amd_chipset_gen values represent AMD different chipset generations
|
|
|
|
*/
|
|
|
|
enum amd_chipset_gen {
|
|
|
|
NOT_AMD_CHIPSET = 0,
|
|
|
|
AMD_CHIPSET_SB600,
|
|
|
|
AMD_CHIPSET_SB700,
|
|
|
|
AMD_CHIPSET_SB800,
|
|
|
|
AMD_CHIPSET_HUDSON2,
|
|
|
|
AMD_CHIPSET_BOLTON,
|
|
|
|
AMD_CHIPSET_YANGTZE,
|
|
|
|
AMD_CHIPSET_UNKNOWN,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct amd_chipset_type {
|
|
|
|
enum amd_chipset_gen gen;
|
|
|
|
u8 rev;
|
|
|
|
};
|
|
|
|
|
2011-03-01 06:57:05 +00:00
|
|
|
static struct amd_chipset_info {
|
|
|
|
struct pci_dev *nb_dev;
|
|
|
|
struct pci_dev *smbus_dev;
|
|
|
|
int nb_type;
|
2013-09-16 15:47:27 +00:00
|
|
|
struct amd_chipset_type sb_type;
|
2011-03-01 06:57:05 +00:00
|
|
|
int isoc_reqs;
|
|
|
|
int probe_count;
|
|
|
|
int probe_result;
|
|
|
|
} amd_chipset;
|
|
|
|
|
|
|
|
static DEFINE_SPINLOCK(amd_lock);
|
|
|
|
|
2013-09-16 15:47:27 +00:00
|
|
|
/*
|
|
|
|
* amd_chipset_sb_type_init - initialize amd chipset southbridge type
|
|
|
|
*
|
|
|
|
* AMD FCH/SB generation and revision is identified by SMBus controller
|
|
|
|
* vendor, device and revision IDs.
|
|
|
|
*
|
|
|
|
* Returns: 1 if it is an AMD chipset, 0 otherwise.
|
|
|
|
*/
|
2013-09-26 18:56:44 +00:00
|
|
|
static int amd_chipset_sb_type_init(struct amd_chipset_info *pinfo)
|
2013-09-16 15:47:27 +00:00
|
|
|
{
|
|
|
|
u8 rev = 0;
|
|
|
|
pinfo->sb_type.gen = AMD_CHIPSET_UNKNOWN;
|
|
|
|
|
|
|
|
pinfo->smbus_dev = pci_get_device(PCI_VENDOR_ID_ATI,
|
|
|
|
PCI_DEVICE_ID_ATI_SBX00_SMBUS, NULL);
|
|
|
|
if (pinfo->smbus_dev) {
|
|
|
|
rev = pinfo->smbus_dev->revision;
|
|
|
|
if (rev >= 0x10 && rev <= 0x1f)
|
|
|
|
pinfo->sb_type.gen = AMD_CHIPSET_SB600;
|
|
|
|
else if (rev >= 0x30 && rev <= 0x3f)
|
|
|
|
pinfo->sb_type.gen = AMD_CHIPSET_SB700;
|
|
|
|
else if (rev >= 0x40 && rev <= 0x4f)
|
|
|
|
pinfo->sb_type.gen = AMD_CHIPSET_SB800;
|
|
|
|
} else {
|
|
|
|
pinfo->smbus_dev = pci_get_device(PCI_VENDOR_ID_AMD,
|
|
|
|
PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, NULL);
|
|
|
|
|
|
|
|
if (!pinfo->smbus_dev) {
|
|
|
|
pinfo->sb_type.gen = NOT_AMD_CHIPSET;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
rev = pinfo->smbus_dev->revision;
|
|
|
|
if (rev >= 0x11 && rev <= 0x14)
|
|
|
|
pinfo->sb_type.gen = AMD_CHIPSET_HUDSON2;
|
|
|
|
else if (rev >= 0x15 && rev <= 0x18)
|
|
|
|
pinfo->sb_type.gen = AMD_CHIPSET_BOLTON;
|
|
|
|
else if (rev >= 0x39 && rev <= 0x3a)
|
|
|
|
pinfo->sb_type.gen = AMD_CHIPSET_YANGTZE;
|
|
|
|
}
|
|
|
|
|
|
|
|
pinfo->sb_type.rev = rev;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2013-05-28 13:04:50 +00:00
|
|
|
void sb800_prefetch(struct device *dev, int on)
|
|
|
|
{
|
|
|
|
u16 misc;
|
|
|
|
struct pci_dev *pdev = to_pci_dev(dev);
|
|
|
|
|
|
|
|
pci_read_config_word(pdev, 0x50, &misc);
|
|
|
|
if (on == 0)
|
|
|
|
pci_write_config_word(pdev, 0x50, misc & 0xfcff);
|
|
|
|
else
|
|
|
|
pci_write_config_word(pdev, 0x50, misc | 0x0300);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(sb800_prefetch);
|
|
|
|
|
2011-03-01 06:57:05 +00:00
|
|
|
int usb_amd_find_chipset_info(void)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
2011-04-13 06:38:16 +00:00
|
|
|
struct amd_chipset_info info;
|
|
|
|
int ret;
|
2011-03-01 06:57:05 +00:00
|
|
|
|
|
|
|
spin_lock_irqsave(&amd_lock, flags);
|
|
|
|
|
|
|
|
/* probe only once */
|
2011-04-13 06:38:16 +00:00
|
|
|
if (amd_chipset.probe_count > 0) {
|
|
|
|
amd_chipset.probe_count++;
|
2011-03-01 06:57:05 +00:00
|
|
|
spin_unlock_irqrestore(&amd_lock, flags);
|
|
|
|
return amd_chipset.probe_result;
|
|
|
|
}
|
2011-04-13 06:38:16 +00:00
|
|
|
memset(&info, 0, sizeof(info));
|
|
|
|
spin_unlock_irqrestore(&amd_lock, flags);
|
2011-03-01 06:57:05 +00:00
|
|
|
|
2013-09-16 15:47:27 +00:00
|
|
|
if (!amd_chipset_sb_type_init(&info)) {
|
|
|
|
ret = 0;
|
|
|
|
goto commit;
|
2011-03-01 06:57:05 +00:00
|
|
|
}
|
|
|
|
|
2013-09-16 15:47:27 +00:00
|
|
|
/* Below chipset generations needn't enable AMD PLL quirk */
|
|
|
|
if (info.sb_type.gen == AMD_CHIPSET_UNKNOWN ||
|
|
|
|
info.sb_type.gen == AMD_CHIPSET_SB600 ||
|
|
|
|
info.sb_type.gen == AMD_CHIPSET_YANGTZE ||
|
|
|
|
(info.sb_type.gen == AMD_CHIPSET_SB700 &&
|
|
|
|
info.sb_type.rev > 0x3b)) {
|
2011-04-13 06:38:16 +00:00
|
|
|
if (info.smbus_dev) {
|
|
|
|
pci_dev_put(info.smbus_dev);
|
|
|
|
info.smbus_dev = NULL;
|
2011-03-01 06:57:05 +00:00
|
|
|
}
|
2011-04-13 06:38:16 +00:00
|
|
|
ret = 0;
|
|
|
|
goto commit;
|
2011-03-01 06:57:05 +00:00
|
|
|
}
|
|
|
|
|
2011-04-13 06:38:16 +00:00
|
|
|
info.nb_dev = pci_get_device(PCI_VENDOR_ID_AMD, 0x9601, NULL);
|
|
|
|
if (info.nb_dev) {
|
|
|
|
info.nb_type = 1;
|
2011-03-01 06:57:05 +00:00
|
|
|
} else {
|
2011-04-13 06:38:16 +00:00
|
|
|
info.nb_dev = pci_get_device(PCI_VENDOR_ID_AMD, 0x1510, NULL);
|
|
|
|
if (info.nb_dev) {
|
|
|
|
info.nb_type = 2;
|
|
|
|
} else {
|
|
|
|
info.nb_dev = pci_get_device(PCI_VENDOR_ID_AMD,
|
|
|
|
0x9600, NULL);
|
|
|
|
if (info.nb_dev)
|
|
|
|
info.nb_type = 3;
|
2011-03-01 06:57:05 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-04-13 06:38:16 +00:00
|
|
|
ret = info.probe_result = 1;
|
2011-03-01 06:57:05 +00:00
|
|
|
printk(KERN_DEBUG "QUIRK: Enable AMD PLL fix\n");
|
|
|
|
|
2011-04-13 06:38:16 +00:00
|
|
|
commit:
|
|
|
|
|
|
|
|
spin_lock_irqsave(&amd_lock, flags);
|
|
|
|
if (amd_chipset.probe_count > 0) {
|
|
|
|
/* race - someone else was faster - drop devices */
|
|
|
|
|
|
|
|
/* Mark that we where here */
|
|
|
|
amd_chipset.probe_count++;
|
|
|
|
ret = amd_chipset.probe_result;
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&amd_lock, flags);
|
|
|
|
|
|
|
|
if (info.nb_dev)
|
|
|
|
pci_dev_put(info.nb_dev);
|
|
|
|
if (info.smbus_dev)
|
|
|
|
pci_dev_put(info.smbus_dev);
|
|
|
|
|
|
|
|
} else {
|
|
|
|
/* no race - commit the result */
|
|
|
|
info.probe_count++;
|
|
|
|
amd_chipset = info;
|
|
|
|
spin_unlock_irqrestore(&amd_lock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
2011-03-01 06:57:05 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_amd_find_chipset_info);
|
|
|
|
|
2013-09-16 15:47:28 +00:00
|
|
|
int usb_hcd_amd_remote_wakeup_quirk(struct pci_dev *pdev)
|
|
|
|
{
|
|
|
|
/* Make sure amd chipset type has already been initialized */
|
|
|
|
usb_amd_find_chipset_info();
|
|
|
|
if (amd_chipset.sb_type.gen != AMD_CHIPSET_YANGTZE)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
dev_dbg(&pdev->dev, "QUIRK: Enable AMD remote wakeup fix\n");
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_hcd_amd_remote_wakeup_quirk);
|
|
|
|
|
2013-10-03 15:37:12 +00:00
|
|
|
bool usb_amd_hang_symptom_quirk(void)
|
|
|
|
{
|
|
|
|
u8 rev;
|
|
|
|
|
|
|
|
usb_amd_find_chipset_info();
|
|
|
|
rev = amd_chipset.sb_type.rev;
|
|
|
|
/* SB600 and old version of SB700 have hang symptom bug */
|
|
|
|
return amd_chipset.sb_type.gen == AMD_CHIPSET_SB600 ||
|
|
|
|
(amd_chipset.sb_type.gen == AMD_CHIPSET_SB700 &&
|
|
|
|
rev >= 0x3a && rev <= 0x3b);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_amd_hang_symptom_quirk);
|
|
|
|
|
2013-10-03 15:37:13 +00:00
|
|
|
bool usb_amd_prefetch_quirk(void)
|
|
|
|
{
|
|
|
|
usb_amd_find_chipset_info();
|
|
|
|
/* SB800 needs pre-fetch fix */
|
|
|
|
return amd_chipset.sb_type.gen == AMD_CHIPSET_SB800;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_amd_prefetch_quirk);
|
|
|
|
|
2011-03-01 06:57:05 +00:00
|
|
|
/*
|
|
|
|
* The hardware normally enables the A-link power management feature, which
|
|
|
|
* lets the system lower the power consumption in idle states.
|
|
|
|
*
|
|
|
|
* This USB quirk prevents the link going into that lower power state
|
|
|
|
* during isochronous transfers.
|
|
|
|
*
|
|
|
|
* Without this quirk, isochronous stream on OHCI/EHCI/xHCI controllers of
|
|
|
|
* some AMD platforms may stutter or have breaks occasionally.
|
|
|
|
*/
|
|
|
|
static void usb_amd_quirk_pll(int disable)
|
|
|
|
{
|
|
|
|
u32 addr, addr_low, addr_high, val;
|
|
|
|
u32 bit = disable ? 0 : 1;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&amd_lock, flags);
|
|
|
|
|
|
|
|
if (disable) {
|
|
|
|
amd_chipset.isoc_reqs++;
|
|
|
|
if (amd_chipset.isoc_reqs > 1) {
|
|
|
|
spin_unlock_irqrestore(&amd_lock, flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
amd_chipset.isoc_reqs--;
|
|
|
|
if (amd_chipset.isoc_reqs > 0) {
|
|
|
|
spin_unlock_irqrestore(&amd_lock, flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-16 15:47:27 +00:00
|
|
|
if (amd_chipset.sb_type.gen == AMD_CHIPSET_SB800 ||
|
|
|
|
amd_chipset.sb_type.gen == AMD_CHIPSET_HUDSON2 ||
|
|
|
|
amd_chipset.sb_type.gen == AMD_CHIPSET_BOLTON) {
|
2011-03-01 06:57:05 +00:00
|
|
|
outb_p(AB_REG_BAR_LOW, 0xcd6);
|
|
|
|
addr_low = inb_p(0xcd7);
|
|
|
|
outb_p(AB_REG_BAR_HIGH, 0xcd6);
|
|
|
|
addr_high = inb_p(0xcd7);
|
|
|
|
addr = addr_high << 8 | addr_low;
|
|
|
|
|
|
|
|
outl_p(0x30, AB_INDX(addr));
|
|
|
|
outl_p(0x40, AB_DATA(addr));
|
|
|
|
outl_p(0x34, AB_INDX(addr));
|
|
|
|
val = inl_p(AB_DATA(addr));
|
2013-09-16 15:47:27 +00:00
|
|
|
} else if (amd_chipset.sb_type.gen == AMD_CHIPSET_SB700 &&
|
|
|
|
amd_chipset.sb_type.rev <= 0x3b) {
|
2011-03-01 06:57:05 +00:00
|
|
|
pci_read_config_dword(amd_chipset.smbus_dev,
|
|
|
|
AB_REG_BAR_SB700, &addr);
|
|
|
|
outl(AX_INDXC, AB_INDX(addr));
|
|
|
|
outl(0x40, AB_DATA(addr));
|
|
|
|
outl(AX_DATAC, AB_INDX(addr));
|
|
|
|
val = inl(AB_DATA(addr));
|
|
|
|
} else {
|
|
|
|
spin_unlock_irqrestore(&amd_lock, flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (disable) {
|
|
|
|
val &= ~0x08;
|
|
|
|
val |= (1 << 4) | (1 << 9);
|
|
|
|
} else {
|
|
|
|
val |= 0x08;
|
|
|
|
val &= ~((1 << 4) | (1 << 9));
|
|
|
|
}
|
|
|
|
outl_p(val, AB_DATA(addr));
|
|
|
|
|
|
|
|
if (!amd_chipset.nb_dev) {
|
|
|
|
spin_unlock_irqrestore(&amd_lock, flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (amd_chipset.nb_type == 1 || amd_chipset.nb_type == 3) {
|
|
|
|
addr = PCIE_P_CNTL;
|
|
|
|
pci_write_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_ADDR, addr);
|
|
|
|
pci_read_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_DATA, &val);
|
|
|
|
|
|
|
|
val &= ~(1 | (1 << 3) | (1 << 4) | (1 << 9) | (1 << 12));
|
|
|
|
val |= bit | (bit << 3) | (bit << 12);
|
|
|
|
val |= ((!bit) << 4) | ((!bit) << 9);
|
|
|
|
pci_write_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_DATA, val);
|
|
|
|
|
|
|
|
addr = BIF_NB;
|
|
|
|
pci_write_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_ADDR, addr);
|
|
|
|
pci_read_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_DATA, &val);
|
|
|
|
val &= ~(1 << 8);
|
|
|
|
val |= bit << 8;
|
|
|
|
|
|
|
|
pci_write_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_DATA, val);
|
|
|
|
} else if (amd_chipset.nb_type == 2) {
|
|
|
|
addr = NB_PIF0_PWRDOWN_0;
|
|
|
|
pci_write_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_ADDR, addr);
|
|
|
|
pci_read_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_DATA, &val);
|
|
|
|
if (disable)
|
|
|
|
val &= ~(0x3f << 7);
|
|
|
|
else
|
|
|
|
val |= 0x3f << 7;
|
|
|
|
|
|
|
|
pci_write_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_DATA, val);
|
|
|
|
|
|
|
|
addr = NB_PIF0_PWRDOWN_1;
|
|
|
|
pci_write_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_ADDR, addr);
|
|
|
|
pci_read_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_DATA, &val);
|
|
|
|
if (disable)
|
|
|
|
val &= ~(0x3f << 7);
|
|
|
|
else
|
|
|
|
val |= 0x3f << 7;
|
|
|
|
|
|
|
|
pci_write_config_dword(amd_chipset.nb_dev,
|
|
|
|
NB_PCIE_INDX_DATA, val);
|
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&amd_lock, flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
void usb_amd_quirk_pll_disable(void)
|
|
|
|
{
|
|
|
|
usb_amd_quirk_pll(1);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_disable);
|
|
|
|
|
|
|
|
void usb_amd_quirk_pll_enable(void)
|
|
|
|
{
|
|
|
|
usb_amd_quirk_pll(0);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_amd_quirk_pll_enable);
|
|
|
|
|
|
|
|
void usb_amd_dev_put(void)
|
|
|
|
{
|
2011-04-13 06:38:16 +00:00
|
|
|
struct pci_dev *nb, *smbus;
|
2011-03-01 06:57:05 +00:00
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&amd_lock, flags);
|
|
|
|
|
|
|
|
amd_chipset.probe_count--;
|
|
|
|
if (amd_chipset.probe_count > 0) {
|
|
|
|
spin_unlock_irqrestore(&amd_lock, flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2011-04-13 06:38:16 +00:00
|
|
|
/* save them to pci_dev_put outside of spinlock */
|
|
|
|
nb = amd_chipset.nb_dev;
|
|
|
|
smbus = amd_chipset.smbus_dev;
|
|
|
|
|
|
|
|
amd_chipset.nb_dev = NULL;
|
|
|
|
amd_chipset.smbus_dev = NULL;
|
2011-03-01 06:57:05 +00:00
|
|
|
amd_chipset.nb_type = 0;
|
2013-09-16 15:47:27 +00:00
|
|
|
memset(&amd_chipset.sb_type, 0, sizeof(amd_chipset.sb_type));
|
2011-03-01 06:57:05 +00:00
|
|
|
amd_chipset.isoc_reqs = 0;
|
|
|
|
amd_chipset.probe_result = 0;
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&amd_lock, flags);
|
2011-04-13 06:38:16 +00:00
|
|
|
|
|
|
|
if (nb)
|
|
|
|
pci_dev_put(nb);
|
|
|
|
if (smbus)
|
|
|
|
pci_dev_put(smbus);
|
2011-03-01 06:57:05 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_amd_dev_put);
|
2005-09-24 00:14:37 +00:00
|
|
|
|
2005-10-03 20:36:29 +00:00
|
|
|
/*
|
|
|
|
* Make sure the controller is completely inactive, unable to
|
|
|
|
* generate interrupts or do DMA.
|
|
|
|
*/
|
|
|
|
void uhci_reset_hc(struct pci_dev *pdev, unsigned long base)
|
|
|
|
{
|
|
|
|
/* Turn off PIRQ enable and SMI enable. (This also turns off the
|
|
|
|
* BIOS's USB Legacy Support.) Turn off all the R/WC bits too.
|
|
|
|
*/
|
|
|
|
pci_write_config_word(pdev, UHCI_USBLEGSUP, UHCI_USBLEGSUP_RWC);
|
|
|
|
|
|
|
|
/* Reset the HC - this will force us to get a
|
|
|
|
* new notification of any already connected
|
|
|
|
* ports due to the virtual disconnect that it
|
|
|
|
* implies.
|
|
|
|
*/
|
|
|
|
outw(UHCI_USBCMD_HCRESET, base + UHCI_USBCMD);
|
|
|
|
mb();
|
|
|
|
udelay(5);
|
|
|
|
if (inw(base + UHCI_USBCMD) & UHCI_USBCMD_HCRESET)
|
|
|
|
dev_warn(&pdev->dev, "HCRESET not completed yet!\n");
|
|
|
|
|
|
|
|
/* Just to be safe, disable interrupt requests and
|
|
|
|
* make sure the controller is stopped.
|
|
|
|
*/
|
|
|
|
outw(0, base + UHCI_USBINTR);
|
|
|
|
outw(0, base + UHCI_USBCMD);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(uhci_reset_hc);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize a controller that was newly discovered or has just been
|
|
|
|
* resumed. In either case we can't be sure of its previous state.
|
|
|
|
*
|
|
|
|
* Returns: 1 if the controller was reset, 0 otherwise.
|
|
|
|
*/
|
|
|
|
int uhci_check_and_reset_hc(struct pci_dev *pdev, unsigned long base)
|
|
|
|
{
|
|
|
|
u16 legsup;
|
|
|
|
unsigned int cmd, intr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When restarting a suspended controller, we expect all the
|
|
|
|
* settings to be the same as we left them:
|
|
|
|
*
|
|
|
|
* PIRQ and SMI disabled, no R/W bits set in USBLEGSUP;
|
|
|
|
* Controller is stopped and configured with EGSM set;
|
|
|
|
* No interrupts enabled except possibly Resume Detect.
|
|
|
|
*
|
|
|
|
* If any of these conditions are violated we do a complete reset.
|
|
|
|
*/
|
|
|
|
pci_read_config_word(pdev, UHCI_USBLEGSUP, &legsup);
|
|
|
|
if (legsup & ~(UHCI_USBLEGSUP_RO | UHCI_USBLEGSUP_RWC)) {
|
|
|
|
dev_dbg(&pdev->dev, "%s: legsup = 0x%04x\n",
|
2008-03-04 00:08:34 +00:00
|
|
|
__func__, legsup);
|
2005-10-03 20:36:29 +00:00
|
|
|
goto reset_needed;
|
|
|
|
}
|
|
|
|
|
|
|
|
cmd = inw(base + UHCI_USBCMD);
|
|
|
|
if ((cmd & UHCI_USBCMD_RUN) || !(cmd & UHCI_USBCMD_CONFIGURE) ||
|
|
|
|
!(cmd & UHCI_USBCMD_EGSM)) {
|
|
|
|
dev_dbg(&pdev->dev, "%s: cmd = 0x%04x\n",
|
2008-03-04 00:08:34 +00:00
|
|
|
__func__, cmd);
|
2005-10-03 20:36:29 +00:00
|
|
|
goto reset_needed;
|
|
|
|
}
|
|
|
|
|
|
|
|
intr = inw(base + UHCI_USBINTR);
|
|
|
|
if (intr & (~UHCI_USBINTR_RESUME)) {
|
|
|
|
dev_dbg(&pdev->dev, "%s: intr = 0x%04x\n",
|
2008-03-04 00:08:34 +00:00
|
|
|
__func__, intr);
|
2005-10-03 20:36:29 +00:00
|
|
|
goto reset_needed;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
reset_needed:
|
|
|
|
dev_dbg(&pdev->dev, "Performing full reset\n");
|
|
|
|
uhci_reset_hc(pdev, base);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(uhci_check_and_reset_hc);
|
|
|
|
|
2005-11-01 05:12:40 +00:00
|
|
|
static inline int io_type_enabled(struct pci_dev *pdev, unsigned int mask)
|
|
|
|
{
|
|
|
|
u16 cmd;
|
|
|
|
return !pci_read_config_word(pdev, PCI_COMMAND, &cmd) && (cmd & mask);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define pio_enabled(dev) io_type_enabled(dev, PCI_COMMAND_IO)
|
|
|
|
#define mmio_enabled(dev) io_type_enabled(dev, PCI_COMMAND_MEMORY)
|
|
|
|
|
2012-11-19 18:21:48 +00:00
|
|
|
static void quirk_usb_handoff_uhci(struct pci_dev *pdev)
|
2005-09-24 00:14:37 +00:00
|
|
|
{
|
|
|
|
unsigned long base = 0;
|
|
|
|
int i;
|
|
|
|
|
2005-11-01 05:12:40 +00:00
|
|
|
if (!pio_enabled(pdev))
|
|
|
|
return;
|
|
|
|
|
2005-09-24 00:14:37 +00:00
|
|
|
for (i = 0; i < PCI_ROM_RESOURCE; i++)
|
|
|
|
if ((pci_resource_flags(pdev, i) & IORESOURCE_IO)) {
|
|
|
|
base = pci_resource_start(pdev, i);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2005-10-03 20:36:29 +00:00
|
|
|
if (base)
|
|
|
|
uhci_check_and_reset_hc(pdev, base);
|
2005-09-24 00:14:37 +00:00
|
|
|
}
|
|
|
|
|
2012-11-19 18:21:48 +00:00
|
|
|
static int mmio_resource_enabled(struct pci_dev *pdev, int idx)
|
2005-11-01 05:12:40 +00:00
|
|
|
{
|
|
|
|
return pci_resource_start(pdev, idx) && mmio_enabled(pdev);
|
|
|
|
}
|
|
|
|
|
2012-11-19 18:21:48 +00:00
|
|
|
static void quirk_usb_handoff_ohci(struct pci_dev *pdev)
|
2005-09-24 00:14:37 +00:00
|
|
|
{
|
|
|
|
void __iomem *base;
|
2010-09-10 20:37:05 +00:00
|
|
|
u32 control;
|
2011-11-17 21:41:45 +00:00
|
|
|
u32 fminterval;
|
|
|
|
int cnt;
|
2005-09-24 00:14:37 +00:00
|
|
|
|
2005-11-01 05:12:40 +00:00
|
|
|
if (!mmio_resource_enabled(pdev, 0))
|
|
|
|
return;
|
|
|
|
|
2008-10-21 04:46:01 +00:00
|
|
|
base = pci_ioremap_bar(pdev, 0);
|
|
|
|
if (base == NULL)
|
|
|
|
return;
|
2005-09-24 00:14:37 +00:00
|
|
|
|
2010-09-10 20:37:05 +00:00
|
|
|
control = readl(base + OHCI_CONTROL);
|
|
|
|
|
2005-09-23 05:43:30 +00:00
|
|
|
/* On PA-RISC, PDC can leave IR set incorrectly; ignore it there. */
|
2010-09-10 20:37:05 +00:00
|
|
|
#ifdef __hppa__
|
|
|
|
#define OHCI_CTRL_MASK (OHCI_CTRL_RWC | OHCI_CTRL_IR)
|
|
|
|
#else
|
|
|
|
#define OHCI_CTRL_MASK OHCI_CTRL_RWC
|
|
|
|
|
2005-09-23 05:43:30 +00:00
|
|
|
if (control & OHCI_CTRL_IR) {
|
2006-06-25 22:45:29 +00:00
|
|
|
int wait_time = 500; /* arbitrary; 5 seconds */
|
2005-09-24 00:14:37 +00:00
|
|
|
writel(OHCI_INTR_OC, base + OHCI_INTRENABLE);
|
|
|
|
writel(OHCI_OCR, base + OHCI_CMDSTATUS);
|
|
|
|
while (wait_time > 0 &&
|
|
|
|
readl(base + OHCI_CONTROL) & OHCI_CTRL_IR) {
|
|
|
|
wait_time -= 10;
|
|
|
|
msleep(10);
|
|
|
|
}
|
2005-09-23 05:43:30 +00:00
|
|
|
if (wait_time <= 0)
|
2007-12-17 21:09:39 +00:00
|
|
|
dev_warn(&pdev->dev, "OHCI: BIOS handoff failed"
|
|
|
|
" (BIOS bug?) %08x\n",
|
2006-02-09 21:35:31 +00:00
|
|
|
readl(base + OHCI_CONTROL));
|
2005-09-24 00:14:37 +00:00
|
|
|
}
|
2005-09-23 05:43:30 +00:00
|
|
|
#endif
|
2005-09-24 00:14:37 +00:00
|
|
|
|
2011-11-17 21:41:45 +00:00
|
|
|
/* disable interrupts */
|
|
|
|
writel((u32) ~0, base + OHCI_INTRDISABLE);
|
2011-07-15 21:22:15 +00:00
|
|
|
|
2011-11-17 21:41:45 +00:00
|
|
|
/* Reset the USB bus, if the controller isn't already in RESET */
|
|
|
|
if (control & OHCI_HCFS) {
|
|
|
|
/* Go into RESET, preserving RWC (and possibly IR) */
|
|
|
|
writel(control & OHCI_CTRL_MASK, base + OHCI_CONTROL);
|
|
|
|
readl(base + OHCI_CONTROL);
|
2011-07-15 21:22:15 +00:00
|
|
|
|
2011-11-17 21:41:45 +00:00
|
|
|
/* drive bus reset for at least 50 ms (7.1.7.5) */
|
2011-07-15 21:22:15 +00:00
|
|
|
msleep(50);
|
2011-11-17 21:41:45 +00:00
|
|
|
}
|
2011-07-15 21:22:15 +00:00
|
|
|
|
2011-11-17 21:41:45 +00:00
|
|
|
/* software reset of the controller, preserving HcFmInterval */
|
|
|
|
fminterval = readl(base + OHCI_FMINTERVAL);
|
|
|
|
writel(OHCI_HCR, base + OHCI_CMDSTATUS);
|
2011-07-15 21:22:15 +00:00
|
|
|
|
2011-11-17 21:41:45 +00:00
|
|
|
/* reset requires max 10 us delay */
|
|
|
|
for (cnt = 30; cnt > 0; --cnt) { /* ... allow extra time */
|
|
|
|
if ((readl(base + OHCI_CMDSTATUS) & OHCI_HCR) == 0)
|
|
|
|
break;
|
|
|
|
udelay(1);
|
2011-07-15 21:22:15 +00:00
|
|
|
}
|
2011-11-17 21:41:45 +00:00
|
|
|
writel(fminterval, base + OHCI_FMINTERVAL);
|
2010-09-10 20:37:05 +00:00
|
|
|
|
2011-11-17 21:41:45 +00:00
|
|
|
/* Now the controller is safely in SUSPEND and nothing can wake it up */
|
2005-09-24 00:14:37 +00:00
|
|
|
iounmap(base);
|
|
|
|
}
|
|
|
|
|
2012-11-19 18:25:20 +00:00
|
|
|
static const struct dmi_system_id ehci_dmi_nohandoff_table[] = {
|
2011-07-05 14:38:45 +00:00
|
|
|
{
|
|
|
|
/* Pegatron Lucid (ExoPC) */
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "EXOPG06411"),
|
|
|
|
DMI_MATCH(DMI_BIOS_VERSION, "Lucid-CE-133"),
|
|
|
|
},
|
|
|
|
},
|
2011-07-05 14:38:46 +00:00
|
|
|
{
|
|
|
|
/* Pegatron Lucid (Ordissimo AIRIS) */
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "M11JB"),
|
2012-10-09 10:22:36 +00:00
|
|
|
DMI_MATCH(DMI_BIOS_VERSION, "Lucid-"),
|
2011-07-05 14:38:46 +00:00
|
|
|
},
|
|
|
|
},
|
2012-10-09 10:22:37 +00:00
|
|
|
{
|
|
|
|
/* Pegatron Lucid (Ordissimo) */
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "Ordissimo"),
|
|
|
|
DMI_MATCH(DMI_BIOS_VERSION, "Lucid-"),
|
|
|
|
},
|
|
|
|
},
|
2011-07-05 14:38:45 +00:00
|
|
|
{ }
|
|
|
|
};
|
|
|
|
|
2012-11-19 18:21:48 +00:00
|
|
|
static void ehci_bios_handoff(struct pci_dev *pdev,
|
2011-05-11 22:15:51 +00:00
|
|
|
void __iomem *op_reg_base,
|
|
|
|
u32 cap, u8 offset)
|
|
|
|
{
|
2011-05-11 22:52:38 +00:00
|
|
|
int try_handoff = 1, tried_handoff = 0;
|
|
|
|
|
2011-07-05 14:38:45 +00:00
|
|
|
/* The Pegatron Lucid tablet sporadically waits for 98 seconds trying
|
|
|
|
* the handoff on its unused controller. Skip it. */
|
2011-05-11 22:52:38 +00:00
|
|
|
if (pdev->vendor == 0x8086 && pdev->device == 0x283a) {
|
2011-07-05 14:38:45 +00:00
|
|
|
if (dmi_check_system(ehci_dmi_nohandoff_table))
|
2011-05-11 22:52:38 +00:00
|
|
|
try_handoff = 0;
|
|
|
|
}
|
2011-05-11 22:15:51 +00:00
|
|
|
|
2011-05-11 22:52:38 +00:00
|
|
|
if (try_handoff && (cap & EHCI_USBLEGSUP_BIOS)) {
|
2011-05-11 22:15:51 +00:00
|
|
|
dev_dbg(&pdev->dev, "EHCI: BIOS handoff\n");
|
|
|
|
|
|
|
|
#if 0
|
|
|
|
/* aleksey_gorelov@phoenix.com reports that some systems need SMI forced on,
|
|
|
|
* but that seems dubious in general (the BIOS left it off intentionally)
|
|
|
|
* and is known to prevent some systems from booting. so we won't do this
|
|
|
|
* unless maybe we can determine when we're on a system that needs SMI forced.
|
|
|
|
*/
|
|
|
|
/* BIOS workaround (?): be sure the pre-Linux code
|
|
|
|
* receives the SMI
|
|
|
|
*/
|
|
|
|
pci_read_config_dword(pdev, offset + EHCI_USBLEGCTLSTS, &val);
|
|
|
|
pci_write_config_dword(pdev, offset + EHCI_USBLEGCTLSTS,
|
|
|
|
val | EHCI_USBLEGCTLSTS_SOOE);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/* some systems get upset if this semaphore is
|
|
|
|
* set for any other reason than forcing a BIOS
|
|
|
|
* handoff..
|
|
|
|
*/
|
|
|
|
pci_write_config_byte(pdev, offset + 3, 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* if boot firmware now owns EHCI, spin till it hands it over. */
|
2011-05-11 22:52:38 +00:00
|
|
|
if (try_handoff) {
|
|
|
|
int msec = 1000;
|
|
|
|
while ((cap & EHCI_USBLEGSUP_BIOS) && (msec > 0)) {
|
|
|
|
tried_handoff = 1;
|
|
|
|
msleep(10);
|
|
|
|
msec -= 10;
|
|
|
|
pci_read_config_dword(pdev, offset, &cap);
|
|
|
|
}
|
2011-05-11 22:15:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (cap & EHCI_USBLEGSUP_BIOS) {
|
|
|
|
/* well, possibly buggy BIOS... try to shut it down,
|
|
|
|
* and hope nothing goes too wrong
|
|
|
|
*/
|
2011-05-11 22:52:38 +00:00
|
|
|
if (try_handoff)
|
|
|
|
dev_warn(&pdev->dev, "EHCI: BIOS handoff failed"
|
|
|
|
" (BIOS bug?) %08x\n", cap);
|
2011-05-11 22:15:51 +00:00
|
|
|
pci_write_config_byte(pdev, offset + 2, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* just in case, always disable EHCI SMIs */
|
|
|
|
pci_write_config_dword(pdev, offset + EHCI_USBLEGCTLSTS, 0);
|
|
|
|
|
|
|
|
/* If the BIOS ever owned the controller then we can't expect
|
|
|
|
* any power sessions to remain intact.
|
|
|
|
*/
|
|
|
|
if (tried_handoff)
|
|
|
|
writel(0, op_reg_base + EHCI_CONFIGFLAG);
|
|
|
|
}
|
|
|
|
|
2012-11-19 18:21:48 +00:00
|
|
|
static void quirk_usb_disable_ehci(struct pci_dev *pdev)
|
2005-09-24 00:14:37 +00:00
|
|
|
{
|
|
|
|
void __iomem *base, *op_reg_base;
|
2011-05-11 22:15:51 +00:00
|
|
|
u32 hcc_params, cap, val;
|
2006-01-24 15:15:30 +00:00
|
|
|
u8 offset, cap_length;
|
2011-10-27 15:20:21 +00:00
|
|
|
int wait_time, count = 256/4;
|
2005-09-24 00:14:37 +00:00
|
|
|
|
2005-11-01 05:12:40 +00:00
|
|
|
if (!mmio_resource_enabled(pdev, 0))
|
|
|
|
return;
|
|
|
|
|
2008-10-21 04:46:01 +00:00
|
|
|
base = pci_ioremap_bar(pdev, 0);
|
|
|
|
if (base == NULL)
|
|
|
|
return;
|
2005-09-24 00:14:37 +00:00
|
|
|
|
|
|
|
cap_length = readb(base);
|
|
|
|
op_reg_base = base + cap_length;
|
2006-01-24 15:15:30 +00:00
|
|
|
|
|
|
|
/* EHCI 0.96 and later may have "extended capabilities"
|
|
|
|
* spec section 5.1 explains the bios handoff, e.g. for
|
|
|
|
* booting from USB disk or using a usb keyboard
|
|
|
|
*/
|
2005-09-24 00:14:37 +00:00
|
|
|
hcc_params = readl(base + EHCI_HCC_PARAMS);
|
2006-01-24 15:15:30 +00:00
|
|
|
offset = (hcc_params >> 8) & 0xff;
|
2009-01-31 11:37:04 +00:00
|
|
|
while (offset && --count) {
|
2006-01-24 15:15:30 +00:00
|
|
|
pci_read_config_dword(pdev, offset, &cap);
|
|
|
|
|
2011-05-11 22:15:51 +00:00
|
|
|
switch (cap & 0xff) {
|
|
|
|
case 1:
|
|
|
|
ehci_bios_handoff(pdev, op_reg_base, cap, offset);
|
2006-01-24 15:15:30 +00:00
|
|
|
break;
|
2011-05-11 22:15:51 +00:00
|
|
|
case 0: /* Illegal reserved cap, set cap=0 so we exit */
|
|
|
|
cap = 0; /* then fallthrough... */
|
2006-01-24 15:15:30 +00:00
|
|
|
default:
|
2007-12-17 21:09:39 +00:00
|
|
|
dev_warn(&pdev->dev, "EHCI: unrecognized capability "
|
2011-05-11 22:15:51 +00:00
|
|
|
"%02x\n", cap & 0xff);
|
2005-09-24 00:14:37 +00:00
|
|
|
}
|
2006-01-24 15:15:30 +00:00
|
|
|
offset = (cap >> 8) & 0xff;
|
2005-09-24 00:14:37 +00:00
|
|
|
}
|
2006-01-24 15:15:30 +00:00
|
|
|
if (!count)
|
2007-12-17 21:09:39 +00:00
|
|
|
dev_printk(KERN_DEBUG, &pdev->dev, "EHCI: capability loop?\n");
|
2005-09-24 00:14:37 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* halt EHCI & disable its interrupts in any case
|
|
|
|
*/
|
|
|
|
val = readl(op_reg_base + EHCI_USBSTS);
|
|
|
|
if ((val & EHCI_USBSTS_HALTED) == 0) {
|
|
|
|
val = readl(op_reg_base + EHCI_USBCMD);
|
|
|
|
val &= ~EHCI_USBCMD_RUN;
|
|
|
|
writel(val, op_reg_base + EHCI_USBCMD);
|
|
|
|
|
|
|
|
wait_time = 2000;
|
|
|
|
do {
|
|
|
|
writel(0x3f, op_reg_base + EHCI_USBSTS);
|
2011-10-27 15:20:21 +00:00
|
|
|
udelay(100);
|
|
|
|
wait_time -= 100;
|
2005-09-24 00:14:37 +00:00
|
|
|
val = readl(op_reg_base + EHCI_USBSTS);
|
|
|
|
if ((val == ~(u32)0) || (val & EHCI_USBSTS_HALTED)) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
} while (wait_time > 0);
|
|
|
|
}
|
|
|
|
writel(0, op_reg_base + EHCI_USBINTR);
|
|
|
|
writel(0x3f, op_reg_base + EHCI_USBSTS);
|
|
|
|
|
|
|
|
iounmap(base);
|
|
|
|
}
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
/*
|
|
|
|
* handshake - spin reading a register until handshake completes
|
|
|
|
* @ptr: address of hc register to be read
|
|
|
|
* @mask: bits to look at in result of read
|
|
|
|
* @done: value of those bits when handshake succeeds
|
|
|
|
* @wait_usec: timeout in microseconds
|
|
|
|
* @delay_usec: delay in microseconds to wait between polling
|
|
|
|
*
|
|
|
|
* Polls a register every delay_usec microseconds.
|
|
|
|
* Returns 0 when the mask bits have the value done.
|
|
|
|
* Returns -ETIMEDOUT if this condition is not true after
|
|
|
|
* wait_usec microseconds have passed.
|
|
|
|
*/
|
|
|
|
static int handshake(void __iomem *ptr, u32 mask, u32 done,
|
|
|
|
int wait_usec, int delay_usec)
|
|
|
|
{
|
|
|
|
u32 result;
|
|
|
|
|
|
|
|
do {
|
|
|
|
result = readl(ptr);
|
|
|
|
result &= mask;
|
|
|
|
if (result == done)
|
|
|
|
return 0;
|
|
|
|
udelay(delay_usec);
|
|
|
|
wait_usec -= delay_usec;
|
|
|
|
} while (wait_usec > 0);
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
}
|
|
|
|
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
/*
|
|
|
|
* Intel's Panther Point chipset has two host controllers (EHCI and xHCI) that
|
|
|
|
* share some number of ports. These ports can be switched between either
|
|
|
|
* controller. Not all of the ports under the EHCI host controller may be
|
|
|
|
* switchable.
|
|
|
|
*
|
|
|
|
* The ports should be switched over to xHCI before PCI probes for any device
|
|
|
|
* start. This avoids active devices under EHCI being disconnected during the
|
|
|
|
* port switchover, which could cause loss of data on USB storage devices, or
|
|
|
|
* failed boot when the root file system is on a USB mass storage device and is
|
|
|
|
* enumerated under EHCI first.
|
|
|
|
*
|
|
|
|
* We write into the xHC's PCI configuration space in some Intel-specific
|
|
|
|
* registers to switch the ports over. The USB 3.0 terminations and the USB
|
|
|
|
* 2.0 data wires are switched separately. We want to enable the SuperSpeed
|
|
|
|
* terminations before switching the USB 2.0 wires over, so that USB 3.0
|
|
|
|
* devices connect at SuperSpeed, rather than at USB 2.0 speeds.
|
|
|
|
*/
|
2013-07-23 08:35:47 +00:00
|
|
|
void usb_enable_intel_xhci_ports(struct pci_dev *xhci_pdev)
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
{
|
|
|
|
u32 ports_available;
|
2013-07-23 08:35:47 +00:00
|
|
|
bool ehci_found = false;
|
|
|
|
struct pci_dev *companion = NULL;
|
|
|
|
|
|
|
|
/* make sure an intel EHCI controller exists */
|
|
|
|
for_each_pci_dev(companion) {
|
|
|
|
if (companion->class == PCI_CLASS_SERIAL_USB_EHCI &&
|
|
|
|
companion->vendor == PCI_VENDOR_ID_INTEL) {
|
|
|
|
ehci_found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ehci_found)
|
|
|
|
return;
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
|
2012-04-16 17:56:47 +00:00
|
|
|
/* Don't switchover the ports if the user hasn't compiled the xHCI
|
|
|
|
* driver. Otherwise they will see "dead" USB ports that don't power
|
|
|
|
* the devices.
|
|
|
|
*/
|
|
|
|
if (!IS_ENABLED(CONFIG_USB_XHCI_HCD)) {
|
|
|
|
dev_warn(&xhci_pdev->dev,
|
|
|
|
"CONFIG_USB_XHCI_HCD is turned off, "
|
|
|
|
"defaulting to EHCI.\n");
|
|
|
|
dev_warn(&xhci_pdev->dev,
|
|
|
|
"USB 3.0 devices will work at USB 2.0 speeds.\n");
|
2013-01-24 06:19:49 +00:00
|
|
|
usb_disable_xhci_ports(xhci_pdev);
|
2012-04-16 17:56:47 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-08-09 17:39:23 +00:00
|
|
|
/* Read USB3PRM, the USB 3.0 Port Routing Mask Register
|
|
|
|
* Indicate the ports that can be changed from OS.
|
|
|
|
*/
|
|
|
|
pci_read_config_dword(xhci_pdev, USB_INTEL_USB3PRM,
|
|
|
|
&ports_available);
|
|
|
|
|
|
|
|
dev_dbg(&xhci_pdev->dev, "Configurable ports to enable SuperSpeed: 0x%x\n",
|
|
|
|
ports_available);
|
|
|
|
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
/* Write USB3_PSSEN, the USB 3.0 Port SuperSpeed Enable
|
2012-08-09 17:39:23 +00:00
|
|
|
* Register, to turn on SuperSpeed terminations for the
|
|
|
|
* switchable ports.
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
*/
|
|
|
|
pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN,
|
2013-09-20 16:45:53 +00:00
|
|
|
ports_available);
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
|
|
|
|
pci_read_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN,
|
|
|
|
&ports_available);
|
|
|
|
dev_dbg(&xhci_pdev->dev, "USB 3.0 ports that are now enabled "
|
|
|
|
"under xHCI: 0x%x\n", ports_available);
|
|
|
|
|
2012-08-09 17:39:23 +00:00
|
|
|
/* Read XUSB2PRM, xHCI USB 2.0 Port Routing Mask Register
|
|
|
|
* Indicate the USB 2.0 ports to be controlled by the xHCI host.
|
|
|
|
*/
|
|
|
|
|
|
|
|
pci_read_config_dword(xhci_pdev, USB_INTEL_USB2PRM,
|
|
|
|
&ports_available);
|
|
|
|
|
|
|
|
dev_dbg(&xhci_pdev->dev, "Configurable USB 2.0 ports to hand over to xCHI: 0x%x\n",
|
|
|
|
ports_available);
|
|
|
|
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
/* Write XUSB2PR, the xHC USB 2.0 Port Routing Register, to
|
|
|
|
* switch the USB 2.0 power and data lines over to the xHCI
|
|
|
|
* host.
|
|
|
|
*/
|
|
|
|
pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR,
|
2013-09-20 16:45:53 +00:00
|
|
|
ports_available);
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
|
|
|
|
pci_read_config_dword(xhci_pdev, USB_INTEL_XUSB2PR,
|
|
|
|
&ports_available);
|
|
|
|
dev_dbg(&xhci_pdev->dev, "USB 2.0 ports that are now switched over "
|
|
|
|
"to xHCI: 0x%x\n", ports_available);
|
|
|
|
}
|
2013-07-23 08:35:47 +00:00
|
|
|
EXPORT_SYMBOL_GPL(usb_enable_intel_xhci_ports);
|
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>
2011-02-22 17:57:15 +00:00
|
|
|
|
xhci: Switch PPT ports to EHCI on shutdown.
The Intel desktop boards DH77EB and DH77DF have a hardware issue that
can be worked around by BIOS. If the USB ports are switched to xHCI on
shutdown, the xHCI host will send a spurious interrupt, which will wake
the system. Some BIOS will work around this, but not all.
The bug can be avoided if the USB ports are switched back to EHCI on
shutdown. The Intel Windows driver switches the ports back to EHCI, so
change the Linux xHCI driver to do the same.
Unfortunately, we can't tell the two effected boards apart from other
working motherboards, because the vendors will change the DMI strings
for the DH77EB and DH77DF boards to their own custom names. One example
is Compulab's mini-desktop, the Intense-PC. Instead, key off the
Panther Point xHCI host PCI vendor and device ID, and switch the ports
over for all PPT xHCI hosts.
The only impact this will have on non-effected boards is to add a couple
hundred milliseconds delay on boot when the BIOS has to switch the ports
over from EHCI to xHCI.
This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Denis Turischev <denis@compulab.co.il>
Tested-by: Denis Turischev <denis@compulab.co.il>
Cc: stable@vger.kernel.org
2012-07-23 15:59:30 +00:00
|
|
|
void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
|
|
|
|
{
|
|
|
|
pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN, 0x0);
|
|
|
|
pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR, 0x0);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
/**
|
|
|
|
* PCI Quirks for xHCI.
|
|
|
|
*
|
|
|
|
* Takes care of the handoff between the Pre-OS (i.e. BIOS) and the OS.
|
|
|
|
* It signals to the BIOS that the OS wants control of the host controller,
|
|
|
|
* and then waits 5 seconds for the BIOS to hand over control.
|
|
|
|
* If we timeout, assume the BIOS is broken and take control anyway.
|
|
|
|
*/
|
2012-11-19 18:21:48 +00:00
|
|
|
static void quirk_usb_handoff_xhci(struct pci_dev *pdev)
|
2009-04-28 02:52:28 +00:00
|
|
|
{
|
|
|
|
void __iomem *base;
|
|
|
|
int ext_cap_offset;
|
|
|
|
void __iomem *op_reg_base;
|
|
|
|
u32 val;
|
|
|
|
int timeout;
|
2012-08-14 20:44:49 +00:00
|
|
|
int len = pci_resource_len(pdev, 0);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
if (!mmio_resource_enabled(pdev, 0))
|
|
|
|
return;
|
|
|
|
|
2012-08-14 20:44:49 +00:00
|
|
|
base = ioremap_nocache(pci_resource_start(pdev, 0), len);
|
2009-04-28 02:52:28 +00:00
|
|
|
if (base == NULL)
|
|
|
|
return;
|
2005-09-24 00:14:37 +00:00
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
/*
|
|
|
|
* Find the Legacy Support Capability register -
|
|
|
|
* this is optional for xHCI host controllers.
|
|
|
|
*/
|
|
|
|
ext_cap_offset = xhci_find_next_cap_offset(base, XHCI_HCC_PARAMS_OFFSET);
|
|
|
|
do {
|
2012-08-14 20:44:49 +00:00
|
|
|
if ((ext_cap_offset + sizeof(val)) > len) {
|
|
|
|
/* We're reading garbage from the controller */
|
|
|
|
dev_warn(&pdev->dev,
|
|
|
|
"xHCI controller failing to respond");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
if (!ext_cap_offset)
|
|
|
|
/* We've reached the end of the extended capabilities */
|
|
|
|
goto hc_init;
|
2012-08-14 20:44:49 +00:00
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
val = readl(base + ext_cap_offset);
|
|
|
|
if (XHCI_EXT_CAPS_ID(val) == XHCI_EXT_CAPS_LEGACY)
|
|
|
|
break;
|
|
|
|
ext_cap_offset = xhci_find_next_cap_offset(base, ext_cap_offset);
|
|
|
|
} while (1);
|
|
|
|
|
|
|
|
/* If the BIOS owns the HC, signal that the OS wants it, and wait */
|
|
|
|
if (val & XHCI_HC_BIOS_OWNED) {
|
2011-07-16 03:04:19 +00:00
|
|
|
writel(val | XHCI_HC_OS_OWNED, base + ext_cap_offset);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
/* Wait for 5 seconds with 10 microsecond polling interval */
|
|
|
|
timeout = handshake(base + ext_cap_offset, XHCI_HC_BIOS_OWNED,
|
|
|
|
0, 5000, 10);
|
|
|
|
|
|
|
|
/* Assume a buggy BIOS and take HC ownership anyway */
|
|
|
|
if (timeout) {
|
|
|
|
dev_warn(&pdev->dev, "xHCI BIOS handoff failed"
|
|
|
|
" (BIOS bug ?) %08x\n", val);
|
|
|
|
writel(val & ~XHCI_HC_BIOS_OWNED, base + ext_cap_offset);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-30 02:21:38 +00:00
|
|
|
val = readl(base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
|
|
|
|
/* Mask off (turn off) any enabled SMIs */
|
|
|
|
val &= XHCI_LEGACY_DISABLE_SMI;
|
|
|
|
/* Mask all SMI events bits, RW1C */
|
|
|
|
val |= XHCI_LEGACY_SMI_EVENTS;
|
|
|
|
/* Disable any BIOS SMIs and clear all SMI events*/
|
|
|
|
writel(val, base + ext_cap_offset + XHCI_LEGACY_CONTROL_OFFSET);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2012-08-22 16:53:18 +00:00
|
|
|
hc_init:
|
2013-07-23 08:35:47 +00:00
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_INTEL)
|
|
|
|
usb_enable_intel_xhci_ports(pdev);
|
2012-08-22 16:53:18 +00:00
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
op_reg_base = base + XHCI_HC_LENGTH(readl(base));
|
|
|
|
|
|
|
|
/* Wait for the host controller to be ready before writing any
|
|
|
|
* operational or runtime registers. Wait 5 seconds and no more.
|
|
|
|
*/
|
|
|
|
timeout = handshake(op_reg_base + XHCI_STS_OFFSET, XHCI_STS_CNR, 0,
|
|
|
|
5000, 10);
|
|
|
|
/* Assume a buggy HC and start HC initialization anyway */
|
|
|
|
if (timeout) {
|
|
|
|
val = readl(op_reg_base + XHCI_STS_OFFSET);
|
|
|
|
dev_warn(&pdev->dev,
|
|
|
|
"xHCI HW not ready after 5 sec (HC bug?) "
|
|
|
|
"status = 0x%x\n", val);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Send the halt and disable interrupts command */
|
|
|
|
val = readl(op_reg_base + XHCI_CMD_OFFSET);
|
|
|
|
val &= ~(XHCI_CMD_RUN | XHCI_IRQS);
|
|
|
|
writel(val, op_reg_base + XHCI_CMD_OFFSET);
|
|
|
|
|
|
|
|
/* Wait for the HC to halt - poll every 125 usec (one microframe). */
|
|
|
|
timeout = handshake(op_reg_base + XHCI_STS_OFFSET, XHCI_STS_HALT, 1,
|
|
|
|
XHCI_MAX_HALT_USEC, 125);
|
|
|
|
if (timeout) {
|
|
|
|
val = readl(op_reg_base + XHCI_STS_OFFSET);
|
|
|
|
dev_warn(&pdev->dev,
|
|
|
|
"xHCI HW did not halt within %d usec "
|
|
|
|
"status = 0x%x\n", XHCI_MAX_HALT_USEC, val);
|
|
|
|
}
|
|
|
|
|
|
|
|
iounmap(base);
|
|
|
|
}
|
2005-09-24 00:14:37 +00:00
|
|
|
|
2012-11-19 18:21:48 +00:00
|
|
|
static void quirk_usb_early_handoff(struct pci_dev *pdev)
|
2005-09-24 00:14:37 +00:00
|
|
|
{
|
2012-01-27 14:57:32 +00:00
|
|
|
/* Skip Netlogic mips SoC's internal PCI USB controller.
|
|
|
|
* This device does not need/support EHCI/OHCI handoff
|
|
|
|
*/
|
|
|
|
if (pdev->vendor == 0x184e) /* vendor Netlogic */
|
|
|
|
return;
|
2012-02-07 23:11:46 +00:00
|
|
|
if (pdev->class != PCI_CLASS_SERIAL_USB_UHCI &&
|
|
|
|
pdev->class != PCI_CLASS_SERIAL_USB_OHCI &&
|
|
|
|
pdev->class != PCI_CLASS_SERIAL_USB_EHCI &&
|
|
|
|
pdev->class != PCI_CLASS_SERIAL_USB_XHCI)
|
|
|
|
return;
|
2012-01-27 14:57:32 +00:00
|
|
|
|
2012-02-07 23:11:46 +00:00
|
|
|
if (pci_enable_device(pdev) < 0) {
|
|
|
|
dev_warn(&pdev->dev, "Can't enable PCI device, "
|
|
|
|
"BIOS handoff failed.\n");
|
|
|
|
return;
|
|
|
|
}
|
2005-10-19 16:52:02 +00:00
|
|
|
if (pdev->class == PCI_CLASS_SERIAL_USB_UHCI)
|
2005-09-24 00:14:37 +00:00
|
|
|
quirk_usb_handoff_uhci(pdev);
|
2005-10-19 16:52:02 +00:00
|
|
|
else if (pdev->class == PCI_CLASS_SERIAL_USB_OHCI)
|
2005-09-24 00:14:37 +00:00
|
|
|
quirk_usb_handoff_ohci(pdev);
|
2005-10-19 16:52:02 +00:00
|
|
|
else if (pdev->class == PCI_CLASS_SERIAL_USB_EHCI)
|
2005-09-24 00:14:37 +00:00
|
|
|
quirk_usb_disable_ehci(pdev);
|
2009-04-28 02:52:28 +00:00
|
|
|
else if (pdev->class == PCI_CLASS_SERIAL_USB_XHCI)
|
|
|
|
quirk_usb_handoff_xhci(pdev);
|
2012-02-07 23:11:46 +00:00
|
|
|
pci_disable_device(pdev);
|
2005-09-24 00:14:37 +00:00
|
|
|
}
|
2012-02-24 07:46:59 +00:00
|
|
|
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_ANY_ID, PCI_ANY_ID,
|
|
|
|
PCI_CLASS_SERIAL_USB, 8, quirk_usb_early_handoff);
|