1. 11 4月, 2012 2 次提交
  2. 02 12月, 2011 1 次提交
    • S
      Revert "xHCI: reset-on-resume quirk for NEC uPD720200" · 0de13500
      Sarah Sharp 提交于
      This reverts commit df711fc9.
      
      The commit added a reset-on-resume quirk because the NEC chipset stopped
      responding to commands about 30 minutes after a system resume from
      suspend.  We thought it was a chipset issue, but it turns out that the
      xHCI driver was zeroing out the link TRB after a successful context
      restore during resume.  The host controller would fall off the command
      ring sometime later, causing it to not respond to new commands.
      
      The link TRB issue has been fixed with commit
      158886cd "xHCI: fix bug in
      xhci_clear_command_ring()", so revert the reset-on-resume quirk, as it's
      not necessary.
      
      Commit df711fc9 was marked for stable
      trees back to 2.6.37, but according to my mail, it has not made it into
      Linus' tree or the stable trees yet.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NJulian Sikorski <belegdol@gmail.com>
      Cc: Andiry Xu <andiry.xu@amd.com>
      0de13500
  3. 29 11月, 2011 1 次提交
  4. 01 11月, 2011 1 次提交
  5. 27 9月, 2011 6 次提交
    • S
      usb/xhci: remove CONFIG_PCI in xhci.c's probe function · 0cc47d54
      Sebastian Andrzej Siewior 提交于
      This removes the need of ifdefs within the init function and with it the
      headache about the correct clean without bus X but with bus/platform Y &
      Z.
      xhci-pci is only compiled if CONFIG_PCI is selected which can be
      de-selected now without trouble. For now the result is kinda useless
      because we have no other glue code. However, since nobody is using
      USB_ARCH_HAS_XHCI then it should not be an issue :)
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0cc47d54
    • S
      usb/xhci: move xhci_gen_setup() away from -pci. · 552e0c4f
      Sebastian Andrzej Siewior 提交于
      xhci_gen_setup() is generic so it can be used to perform the bare xhci
      setup even on non-pci based platform. The typedef for the function
      pointer is moved into the headerfile
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      552e0c4f
    • S
      usb/xhci: refactor xhci_pci_setup() · da3c9c4f
      Sebastian Andrzej Siewior 提交于
      xhci_pci_setup() is split into three pieces:
      
      - xhci_gen_setup()
        The major remaining of xhci_pci_setup() is now containing the generic
        part of the xhci setup. It allocates the xhci struct, setup
        hcs_params? and friends, performs xhci_halt(), xhci_init and so one.
        It also obtains the quirks via a callback
      - xhci_pci_quirks()
        It checks the origin of the xhci core and sets core specific quirks.
      - xhci_pci_setup()
        PCI specific setup functions. Besides calling xhci_gen_setup() with
        xhci_pci_quirks() as an argument it performs PCI specific setup like
        obtaining the address of sbrn via a PCI config space.
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      da3c9c4f
    • A
      xHCI: AMD isoc link TRB chain bit quirk · 7e393a83
      Andiry Xu 提交于
      Setting the chain (CH) bit in the link TRB of isochronous transfer rings
      is required by AMD 0.96 xHCI host controller to successfully transverse
      multi-TRB TD that span through different memory segments.
      
      When a Missed Service Error event occurs, if the chain bit is not set in
      the link TRB and the host skips TDs which just across a link TRB, the
      host may falsely recognize the link TRB as a normal TRB. You can see
      this may cause big trouble - the host does not jump to the right address
      which is pointed by the link TRB, but continue fetching the memory which
      is after the link TRB address, which may not even belong to the host,
      and the result cannot be predicted.
      
      This causes some big problems. Without the former patch I sent: "xHCI:
      prevent infinite loop when processing MSE event", the system may hang.
      With that patch applied, system does not hang, but the host still access
      wrong memory address and isoc transfer will fail. With this patch,
      isochronous transfer works as expected.
      
      This patch should be applied to kernels as old as 2.6.36, which was when
      the first isochronous support was added for the xHCI host controller.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7e393a83
    • A
      xHCI: set USB2 hardware LPM · 65580b43
      Andiry Xu 提交于
      If the device pass the USB2 software LPM and the host supports hardware
      LPM, enable hardware LPM for the device to let the host decide when to
      put the link into lower power state.
      
      If hardware LPM is enabled for a port and driver wants to put it into
      suspend, it must first disable hardware LPM, resume the port into U0,
      and then suspend the port.
      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>
      65580b43
    • A
      xHCI: test USB2 software LPM · 9574323c
      Andiry Xu 提交于
      This patch tests USB2 software LPM for a USB2 LPM-capable device.
      
      When a lpm-capable device is addressed, if the host also supports software
      LPM, apply a test by putting the device into L1 state and resume it to see
      if the device can do L1 suspend/resume successfully.
      
      If the device fails to enter L1 or resume from L1 state, it may not
      function normally and usbcore may disconnect and re-enumerate it. In this
      case, store the device's Vid and Pid information, make sure the host will
      not test LPM for it twice.
      
      The test result is per device/host. Some devices claim to be lpm-capable,
      but fail to enter L1 or resume. So the test is necessary.
      
      The xHCI 1.0 errata has modified the USB2.0 LPM implementation. It redefines
      the HIRD field to BESL, and adds another register Port Hardware LPM Control
      (PORTHLPMC). However, this should not affect the LPM behavior on xHC which
      does not implement 1.0 errata.
      
      USB2.0 LPM errata defines a new bit BESL in the device's USB 2.0 extension
      descriptor. If the device reports it uses BESL, driver should use BESL
      instead of HIRD for it.
      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>
      9574323c
  6. 18 9月, 2011 1 次提交
  7. 10 9月, 2011 1 次提交
  8. 18 6月, 2011 1 次提交
  9. 03 6月, 2011 1 次提交
    • S
      xhci: Disable MSI for some Fresco Logic hosts. · f5182b41
      Sarah Sharp 提交于
      Some Fresco Logic hosts, including those found in the AUAU N533V laptop,
      advertise MSI, but fail to actually generate MSI interrupts.  Add a new
      xHCI quirk to skip MSI enabling for the Fresco Logic host controllers.
      Fresco Logic confirms that all chips with PCI vendor ID 0x1b73 and device
      ID 0x1000, regardless of PCI revision ID, do not support MSI.
      
      This should be backported to stable kernels as far back as 2.6.36, which
      was the first kernel to support MSI on xHCI hosts.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Reported-by: NSergey Galanov <sergey.e.galanov@gmail.com>
      Cc: stable@kernel.org
      f5182b41
  10. 28 5月, 2011 3 次提交
    • S
      Intel xhci: Limit number of active endpoints to 64. · 2cf95c18
      Sarah Sharp 提交于
      The Panther Point chipset has an xHCI host controller that has a limit to
      the number of active endpoints it can handle.  Ideally, it would signal
      that it can't handle anymore endpoints by returning a Resource Error for
      the Configure Endpoint command, but they don't.  Instead it needs software
      to keep track of the number of active endpoints, across configure endpoint
      commands, reset device commands, disable slot commands, and address device
      commands.
      
      Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
      to track the number of endpoints the xHC has active.  This gets a little
      tricky, because commands to change the number of active endpoints can
      fail.  This patch adds a new xHCI quirk for these Intel hosts, and the new
      code should not have any effect on other xHCI host controllers.
      
      Fail a new device allocation if we don't have room for the new default
      control endpoint.  Use the endpoint ring pointers to determine what
      endpoints were active before a Reset Device command or a Disable Slot
      command, and drop those once the command completes.
      
      Fail a configure endpoint command if it would add too many new endpoints.
      We have to be a bit over zealous here, and only count the number of new
      endpoints to be added, without subtracting the number of dropped
      endpoints.  That's because a second configure endpoint command for a
      different device could sneak in before we know if the first command is
      completed.  If the first command dropped resources, the host controller
      fails the command for some reason, and we're nearing the limit of
      endpoints, we could end up oversubscribing the host.
      
      To fix this race condition, when evaluating whether a configure endpoint
      command will fix in our bandwidth budget, only add the new endpoints to
      xhci->num_active_eps, and don't subtract the dropped endpoints.  Ignore
      changed endpoints (ones that are dropped and then re-added), as that
      shouldn't effect the host's endpoint resources.  When the configure
      endpoint command completes, subtract off the dropped endpoints.
      
      This may mean some configuration changes may temporarily fail, but it's
      always better to under-subscribe than over-subscribe resources.
      
      (Originally my plan had been to push the resource allocation down into the
      ring allocation functions.  However, that would cause us to allocate
      unnecessary resources when endpoints were changed, because the xHCI driver
      allocates a new ring for the changed endpoint, and only deletes the old
      ring once the Configure Endpoint command succeeds.  A further complication
      would have been dealing with the per-device endpoint ring cache.)
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      2cf95c18
    • S
      Intel xhci: Ignore spurious successful event. · ad808333
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      ad808333
    • S
      Intel xhci: Support EHCI/xHCI port switching. · 69e848c2
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      69e848c2
  11. 30 4月, 2011 1 次提交
  12. 14 4月, 2011 1 次提交
    • A
      xHCI: Implement AMD PLL quirk · c41136b0
      Andiry Xu 提交于
      This patch disable the optional PM feature inside the Hudson3 platform under
      the following conditions:
      
      1. If an isochronous device is connected to xHCI port and is active;
      2. Optional PM feature that powers down the internal Bus PLL when the link is
         in low power state is enabled.
      
      The PM feature needs to be disabled to eliminate PLL startup delays when the
      link comes out of low power state. The performance of DMA data transfer could
      be impacted if system delay were encountered and in addition to the PLL start
      up delays. Disabling the PM would leave room for unpredictable system delays
      in order to guarantee uninterrupted data transfer to isochronous audio or
      video stream devices that require time sensitive information. If data in an
      audio/video stream was interrupted then erratic audio or video performance
      may be encountered.
      
      AMD PLL quirk is already implemented in OHCI/EHCI driver. After moving the
      quirk code to pci-quirks.c and export them, xHCI driver can call it directly
      without having the quirk implementation in itself.
      Signed-off-by: NAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c41136b0
  13. 14 3月, 2011 3 次提交
    • 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 hcd_priv into a pointer. · b02d0ed6
      Sarah Sharp 提交于
      Instead of allocating space for the whole xhci_hcd structure at the end of
      usb_hcd, make the USB core allocate enough space for a pointer to the
      xhci_hcd structure.  This will make it easy to share the xhci_hcd
      structure across the two roothubs (the USB 3.0 usb_hcd and the USB 2.0
      usb_hcd).
      
      Deallocate the xhci_hcd at PCI remove time, so the hcd_priv will be
      deallocated after the usb_hcd is deallocated.  We do this by registering a
      different PCI remove function that calls the usb_hcd_pci_remove()
      function, and then frees the xhci_hcd.  usb_hcd_pci_remove() calls
      kput() on the usb_hcd structure, which will deallocate the memory that
      contains the hcd_priv pointer, but not the memory it points to.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      b02d0ed6
  14. 23 10月, 2010 3 次提交
  15. 11 8月, 2010 1 次提交
  16. 05 6月, 2010 1 次提交
    • S
      USB: xhci: Print NEC firmware version. · 0238634d
      Sarah Sharp 提交于
      The NEC xHCI host controller firmware version can be found by putting a
      vendor-specific command on the command ring and extracting the BCD
      encoded-version out of the vendor-specific event TRB.
      
      The firmware version debug line in dmesg will look like:
      
      xhci_hcd 0000:05:00.0: NEC firmware version 30.21
      
      (NEC merged with Renesas Technologies and became Renesas Electronics on
      April 1, 2010.  I have their OK to merge this vendor-specific code.)
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Satoshi Otani <satoshi.otani.xm@renesas.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0238634d
  17. 21 5月, 2010 3 次提交
    • R
      USB: clean up some host controller sparse warnings · 326b4810
      Randy Dunlap 提交于
      Fix usb sparse warnings:
      
      drivers/usb/host/isp1362-hcd.c:2220:50: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:43:24: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:49:24: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:161:24: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:198:16: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:319:31: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:1231:33: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-pci.c:177:23: warning: non-ANSI function declaration of function 'xhci_register_pci'
      drivers/usb/host/xhci-pci.c:182:26: warning: non-ANSI function declaration of function 'xhci_unregister_pci'
      drivers/usb/host/xhci-ring.c:342:32: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:525:34: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:1009:32: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:1031:32: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:1041:16: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:1096:30: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-ring.c:1100:27: warning: Using plain integer as NULL pointer
      drivers/usb/host/xhci-mem.c:224:27: warning: symbol 'xhci_alloc_container_ctx' was not declared. Should it be static?
      drivers/usb/host/xhci-mem.c:242:6: warning: symbol 'xhci_free_container_ctx' was not declared. Should it be static?
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Lothar Wassmann <LW@KARO-electronics.de>
      Signed-off By: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      326b4810
    • S
      USB: Support for allocating USB 3.0 streams. · eab1cafc
      Sarah Sharp 提交于
      Bulk endpoint streams were added in the USB 3.0 specification.  Streams
      allow a device driver to overload a bulk endpoint so that multiple
      transfers can be queued at once.
      
      The device then decides which transfer it wants to work on first, and can
      queue part of a transfer before it switches to a new stream.  All this
      switching is invisible to the device driver, which just gets a completion
      for the URB.  Drivers that use streams must be able to handle URBs
      completing in a different order than they were submitted to the endpoint.
      
      This requires adding new API to set up xHCI data structures to support
      multiple queues ("stream rings") per endpoint.  Drivers will allocate a
      number of stream IDs before enqueueing URBs to the bulk endpoints of the
      device, and free the stream IDs in their disconnect function.  See
      Documentation/usb/bulk-streams.txt for details.
      
      The new mass storage device class, USB Attached SCSI Protocol (UASP), uses
      these streams API.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      eab1cafc
    • S
      USB: xhci: Limit bus sg_tablesize to 62 TRBs. · bc88d2eb
      Sarah Sharp 提交于
      When a scatter-gather list is enqueued to the xHCI driver, it translates
      each entry into a transfer request block (TRB).  Only 63 TRBs can be
      used per ring segment, and there must be one additional TRB reserved to
      make sure the hardware does not think the ring is empty (so the enqueue
      pointer doesn't equal the dequeue pointer).  Limit the bus sg_tablesize
      to 62 TRBs.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bc88d2eb
  18. 03 3月, 2010 1 次提交
  19. 12 12月, 2009 1 次提交
  20. 23 9月, 2009 3 次提交
    • S
      USB: Add hub descriptor update hook for xHCI · b356b7c7
      Sarah Sharp 提交于
      Add a hook for updating xHCI internal structures after khubd fetches the
      hub descriptor and sets up the hub's TT information.  The xHCI driver must
      update the internal structures before devices under the hub can be
      enumerated.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b356b7c7
    • S
      USB: xhci: Support USB hubs. · ac1c1b7f
      Sarah Sharp 提交于
      For a USB hub to work under an xHCI host controller, the xHC's internal
      scheduler must be made aware of the hub's characteristics.  Add an xHCI
      hook that the USB core will call after it fetches the hub descriptor.
      This hook will add hub information to the slot context for that device,
      including whether it has multiple TTs or a single TT, the number of ports
      on the hub, and TT think time.
      
      Setting up the slot context for the device is different for 0.95 and 0.96
      xHCI host controllers.
      
      Some of the slot context reserved fields in the 0.95 specification were
      changed into hub fields in the 0.96 specification.  Don't set the TT think
      time or number of ports for a hub if we're dealing with a 0.95-compliant
      xHCI host controller.
      
      The 0.95 xHCI specification says that to modify the hub flag, we need to
      issue an evaluate context command.  The 0.96 specification says that flag
      can be set with a configure endpoint command.  Issue the correct command
      based on the version reported by the hardware.
      
      This patch does not add support for multi-TT hubs.  Multi-TT hubs expose
      a single TT on alt setting 0, and multi-TT on alt setting 1.  The xHCI
      driver can't handle setting alternate interfaces yet.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ac1c1b7f
    • S
      USB: xhci: Add quirk for Fresco Logic xHCI hardware. · ac9d8fe7
      Sarah Sharp 提交于
      This Fresco Logic xHCI host controller chip revision puts bad data into
      the output endpoint context after a Reset Endpoint command.  It needs a
      Configure Endpoint command (instead of a Set TR Dequeue Pointer command)
      after the reset endpoint command.
      
      Set up the input context before issuing the Reset Endpoint command so we
      don't copy bad data from the output endpoint context.  The HW also can't
      handle two commands queued at once, so submit the TRB for the Configure
      Endpoint command in the event handler for the Reset Endpoint command.
      
      Devices that stall on control endpoints before a configuration is selected
      will not work under this Fresco Logic xHCI host controller revision.
      
      This patch is for prototype hardware that will be given to other companies
      for evaluation purposes only, and should not reach consumer hands.  Fresco
      Logic's next chip rev should have this bug fixed.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable <stable@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ac9d8fe7
  21. 29 7月, 2009 1 次提交
    • S
      USB: xhci: Deal with stalled endpoints. · a1587d97
      Sarah Sharp 提交于
      When an endpoint on a device under an xHCI host controller stalls, the
      host controller driver must let the hardware know that the USB core has
      successfully cleared the halt condition.  The HCD submits a Reset Endpoint
      Command, which will clear the toggle bit for USB 2.0 devices, and set the
      sequence number to zero for USB 3.0 devices.
      
      The xHCI urb_enqueue will accept new URBs while the endpoint is halted,
      and will queue them to the hardware rings.  However, the endpoint doorbell
      will not be rung until the Reset Endpoint Command completes.
      
      Don't queue a reset endpoint command for root hubs.  khubd clears halt
      conditions on the roothub during the initialization process, but the roothub
      isn't a real device, so the xHCI host controller doesn't need to know about the
      cleared halt.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      a1587d97
  22. 16 6月, 2009 3 次提交
    • S
      USB: xhci: Bandwidth allocation support · f94e0186
      Sarah Sharp 提交于
      Since the xHCI host controller hardware (xHC) has an internal schedule, it
      needs a better representation of what devices are consuming bandwidth on
      the bus.  Each device is represented by a device context, with data about
      the device, endpoints, and pointers to each endpoint ring.
      
      We need to update the endpoint information for a device context before a
      new configuration or alternate interface setting is selected.  We setup an
      input device context with modified endpoint information and newly
      allocated endpoint rings, and then submit a Configure Endpoint Command to
      the hardware.
      
      The host controller can reject the new configuration if it exceeds the bus
      bandwidth, or the host controller doesn't have enough internal resources
      for the configuration.  If the command fails, we still have the older
      device context with the previous configuration.  If the command succeeds,
      we free the old endpoint rings.
      
      The root hub isn't a real device, so always say yes to any bandwidth
      changes for it.
      
      The USB core will enable, disable, and then enable endpoint 0 several
      times during the initialization sequence.  The device will always have an
      endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
      device is disconnected or gets a SetAddress 0 request.  So we don't pay
      attention for when xhci_check_bandwidth() is called for a re-add of
      endpoint 0.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f94e0186
    • S
      USB: xhci: Control transfer support. · d0e96f5a
      Sarah Sharp 提交于
      Allow device drivers to enqueue URBs to control endpoints on devices under
      an xHCI host controller.  Each control transfer is represented by a
      series of Transfer Descriptors (TDs) written to an endpoint ring.  There
      is one TD for the Setup phase, (optionally) one TD for the Data phase, and
      one TD for the Status phase.
      
      Enqueue these TDs onto the endpoint ring that represents the control
      endpoint.  The host controller hardware will return an event on the event
      ring that points to the (DMA) address of one of the TDs on the endpoint
      ring.  If the transfer was successful, the transfer event TRB will have a
      completion code of success, and it will point to the Status phase TD.
      Anything else is considered an error.
      
      This should work for control endpoints besides the default endpoint, but
      that hasn't been tested.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d0e96f5a
    • S
      USB: xhci: Allocate and address USB devices · 3ffbba95
      Sarah Sharp 提交于
      xHCI needs to get a "Slot ID" from the host controller and allocate other
      data structures for every USB device.  Make usb_alloc_dev() and
      usb_release_dev() allocate and free these device structures.  After
      setting up the xHC device structures, usb_alloc_dev() must wait for the
      hardware to respond to an Enable Slot command.  usb_alloc_dev() fires off
      a Disable Slot command and does not wait for it to complete.
      
      When the USB core wants to choose an address for the device, the xHCI
      driver must issue a Set Address command and wait for an event for that
      command.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      3ffbba95