1. 14 3月, 2011 12 次提交
    • S
      xhci: Fix cycle bit calculation during stall handling. · 01a1fdb9
      Sarah Sharp 提交于
      When an endpoint stalls, we need to update the xHCI host's internal
      dequeue pointer to move it past the stalled transfer.  This includes
      updating the cycle bit (TRB ownership bit) if we have moved the dequeue
      pointer past a link TRB with the toggle cycle bit set.
      
      When we're trying to find the new dequeue segment, find_trb_seg() is
      supposed to keep track of whether we've passed any link TRBs with the
      toggle cycle bit set.  However, this while loop's body
      
      	while (cur_seg->trbs > trb ||
      			&cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) {
      
      Will never get executed if the ring only contains one segment.
      find_trb_seg() will return immediately, without updating the new cycle
      bit.  Since find_trb_seg() has no idea where in the segment the TD that
      stalled was, make the caller, xhci_find_new_dequeue_state(), check for
      this special case and update the cycle bit accordingly.
      
      This patch should be queued to kernels all the way back to 2.6.31.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NTakashi Iwai <tiwai@suse.de>
      Cc: stable@kernel.org
      01a1fdb9
    • S
      xhci: Update internal dequeue pointers after stalls. · bf161e85
      Sarah Sharp 提交于
      When an endpoint stalls, the xHCI driver must move the endpoint ring's
      dequeue pointer past the stalled transfer.  To do that, the driver issues
      a Set TR Dequeue Pointer command, which will complete some time later.
      
      Takashi was having issues with USB 1.1 audio devices that stalled, and his
      analysis of the code was that the old code would not update the xHCI
      driver's ring dequeue pointer after the command completes.  However, the
      dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
      set command is issued to the hardware.
      
      Setting the dequeue pointer before the Set TR Dequeue Pointer command
      completes is a dangerous thing to do, since the xHCI hardware can fail the
      command.  Instead, store the new dequeue pointer in the xhci_virt_ep
      structure, and update the ring's dequeue pointer when the Set TR dequeue
      pointer command completes.
      
      While we're at it, make sure we can't queue another Set TR Dequeue Command
      while the first one is still being processed.  This just won't work with
      the internal xHCI state code.  I'm still not sure if this is the right
      thing to do, since we might have a case where a driver queues multiple
      URBs to a control ring, one of the URBs Stalls, and then the driver tries
      to cancel the second URB.  There may be a race condition there where the
      xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
      but I would have to think very hard about how the Stop Endpoint and
      cancellation code works.  Keep the fix simple until when/if we run into
      that case.
      
      This patch should be queued to kernels all the way back to 2.6.31.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NTakashi Iwai <tiwai@suse.de>
      Cc: stable@kernel.org
      bf161e85
    • S
      xhci: Fixes for suspend/resume of shared HCDs. · b3209379
      Sarah Sharp 提交于
      Make sure the HCD_FLAG_HW_ACCESSIBLE flag is mirrored by both roothubs,
      since it refers to whether the shared hardware is accessible.  Make sure
      each bus is marked as suspended by setting usb_hcd->state to
      HC_STATE_SUSPENDED when the PCI host controller is resumed.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      b3209379
    • S
      xhci: Register second xHCI roothub. · f6ff0ac8
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f6ff0ac8
    • S
      xhci: Change xhci_find_slot_id_by_port() API. · 5233630f
      Sarah Sharp 提交于
      xhci_find_slot_id_by_port() tries to map the port index to the slot ID for
      the USB device.  In the future, there will be two xHCI roothubs, and their
      port indices will overlap.  Therefore, xhci_find_slot_id_by_port() will
      need to use information in the roothub's usb_hcd structure to map the port
      index and roothub speed to the right slot ID.
      
      Add a new parameter to xhci_find_slot_id_by_port(), in order to pass in
      the roothub's usb_hcd structure.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      5233630f
    • S
      xhci: Refactor bus suspend state into a struct. · 20b67cf5
      Sarah Sharp 提交于
      There are several variables in the xhci_hcd structure that are related to
      bus suspend and resume state.  There are a couple different port status
      arrays that are accessed by port index.  Move those variables into a
      separate structure, xhci_bus_state.  Stash that structure in xhci_hcd.
      
      When we have two roothhubs that can be suspended and resumed separately,
      we can have two xhci_bus_states, and index into the port arrays in each
      structure with the fake roothub port index (not the real hardware port
      index).
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      20b67cf5
    • S
      xhci: Index with a port array instead of PORTSC addresses. · 5308a91b
      Sarah Sharp 提交于
      In the upcoming patches, the roothub emulation code will need to return
      port status and port change buffers based on whether they are called with
      the xHCI USB 2.0 or USB 3.0 roothub.  To facilitate that, make the roothub
      code index into an array of port addresses with wIndex, rather than
      calculating the address using the offset and the address of the PORTSC
      registers.  Later we can set the port array to be the array of USB 3.0
      port addresses, or the USB 2.0 port addresses, depending on the roothub
      passed in.
      
      Create a temporary (statically sized) port array and fill it in with both
      USB 3.0 and USB 2.0 port addresses.  This is inefficient to do for every
      roothub call, but this is needed for git bisect compatibility.  The
      temporary port array will be deleted in a subsequent patch.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      5308a91b
    • S
      USB: Set usb_hcd->state and flags for shared roothubs. · ff9d78b3
      Sarah Sharp 提交于
      The hcd->flags are in a sorry state.  Some of them are clearly specific to
      the particular roothub (HCD_POLL_RH, HCD_POLL_PENDING, and
      HCD_WAKEUP_PENDING), but some flags are related to PCI device state
      (HCD_HW_ACCESSIBLE and HCD_SAW_IRQ).  This is an issue when one PCI device
      can have two roothubs that share the same IRQ line and hardware.
      
      Make sure to set HCD_FLAG_SAW_IRQ for both roothubs when an interrupt is
      serviced, or an URB is unlinked without an interrupt.  (We can't tell if
      the host actually serviced an interrupt for a particular bus, but we can
      tell it serviced some interrupt.)
      
      HCD_HW_ACCESSIBLE is set once by usb_add_hcd(), which is set for both
      roothubs as they are added, so it doesn't need to be modified.
      HCD_POLL_RH and HCD_POLL_PENDING are only checked by the USB core, and
      they are never set by the xHCI driver, since the roothub never needs to be
      polled.
      
      The usb_hcd's state field is a similar mess.  Sometimes the state applies
      to the underlying hardware: HC_STATE_HALT, HC_STATE_RUNNING, and
      HC_STATE_QUIESCING.  But sometimes the state refers to the roothub state:
      HC_STATE_RESUMING and HC_STATE_SUSPENDED.
      
      Alan Stern recently made the USB core not rely on the hcd->state variable.
      Internally, the xHCI driver still checks for HC_STATE_SUSPENDED, so leave
      that code in.  Remove all references to HC_STATE_HALT, since the xHCI
      driver only sets and doesn't test those variables.  We still have to set
      HC_STATE_RUNNING, since Alan's patch has a bug that means the roothub
      won't get registered if we don't set that.
      
      Alan's patch made the USB core check a different variable when trying to
      determine whether to suspend a roothub.  The xHCI host has a split
      roothub, where two buses are registered for one PCI device.  Each bus in
      the xHCI split roothub can be suspended separately, but both buses must be
      suspended before the PCI device can be suspended.  Therefore, make sure
      that the USB core checks HCD_RH_RUNNING() for both roothubs before
      suspending the PCI host.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      ff9d78b3
    • S
      xhci: Always use usb_hcd in URB instead of converting xhci_hcd. · 214f76f7
      Sarah Sharp 提交于
      Make sure to call into the USB core's link, unlink, and giveback URB
      functions with the usb_hcd pointer found by using urb->dev->bus.  This
      will avoid confusion later, when the xHCI driver will deal with URBs from
      two separate buses (the USB 3.0 roothub and the faked USB 2.0 roothub).
      
      Assume xhci_urb_dequeue() will be called with the proper usb_hcd.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      214f76f7
    • S
      xhci: Remove references to HC_STATE_HALT. · ac04e6ff
      Sarah Sharp 提交于
      The xHCI driver doesn't ever test hcd->state for HC_STATE_HALT.  The USB
      core recently stopped using it internally, so there's no point in setting
      it in the driver.  We still need to set HC_STATE_RUNNING in order to make
      it past the USB core's hcd->state check in register_roothub().
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      ac04e6ff
    • S
      xhci: Rename variables and reduce register reads. · 518e848e
      Sarah Sharp 提交于
      The xhci_bus_suspend() and xhci_bus_resume() functions are a bit hard to
      read, because they have an ambiguously named variable "port".  Rename it
      to "port_index".  Introduce a new temporary variable, "max_ports" that
      holds the maximum number of roothub ports the host controller supports.
      This will reduce the number of register reads, and make it easy to change
      the maximum number of ports when there are two roothubs.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      518e848e
    • S
      xhci: Remove old no-op test. · 0b8ca72a
      Sarah Sharp 提交于
      The test of placing a number of command no-ops on the command ring and
      counting the number of no-op events that were generated was only used
      during the initial xHCI driver bring up.  This test is no longer used, so
      delete it.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      0b8ca72a
  2. 15 1月, 2011 7 次提交
  3. 12 11月, 2010 1 次提交
    • S
      xhci: Remove excessive printks with shared IRQs. · 241b652f
      Sarah Sharp 提交于
      If the xHCI host controller shares an interrupt line with another device,
      the xHCI driver needs to check if the interrupt was generated by its
      hardware.  Unfortunately, the user will see a ton of "Spurious interrupt."
      lines if the other hardware interrupts often.  Lawrence found his dmesg
      output cluttered with this output when the xHCI host shared an interrupt
      with his i915 hardware.
      
      Remove the warning, as sharing an interrupt is a normal thing.
      
      This should be applied to the 2.6.36 stable tree.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NLawrence Rust <lvr@softsystem.co.uk>
      Cc: stable@kernel.org
      241b652f
  4. 23 10月, 2010 2 次提交
    • A
      USB: xHCI: port remote wakeup implementation · 56192531
      Andiry Xu 提交于
      This commit implements port remote wakeup.
      
      When a port is in U3 state and resume signaling is detected from a device,
      the port transitions to the Resume state, and the xHC generates a Port Status
      Change Event.
      
      For USB3 port, software write a '0' to the PLS field to complete the resume
      signaling. For USB2 port, the resume should be signaling for at least 20ms,
      irq handler set a timer for port remote wakeup, and then finishes process in
      hub_control GetPortStatus.
      
      Some codes are borrowed from EHCI code.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      56192531
    • A
      USB: xHCI: port power management implementation · be88fe4f
      Andiry Xu 提交于
      Add software trigger USB device suspend resume function hook.
      Do port suspend & resume in terms of xHCI spec.
      
      Port Suspend:
      Stop all endpoints via Stop Endpoint Command with Suspend (SP) flag set.
      Place individual ports into suspend mode by writing '3' for Port Link State
      (PLS) field into PORTSC register. This can only be done when the port is in
      Enabled state. When writing, the Port Link State Write Strobe (LWS) bit shall
      be set to '1'.
      Allocate an xhci_command and stash it in xhci_virt_device to wait completion for
      the last Stop Endpoint Command.  Use the Suspend bit in TRB to indicate the Stop
      Endpoint Command is for port suspend. Based on Sarah's suggestion.
      
      Port Resume:
      Write '0' in PLS field, device will transition to running state.
      Ring an endpoints' doorbell to restart it.
      
      Ref: USB device remote wake need another patch to implement. For details of
      how USB subsystem do power management, please see:
          Documentation/usb/power-management.txt
      Signed-off-by: NCrane Cai <crane.cai@amd.com>
      Signed-off-by: NLibin Yang <libin.yang@amd.com>
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      be88fe4f
  5. 24 8月, 2010 2 次提交
  6. 11 8月, 2010 16 次提交