1. 09 Sep, 2011 5 commits
    • Sarah Sharp's avatar
      xhci: Store information about roothubs and TTs. · 839c817c
      Sarah Sharp authored
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      839c817c
    • Sarah Sharp's avatar
      xhci: Store the "real" root port number. · 66381755
      Sarah Sharp authored
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      66381755
    • Sarah Sharp's avatar
      xhci: Refactor endpoint limit checking. · 750645f8
      Sarah Sharp authored
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      750645f8
    • Sarah Sharp's avatar
      xhci: Rename virt_dev->port to fake_port. · fe30182c
      Sarah Sharp authored
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      fe30182c
    • Sarah Sharp's avatar
      xhci: If no endpoints changed, don't issue BW command. · 2dc37539
      Sarah Sharp authored
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2dc37539
  2. 29 Aug, 2011 2 commits
  3. 28 Aug, 2011 1 commit
  4. 27 Aug, 2011 2 commits
  5. 26 Aug, 2011 14 commits
  6. 25 Aug, 2011 16 commits