1. 27 May, 2011 2 commits
    • Sarah Sharp's avatar
      Intel xhci: Ignore spurious successful event. · ad808333
      Sarah Sharp authored
      The xHCI host controller in the Panther Point chipset sometimes produces
      spurious events on the event ring.  If it receives a short packet, it
      first puts a Transfer Event with a short transfer completion code on the
      event ring.  Then it puts a Transfer Event with a successful completion
      code on the ring for the same TD.  The xHCI driver correctly processes the
      short transfer completion code, gives the URB back to the driver, and then
      prints a warning in dmesg about the spurious event.  These warning
      messages really fill up dmesg when an HD webcam is plugged into xHCI.
      
      This spurious successful event behavior isn't technically disallowed by
      the xHCI specification, so make the xHCI driver just ignore the spurious
      completion event.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      ad808333
    • Sarah Sharp's avatar
      Intel xhci: Support EHCI/xHCI port switching. · 69e848c2
      Sarah Sharp authored
      The Intel Panther Point chipsets contain an EHCI and xHCI host controller
      that shares some number of skew-dependent ports.  These ports can be
      switched from the EHCI to the xHCI host (and vice versa) by a hardware MUX
      that is controlled by registers in the xHCI PCI configuration space.  The
      USB 3.0 SuperSpeed terminations on the xHCI ports can be controlled
      separately from the USB 2.0 data wires.
      
      This switchover mechanism is there to support users who do a custom
      install of certain non-Linux operating systems that don't have official
      USB 3.0 support.  By default, the ports are under EHCI, SuperSpeed
      terminations are off, and USB 3.0 devices will show up under the EHCI
      controller at reduced speeds.  (This was more palatable for the marketing
      folks than having completely dead USB 3.0 ports if no xHCI drivers are
      available.)  Users should be able to turn on xHCI by default through a
      BIOS option, but users are happiest when they don't have to change random
      BIOS settings.
      
      This patch introduces a driver method to switchover the ports from EHCI to
      xHCI before the EHCI driver finishes PCI enumeration.  We want to switch
      the ports over before the USB core has the chance to enumerate devices
      under EHCI, or boot from USB mass storage will fail if the boot device
      connects under EHCI first, and then gets disconnected when the port
      switches over to xHCI.
      
      Add code to the xHCI PCI quirk to switch the ports from EHCI to xHCI.  The
      PCI quirks code will run before any other PCI probe function is called, so
      this avoids the issue with boot devices.
      
      Another issue is with BIOS behavior during system resume from hibernate.
      If the BIOS doesn't support xHCI, it may switch the devices under EHCI to
      allow use of the USB keyboard, mice, and mass storage devices.  It's
      supposed to remember the value of the port routing registers and switch
      them back when the OS attempts to take control of the xHCI host controller,
      but we all know not to trust BIOS writers.
      
      Make both the xHCI driver and the EHCI driver attempt to switchover the
      ports in their PCI resume functions.  We can't guarantee which PCI device
      will be resumed first, so this avoids any race conditions.  Writing a '1'
      to an already set port switchover bit or a '0' to a cleared port switchover
      bit should have no effect.
      
      The xHCI PCI configuration registers will be documented in the EDS-level
      chipset spec, which is not public yet.  I have permission from legal and
      the Intel chipset group to release this patch early to allow good Linux
      support at product launch.  I've tried to document the registers as much
      as possible, so please let me know if anything is unclear.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      69e848c2
  2. 26 May, 2011 1 commit
  3. 25 May, 2011 5 commits
    • Sarah Sharp's avatar
      xhci: STFU: Be quieter during URB submission and completion. · f444ff27
      Sarah Sharp authored
      Unsurprisingly, URBs get submitted and completed a lot in the xHCI
      driver.  If we have to print 10 lines of debug for every URB submitted
      or completed, then that can cause the whole system to stay in the
      interrupt handler too long, and can cause Missed Service completion
      codes for isochronous transfers.
      
      Cut down the debugging in the URB submission and completion paths:
       - Don't squawk about successful transfers, only unsuccessful ones.
       - Only print the number of bytes transferred if this was a short
         transfer.
       - Don't print the endpoint index for successful transfers (will add
         more debug to failed transfers to show endpoint index there later).
       - Stop printing MMIO writes.  This debugging shows up when the endpoint
         doorbell is rung a to start a transfer (basically for every URB).
       - Don't print out the ring enqueue and dequeue pointers
       - Stop printing when we're pointing to a link TRB.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      f444ff27
    • Sarah Sharp's avatar
      xhci: STFU: Don't print event ring dequeue pointer. · 5153b7b3
      Sarah Sharp authored
      Stop printing out the event ring dequeue pointer and status register in
      the operational register set.  The host will report an OK status 99% of
      the time the interrupt handler is called, and usually when it's really
      hosed, a host controller won't even call the interrupt handler.  So the
      line is really useless.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      5153b7b3
    • Sarah Sharp's avatar
      xhci: STFU: Remove function tracing. · 380032c3
      Sarah Sharp authored
      Remove unnecessary debugging from the xHCI driver.  We don't need to
      know what function we're calling or returning from.  Now I know how to
      use markup-oops.pl to de-mystify stack dumps of crashes.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      380032c3
    • Sarah Sharp's avatar
      xhci: Don't submit commands when the host is dead. · fe6c6c13
      Sarah Sharp authored
      When the xHCI host controller dies, the USB core may attempt to reset the
      devices to their default configuration before disconnecting them.  This
      causes calls into the xHCI bandwidth allocation functions.  Don't allow
      those functions to submit commands or work on xHCI structures if the host
      controller is marked as dying.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      fe6c6c13
    • Sarah Sharp's avatar
      xhci: Clear stopped_td when Stop Endpoint command completes. · 0714a57c
      Sarah Sharp authored
      When an URB is cancelled, the xHCI driver issues a Stop Endpoint command
      so that it can manipulate the ring and remove the transfer.  The xHC
      hardware then places a transfer event with the completion code "Stopped"
      or "Stopped Invalid" to let the driver know what TD it was in the middle
      of processing.  This TD and TRB is stored in ep->stopped_td and
      ep->stopped_trb.  These pointers are also used in handling stalled
      endpoints.
      
      By design, the Stop Endpoint command can race with URB completion.  By
      the time the Stop Endpoint command is handled, the URBs to be cancelled
      may have been given back to the driver.  Unfortunately, the stopped_td
      and stopped_trb pointers were not getting cleared in this case.
      
      The USB core unconditionally tries to reset the toggle bits on any
      endpoints when a new alternate interface setting is installed.  When the
      xHCI driver saw that ep->stopped_td was still set from the Stop Endpoint
      command, xhci_reset_endpoint assumed the endpoint was actually stalled,
      and attempted to clean up the endpoint rings.  This would manifest
      itself in a failed Reset Endpoint command and failed Set TR dequeue
      Pointer command after a successful Configure Endpoint command.  It may
      have also been causing driver oops when the stopped_td was accessed.
      
      This patch should be backported to stable kernels since 2.6.31.  Before
      2.6.33, stopped_td was found in the xhci_endpoint_ring, not the
      xhci_virt_ep.
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      0714a57c
  4. 24 May, 2011 7 commits
  5. 23 May, 2011 25 commits