2009-04-28 06:52:28 +04:00
|
|
|
/*
|
|
|
|
|
* xHCI host controller driver PCI Bus Glue.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 2008 Intel Corp.
|
|
|
|
|
*
|
|
|
|
|
* Author: Sarah Sharp
|
|
|
|
|
* Some code borrowed from the Linux EHCI driver.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
|
|
|
|
|
* or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
|
|
|
|
* for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
|
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/pci.h>
|
2011-04-25 19:54:28 +04:00
|
|
|
#include <linux/slab.h>
|
2011-07-04 00:09:31 +04:00
|
|
|
#include <linux/module.h>
|
2009-04-28 06:52:28 +04:00
|
|
|
|
|
|
|
|
#include "xhci.h"
|
|
|
|
|
|
2009-08-08 01:04:55 +04:00
|
|
|
/* Device for a quirk */
|
|
|
|
|
#define PCI_VENDOR_ID_FRESCO_LOGIC 0x1b73
|
|
|
|
|
#define PCI_DEVICE_ID_FRESCO_LOGIC_PDK 0x1000
|
|
|
|
|
|
2011-06-16 01:47:21 +04:00
|
|
|
#define PCI_VENDOR_ID_ETRON 0x1b6f
|
|
|
|
|
#define PCI_DEVICE_ID_ASROCK_P67 0x7023
|
|
|
|
|
|
2009-04-28 06:52:28 +04:00
|
|
|
static const char hcd_name[] = "xhci_hcd";
|
|
|
|
|
|
|
|
|
|
/* called after powerup, by probe or system-pm "wakeup" */
|
|
|
|
|
static int xhci_pci_reinit(struct xhci_hcd *xhci, struct pci_dev *pdev)
|
|
|
|
|
{
|
|
|
|
|
/*
|
|
|
|
|
* TODO: Implement finding debug ports later.
|
|
|
|
|
* TODO: see if there are any quirks that need to be added to handle
|
|
|
|
|
* new extended capabilities.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* PCI Memory-Write-Invalidate cycle support is optional (uncommon) */
|
|
|
|
|
if (!pci_set_mwi(pdev))
|
|
|
|
|
xhci_dbg(xhci, "MWI active\n");
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Finished xhci_pci_reinit\n");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-24 01:20:00 +04:00
|
|
|
static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(dev);
|
|
|
|
|
|
2009-08-08 01:04:55 +04:00
|
|
|
/* Look for vendor-specific quirks */
|
|
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_FRESCO_LOGIC &&
|
2011-06-02 22:33:02 +04:00
|
|
|
pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK) {
|
|
|
|
|
if (pdev->revision == 0x0) {
|
2009-08-08 01:04:55 +04:00
|
|
|
xhci->quirks |= XHCI_RESET_EP_QUIRK;
|
|
|
|
|
xhci_dbg(xhci, "QUIRK: Fresco Logic xHC needs configure"
|
|
|
|
|
" endpoint cmd after reset endpoint\n");
|
2011-06-02 22:33:02 +04:00
|
|
|
}
|
|
|
|
|
/* Fresco Logic confirms: all revisions of this chip do not
|
|
|
|
|
* support MSI, even though some of them claim to in their PCI
|
|
|
|
|
* capabilities.
|
|
|
|
|
*/
|
|
|
|
|
xhci->quirks |= XHCI_BROKEN_MSI;
|
|
|
|
|
xhci_dbg(xhci, "QUIRK: Fresco Logic revision %u "
|
|
|
|
|
"has broken MSI implementation\n",
|
|
|
|
|
pdev->revision);
|
xhci: Add new short TX quirk for Fresco Logic host.
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-08 20:22:49 +04:00
|
|
|
xhci->quirks |= XHCI_TRUST_TX_LENGTH;
|
2009-08-08 01:04:55 +04:00
|
|
|
}
|
2011-06-02 22:33:02 +04:00
|
|
|
|
2010-05-25 00:25:28 +04:00
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_NEC)
|
|
|
|
|
xhci->quirks |= XHCI_NEC_HOST;
|
2009-08-08 01:04:55 +04:00
|
|
|
|
xHCI: AMD isoc link TRB chain bit quirk
Setting the chain (CH) bit in the link TRB of isochronous transfer rings
is required by AMD 0.96 xHCI host controller to successfully transverse
multi-TRB TD that span through different memory segments.
When a Missed Service Error event occurs, if the chain bit is not set in
the link TRB and the host skips TDs which just across a link TRB, the
host may falsely recognize the link TRB as a normal TRB. You can see
this may cause big trouble - the host does not jump to the right address
which is pointed by the link TRB, but continue fetching the memory which
is after the link TRB address, which may not even belong to the host,
and the result cannot be predicted.
This causes some big problems. Without the former patch I sent: "xHCI:
prevent infinite loop when processing MSE event", the system may hang.
With that patch applied, system does not hang, but the host still access
wrong memory address and isoc transfer will fail. With this patch,
isochronous transfer works as expected.
This patch should be applied to kernels as old as 2.6.36, which was when
the first isochronous support was added for the xHCI host controller.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-24 01:19:54 +04:00
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_AMD && xhci->hci_version == 0x96)
|
|
|
|
|
xhci->quirks |= XHCI_AMD_0x96_HOST;
|
|
|
|
|
|
2011-03-22 12:08:14 +03:00
|
|
|
/* AMD PLL quirk */
|
|
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_AMD && usb_amd_find_chipset_info())
|
|
|
|
|
xhci->quirks |= XHCI_AMD_PLL_FIX;
|
2012-05-17 00:36:24 +04:00
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
|
|
|
|
|
xhci->quirks |= XHCI_LPM_SUPPORT;
|
|
|
|
|
xhci->quirks |= XHCI_INTEL_HOST;
|
|
|
|
|
}
|
2011-05-25 21:43:56 +04:00
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
|
|
|
|
|
pdev->device == PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI) {
|
|
|
|
|
xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-12 03:14:58 +04:00
|
|
|
xhci->quirks |= XHCI_EP_LIMIT_QUIRK;
|
|
|
|
|
xhci->limit_active_eps = 64;
|
2011-09-02 22:05:54 +04:00
|
|
|
xhci->quirks |= XHCI_SW_BW_CHECKING;
|
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 19:59:30 +04:00
|
|
|
/*
|
|
|
|
|
* PPT desktop boards DH77EB and DH77DF will power back on after
|
|
|
|
|
* a few seconds of being shutdown. The fix for this is to
|
|
|
|
|
* switch the ports from xHCI to EHCI on shutdown. We can't use
|
|
|
|
|
* DMI information to find those particular boards (since each
|
|
|
|
|
* vendor will change the board name), so we have to key off all
|
|
|
|
|
* PPT chipsets.
|
|
|
|
|
*/
|
|
|
|
|
xhci->quirks |= XHCI_SPURIOUS_REBOOT;
|
xhci: Intel Panther Point BEI quirk.
When a device with an isochronous endpoint is behind a hub plugged into
the Intel Panther Point xHCI host controller, and the driver submits
multiple frames per URB, the xHCI driver will set the Block Event
Interrupt (BEI) flag on all but the last TD for the URB. This causes
the host controller to place an event on the event ring, but not send an
interrupt. When the last TD for the URB completes, BEI is cleared, and
we get an interrupt for the whole URB.
However, under a Panther Point xHCI host controller, if the parent hub
is unplugged when one or more events from transfers with BEI set are on
the event ring, a port status change event is placed on the event ring,
but no interrupt is generated. This means URBs stop completing, and the
USB device disconnect is not noticed. Something like a USB headset will
cause mplayer to hang when the device is disconnected.
If another transfer is sent (such as running `sudo lsusb -v`), the next
transfer event seems to "unstick" the event ring, the xHCI driver gets
an interrupt, and the disconnect is reported to the USB core.
The fix is not to use the BEI flag under the Panther Point xHCI host.
This will impact power consumption and system responsiveness, because
the xHCI driver will receive an interrupt for every frame in all
isochronous URBs instead of once per URB.
Intel chipset developers confirm that this bug will be hit if the BEI
flag is used on any endpoint, not just ones that are behind a hub.
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>
Cc: stable@vger.kernel.org
2012-09-20 03:27:26 +04:00
|
|
|
xhci->quirks |= XHCI_AVOID_BEI;
|
2011-05-25 21:43:56 +04:00
|
|
|
}
|
2011-06-16 01:47:21 +04:00
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
|
|
|
|
|
pdev->device == PCI_DEVICE_ID_ASROCK_P67) {
|
|
|
|
|
xhci->quirks |= XHCI_RESET_ON_RESUME;
|
|
|
|
|
xhci_dbg(xhci, "QUIRK: Resetting on resume\n");
|
2012-07-03 00:36:23 +04:00
|
|
|
xhci->quirks |= XHCI_TRUST_TX_LENGTH;
|
2011-06-16 01:47:21 +04:00
|
|
|
}
|
2012-03-29 11:47:50 +04:00
|
|
|
if (pdev->vendor == PCI_VENDOR_ID_VIA)
|
|
|
|
|
xhci->quirks |= XHCI_RESET_ON_RESUME;
|
2011-09-24 01:20:00 +04:00
|
|
|
}
|
2011-03-22 12:08:14 +03:00
|
|
|
|
2011-09-24 01:20:00 +04:00
|
|
|
/* called during probe() after chip reset completes */
|
|
|
|
|
static int xhci_pci_setup(struct usb_hcd *hcd)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
|
|
|
|
|
int retval;
|
2009-04-28 06:52:28 +04:00
|
|
|
|
2011-09-24 01:20:00 +04:00
|
|
|
retval = xhci_gen_setup(hcd, xhci_pci_quirks);
|
2009-04-28 06:52:28 +04:00
|
|
|
if (retval)
|
2011-09-24 01:20:00 +04:00
|
|
|
return retval;
|
2010-07-30 09:13:22 +04:00
|
|
|
|
2011-09-24 01:20:00 +04:00
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
if (!usb_hcd_is_primary_hcd(hcd))
|
|
|
|
|
return 0;
|
2009-04-28 06:52:28 +04:00
|
|
|
|
|
|
|
|
pci_read_config_byte(pdev, XHCI_SBRN_OFFSET, &xhci->sbrn);
|
|
|
|
|
xhci_dbg(xhci, "Got SBRN %u\n", (unsigned int) xhci->sbrn);
|
|
|
|
|
|
|
|
|
|
/* Find any debug ports */
|
2010-10-26 22:03:44 +04:00
|
|
|
retval = xhci_pci_reinit(xhci, pdev);
|
|
|
|
|
if (!retval)
|
|
|
|
|
return retval;
|
|
|
|
|
|
|
|
|
|
kfree(xhci);
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
/*
|
|
|
|
|
* We need to register our own PCI probe function (instead of the USB core's
|
|
|
|
|
* function) in order to create a second roothub under xHCI.
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
|
|
|
|
|
{
|
|
|
|
|
int retval;
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
struct hc_driver *driver;
|
|
|
|
|
struct usb_hcd *hcd;
|
|
|
|
|
|
|
|
|
|
driver = (struct hc_driver *)id->driver_data;
|
|
|
|
|
/* Register the USB 2.0 roothub.
|
|
|
|
|
* FIXME: USB core must know to register the USB 2.0 roothub first.
|
|
|
|
|
* This is sort of silly, because we could just set the HCD driver flags
|
|
|
|
|
* to say USB 2.0, but I'm not sure what the implications would be in
|
|
|
|
|
* the other parts of the HCD code.
|
|
|
|
|
*/
|
|
|
|
|
retval = usb_hcd_pci_probe(dev, id);
|
|
|
|
|
|
|
|
|
|
if (retval)
|
|
|
|
|
return retval;
|
|
|
|
|
|
|
|
|
|
/* USB 2.0 roothub is stored in the PCI device now. */
|
|
|
|
|
hcd = dev_get_drvdata(&dev->dev);
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
xhci->shared_hcd = usb_create_shared_hcd(driver, &dev->dev,
|
|
|
|
|
pci_name(dev), hcd);
|
|
|
|
|
if (!xhci->shared_hcd) {
|
|
|
|
|
retval = -ENOMEM;
|
|
|
|
|
goto dealloc_usb2_hcd;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Set the xHCI pointer before xhci_pci_setup() (aka hcd_driver.reset)
|
|
|
|
|
* is called by usb_add_hcd().
|
|
|
|
|
*/
|
|
|
|
|
*((struct xhci_hcd **) xhci->shared_hcd->hcd_priv) = xhci;
|
|
|
|
|
|
|
|
|
|
retval = usb_add_hcd(xhci->shared_hcd, dev->irq,
|
2011-09-07 12:10:52 +04:00
|
|
|
IRQF_SHARED);
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
if (retval)
|
|
|
|
|
goto put_usb3_hcd;
|
|
|
|
|
/* Roothub already marked as USB 3.0 speed */
|
xhci: Add infrastructure for host-specific LPM policies.
The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific. Here are a few examples of why it's
host specific:
1. Setting the U1/U2 timeout too short may cause the link to go into
U1/U2 in between service intervals, which some hosts may tolerate,
and some may not.
2. The host controller has to modify its bus schedule in order to take
into account the Maximum Exit Latency (MEL) to bring all the links
from the host to the device into U0. If the MEL is too big, and it
takes too long to bring the links into an active state, the host
controller may not be able to service periodic endpoints in time.
3. Host controllers may also have scheduling limitations that force
them to disable U1 or U2 if a USB device is behind too many tiers of
hubs.
We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller. However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands. Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.
Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.
To extend the framework, they will need to:
- Modify the PCI init code to add a new xhci->quirk for their host, and
set the XHCI_LPM_SUPPORT quirk flag.
- Add their own vendor-specific hooks, like the ones that will be added
in xhci_call_host_update_timeout_for_endpoint() and
xhci_check_tier_policy()
- Make the LPM enable/disable methods call those functions based on the
xhci->quirk for their host.
An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 21:55:03 +04:00
|
|
|
|
|
|
|
|
/* We know the LPM timeout algorithms for this host, let the USB core
|
|
|
|
|
* enable and disable LPM for devices under the USB 3.0 roothub.
|
|
|
|
|
*/
|
|
|
|
|
if (xhci->quirks & XHCI_LPM_SUPPORT)
|
|
|
|
|
hcd_to_bus(xhci->shared_hcd)->root_hub->lpm_capable = 1;
|
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
put_usb3_hcd:
|
|
|
|
|
usb_put_hcd(xhci->shared_hcd);
|
|
|
|
|
dealloc_usb2_hcd:
|
|
|
|
|
usb_hcd_pci_remove(dev);
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-26 22:03:44 +04:00
|
|
|
static void xhci_pci_remove(struct pci_dev *dev)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
|
|
|
|
|
xhci = hcd_to_xhci(pci_get_drvdata(dev));
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
if (xhci->shared_hcd) {
|
|
|
|
|
usb_remove_hcd(xhci->shared_hcd);
|
|
|
|
|
usb_put_hcd(xhci->shared_hcd);
|
|
|
|
|
}
|
2010-10-26 22:03:44 +04:00
|
|
|
usb_hcd_pci_remove(dev);
|
|
|
|
|
kfree(xhci);
|
2009-04-28 06:52:28 +04:00
|
|
|
}
|
|
|
|
|
|
2010-10-14 18:23:06 +04:00
|
|
|
#ifdef CONFIG_PM
|
|
|
|
|
static int xhci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
int retval = 0;
|
|
|
|
|
|
2011-03-07 22:24:07 +03:00
|
|
|
if (hcd->state != HC_STATE_SUSPENDED ||
|
|
|
|
|
xhci->shared_hcd->state != HC_STATE_SUSPENDED)
|
2010-10-14 18:23:06 +04:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
retval = xhci_suspend(xhci);
|
|
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int xhci_pci_resume(struct usb_hcd *hcd, bool hibernated)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
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 20:57:15 +03:00
|
|
|
struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
|
2010-10-14 18:23:06 +04:00
|
|
|
int retval = 0;
|
|
|
|
|
|
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 20:57:15 +03:00
|
|
|
/* The BIOS on systems with the Intel Panther Point chipset may or may
|
|
|
|
|
* not support xHCI natively. That means that during system resume, it
|
|
|
|
|
* may switch the ports back to EHCI so that users can use their
|
|
|
|
|
* keyboard to select a kernel from GRUB after resume from hibernate.
|
|
|
|
|
*
|
|
|
|
|
* The BIOS is supposed to remember whether the OS had xHCI ports
|
|
|
|
|
* enabled before resume, and switch the ports back to xHCI when the
|
|
|
|
|
* BIOS/OS semaphore is written, but we all know we can't trust BIOS
|
|
|
|
|
* writers.
|
|
|
|
|
*
|
|
|
|
|
* Unconditionally switch the ports back to xHCI after a system resume.
|
|
|
|
|
* We can't tell whether the EHCI or xHCI controller will be resumed
|
|
|
|
|
* first, so we have to do the port switchover in both drivers. Writing
|
|
|
|
|
* a '1' to the port switchover registers should have no effect if the
|
|
|
|
|
* port was already switched over.
|
|
|
|
|
*/
|
|
|
|
|
if (usb_is_intel_switchable_xhci(pdev))
|
|
|
|
|
usb_enable_xhci_ports(pdev);
|
|
|
|
|
|
2010-10-14 18:23:06 +04:00
|
|
|
retval = xhci_resume(xhci, hibernated);
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
#endif /* CONFIG_PM */
|
|
|
|
|
|
2009-04-28 06:52:28 +04:00
|
|
|
static const struct hc_driver xhci_pci_hc_driver = {
|
|
|
|
|
.description = hcd_name,
|
|
|
|
|
.product_desc = "xHCI Host Controller",
|
2010-10-26 22:03:44 +04:00
|
|
|
.hcd_priv_size = sizeof(struct xhci_hcd *),
|
2009-04-28 06:52:28 +04:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* generic hardware linkage
|
|
|
|
|
*/
|
2009-04-28 06:53:56 +04:00
|
|
|
.irq = xhci_irq,
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
.flags = HCD_MEMORY | HCD_USB3 | HCD_SHARED,
|
2009-04-28 06:52:28 +04:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* basic lifecycle operations
|
|
|
|
|
*/
|
|
|
|
|
.reset = xhci_pci_setup,
|
|
|
|
|
.start = xhci_run,
|
2010-10-14 18:23:06 +04:00
|
|
|
#ifdef CONFIG_PM
|
|
|
|
|
.pci_suspend = xhci_pci_suspend,
|
|
|
|
|
.pci_resume = xhci_pci_resume,
|
|
|
|
|
#endif
|
2009-04-28 06:52:28 +04:00
|
|
|
.stop = xhci_stop,
|
|
|
|
|
.shutdown = xhci_shutdown,
|
|
|
|
|
|
2009-04-28 06:57:38 +04:00
|
|
|
/*
|
|
|
|
|
* managing i/o requests and associated device resources
|
|
|
|
|
*/
|
2009-04-28 06:58:01 +04:00
|
|
|
.urb_enqueue = xhci_urb_enqueue,
|
|
|
|
|
.urb_dequeue = xhci_urb_dequeue,
|
2009-04-28 06:57:38 +04:00
|
|
|
.alloc_dev = xhci_alloc_dev,
|
|
|
|
|
.free_dev = xhci_free_dev,
|
2010-04-05 21:55:58 +04:00
|
|
|
.alloc_streams = xhci_alloc_streams,
|
|
|
|
|
.free_streams = xhci_free_streams,
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 06:58:38 +04:00
|
|
|
.add_endpoint = xhci_add_endpoint,
|
|
|
|
|
.drop_endpoint = xhci_drop_endpoint,
|
2009-07-27 23:03:15 +04:00
|
|
|
.endpoint_reset = xhci_endpoint_reset,
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 06:58:38 +04:00
|
|
|
.check_bandwidth = xhci_check_bandwidth,
|
|
|
|
|
.reset_bandwidth = xhci_reset_bandwidth,
|
2009-04-28 06:57:38 +04:00
|
|
|
.address_device = xhci_address_device,
|
2009-09-04 21:53:24 +04:00
|
|
|
.update_hub_device = xhci_update_hub_device,
|
2010-10-14 18:22:48 +04:00
|
|
|
.reset_device = xhci_discover_or_reset_device,
|
2009-04-28 06:57:38 +04:00
|
|
|
|
2009-04-28 06:52:28 +04:00
|
|
|
/*
|
|
|
|
|
* scheduling support
|
|
|
|
|
*/
|
|
|
|
|
.get_frame_number = xhci_get_frame,
|
|
|
|
|
|
2009-04-28 06:57:12 +04:00
|
|
|
/* Root hub support */
|
|
|
|
|
.hub_control = xhci_hub_control,
|
|
|
|
|
.hub_status_data = xhci_hub_status_data,
|
2010-10-14 18:23:03 +04:00
|
|
|
.bus_suspend = xhci_bus_suspend,
|
|
|
|
|
.bus_resume = xhci_bus_resume,
|
2011-09-24 01:19:51 +04:00
|
|
|
/*
|
|
|
|
|
* call back when device connected and addressed
|
|
|
|
|
*/
|
|
|
|
|
.update_device = xhci_update_device,
|
2011-09-24 01:19:52 +04:00
|
|
|
.set_usb2_hw_lpm = xhci_set_usb2_hardware_lpm,
|
xhci: Add infrastructure for host-specific LPM policies.
The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific. Here are a few examples of why it's
host specific:
1. Setting the U1/U2 timeout too short may cause the link to go into
U1/U2 in between service intervals, which some hosts may tolerate,
and some may not.
2. The host controller has to modify its bus schedule in order to take
into account the Maximum Exit Latency (MEL) to bring all the links
from the host to the device into U0. If the MEL is too big, and it
takes too long to bring the links into an active state, the host
controller may not be able to service periodic endpoints in time.
3. Host controllers may also have scheduling limitations that force
them to disable U1 or U2 if a USB device is behind too many tiers of
hubs.
We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller. However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands. Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.
Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.
To extend the framework, they will need to:
- Modify the PCI init code to add a new xhci->quirk for their host, and
set the XHCI_LPM_SUPPORT quirk flag.
- Add their own vendor-specific hooks, like the ones that will be added
in xhci_call_host_update_timeout_for_endpoint() and
xhci_check_tier_policy()
- Make the LPM enable/disable methods call those functions based on the
xhci->quirk for their host.
An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 21:55:03 +04:00
|
|
|
.enable_usb3_lpm_timeout = xhci_enable_usb3_lpm_timeout,
|
|
|
|
|
.disable_usb3_lpm_timeout = xhci_disable_usb3_lpm_timeout,
|
2009-04-28 06:52:28 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
|
|
/* PCI driver selection metadata; PCI hotplugging uses this */
|
|
|
|
|
static const struct pci_device_id pci_ids[] = { {
|
|
|
|
|
/* handle any USB 3.0 xHCI controller */
|
|
|
|
|
PCI_DEVICE_CLASS(PCI_CLASS_SERIAL_USB_XHCI, ~0),
|
|
|
|
|
.driver_data = (unsigned long) &xhci_pci_hc_driver,
|
|
|
|
|
},
|
|
|
|
|
{ /* end: all zeroes */ }
|
|
|
|
|
};
|
|
|
|
|
MODULE_DEVICE_TABLE(pci, pci_ids);
|
|
|
|
|
|
|
|
|
|
/* pci driver glue; this is a "new style" PCI driver module */
|
|
|
|
|
static struct pci_driver xhci_pci_driver = {
|
|
|
|
|
.name = (char *) hcd_name,
|
|
|
|
|
.id_table = pci_ids,
|
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 22:21:10 +03:00
|
|
|
.probe = xhci_pci_probe,
|
2010-10-26 22:03:44 +04:00
|
|
|
.remove = xhci_pci_remove,
|
2009-04-28 06:52:28 +04:00
|
|
|
/* suspend and resume implemented later */
|
|
|
|
|
|
|
|
|
|
.shutdown = usb_hcd_pci_shutdown,
|
2010-10-14 18:23:06 +04:00
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
|
.driver = {
|
|
|
|
|
.pm = &usb_hcd_pci_pm_ops
|
|
|
|
|
},
|
|
|
|
|
#endif
|
2009-04-28 06:52:28 +04:00
|
|
|
};
|
|
|
|
|
|
2011-09-24 01:20:02 +04:00
|
|
|
int __init xhci_register_pci(void)
|
2009-04-28 06:52:28 +04:00
|
|
|
{
|
|
|
|
|
return pci_register_driver(&xhci_pci_driver);
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-16 22:34:11 +04:00
|
|
|
void xhci_unregister_pci(void)
|
2009-04-28 06:52:28 +04:00
|
|
|
{
|
|
|
|
|
pci_unregister_driver(&xhci_pci_driver);
|
|
|
|
|
}
|
