linux-toradex.git/drivers/usb/host, branch v2.6.34 Linux kernel for Apalis and Colibri modules USB: sl811-hcd: Fix device disconnect 2010-04-30T16:25:12+00:00 Michael Hennerich michael.hennerich@analog.com 2010-04-28T21:31:36+00:00 8a3461e2cdb719ae4796feb70054f1597005af28 A while ago I provided a patch that fixed device detection after device removal (USB: sl811-hcd: Fix device disconnect). Chris Brissette pointed out that the detection/removal counter method to distinguish insert or remove my fail under certain conditions. Latest SL811HS datasheet (Document 38-08008 Rev. *D) indicates that bit 6 (SL11H_INTMASK_RD) of the Interrupt Status Register together with bit 5 (SL11H_INTMASK_INSRMV) can be used to determine whether a device has been inserted or removed. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
A while ago I provided a patch that fixed device detection after device
removal (USB: sl811-hcd: Fix device disconnect).
Chris Brissette pointed out that the detection/removal counter method
to distinguish insert or remove my fail under certain conditions.
Latest SL811HS datasheet (Document 38-08008 Rev. *D) indicates that
bit 6 (SL11H_INTMASK_RD) of the Interrupt Status Register together with
bit 5 (SL11H_INTMASK_INSRMV) can be used to determine whether a device
has been inserted or removed.

Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: ohci-at91: fix power management hanging 2010-04-30T16:25:12+00:00 Patrice Vilchez patrice.vilchez@atmel.com 2010-04-28T11:45:40+00:00 869aa98c1d6a03dd2078f8f8257a0bcc343cb8b9 A hanging has been detected in ohci-at91 while going in suspend to ram. This is due to asynchronous operations between ohci reset and ohci clocks shutdown. This patch adds the reading of the control register between the reset of the ohci and clocks stop. This "flush the writes" idea was taken from ohci-hcd.c file (ohci_shutdown() function). Signed-off-by: Patrice Vilchez <patrice.vilchez@atmel.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
A hanging has been detected in ohci-at91 while going in suspend to ram. This is
due to asynchronous operations between ohci reset and ohci clocks shutdown.
This patch adds the reading of the control register between the reset of the
ohci and clocks stop. This "flush the writes" idea was taken from ohci-hcd.c
file (ohci_shutdown() function).

Signed-off-by: Patrice Vilchez <patrice.vilchez@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: oxu210hp: release spinlock on error path 2010-04-30T16:25:11+00:00 Dan Carpenter error27@gmail.com 2010-03-29T09:01:27+00:00 82a5eeb9f486366ad1b6c3be2e0d328ca185aa7e Smatch complained about this missing spinlock. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Smatch complained about this missing spinlock.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: xhci: properly set endpoint context fields for periodic eps. 2010-04-30T16:25:10+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2010-04-16T15:07:27+00:00 9238f25d5d32a435277eb234ec82bacdd5daed41 For periodic endpoints, we must let the xHCI hardware know the maximum payload an endpoint can transfer in one service interval. The xHCI specification refers to this as the Maximum Endpoint Service Interval Time Payload (Max ESIT Payload). This is used by the hardware for bandwidth management and scheduling of packets. For SuperSpeed endpoints, the maximum is calculated by multiplying the max packet size by the number of bursts and the number of opportunities to transfer within a service interval (the Mult field of the SuperSpeed Endpoint companion descriptor). Devices advertise this in the wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor. For high speed devices, this is taken by multiplying the max packet size by the "number of additional transaction opportunities per microframe" (the high bits of the wMaxPacketSize field in the endpoint descriptor). For FS/LS devices, this is just the max packet size. The other thing we must set in the endpoint context is the Average TRB Length. This is supposed to be the average of the total bytes in the transfer descriptor (TD), divided by the number of transfer request blocks (TRBs) it takes to describe the TD. This gives the host controller an indication of whether the driver will be enqueuing a scatter gather list with many entries comprised of small buffers, or one contiguous buffer. It also takes into account the number of extra TRBs you need for every TD. This includes No-op TRBs and Link TRBs used to link ring segments together. Some drivers may choose to chain an Event Data TRB on the end of every TD, thus increasing the average number of TRBs per TD. The Linux xHCI driver does not use Event Data TRBs. In theory, if there was an API to allow drivers to state what their bandwidth requirements are, we could set this field accurately. For now, we set it to the same number as the Max ESIT payload. The Average TRB Length should also be set for bulk and control endpoints, but I have no idea how to guess what it should be. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval.  The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload).  This is used by the hardware for bandwidth
management and scheduling of packets.

For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor).  Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.

For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).

For FS/LS devices, this is just the max packet size.

The other thing we must set in the endpoint context is the Average TRB
Length.  This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD.  This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.

It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together.  Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD.  The Linux
xHCI driver does not use Event Data TRBs.

In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately.  For now,
we set it to the same number as the Max ESIT payload.

