1. 25 6月, 2012 2 次提交
  2. 14 6月, 2012 1 次提交
  3. 05 6月, 2012 1 次提交
  4. 22 5月, 2012 3 次提交
    • S
      xhci: Fix DIV_ROUND_UP compile error. · c88db160
      Sarah Sharp 提交于
      Fengguang reports that the xHCI driver isn't linked properly on his
      machine:
      
      ERROR: "__udivdi3" [drivers/usb/host/xhci-hcd.ko] undefined!
      ERROR: "handle_edge_irq" [drivers/gpio/gpio-pch.ko] undefined!
      ERROR: "irq_to_desc" [drivers/gpio/gpio-pch.ko] undefined!
      
      The driver compiles fine on my 64-bit box (gcc version 4.6.1).
      Fengguang thinks it's because the xHCI driver was using DIV_ROUND_UP()
      instead of DIV_ROUND_UP_ULL() with arguments that were unsigned long
      long variables.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NWu Fengguang <wfg@linux.intel.com>
      c88db160
    • S
      xhci: Fix compile with CONFIG_USB_SUSPEND=n · b01bcbf7
      Sarah Sharp 提交于
      The USB 2.0 Link PM code is conditionally compiled when
      CONFIG_USB_SUSPEND=y.  I believe that's a mistake, since Link PM is not
      directly related to USB device suspend and Link PM is implemented
      without relying on any of the suspend code in the USB core.  For now,
      keep the USB 2.0 Link PM code conditionally compiled if
      CONFIG_USB_SUSPEND=y.
      
      This patch does move the code to implement USB 3.0 Link PM out of the
      xHCI driver #ifdefs for CONFIG_USB_SUSPEND and moves it into a section
      dependent on CONFIG_PM.  The USB core functions for USB 3.0 Link PM are
      already conditionally compiled when CONFIG_PM=y.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      b01bcbf7
    • S
      USB: Fix core compile with CONFIG_USB_SUSPEND=n · e9261fb6
      Sarah Sharp 提交于
      When CONFIG_PM=n, make sure that the usb_[unlocked_][en/dis]able_lpm
      declarations are visible in include/linux/usb.h, and exported from
      drivers/usb/core/hub.c.
      
      Before this patch, if CONFIG_USB_SUSPEND was turned off, it would cause
      build errors:
      
      drivers/usb/core/hub.c: In function 'usb_disable_lpm':
      drivers/usb/core/hub.c:3394:2: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration]
      drivers/usb/core/hub.c: At top level:
      drivers/usb/core/hub.c:3424:6: warning: conflicting types for 'usb_enable_lpm' [enabled by default]
      drivers/usb/core/hub.c:3394:2: note: previous implicit declaration of 'usb_enable_lpm' was here
      drivers/usb/core/driver.c: In function 'usb_probe_interface':
      drivers/usb/core/driver.c:339:2: error: implicit declaration of function 'usb_unlocked_disable_lpm' [-Werror=implicit-function-declaration]
      drivers/usb/core/driver.c:364:3: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration]
      drivers/usb/core/message.c: In function 'usb_set_interface':
      drivers/usb/core/message.c:1314:2: error: implicit declaration of function 'usb_disable_lpm' [-Werror=implicit-function-declaration]
      drivers/usb/core/message.c:1323:3: error: implicit declaration of function 'usb_enable_lpm' [-Werror=implicit-function-declaration]
      drivers/usb/core/message.c:1368:2: error: implicit declaration of function 'usb_unlocked_enable_lpm' [-Werror=implicit-function-declaration]
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Reported-by: NChen Peter-B29397 <B29397@freescale.com>
      e9261fb6
  5. 21 5月, 2012 1 次提交
  6. 20 5月, 2012 1 次提交
    • M
      USB: EHCI: fix command register configuration lost problem · 1c01f1d9
      Ming Lei 提交于
      The 3d9545cc(EHCI: maintain the
      ehci->command value properly) introducs one command register
      configuration lost problem by the below line in ehci_reset:
      
      	ehci->command = ehci_readl(ehci, &ehci->regs->command);
      
      After writting RESET into command register, it is restored to
      its default value per EHCI spec[1], so the previous configuration
      will be lost, and may introduce some problems reported recently:
      	- imx51 Babbage board detect usb hub failed[2], reported
      	by Richard Zhao.
      	- mouse and keyboard hangs in linux-next found by
      	Dan Carpenter and Greg-KH.
      
      So this patch just removes the line to fix these problems, and
      keep configurating command register consistent as before the commit
      3d9545cc(EHCI: maintain the ehci->command value properly).
      
      [1], 4.1 Host Controller Initialization of EHCI Specification 1.0
      [2], failed dmesg log:
      	usb 1-1: new high-speed USB device number 2 using mxc-ehci
      	hub 1-1:1.0: USB hub found
      	hub 1-1:1.0: 7 ports detected
      	mxc-ehci mxc-ehci.1: fatal error
      	mxc-ehci mxc-ehci.1: HC died; cleaning up
      	mxc-ehci mxc-ehci.1: force halt; handshake f5780344 00004000 00004000 -> -110
      	mxc-ehci mxc-ehci.1: HC died; cleaning up
      	usb 1-1: USB disconnect, device number 2
      Reported-by: NRichard Zhao <richard.zhao@freescale.com>
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Reported-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Chen Peter-B29397 <B29397@freescale.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NMing Lei <ming.lei@canonical.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1c01f1d9
  7. 19 5月, 2012 15 次提交
    • H
      USB: Remove races in devio.c · 4e09dcf2
      Huajun Li 提交于
      There exist races in devio.c, below is one case,
      and there are similar races in destroy_async()
      and proc_unlinkurb().  Remove these races.
      
       cancel_bulk_urbs()        async_completed()
      -------------------                -----------------------
       spin_unlock(&ps->lock);
      
                                 list_move_tail(&as->asynclist,
      		                    &ps->async_completed);
      
                                 wake_up(&ps->wait);
      
                                 Lead to free_async() be triggered,
                                 then urb and 'as' will be freed.
      
       usb_unlink_urb(as->urb);
       ===> refer to the freed 'as'
      Signed-off-by: NHuajun Li <huajun.li.lee@gmail.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Oncaphillis <oncaphillis@snafu.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e09dcf2
    • H
      USB: ehci-platform: remove update_device · 8377c94f
      Hauke Mehrtens 提交于
      The update_device callback is not needed and the function used here is
      from the pci ehci driver. Without this patch we get a compile error if
      ehci-platform is compiled without ehci-pci.
      Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
      Cc: stable <stable@vger.kernel.org> [3.4]
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8377c94f
    • S
      USB: Disable hub-initiated LPM for comms devices. · e1f12eb6
      Sarah Sharp 提交于
      Hub-initiated LPM is not good for USB communications devices.  Comms
      devices should be able to tell when their link can go into a lower power
      state, because they know when an incoming transmission is finished.
      Ideally, these devices would slam their links into a lower power state,
      using the device-initiated LPM, after finishing the last packet of their
      data transfer.
      
      If we enable the idle timeouts for the parent hubs to enable
      hub-initiated LPM, we will get a lot of useless LPM packets on the bus
      as the devices reject LPM transitions when they're in the middle of
      receiving data.  Worse, some devices might blindly accept the
      hub-initiated LPM and power down their radios while they're in the
      middle of receiving a transmission.
      
      The Intel Windows folks are disabling hub-initiated LPM for all USB
      communications devices under a xHCI USB 3.0 host.  In order to keep
      the Linux behavior as close as possible to Windows, we need to do the
      same in Linux.
      
      Set the disable_hub_initiated_lpm flag for for all USB communications
      drivers.  I know there aren't currently any USB 3.0 devices that
      implement these class specifications, but we should be ready if they do.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Gustavo Padovan <gustavo@padovan.org>
      Cc: Johan Hedberg <johan.hedberg@gmail.com>
      Cc: Hansjoerg Lipp <hjlipp@web.de>
      Cc: Tilman Schmidt <tilman@imap.cc>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: Peter Korsgaard <jacmet@sunsite.dk>
      Cc: Jan Dumon <j.dumon@option.com>
      Cc: Petko Manolov <petkan@users.sourceforge.net>
      Cc: Steve Glendinning <steve.glendinning@smsc.com>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
      Cc: Jouni Malinen <jouni@qca.qualcomm.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
      Cc: Christian Lamparter <chunkeey@googlemail.com>
      Cc: Brett Rudley <brudley@broadcom.com>
      Cc: Roland Vossen <rvossen@broadcom.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: "Franky (Zhenhui) Lin" <frankyl@broadcom.com>
      Cc: Kan Yan <kanyan@broadcom.com>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Cc: Ivo van Doorn <IvDoorn@gmail.com>
      Cc: Gertjan van Wingerde <gwingerde@gmail.com>
      Cc: Helmut Schaa <helmut.schaa@googlemail.com>
      Cc: Herton Ronaldo Krzesinski <herton@canonical.com>
      Cc: Hin-Tak Leung <htl10@users.sourceforge.net>
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Cc: Chaoming Li <chaoming_li@realsil.com.cn>
      Cc: Daniel Drake <dsd@gentoo.org>
      Cc: Ulrich Kunitz <kune@deine-taler.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      e1f12eb6
    • S
      xhci: Add Intel U1/U2 timeout policy. · e3567d2c
      Sarah Sharp 提交于
      All Intel xHCI host controllers support USB 3.0 Link Power Management.
      
      The Panther Point xHCI host controller needs the xHCI driver to
      calculate the U1 and U2 timeout values, because it will blindly accept a
      MEL that would cause scheduling issues.
      
      The Lynx Point xHCI host controller will reject MEL values that are too
      high, but internally it implements the same algorithm that is needed for
      Panther Point xHCI.
      
      Simplify the code paths by just having the xHCI driver calculate what
      the U1/U2 timeouts should be.  Comments on the policy are in the code.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      e3567d2c
    • S
      xhci: Add infrastructure for host-specific LPM policies. · 3b3db026
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      3b3db026
    • S
      xhci: Reserve one command for USB3 LPM disable. · dbc33303
      Sarah Sharp 提交于
      We want to do everything we can to ensure that USB 3.0 Link Power
      Management (LPM) can be disabled when it is enabled.  If LPM can't be
      disabled, we can't suspend USB 3.0 devices, or reset them.  To make sure
      we can submit the command to disable LPM, allocate a command in the
      xhci_hcd structure, and reserve one TRB on the command ring.
      
      We only need one command per xHCI driver instance, because LPM is only
      disabled or enabled while the USB core is holding the bandwidth_mutex
      that is shared between the xHCI USB 2.0 and USB 3.0 roothubs.  The
      bandwidth_mutex will be held until the command completes, or times out.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      dbc33303
    • S
      xhci: Some Evaluate Context commands must succeed. · 4b266541
      Sarah Sharp 提交于
      The upcoming USB 3.0 Link PM patches will introduce new API to enable
      and disable low-power link states.  We must be able to disable LPM in
      order to reset a device, or place the device into U3 (device suspend).
      Therefore, we need to make sure the Evaluate Context command to disable
      the LPM timeouts can't fail due to there being no room on the command
      ring.
      
      Introduce a new flag to the function that queues the Evaluate Context
      command, command_must_succeed.  This tells the ring handler that a TRB
      has already been reserved for the command (by incrementing
      xhci->cmd_ring_reserved_trbs), and basically ensures that prepare_ring()
      won't fail.  A similar flag was already implemented for the Configure
      Endpoint command queuing function.
      
      All functions that currently call xhci_configure_endpoint() to issue an
      Evaluate Context command pass "false" for the "must_succeed" parameter,
      so this patch should have no effect on current xHCI driver behavior.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      4b266541
    • S
      USB: Disable USB 3.0 LPM in critical sections. · 8306095f
      Sarah Sharp 提交于
      There are several places where the USB core needs to disable USB 3.0
      Link PM:
       - usb_bind_interface
       - usb_unbind_interface
       - usb_driver_claim_interface
       - usb_port_suspend/usb_port_resume
       - usb_reset_and_verify_device
       - usb_set_interface
       - usb_reset_configuration
       - usb_set_configuration
      
      Use the new LPM disable/enable functions to temporarily disable LPM
      around these critical sections.
      
      We need to protect the critical section around binding and unbinding USB
      interface drivers.  USB drivers may want to disable hub-initiated USB
      3.0 LPM, which will change the value of the U1/U2 timeouts that the xHCI
      driver will install.  We need to disable LPM completely until the driver
      is bound to the interface, and the driver has a chance to enable
      whatever alternate interface setting it needs in its probe routine.
      Then re-enable USB3 LPM, and recalculate the U1/U2 timeout values.
      
      We also need to disable LPM in usb_driver_claim_interface,
      because drivers like usbfs can bind to an interface through that
      function.  Note, there is no way currently for userspace drivers to
      disable hub-initiated USB 3.0 LPM.  Revisit this later.
      
      When a driver is unbound, the U1/U2 timeouts may change because we are
      unbinding the last driver that needed hub-initiated USB 3.0 LPM to be
      disabled.
      
      USB LPM must be disabled when a USB device is going to be suspended.
      The USB 3.0 spec does not define a state transition from U1 or U2 into
      U3, so we need to bring the device into U0 by disabling LPM before we
      can place it into U3.  Therefore, call usb_unlocked_disable_lpm() in
      usb_port_suspend(), and call usb_unlocked_enable_lpm() in
      usb_port_resume().  If the port suspend fails, make sure to re-enable
      LPM by calling usb_unlocked_enable_lpm(), since usb_port_resume() will
      not be called on a failed port suspend.
      
      USB 3.0 devices lose their USB 3.0 LPM settings (including whether USB
      device-initiated LPM is enabled) across device suspend.  Therefore,
      disable LPM before the device will be reset in
      usb_reset_and_verify_device(), and re-enable LPM after the reset is
      complete and the configuration/alt settings are re-installed.
      
      The calculated U1/U2 timeout values are heavily dependent on what USB
      device endpoints are currently enabled.  When any of the enabled
      endpoints on the device might change, due to a new configuration, or new
      alternate interface setting, we need to first disable USB 3.0 LPM, add
      or delete endpoints from the xHCI schedule, install the new interfaces
      and alt settings, and then re-enable LPM.  Do this in usb_set_interface,
      usb_reset_configuration, and usb_set_configuration.
      
      Basically, there is a call to disable and then enable LPM in all
      functions that lock the bandwidth_mutex.  One exception is
      usb_disable_device, because the device is disconnecting or otherwise
      going away, and we should not care about whether USB 3.0 LPM is enabled.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      8306095f
    • S
      USB: Add support to enable/disable USB3 link states. · 1ea7e0e8
      Sarah Sharp 提交于
      There are various functions within the USB core that will need to
      disable USB 3.0 link power states.  For example, when a USB device
      driver is being bound to an interface, we need to disable USB 3.0 LPM
      until we know if the driver will allow hub-initiated LPM transitions.
      Another example is when the USB core is switching alternate interface
      settings.  The USB 3.0 timeout values are dependent on what endpoints
      are enabled, so we want to ensure that LPM is disabled until the new alt
      setting is fully installed.
      
      Multiple functions need to disable LPM, and those functions can even be
      nested.  For example, usb_bind_interface() could disable LPM, and then
      call into the driver probe function, which may attempt to switch to a
      different alt setting.  Therefore, we need to keep a count of the number
      of functions that require LPM to be disabled at any point in time.
      
      Introduce two new USB core API calls, usb_disable_lpm() and
      usb_enable_lpm().  These functions increment and decrement a new
      variable in the usb_device, lpm_disable_count.  If usb_disable_lpm()
      fails, it will call usb_enable_lpm() in order to balance the
      lpm_disable_count.
      
      These two new functions must be called with the bandwidth_mutex locked.
      If the bandwidth_mutex is not already held by the caller, it should
      instead call usb_unlocked_disable_lpm() and usb_enable_lpm(), which take
      the bandwidth_mutex before calling usb_disable_lpm() and
      usb_enable_lpm(), respectively.
      
      Introduce a new variable (timeout) in the usb3_lpm_params structure to
      keep track of the currently enabled U1/U2 timeout values.  When
      usb_disable_lpm() is called, and the USB device has the U1 or U2
      timeouts set to a non-zero value (meaning either device-initiated or
      hub-initiated LPM is enabled), attempt to disable LPM, regardless of the
      state of the lpm_disable_count.  We want to ensure that all callers can
      be guaranteed that LPM is disabled if usb_disable_lpm() returns zero.
      
      Otherwise the following scenario could occur:
      
      1. Driver A is being bound to interface 1.  usb_probe_interface()
      disables LPM.  Driver A doesn't care if hub-initiated LPM is enabled, so
      even though usb_disable_lpm() fails, the probe of the driver continues,
      and the bandwidth mutex is dropped.
      
      2. Meanwhile, Driver B is being bound to interface 2.
      usb_probe_interface() grabs the bandwidth mutex and calls
      usb_disable_lpm().  That call should attempt to disable LPM, even
      though the lpm_disable_count is set to 1 by Driver A.
      
      For usb_enable_lpm(), we attempt to enable LPM only when the
      lpm_disable_count is zero.  If some step in enabling LPM fails, it will
      only have a minimal impact on power consumption, and all USB device
      drivers should still work properly.  Therefore don't bother to return
      any error codes.
      
      Don't enable device-initiated LPM if the device is unconfigured.  The
      USB device will only accept the U1/U2_ENABLE control transfers in the
      configured state.  Do enable hub-initiated LPM in that case, since
      devices are allowed to accept the LGO_Ux link commands in any state.
      
      Don't enable or disable LPM if the device is marked as not being LPM
      capable.  This can happen if:
       - the USB device doesn't have a SS BOS descriptor,
       - the device's parent hub has a zeroed bHeaderDecodeLatency value, or
       - the xHCI host doesn't support LPM.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Andiry Xu <andiry.xu@amd.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      1ea7e0e8
    • S
      USB: Calculate USB 3.0 exit latencies for LPM. · 51e0a012
      Sarah Sharp 提交于
      There are several different exit latencies associated with coming out of
      the U1 or U2 lower power link state.
      
      Device Exit Latency (DEL) is the maximum time it takes for the USB
      device to bring its upstream link into U0.  That can be found in the
      SuperSpeed Extended Capabilities BOS descriptor for the device.  The
      time it takes for a particular link in the tree to exit to U0 is the
      maximum of either the parent hub's U1/U2 DEL, or the child's U1/U2 DEL.
      
      Hubs introduce a further delay that effects how long it takes a child
      device to transition to U0.  When a USB 3.0 hub receives a header
      packet, it takes some time to decode that header and figure out which
      downstream port the packet was destined for.  If the port is not in U0,
      this hub header decode latency will cause an additional delay for
      bringing the child device to U0.  This Hub Header Decode Latency is
      found in the USB 3.0 hub descriptor.
      
      We can use DEL and the header decode latency, along with additional
      latencies imposed by each additional hub tier, to figure out the exit
      latencies for both host-initiated and device-initiated exit to U0.
      
      The Max Exit Latency (MEL) is the worst-case time it will take for a
      host-initiated exit to U0, based on whether U1 or U2 link states are
      enabled.  The ping or packet must traverse the path to the device, and
      each hub along the way incurs the hub header decode latency in order to
      figure out which device the transfer was bound for.  We say worst-case,
      because some hubs may not be in the lowest link state that is enabled.
      See the examples in section C.2.2.1.
      
      Note that "HSD" is a "host specific delay" that the power appendix
      architect has not been able to tell me how to calculate.  There's no way
      to get HSD from the xHCI registers either, so I'm simply ignoring it.
      
      The Path Exit Latency (PEL) is the worst-case time it will take for a
      device-initiate exit to U0 to place all the links from the device to the
      host into U0.
      
      The System Exit Latency (SEL) is another device-initiated exit latency.
      SEL is useful for USB 3.0 devices that need to send data to the host at
      specific intervals.  The device may send an NRDY to indicate it isn't
      ready to send data, then put its link into a lower power state.  If it
      needs to have that data transmitted at a specific time, it can use SEL
      to back calculate when it will need to bring the link back into U0 to
      meet its deadlines.
      
      SEL is the worst-case time from the device-initiated exit to U0, to when
      the device will receive a packet from the host controller.  It includes
      PEL, the time it takes for an ERDY to get to the host, a host-specific
      delay for the host to process that ERDY, and the time it takes for the
      packet to traverse the path to the device.  See Figure C-2 in the USB
      3.0 bus specification.
      
      Note: I have not been able to get good answers about what the
      host-specific delay to process the ERDY should be.  The Intel HW
      developers say it will be specific to the platform the xHCI host is
      integrated into, and they say it's negligible.  Ignore this too.
      
      Separate from these four exit latencies are the U1/U2 timeout values we
      program into the parent hubs.  These timeouts tell the hub to attempt to
      place the device into a lower power link state after the link has been
      idle for that amount of time.
      
      Create two arrays (one for U1 and one for U2) to store mel, pel, sel,
      and the timeout values.  Store the exit latency values in nanosecond
      units, since that's the smallest units used (DEL is in us, but the Hub
      Header Decode Latency is in ns).
      
      If a USB 3.0 device doesn't have a SuperSpeed Extended Capabilities BOS
      descriptor, it's highly unlikely it will be able to handle LPM requests
      properly.  So it's best to disable LPM for devices that don't have this
      descriptor, and any children beneath it, if it's a USB 3.0 hub.  Warn
      users when that happens, since it means they have a non-compliant USB
      3.0 device or hub.
      
      This patch assumes a simplified design where links deep in the tree will
      not have U1 or U2 enabled unless all their parent links have the
      corresponding LPM state enabled.  Eventually, we might want to allow a
      different policy, and we can revisit this patch when that happens.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      51e0a012
    • S
      USB: Refactor code to set LPM support flag. · d9b2099c
      Sarah Sharp 提交于
      Refactor the code that sets the usb_device flag to indicate the device
      support link power management (lpm_capable).  The current code sets
      lpm_capable unconditionally if the USB devices have a USB 2.0 Extended
      Capabilities Descriptor.  USB 3.0 devices can also have that descriptor,
      but the xHCI driver code that uses lpm_capable will not run the USB 2.0
      LPM test for devices under the USB 3.0 roothub.  Therefore, it's fine
      only set lpm_capable for high speed devices in this refactoring.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      d9b2099c
    • S
      USB: Make sure to fetch the BOS desc for roothubs. · 448b6eb1
      Sarah Sharp 提交于
      The BOS descriptor is normally fetched and stored in the usb_device->bos
      during enumeration.  USB 3.0 roothubs don't undergo enumeration, but we
      need them to have a BOS descriptor, since each xHCI host has a different
      U1 and U2 exit latency.  Make sure to fetch the BOS descriptor for USB
      3.0 roothubs.  It will be freed when the roothub usb_device is released.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Andiry Xu <andiry.xu@amd.com>
      448b6eb1
    • S
      xhci: Add roothub code to set U1/U2 timeouts. · 797b0ca5
      Sarah Sharp 提交于
      USB 3.0 hubs can be put into a mode where the hub can automatically
      request that the link go into a deeper link power state after the link
      has been idle for a specified amount of time.  Each of the new USB 3.0
      link states (U1 and U2) have their own timeout that can be programmed
      per port.
      
      Change the xHCI roothub emulation code to handle the request to set the
      U1 and U2 timeouts.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      797b0ca5
    • S
      xhci: Reset reserved command ring TRBs on cleanup. · 33b2831a
      Sarah Sharp 提交于
      When the xHCI driver needs to clean up memory (perhaps due to a failed
      register restore on resume from S3 or resume from S4), it needs to reset
      the number of reserved TRBs on the command ring to zero.  Otherwise,
      several resume cycles (about 30) with a UAS device attached will
      continually increment the number of reserved TRBs, until all command
      submissions fail because there isn't enough room on the command ring.
      
      This patch should be backported to kernels as old as 2.6.32,
      that contain the commit 913a8a34
      "USB: xhci: Change how xHCI commands are handled."
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      33b2831a
    • O
      USB: fix resource leak in xhci power loss path · f8a9e72d
      Oliver Neukum 提交于
      Some more data structures must be freed and counters
      reset if an XHCI controller has lost power. The failure
      to do so renders some chips inoperative after a certain number
      of S4 cycles.
      
      This patch should be backported to kernels as old as 3.2,
      that contain the commits c29eea62
      "xhci: Implement HS/FS/LS bandwidth checking." and
      commit 839c817c
      "xhci: Implement HS/FS/LS bandwidth checking."
      Signed-off-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      f8a9e72d
  8. 18 5月, 2012 11 次提交
  9. 16 5月, 2012 5 次提交