summaryrefslogtreecommitdiffstats
path: root/drivers/usb/host/xhci-pci.c
diff options
context:
space:
mode:
authorSarah Sharp <sarah.a.sharp@linux.intel.com>2012-05-09 10:55:03 -0700
committerSarah Sharp <sarah.a.sharp@linux.intel.com>2012-05-18 15:42:03 -0700
commit3b3db026414bba1c8f45c49d5eeaefd48d66e1ae (patch)
tree7ecc41b7c5e440b5da8671caa6e33fcd5cac9b27 /drivers/usb/host/xhci-pci.c
parent6538eafc7cb6b2d718d2539bef3158bfaad57468 (diff)
downloadop-kernel-dev-3b3db026414bba1c8f45c49d5eeaefd48d66e1ae.zip
op-kernel-dev-3b3db026414bba1c8f45c49d5eeaefd48d66e1ae.tar.gz
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>
Diffstat (limited to 'drivers/usb/host/xhci-pci.c')
-rw-r--r--drivers/usb/host/xhci-pci.c9
1 files changed, 9 insertions, 0 deletions
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 19e8921..890ba73 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -170,6 +170,13 @@ static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
if (retval)
goto put_usb3_hcd;
/* Roothub already marked as USB 3.0 speed */
+
+ /* 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;
+
return 0;
put_usb3_hcd:
@@ -293,6 +300,8 @@ static const struct hc_driver xhci_pci_hc_driver = {
*/
.update_device = xhci_update_device,
.set_usb2_hw_lpm = xhci_set_usb2_hardware_lpm,
+ .enable_usb3_lpm_timeout = xhci_enable_usb3_lpm_timeout,
+ .disable_usb3_lpm_timeout = xhci_disable_usb3_lpm_timeout,
};
/*-------------------------------------------------------------------------*/
OpenPOWER on IntegriCloud