The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: xhci: properly set the "Mult" field of the endpoint context. 2010-04-30T16:25:10+00:00 Sarah Sharp sarah.a.sharp@linux.intel.com 2010-04-16T15:07:04+00:00 1cf62246c0e394021e494e0a8f1013e80db1a1a9 A SuperSpeed interrupt or isochronous endpoint can define the number of "burst transactions" it can handle in a service interval. This is indicated by the "Mult" bits in the bmAttributes of the SuperSpeed Endpoint Companion Descriptor. For example, if it has a max packet size of 1024, a max burst of 11, and a mult of 3, the host may send 33 1024-byte packets in one service interval. We must tell the xHCI host controller the number of multiple service opportunities (mults) the device can handle when the endpoint is installed. We do that by setting the Mult field of the Endpoint Context before a configure endpoint command is sent down. The Mult field is invalid for control or bulk SuperSpeed endpoints. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
A SuperSpeed interrupt or isochronous endpoint can define the number of
"burst transactions" it can handle in a service interval.  This is
indicated by the "Mult" bits in the bmAttributes of the SuperSpeed
Endpoint Companion Descriptor.  For example, if it has a max packet size
of 1024, a max burst of 11, and a mult of 3, the host may send 33
1024-byte packets in one service interval.

We must tell the xHCI host controller the number of multiple service
opportunities (mults) the device can handle when the endpoint is
installed.  We do that by setting the Mult field of the Endpoint Context
before a configure endpoint command is sent down.  The Mult field is
invalid for control or bulk SuperSpeed endpoints.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: OHCI: don't look at the root hub to get the number of ports 2010-04-30T16:25:10+00:00 Alan Stern stern@rowland.harvard.edu 2010-04-20T14:37:57+00:00 fcf7d2141f4a363a4a8454c4a0f26bb69e766c5f This patch (as1371) fixes a small bug in ohci-hcd. The HCD already knows how many ports the controller has; there's no need to go looking at the root hub's usb_device structure to find out. Especially since the root hub's maxchild value is set correctly only while the root hub is bound to the hub driver. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This patch (as1371) fixes a small bug in ohci-hcd.  The HCD already
knows how many ports the controller has; there's no need to go looking
at the root hub's usb_device structure to find out.  Especially since
the root hub's maxchild value is set correctly only while the root hub
is bound to the hub driver.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usb: Increase timeout value for device reset 2010-04-22T22:18:29+00:00 Dinh Nguyen Dinh.Nguyen@freescale.com 2010-04-13T16:13:15+00:00 6307e0961205c50a8a9b6e8e3e4dfd178a944ba9 It seems that for USB IP on Freescale MX5x processors, it needs >750 usec for the reset to complete. This change should not hurt any other EHCI hardware. Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
It seems that for USB IP on Freescale MX5x processors, it needs >750
usec for the reset to complete. This change should not hurt any other
EHCI hardware.

Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: EHCI: defer reclamation of siTDs 2010-04-22T22:18:28+00:00 Alan Stern stern@rowland.harvard.edu 2010-04-08T20:56:37+00:00 0e5f231bc16ff9910882fa5b9d64d80e7691cfab This patch (as1369) fixes a problem in ehci-hcd. Some controllers occasionally run into trouble when the driver reclaims siTDs too quickly. This can happen while streaming audio; it causes the controller to crash. The patch changes siTD reclamation to work the same way as iTD reclamation: Completed siTDs are stored on a list and not reused until at least one frame has passed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Tested-by: Nate Case <ncase@xes-inc.com> CC: <stable@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This patch (as1369) fixes a problem in ehci-hcd.  Some controllers
occasionally run into trouble when the driver reclaims siTDs too
quickly.  This can happen while streaming audio; it causes the
controller to crash.

The patch changes siTD reclamation to work the same way as iTD
reclamation: Completed siTDs are stored on a list and not reused until
at least one frame has passed.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Nate Case <ncase@xes-inc.com>
CC: <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: OHCI: DA8xx/OMAP-L1x: fix up macro rename 2010-04-22T22:18:24+00:00 Sergei Shtylyov sshtylyov@ru.mvista.com 2010-03-26T14:37:14+00:00 9600cbb24b3937dc6ebf470211d8908354ca3b0c It appears that the DA8xx/OMAP-L1x glue layer went into the kernel uncompilable: commit 1960e693ac12ae5fe518309d6a63a44c93fad9e7 (davinci: da8xx/omapl1: add support for the second sysconfig module) has renamed DA8XX_SYSCFG_* macros to DA8XX_SYSCFG0_* and it's been committed before the glue layer... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
It appears that the DA8xx/OMAP-L1x glue layer went into the kernel uncompilable:
commit 1960e693ac12ae5fe518309d6a63a44c93fad9e7 (davinci: da8xx/omapl1: add
support for the second sysconfig module) has renamed DA8XX_SYSCFG_* macros to
DA8XX_SYSCFG0_* and it's been committed before the glue layer...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: ehci: omap: fix kernel panic with rmmod 2010-04-22T22:18:21+00:00 Ajay Kumar Gupta ajay.gupta@ti.com 2010-03-18T11:28:35+00:00 18f91196b6e7994bd694a96a6c3b0ac1f3e81d82 Sets the regulator values to NULL if they are not defined. This is required to fix the kernel panic in exit path when EHCI module is removed on the platforms where EHCI regulator are not set. Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Sets the regulator values to NULL if they are not defined. This
is required to fix the kernel panic in exit path when EHCI module
is removed on the platforms where EHCI regulator are not set.

Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>