1. 24 9月, 2013 2 次提交
    • S
      usb: Fix xHCI host issues on remote wakeup. · 8b3d4570
      Sarah Sharp 提交于
      When a device signals remote wakeup on a roothub, and the suspend change
      bit is set, the host controller driver must not give control back to the
      USB core until the port goes back into the active state.
      
      EHCI accomplishes this by waiting in the get port status function until
      the PORT_RESUME bit is cleared:
      
                              /* stop resume signaling */
                              temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME);
                              ehci_writel(ehci, temp, status_reg);
                              clear_bit(wIndex, &ehci->resuming_ports);
                              retval = ehci_handshake(ehci, status_reg,
                                              PORT_RESUME, 0, 2000 /* 2msec */);
      
      Similarly, the xHCI host should wait until the port goes into U0, before
      passing control up to the USB core.  When the port transitions from the
      RExit state to U0, the xHCI driver will get a port status change event.
      We need to wait for that event before passing control up to the USB
      core.
      
      After the port transitions to the active state, the USB core should time
      a recovery interval before it talks to the device.  The length of that
      recovery interval is TRSMRCY, 10 ms, mentioned in the USB 2.0 spec,
      section 7.1.7.7.  The previous xHCI code (which did not wait for the
      port to go into U0) would cause the USB core to violate that recovery
      interval.
      
      This bug caused numerous USB device disconnects on remote wakeup under
      ChromeOS and a Lynx Point LP xHCI host that takes up to 20 ms to move
      from RExit to U0.  ChromeOS is very aggressive about power savings, and
      sets the autosuspend_delay to 100 ms, and disables USB persist.
      
      I attempted to replicate this bug with Ubuntu 12.04, but could not.  I
      used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
      was triggered on ChromeOS with.  I also changed the USB sysfs settings
      as described above, but still could not reproduce the bug under Ubuntu.
      It may be that ChromeOS userspace triggers this bug through additional
      settings.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      8b3d4570
    • M
      xhci: Ensure a command structure points to the correct trb on the command ring · ec7e43e2
      Mathias Nyman 提交于
      If a command on the command ring needs to be cancelled before it is handled
      it can be turned to a no-op operation when the ring is stopped.
      We want to store the command ring enqueue pointer in the command structure
      when the command in enqueued for the cancellation case.
      
      Some commands used to store the command ring dequeue pointers instead of enqueue
      (these often worked because enqueue happends to equal dequeue quite often)
      
      Other commands correctly used the enqueue pointer but did not check if it pointed
      to a valid trb or a link trb, this caused for example stop endpoint command to timeout in
      xhci_stop_device() in about 2% of suspend/resume cases.
      
      This should also solve some weird behavior happening in command cancellation cases.
      
      This patch is based on a patch submitted by Sarah Sharp to linux-usb, but
      then forgotten:
          http://marc.info/?l=linux-usb&m=136269803207465&w=2
      
      This patch should be backported to kernels as old as 3.7, that contain
      the commit b92cc66c "xHCI: add aborting
      command ring function"
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      ec7e43e2
  2. 16 8月, 2013 1 次提交
    • S
      xhci-plat: Don't enable legacy PCI interrupts. · 52fb6125
      Sarah Sharp 提交于
      The xHCI platform driver calls into usb_add_hcd to register the irq for
      its platform device.  It does not want the xHCI generic driver to
      register an interrupt for it at all.  The original code did that by
      setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not
      enable MSI or MSI-X for a PCI host.
      
      Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled,
      the xHCI generic driver will attempt to register a legacy PCI interrupt
      for the xHCI platform device in xhci_try_enable_msi().  This will result
      in a bogus irq being registered, since the underlying device is a
      platform_device, not a pci_device, and thus the pci_device->irq pointer
      will be bogus.
      
      Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can
      distinguish between a PCI device that can't handle MSI or MSI-X, and a
      platform device that should not have its interrupts touched at all.
      This quirk may be useful in the future, in case other corner cases like
      this arise.
      
      This patch should be backported to kernels as old as 3.9, that
      contain the commit 00eed9c8 "USB: xhci:
      correctly enable interrupts".
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NYu Y Wang <yu.y.wang@intel.com>
      Tested-by: NYu Y Wang <yu.y.wang@intel.com>
      Reviewed-by: NFelipe Balbi <balbi@ti.com>
      Cc: stable@vger.kernel.org
      52fb6125
  3. 14 8月, 2013 3 次提交
    • X
      xhci: add traces for debug messages in xhci_address_device() · 84a99f6f
      Xenia Ragiadakou 提交于
      This patch declares an event class for trace events that
      trace messages with variadic arguments, called xhci_log_msg,
      and defines a trace event for tracing the debug messages in
      xhci_address_device() function, called xhci_dbg_address.
      
      In order to implement this type of trace events, a wrapper function,
      called xhci_dbg_trace(), was created that records the format string
      and variadic arguments into a va_format structure which is passed as
      argument to the tracepoints of the class xhci_log_msg.
      
      All the xhci_dbg() calls in xhci_address_device() are replaced
      with calls to xhci_dbg_trace(). The functionality of xhci_dbg()
      log messages was not removed though, but it is placed inside
      xhci_dbg_trace().
      
      This trace event aims to give the ability to the user or the
      developper to isolate and trace the debug messages generated
      when an Address Device Command is issued to xHC.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      84a99f6f
    • X
      xhci: remove CONFIG_USB_XHCI_HCD_DEBUGGING and unused code · b2497509
      Xenia Ragiadakou 提交于
      CONFIG_USB_XHCI_HCD_DEBUGGING option is used to enable
      verbose debugging output for the xHCI host controller
      driver.
      
      In the current version of the xhci-hcd driver, this
      option must be turned on, in order for the debugging
      log messages to be displayed, and users may need to
      recompile the linux kernel to obtain debugging
      information that will help them track down problems.
      
      This patch removes the above debug option to enable
      debugging log messages at all times.
      The aim of this is to rely on the debugfs and the
      dynamic debugging feature for fine-grained management
      of debugging messages and to not force users to set
      the debug config option and compile the linux kernel
      in order to have access in that information.
      
      This patch, also, removes the XHCI_DEBUG symbol and the
      functions dma_to_stream_ring(), xhci_test_radix_tree()
      and xhci_event_ring_work() that are not useful anymore.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      b2497509
    • X
      xhci: replace xhci_info() with xhci_dbg() · 38a532a6
      Xenia Ragiadakou 提交于
      This patch replaces the calls to xhci_info() with calls to
      xhci_dbg() and removes the unused xhci_info() definition
      from xhci-hcd.
      
      By replacing the xhci_info() with xhci_dbg(), the calls to
      dev_info() are replaced with calls to dev_dbg() so that
      their output can be dynamically controlled via the dynamic
      debugging mechanism.
      Signed-off-by: NXenia Ragiadakou <burzalodowa@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      38a532a6
  4. 06 6月, 2013 5 次提交
  5. 25 5月, 2013 1 次提交
    • S
      xhci: Disable D3cold for buggy TI redrivers. · c3897aa5
      Sarah Sharp 提交于
      Some xHCI hosts contain a "redriver" from TI that silently drops port
      status connect changes if the port slips into Compliance Mode.  If the
      port slips into compliance mode while the host is in D0, there will not
      be a port status change event.  If the port slips into compliance mode
      while the host is in D3, the host will not send a PME.  This includes
      when the system is suspended (S3) or hibernated (S4).
      
      If this happens when the system is in S3/S4, there is nothing software
      can do.  Other port status change events that would normally cause the
      host to wake the system from S3/S4 may also be lost.  This includes
      remote wakeup, disconnects and connects on other ports, and overrcurrent
      events.  A decision was made to _NOT_ disable system suspend/hibernate
      on these systems, since users are unlikely to enable wakeup from S3/S4
      for the xHCI host.
      
      Software can deal with this issue when the system is in S0.  A work
      around was put in to poll the port status registers for Compliance Mode.
      The xHCI driver will continue to poll the registers while the host is
      runtime suspended.  Unfortunately, that means we can't allow the PCI
      device to go into D3cold, because power will be removed from the host,
      and the config space will read as all Fs.
      
      Disable D3cold in the xHCI PCI runtime suspend function.
      
      This patch should be backported to kernels as old as 3.2, that
      contain the commit 71c731a2 "usb: host:
      xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Cc: stable@vger.kernel.org
      c3897aa5
  6. 04 4月, 2013 2 次提交
  7. 26 3月, 2013 2 次提交
    • V
      usb: xhci: Fix TRB transfer length macro used for Event TRB. · 1c11a172
      Vivek Gautam 提交于
      Use proper macro while extracting TRB transfer length from
      Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
      for the same, and use it instead of TRB_LEN (bits 0:16) in
      case of event TRBs.
      
      This patch should be backported to kernels as old as 2.6.31, that
      contain the commit b10de142 "USB: xhci:
      Bulk transfer support".  This patch will have issues applying to older
      kernels.
      Signed-off-by: NVivek gautam <gautam.vivek@samsung.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      1c11a172
    • L
      usb: add find_raw_port_number callback to struct hc_driver() · 3f5eb141
      Lan Tianyu 提交于
      xhci driver divides the root hub into two logical hubs which work
      respectively for usb 2.0 and usb 3.0 devices. They are independent
      devices in the usb core. But in the ACPI table, it's one device node
      and all usb2.0 and usb3.0 ports are under it. Binding usb port with
      its acpi node needs the raw port number which is reflected in the xhci
      extended capabilities table. This patch is to add find_raw_port_number
      callback to struct hc_driver(), fill it with xhci_find_raw_port_number()
      which will return raw port number and add a wrap usb_hcd_find_raw_port_number().
      
      Otherwise, refactor xhci_find_real_port_number(). Using
      xhci_find_raw_port_number() to get real index in the HW port status
      registers instead of scanning through the xHCI roothub port array.
      This can help to speed up.
      
      All addresses in xhci->usb2_ports and xhci->usb3_ports array are
      kown good ports and don't include following bad ports in the extended
      capabilities talbe.
           (1) root port that doesn't have an entry
           (2) root port with unknown speed
           (3) root port that is listed twice and with different speeds.
      
      So xhci_find_raw_port_number() will only return port num of good ones
      and never touch bad ports above.
      Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      3f5eb141
  8. 18 3月, 2013 1 次提交
    • D
      USB: xhci - fix bit definitions for IMAN register · f8264340
      Dmitry Torokhov 提交于
      According to XHCI specification (5.5.2.1) the IP is bit 0 and IE is bit 1
      of IMAN register. Previously their definitions were reversed.
      
      Even though there are no ill effects being observed from the swapped
      definitions (because IMAN_IP is RW1C and in legacy PCI case we come in
      with it already set to 1 so it was clearing itself even though we were
      setting IMAN_IE instead of IMAN_IP), we should still correct the values.
      
      This patch should be backported to kernels as old as 2.6.36, that
      contain the commit 4e833c0b "xhci: don't
      re-enable IE constantly".
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      f8264340
  9. 13 11月, 2012 1 次提交
  10. 26 9月, 2012 1 次提交
    • S
      xhci: Intel Panther Point BEI quirk. · 80fab3b2
      Sarah Sharp 提交于
      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 69e848c2 "Intel xhci: Support
      EHCI/xHCI port switching."
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      80fab3b2
  11. 14 9月, 2012 3 次提交
    • E
      xHCI: cancel command after command timeout · 6e4468b9
      Elric Fu 提交于
      The patch is used to cancel command when the command isn't
      acknowledged and a timeout occurs.
      
      This patch should be backported to kernels as old as 3.0, that contain
      the commit 7ed603ec "xhci: Add an
      assertion to check for virt_dev=0 bug." That commit papers over a NULL
      pointer dereference, and this patch fixes the underlying issue that
      caused the NULL pointer dereference.
      Signed-off-by: NElric Fu <elricfu1@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NMiroslav Sabljic <miroslav.sabljic@avl.com>
      Cc: stable@vger.kernel.org
      6e4468b9
    • E
      xHCI: add aborting command ring function · b92cc66c
      Elric Fu 提交于
      Software have to abort command ring and cancel command
      when a command is failed or hang. Otherwise, the command
      ring will hang up and can't handle the others. An example
      of a command that may hang is the Address Device Command,
      because waiting for a SET_ADDRESS request to be acknowledged
      by a USB device is outside of the xHC's ability to control.
      
      To cancel a command, software will initialize a command
      descriptor for the cancel command, and add it into a
      cancel_cmd_list of xhci.
      
      Sarah: Fixed missing newline on "Have the command ring been stopped?"
      debugging statement.
      
      This patch should be backported to kernels as old as 3.0, that contain
      the commit 7ed603ec "xhci: Add an
      assertion to check for virt_dev=0 bug." That commit papers over a NULL
      pointer dereference, and this patch fixes the underlying issue that
      caused the NULL pointer dereference.
      Signed-off-by: NElric Fu <elricfu1@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NMiroslav Sabljic <miroslav.sabljic@avl.com>
      Cc: stable@vger.kernel.org
      b92cc66c
    • E
      xHCI: add cmd_ring_state · c181bc5b
      Elric Fu 提交于
      Adding cmd_ring_state for command ring. It helps to verify
      the current command ring state for controlling the command
      ring operations.
      
      This patch should be backported to kernels as old as 3.0.  The commit
      7ed603ec "xhci: Add an assertion to
      check for virt_dev=0 bug." papers over the NULL pointer dereference that
      I now believe is related to a timed out Set Address command.  This (and
      the four patches that follow it) contain the real fix that also allows
      VIA USB 3.0 hubs to consistently re-enumerate during the plug/unplug
      stress tests.
      Signed-off-by: NElric Fu <elricfu1@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NMiroslav Sabljic <miroslav.sabljic@avl.com>
      Cc: stable@vger.kernel.org
      c181bc5b
  12. 06 9月, 2012 1 次提交
    • A
      usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware · 71c731a2
      Alexis R. Cortes 提交于
      This patch is intended to work around a known issue on the
      SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
      between a device and the host past the usual handshake timeout.
      
      If that happens on the first insertion, the host controller
      port will enter in Compliance Mode and NO port status event will
      be generated (as per xHCI Spec) making impossible to detect this
      event by software. The port will remain in compliance mode until
      a warm reset is applied to it.
      
      As a result of this, the port will seem "dead" to the user and no
      device connections or disconnections will be detected.
      
      For solving this, the patch creates a timer which polls every 2
      seconds the link state of each host controller's port (this
      by reading the PORTSC register) and recovers the port by issuing a
      Warm reset every time Compliance mode is detected.
      
      If a xHC USB3.0 port has previously entered to U0, the compliance
      mode issue will NOT occur only until system resumes from
      sleep/hibernate, therefore, the compliance mode timer is stopped
      when all xHC USB 3.0 ports have entered U0. The timer is initialized
      again after each system resume.
      
      Since the issue is being caused by a piece of hardware, the timer
      will be enabled ONLY on those systems that have the SN65LVPE502CP
      installed (this patch uses DMI strings for detecting those systems)
      therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
      has been added to the xhci stack).
      
      This patch applies for these systems:
      Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
      
      This patch should be backported to kernels as old as 3.2, as that was
      the first kernel to support warm reset.  The kernels will need to
      contain both commit 10d674a8 "USB: When
      hot reset for USB3 fails, try warm reset" and commit
      8bea2bd3 "usb: Add support for root hub
      port status CAS".  The first patch add warm reset support, and the
      second patch modifies the USB core to issue a warm reset when the port
      is in compliance mode.
      Signed-off-by: NAlexis R. Cortes <alexis.cortes@ti.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      71c731a2
  13. 10 8月, 2012 1 次提交
    • S
      xhci: Switch PPT ports to EHCI on shutdown. · e95829f4
      Sarah Sharp 提交于
      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 69e848c2 "Intel xhci: Support
      EHCI/xHCI port switching."
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NDenis Turischev <denis@compulab.co.il>
      Tested-by: NDenis Turischev <denis@compulab.co.il>
      Cc: stable@vger.kernel.org
      e95829f4
  14. 08 8月, 2012 1 次提交
  15. 03 7月, 2012 1 次提交
    • S
      usb: Add support for root hub port status CAS · 8bea2bd3
      Stanislaw Ledwon 提交于
      The host controller port status register supports CAS (Cold Attach
      Status) bit. This bit could be set when USB3.0 device is connected
      when system is in Sx state. When the system wakes to S0 this port
      status with CAS bit is reported and this port can't be used by any
      device.
      
      When CAS bit is set the port should be reset by warm reset. This
      was not supported by xhci driver.
      
      The issue was found when pendrive was connected to suspended
      platform. The link state of "Compliance Mode" was reported together
      with CAS bit. This link state was also not supported by xhci and
      core/hub.c.
      
      The CAS bit is defined only for xhci root hub port and it is
      not supported on regular hubs. The link status is used to force
      warm reset on port. Make the USB core issue a warm reset when port
      is in ether the 'inactive' or 'compliance mode'. Change the xHCI driver
      to report 'compliance mode' when the CAS is set. This force warm reset
      on the root hub port.
      
      This patch should be backported to stable kernels as old as 3.2, that
      contain the commit 10d674a8 "USB: When
      hot reset for USB3 fails, try warm reset."
      Signed-off-by: NStanislaw Ledwon <staszek.ledwon@linux.intel.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Acked-by: NAndiry Xu <andiry.xu@amd.com>
      Cc: stable@vger.kernel.org
      8bea2bd3
  16. 19 5月, 2012 5 次提交
    • 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
      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
  17. 18 5月, 2012 1 次提交
    • S
      xhci: Add new short TX quirk for Fresco Logic host. · 1530bbc6
      Sarah Sharp 提交于
      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
      f5182b41 "xhci: Disable MSI for some
      Fresco Logic hosts."  That commit was marked for stable kernels as old
      as 2.6.36.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NSergio Correia <lists@uece.net>
      Tested-by: NSergio Correia <lists@uece.net>
      Cc: stable@vger.kernel.org
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      1530bbc6
  18. 04 5月, 2012 1 次提交
    • A
      xHCI: keep track of ports being resumed and indicate in hub_status_data · f370b996
      Andiry Xu 提交于
      This commit adds a bit-array to xhci bus_state for keeping track of
      which ports are undergoing a resume transition. If any of the bits
      are set when xhci_hub_status_data() is called, the routine will return
      a non-zero value even if no ports have any status changes pending.
      This will allow usbcore to handle races between root-hub suspend and
      port wakeup.
      
      This patch should be backported to kernels as old as 3.4, that contain
      the commit 879d38e6 "USB: fix race
      between root-hub suspend and remote wakeup".
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: stable@vger.kernel.org
      f370b996
  19. 11 4月, 2012 1 次提交
    • F
      xhci: don't re-enable IE constantly · 4e833c0b
      Felipe Balbi 提交于
      While we're at that, define IMAN bitfield to aid readability.
      
      The interrupt enable bit should be set once on driver init, and we
      shouldn't need to continually re-enable it.  Commit c21599a3 introduced
      a read of the irq_pending register, and that allows us to preserve the
      state of the IE bit.  Before that commit, we were blindly writing 0x3 to
      the register.
      
      This patch should be backported to kernels as old as 2.6.36, or ones
      that contain the commit c21599a3 "USB:
      xhci: Reduce reads and writes of interrupter registers".
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      4e833c0b
  20. 14 3月, 2012 4 次提交
  21. 13 3月, 2012 2 次提交