1. 10 9月, 2011 12 次提交
    • S
      xhci: Redundant check in xhci_check_args for xhci->devs · 73ddc247
      sifram.rajas@gmail.com 提交于
      The xhci_hcd->devs is an array of pointers rather than pointer to pointer.
      Hence this check is not required.
      
      Signed-off-by: Sifram Rajas <Sifram Rajas sifram.rajas@gmail.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      73ddc247
    • A
      xHCI: refine td allocation · 2ffdea25
      Andiry Xu 提交于
      In xhci_urb_enqueue(), allocate a block of memory for all the TDs instead
      of allocating memory for each of them separately. This reduces the number
      of kzalloc calling when an isochronous usb is submitted.
      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>
      2ffdea25
    • S
      xhci: Don't print short isoc packets. · fd984d24
      Sarah Sharp 提交于
      Now that the xHCI driver always return a status value of zero for isochronous
      URBs, when the last TD of an isochronous URB is short, the local variable
      "status" stays set to -EINPROGRESS.  When xHCI driver debugging is turned on,
      this causes the log file to fill with messages like this:
      
      [   38.859282] xhci_hcd 0000:00:14.0: Giveback URB ffff88013ad47800, len = 1408, expected = 580, status = -115
      
      Don't print out the status of an URB for isochronous URBs.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fd984d24
    • S
      xhci: Add software BW checking quirk to Intel PPT xHCI · 86cc558e
      Sarah Sharp 提交于
      The xHCI host controller in the Intel Panther Point chipset needs to have
      software check whether new devices will fit in the available bus
      bandwidth.  Activate the software bandwidth checking quirk when we find
      the right PCI device.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      86cc558e
    • S
      xhci: Implement HS/FS/LS bandwidth checking. · c29eea62
      Sarah Sharp 提交于
      Now that we have a bandwidth interval table per root port or TT that
      describes the endpoint bandwidth information, we can finally use it to
      check whether the bus bandwidth is oversubscribed for a new device
      configuration/alternate interface setting.
      
      The complication for this algorithm is that the bit of hardware logic that
      creates the bus schedule is only 12-bit logic.  In order to make sure it
      can represent the maximum bus bandwidth in 12 bits, it has to convert the
      endpoint max packet size and max esit payload into "blocks" (basically a
      less-precise representation).  The block size for each speed of device is
      different, aside from low speed and full speed.  In order to make sure we
      don't allow a setup where the scheduler might fail, we also have to do the
      bandwidth checking in blocks.
      
      After checking that the endpoints fit in the schedule, we store the
      bandwidth used for this root port or TT.  If this is a FS/LS device under
      an external HS hub, we also update the TT bandwidth and the root port
      bandwidth (if this is a newly activated or deactivated TT).
      
      I won't go into the details of the algorithm, as it's pretty well
      documented in the comments.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c29eea62
    • 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: Refactor endpoint limit checking. · 750645f8
      Sarah Sharp 提交于
      Move the code to check whether we've reached the host controller's limit
      on the number of endpoints out of the two conditional statements, to
      remove duplicate code.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      750645f8
    • 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
    • S
      xhci: If no endpoints changed, don't issue BW command. · 2dc37539
      Sarah Sharp 提交于
      Some alternate interface settings have no endpoints associated with them.
      This shows up in some USB webcams, particularly the Logitech HD 1080p,
      which uses the uvcvideo driver.  If a driver switches between two alt
      settings with no endpoints, there is no need to issue a configure endpoint
      command, because there is no endpoint information to update.
      
      The only time a configure endpoint command with just the add slot flag set
      makes sense is when the driver is updating hub characteristics in the slot
      context.  However, that code never calls xhci_check_bandwidth, so we
      should be safe not issuing a command if only the slot context add flag is
      set.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      2dc37539
  2. 29 8月, 2011 3 次提交
  3. 28 8月, 2011 1 次提交
  4. 27 8月, 2011 11 次提交
  5. 26 8月, 2011 13 次提交