1. 10 9月, 2011 5 次提交
    • S
      xhci: Track interval bandwidth tables per port/TT. · 2e27980e
      Sarah Sharp 提交于
      In order to update the root port or TT's bandwidth interval table, we will
      need to keep track of a list of endpoints, per interval.  That way we can
      easily know the new largest max packet size when we have to remove an
      endpoint.
      
      Add an endpoint list for each root port or TT structure, sorted by
      endpoint max packet size.  Insert new endpoints into the list such that
      the head of the list always has the endpoint with the greatest max packet
      size.  Only insert endpoints and update the interval table with new
      information when those endpoints are periodic.
      
      Make sure to update the number of active TTs when we add or drop periodic
      endpoints.  A TT is only considered active if it has one or more periodic
      endpoints attached (control and bulk are best effort, and counted in the
      20% reserved on the high speed bus).  If the number of active endpoints
      for a TT was zero, and it's now non-zero, increment the number of active
      TTs for the rootport.  If the number of active endpoints was non-zero, and
      it's now zero, decrement the number of active TTs.
      
      We have to be careful when we're checking the bandwidth for a new
      configuration/alt setting.  If we don't have enough bandwidth, we need to
      be able to "roll back" the bandwidth information stored in the endpoint
      and the root port/TT interval bandwidth table.  We can't just create a
      copy of the interval bandwidth table, modify it, and check the bandwidth
      with the copy because we have lists of endpoints and entries can't be on
      more than one list.  Instead, we copy the old endpoint bandwidth
      information, and use it to revert the interval table when the bandwidth
      check fails.
      
      We don't check the bandwidth after endpoints are dropped from the interval
      table when a device is reset or freed after a disconnect, because having
      endpoints use less bandwidth should not push the bandwidth usage over the
      limits.  Besides which, we can't fail a device disconnect.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2e27980e
    • S
      xhci: Store endpoint bandwidth information. · 9af5d71d
      Sarah Sharp 提交于
      In the upcoming patches, we'll use some stored endpoint information to
      make software keep track of the worst-case bandwidth schedule.  We need to
      store several variables associated with each periodic endpoint:
       - the type of endpoint
       - Max Packet Size
       - Mult
       - Max ESIT payload
       - Max Burst Size (aka number of packets, stored in one-based form)
       - the endpoint interval (normalized to powers of 2 microframes)
      
      All this information is available to the hardware, and stored in its
      device output context.  However, we need to ensure that the new
      information is stored before the xHCI driver drops the xhci->lock to wait
      on the Configure Endpoint command, so that another driver requesting a
      configuration or alt setting change will see the update.  The Configure
      Endpoint command will never fail on the hardware that needs this software
      bandwidth checking (assuming the slot is enabled and the flags are set
      properly), so updating the endpoint info before the command completes
      should be fine.
      
      Until we add in the bandwidth checking code, just update the endpoint
      information after the Configure Endpoint command completes, and after a
      Reset Device command completes.  Don't bother to clear the endpoint
      bandwidth info when a device is being freed, since the xhci_virt_ep is
      just going to be freed anyway.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9af5d71d
    • S
      xhci: Store information about roothubs and TTs. · 839c817c
      Sarah Sharp 提交于
      For upcoming patches, we need to keep information about the bandwidth
      domains under the xHCI host.  Each root port is a separate primary
      bandwidth domain, and each high speed hub's TT (and potentially each port
      on a multi-TT hub) is a secondary bandwidth domain.
      
      If the table were in text form, it would look a bit like this:
      
      EP Interval	Sum of Number	Largest Max	Max Packet
      		of Packets	Packet Size	Overhead
      	0	   N		   mps		  overhead
      ...
      	15	   N		   mps		  overhead
      
      Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
      overhead, etc) for all the endpoints in this interval.  Devices with
      different speeds have different max packet overhead.  For example, if
      there is a low speed and a full speed endpoint that both have an interval
      of 3, we would use the higher overhead (the low speed overhead).  Interval
      0 is a bit special, since we really just want to know the sum of the max
      ESIT payloads instead of the largest max packet size.  That's stored in
      the interval0_esit_payload variable.  For root ports, we also need to keep
      track of the number of active TTs.
      
      For each root port, and each TT under a root port, store some information
      about the bandwidth consumption.  Dynamically allocate an array of root
      port bandwidth information for the number of root ports on the xHCI host.
      Each root port stores a list of TTs under the root port.  A single TT hub
      only has one entry in the list, but a multi-TT hub will have an entry per
      port.
      
      When the USB core says that a USB device is a hub, create one or more
      entries in the root port TT list for the hub.  When a device is deleted,
      and it is a hub, search through the root port TT list and delete all
      TT entries for the hub.  Keep track of which TT entry is associated with a
      device under a TT.
      
      LS/FS devices attached directly to the root port will have usb_device->tt
      set to the roothub.  Ignore that, and treat it like a primary bandwidth
      domain, since there isn't really a high speed bus between the roothub and
      the host.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      839c817c
    • S
      xhci: Store the "real" root port number. · 66381755
      Sarah Sharp 提交于
      Since the xHCI driver now has split USB2/USB3 roothubs, devices under each
      roothub can have duplicate "fake" port numbers.  For the next set of
      patches, we need to keep track of the "real" port number that the xHCI
      host uses to index into the port status arrays.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      66381755
    • S
      xhci: Rename virt_dev->port to fake_port. · fe30182c
      Sarah Sharp 提交于
      The "port" field in xhci_virt_dev stores the port number associated with
      one of the two xHCI split roothubs, not the unique port number the xHCI
      hardware uses.  Since we'll need to store the real hardware port number in
      future patches, rename this field to "fake_port".
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fe30182c
  2. 18 6月, 2011 2 次提交
    • M
      xhci: Add reset on resume quirk for asrock p67 host · c877b3b2
      Maarten Lankhorst 提交于
      The asrock p67 xhci controller completely dies on resume, add a
      quirk for this, to bring the host back online after a suspend.
      
      This should be backported to stable kernels as old as 2.6.37.
      Signed-off-by: NMaarten Lankhorst <m.b.lankhorst@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      c877b3b2
    • A
      xHCI 1.0: Incompatible Device Error · f6ba6fe2
      Alex He 提交于
      It is one new TRB Completion Code for the xHCI spec v1.0.
      Asserted if the xHC detects a problem with a device that does not allow it to
      be successfully accessed, e.g. due to a device compliance or compatibility
      problem. This error may be returned by any command or transfer, and is fatal
      as far as the Slot is concerned. Return -EPROTO by urb->status or frame->status
      of ISOC for transfer case. And return -ENODEV for configure endpoint command,
      evaluate context command and address device command if there is an incompatible
      Device Error. The error codes will be sent back to the USB core to decide how
      to do. It's unnecessary for other commands because after the three commands run
      successfully means that the device has been accepted.
      Signed-off-by: NAlex He <alex.he@amd.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f6ba6fe2
  3. 03 6月, 2011 3 次提交
  4. 28 5月, 2011 2 次提交
    • 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
  5. 26 5月, 2011 1 次提交
    • S
      xhci: STFU: Be quieter during URB submission and completion. · f444ff27
      Sarah Sharp 提交于
      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: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      f444ff27
  6. 10 5月, 2011 3 次提交
  7. 03 5月, 2011 3 次提交
    • S
      xhci 1.0: Set transfer burst last packet count field. · b61d378f
      Sarah Sharp 提交于
      The xHCI 1.0 specification defines a new isochronous TRB field, called
      transfer burst last packet count (TBLPC).  This field defines the number
      of packets in the last "burst" of packets in a TD.  Only SuperSpeed
      endpoints can handle more than one burst, so this is set to the number for
      packets in a TD for all non-SuperSpeed devices (minus one, since the field
      is zero based).
      
      This patch should have no effect on host controllers that don't advertise
      the xHCI 1.0 (0x100) version number in their hci_version field.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      b61d378f
    • S
      xhci 1.0: Set transfer burst count field. · 5cd43e33
      Sarah Sharp 提交于
      The xHCI 1.0 specification adds a new field to the fourth dword in an
      isochronous TRB: the transfer burst count (TBC).  This field is only
      non-zero for SuperSpeed devices.  Each SS endpoint sets the bMaxBurst
      field in the SuperSpeed endpoint companion descriptor, which indicates how
      many max-packet-sized "bursts" it can handle in one service interval.  The
      device driver may choose to burst less max packet sized chunks each
      service interval (which is defined by one TD).  The xHCI driver indicates
      to the host controller how many bursts it needs to schedule through the
      transfer burst count field.
      
      This patch will only effect xHCI hosts that advertise 1.0 support (0x100)
      in the HCI version field of their capabilities register.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      5cd43e33
    • M
      xhci: Make xHCI driver endian-safe · 28ccd296
      Matt Evans 提交于
      This patch changes the struct members defining access to xHCI device-visible
      memory to use __le32/__le64 where appropriate, and then adds swaps where
      required.  Checked with sparse that all accesses are correct.
      
      MMIO accesses use readl/writel so already are performed LE, but prototypes
      now reflect this with __le*.
      
      There were a couple of (debug) instances of DMA pointers being truncated to
      32bits which have been fixed too.
      Signed-off-by: NMatt Evans <matt@ozlabs.org>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      28ccd296
  8. 14 4月, 2011 3 次提交
    • 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
    • D
      USB: xhci: unsigned char never equals -1 · 22e04870
      Dan Carpenter 提交于
      There were some places that compared port_speed == -1 where port_speed
      is a u8.  This doesn't work unless we cast the -1 to u8.  Some places
      did it correctly.
      
      Instead of using -1 directly, I've created a DUPLICATE_ENTRY define
      which does the cast and is more descriptive as well.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      22e04870
    • D
      USB: xhci - fix unsafe macro definitions · 5a6c2f3f
      Dmitry Torokhov 提交于
      Macro arguments used in expressions need to be enclosed in parenthesis
      to avoid unpleasant surprises.
      
      This should be queued for kernels back to 2.6.31
      Signed-off-by: NDmitry Torokhov <dtor@vmware.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@kernel.org
      5a6c2f3f
  9. 31 3月, 2011 1 次提交
  10. 14 3月, 2011 8 次提交
    • 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: Return canceled URBs immediately when host is halted. · c6cc27c7
      Sarah Sharp 提交于
      When the xHCI host controller is halted, it won't respond to commands
      placed on the command ring.  So if an URB is cancelled after the first
      roothub is deallocated, it will try to place a stop endpoint command on
      the command ring, which will fail.  The command watchdog timer will fire
      after five seconds, and the host controller will be marked as dying, and
      all URBs will be completed.
      
      Add a flag to the xHCI's internal state variable for when the host
      controller is halted.  Immediately return the canceled URB if the host
      controller is halted.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      c6cc27c7
    • 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: 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
    • S
      xhci: Rework port suspend structures for limited ports. · 1d5810b6
      Sarah Sharp 提交于
      The USB core only allows up to 31 (USB_MAXCHILDREN) ports under a roothub.
      The xHCI driver keeps track of which ports are suspended, which ports have
      a suspend change bit set, and what time the port will be done resuming.
      It keeps track of the first two by setting a bit in a u32 variable,
      suspended_ports or port_c_suspend.  The xHCI driver currently assumes we
      can have up to 256 ports under a roothub, so it allocates an array of 8
      u32 variables for both suspended_ports and port_c_suspend.  It also
      allocates a 256-element array to keep track of when the ports will be done
      resuming.
      
      Since we can only have 31 roothub ports, we only need to use one u32 for
      each of the suspend state and change variables.  We simplify the bit math
      that's trying to index into those arrays and set the correct bit, if we
      assume wIndex never exceeds 30.  (wIndex is zero-based after it's
      decremented from the value passed in from the USB core.)  Finally, we
      change the resume_done array to only hold 31 elements.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: Andiry Xu <andiry.xu@amd.com>
      1d5810b6
    • 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
  11. 20 2月, 2011 1 次提交
  12. 15 1月, 2011 1 次提交
  13. 20 11月, 2010 1 次提交
    • S
      xhci: Setup array of USB 2.0 and USB 3.0 ports. · da6699ce
      Sarah Sharp 提交于
      An xHCI host controller contains USB 2.0 and USB 3.0 ports, which can
      occur in any order in the PORTSC registers.  We cannot read the port speed
      bits in the PORTSC registers at init time to determine the port speed,
      since those bits are only valid when a USB device is plugged into the
      port.
      
      Instead, we read the "Supported Protocol Capability" registers in the xHC
      Extended Capabilities space.  Those describe the protocol, port offset in
      the PORTSC registers, and port count.  We use those registers to create
      two arrays of pointers to the PORTSC registers, one for USB 3.0 ports, and
      another for USB 2.0 ports.  A third array keeps track of the port protocol
      major revision, and is indexed with the internal xHCI port number.
      
      This commit is a bit big, but it should be queued for stable because the "Don't
      let the USB core disable SuperSpeed ports" patch depends on it.  There is no
      other way to determine which ports are SuperSpeed ports without this patch.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NDon Zickus <dzickus@redhat.com>
      Cc: stable@kernel.org
      da6699ce
  14. 12 11月, 2010 1 次提交
  15. 23 10月, 2010 5 次提交