1. 11 7月, 2012 6 次提交
    • S
      USB: Add a sysfs file to show LTM capabilities. · 024f117c
      Sarah Sharp 提交于
      USB 3.0 devices can optionally support Latency Tolerance Messaging
      (LTM).  Add a new sysfs file in the device directory to show whether a
      device is LTM capable.  This file will be present for both USB 2.0 and
      USB 3.0 devices.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      024f117c
    • S
      USB: Enable Latency Tolerance Messaging (LTM). · f74631e3
      Sarah Sharp 提交于
      USB 3.0 devices may optionally support a new feature called Latency
      Tolerance Messaging.  If both the xHCI host controller and the device
      support LTM, it should be turned on in order to give the system hardware
      a better clue about the latency tolerance values of its PCI devices.
      
      Once a Set Feature request to enable LTM is received, the USB 3.0 device
      will begin to send LTM updates as its buffers fill or empty, and it can
      tolerate more or less latency.
      
      The USB 3.0 spec, section C.4.2 says that LTM should be disabled just
      before the device is placed into suspend.  Then the device will send an
      updated LTM notification, so that the system doesn't think it should
      remain in an active state in order to satisfy the latency requirements
      of the suspended device.
      
      The Set and Clear Feature LTM enable command can only be sent to a
      configured device.  The device will respond with an error if that
      command is sent while it is in the Default or Addressed state.  Make
      sure to check udev->actconfig in usb_enable_ltm() and usb_disable_ltm(),
      and don't send those commands when the device is unconfigured.
      
      LTM should be enabled once a new configuration is installed in
      usb_set_configuration().  If we end up sending duplicate Set Feature LTM
      Enable commands on a switch from one installed configuration to another
      configuration, that should be harmless.
      
      Make sure that LTM is disabled before the device is unconfigured in
      usb_disable_device().  If no drivers are bound to the device, it doesn't
      make sense to allow the device to control the latency tolerance of the
      xHCI host controller.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f74631e3
    • S
      xhci: Export Latency Tolerance Messaging capabilities. · af3a23ef
      Sarah Sharp 提交于
      Some xHCI host controllers may have optional support for Latency
      Tolerance Messaging (LTM).  This allows USB 3.0 devices that support LTM
      to pass information about how much latency they can tolerate to the xHC.
      A PCI xHCI host will use this information to update the PCI Latency
      Tolerance Request (LTR) info.  The goal of this is to gather latency
      information for the system, to enable hardware-driven C states, and the
      shutting down of PLLs.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      af3a23ef
    • S
      USB: Fix LPM disable count mismatch on driver unbind. · 24971912
      Sarah Sharp 提交于
      When a user runs `echo 0 > bConfigurationValue` for a USB 3.0 device,
      usb_disable_device() is called.  This function disables all drivers,
      deallocates interfaces, and sets the device configuration value to 0
      (unconfigured).
      
      With the new scheme to ensure that unconfigured devices have LPM
      disabled, usb_disable_device() must call usb_unlocked_disable_lpm() once
      it unconfigures the device.
      
      This commit should be backported to kernels as old as 3.5, that contain
      the commit 8306095f "USB: Disable USB
      3.0 LPM in critical sections."
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      24971912
    • S
      USB: Disable LPM while the device is unconfigured. · 9cf65991
      Sarah Sharp 提交于
      The USB 3.0 Set/Clear Feature U1/U2 Enable cannot be sent to a device in
      the Default or Addressed state.  It can only be sent to a configured
      device.  Change the USB core to initialize the LPM disable count to 1
      (disabled), which reflects this limitation.
      
      Change usb_set_configuration() to ensure that if the device is
      unconfigured on entry, usb_lpm_disable() is not called.  This avoids
      sending the Clear Feature U1/U2 when the device is in the Addressed
      state.  When usb_set_configuration() exits with a successfully installed
      configuration, usb_lpm_enable() will be called.
      
      Once the new configuration is installed, make sure
      usb_set_configuration() only calls usb_enable_lpm() if the device moved
      to the Configured state.  If we have unconfigured the device by sending
      it a Set Configuration for config 0, don't enable LPM.
      
      This commit should be backported to kernels as old as 3.5, that contain
      the commit 8306095f "USB: Disable USB
      3.0 LPM in critical sections."
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      9cf65991
    • S
      USB: Fix LPM disable/enable during device reset. · 6d1d0513
      Sarah Sharp 提交于
      The USB 3.0 specification says that sending a Set Feature or Clear
      Feature for U1/U2 Enable is not a valid request when the device is in
      the Default or Addressed state.  It is only valid when the device is in
      the Configured state.
      
      The original LPM patch attempted to disable LPM after the device had
      been reset by hub_port_init(), before it had the configuration
      reinstalled.  The TI hub I tested with did not fail the Clear Feature
      U1/U2 Enable request that khubd sent while it was in the addressed
      state, which is why I didn't catch it.
      
      Move the LPM disable before the device reset, so that we can send the
      Clear Feature U1/U2 Enable successfully, and balance the LPM disable
      count.
      
      Also delete any calls to usb_enable_lpm() on error paths that lead to
      re-enumeration.  The calls will fail because the device isn't
      configured, and it's not useful to balance the LPM disable count because
      the usb_device is about to be destroyed before re-enumeration.
      
      Fix the early exit path ("done" label) to call usb_enable_lpm() to
      balance the LPM disable count.
      
      Note that calling usb_reset_and_verify_device() with an unconfigured
      device may fail on the first call to usb_disable_lpm().  That's because
      the LPM disable count is initialized to 0 (LPM enabled), and
      usb_disable_lpm() will attempt to send a Clear Feature U1/U2 request to
      a device in the Addressed state.  The next patch will fix that.
      
      This commit should be backported to kernels as old as 3.5, that contain
      the commit 8306095f "USB: Disable USB
      3.0 LPM in critical sections."
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      6d1d0513
  2. 10 7月, 2012 11 次提交
  3. 09 7月, 2012 1 次提交
    • A
      EHCI: centralize controller suspend/resume · c5cf9212
      Alan Stern 提交于
      This patch (as1563) removes a lot of duplicated code by moving the
      EHCI controller suspend/resume routines into the core driver, where
      the various platform drivers can invoke them as needed.
      
      Not only does this simplify these platform drivers, this also makes it
      easier for other platform drivers to add suspend/resume support in the
      future.
      
      Note: The patch does not touch the ehci-fsl.c file, because its
      approach to suspend and resume is so different from all the others.
      It will have to be handled specially by its maintainer.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c5cf9212
  4. 07 7月, 2012 13 次提交
  5. 02 7月, 2012 9 次提交