1. 20 Sep, 2011 4 commits
  2. 18 Sep, 2011 18 commits
  3. 09 Sep, 2011 18 commits
    • Klaus Schwarzkopf's avatar
      usb gadget: clean up FSF boilerplate text · 28c9fc68
      Klaus Schwarzkopf authored
      remove the following two paragraphs as they are not needed:
      
      This program is distributed in the hope that it will be useful, but
      WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
      FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
      License for more details.
      
      You should have received a copy of the GNU General Public License along with
      this program; if not, write to the Free Software Foundation, Inc.,59
      Temple Place - Suite 330, Boston, MA  02111-1307, USA.
      Signed-off-by: default avatarKlaus Schwarzkopf <schwarzkopf@sensortherm.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      28c9fc68
    • Hans Petter Selasky's avatar
      musb_gadget: Fix for spurious interrupts on endpoint zero. · de76cc2b
      Hans Petter Selasky authored
      There is a multi-year old bug in the MUSB hardware which is not documented.
      It causes spurious interrupts and have various symptoms, like endless
      "SetupEnd came in a wrong ep0stage" messages. The fix is taken from the
      FreeBSD's musb driver.
      
      How to reproduce:
      For example issue clear-stall on a couple of endpoints very fast,
      like one request per 125us. After a while the bug triggers and the
      musb-chip becomes unusable until next re-enumeration.
      Signed-off-by: default avatarHans Petter Selasky <hps@bitfrost.no>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      de76cc2b
    • Jim Wylder's avatar
      USB: for usb_autopm_get_interface_async -EINPROGRESS is not an error · c5a48592
      Jim Wylder authored
      A return value of -EINPROGRESS from pm_runtime_get indicates that
      the device is already resuming due to a previous call.  Internally,
      usb_autopm_get_interface_async doesn't treat this as an error and
      increments the usage count, but passes the error status along
      to the caller.  The logical assumption of the caller is that
      any negative return value reflects the device not resuming
      and the pm_usage_cnt not being incremented.  Since the usage count
      is being incremented and the device is resuming, return success (0)
      instead.
      Signed-off-by: default avatarJames Wylder <james.wylder@motorola.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c5a48592
    • Luben Tuikov's avatar
      USB: storage: Use normalized sense when emulating autosense · e16da02f
      Luben Tuikov authored
      This patch solves two things:
      1) Enables autosense emulation code to correctly
      interpret descriptor format sense data, and
      2) Fixes a bug whereby the autosense emulation
      code would overwrite descriptor format sense data
      with SENSE KEY HARDWARE ERROR in fixed format, to
      incorrectly look like this:
      
      Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc]  Sense Key : Recovered Error [current] [descriptor]
      Oct 21 14:11:07 localhost kernel: Descriptor sense data with sense descriptors (in hex):
      Oct 21 14:11:07 localhost kernel:        72 01 04 1d 00 00 00 0e 09 0c 00 00 00 00 00 00
      Oct 21 14:11:07 localhost kernel:        00 4f 00 c2 00 50
      Oct 21 14:11:07 localhost kernel: sd 7:0:0:0: [sdc]  ASC=0x4 ASCQ=0x1d
      Signed-off-by: default avatarLuben Tuikov <ltuikov@yahoo.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Acked-by: default avatarMatthew Dharm <mdharm-usb@one-eyed-alien.net>
      Cc: stable <stable@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e16da02f
    • sifram.rajas@gmail.com's avatar
      xhci: Redundant check in xhci_check_args for xhci->devs · 73ddc247
      sifram.rajas@gmail.com authored
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      73ddc247
    • Andiry Xu's avatar
      xHCI: refine td allocation · 2ffdea25
      Andiry Xu authored
      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: default avatarAndiry Xu <andiry.xu@amd.com>
      Signed-off-by: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2ffdea25
    • Sarah Sharp's avatar
      xhci: Don't print short isoc packets. · fd984d24
      Sarah Sharp authored
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      fd984d24
    • Sarah Sharp's avatar
      xhci: Add software BW checking quirk to Intel PPT xHCI · 86cc558e
      Sarah Sharp authored
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      86cc558e
    • Sarah Sharp's avatar
      xhci: Implement HS/FS/LS bandwidth checking. · c29eea62
      Sarah Sharp authored
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      c29eea62
    • Sarah Sharp's avatar
      xhci: Track interval bandwidth tables per port/TT. · 2e27980e
      Sarah Sharp authored
      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: default avatarSarah Sharp <sarah.a.sharp@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2e27980e
    • 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
    • Anand Gadiyar's avatar
      usb: musb: Enable DMA mode1 RX for transfers without short packets · 0ae52d54
      Anand Gadiyar authored
      This patch enables DMA mode1 for the RX path when we know
      there won't be any short packets. We check that by looking
      into the short_no_ok flag, if it's true we enable mode1, otherwise
      we use mode0 to transfer the data.
      
      This will result in a throughput performance gain of around
      40% for USB mass-storage/mtp use cases.
      
      [ balbi@ti.com : updated commit log and code comments slightly ]
      Signed-off-by: default avatarAnand Gadiyar <gadiyar@ti.com>
      Signed-off-by: default avatarMoiz Sonasath <m-sonasath@ti.com>
      Signed-off-by: default avatarVikram Pandita <vikram.pandita@ti.com>
      Tested-by: default avatarVikram Pandita <vikram.pandita@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      0ae52d54
    • Felipe Balbi's avatar
      usb: musb: fix build breakage · b3c3dc22
      Felipe Balbi authored
      This patch fixes the compilation brekage which
      commits 208466dc ("usb: otg:OMAP4430: Powerdown
      the internal PHY when USB is disabled") and
      fb91cde4 ("usb: musb: OMAP4430: Power down
      the PHY during board init") introduced when
      building a OMAP2-only kernel.
      
        LD      .tmp_vmlinux1
      arch/arm/mach-omap2/built-in.o:(.data+0x7ce0): undefined reference to
      +`omap4430_phy_init'
      arch/arm/mach-omap2/built-in.o:(.data+0x7ce4): undefined reference to
      +`omap4430_phy_exit'
      arch/arm/mach-omap2/built-in.o:(.data+0x7ce8): undefined reference to
      +`omap4430_phy_power'
      arch/arm/mach-omap2/built-in.o:(.data+0x7cec): undefined reference to
      +`omap4430_phy_set_clk'
      arch/arm/mach-omap2/built-in.o:(.data+0x7cf0): undefined reference to
      +`omap4430_phy_suspend'
      make: *** [.tmp_vmlinux1] Error 1
      Reported-by: default avatarPaul Walmsley <paul@pwsan.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      b3c3dc22