1. 09 Sep, 2011 6 commits
    • Sarah Sharp's avatar
      xhci: Store endpoint bandwidth information. · 9af5d71d
      Sarah Sharp authored
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      9af5d71d
    • 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 15 commits