linux-toradex.git/drivers/usb/host, branch v3.2-rc5

Revert "xHCI: reset-on-resume quirk for NEC uPD720200"

2011-12-01T18:41:40+00:00

This reverts commit df711fc9962b9491af2b92bd0d21ecbfefe4e5fa.

The commit added a reset-on-resume quirk because the NEC chipset stopped
responding to commands about 30 minutes after a system resume from
suspend.  We thought it was a chipset issue, but it turns out that the
xHCI driver was zeroing out the link TRB after a successful context
restore during resume.  The host controller would fall off the command
ring sometime later, causing it to not respond to new commands.

The link TRB issue has been fixed with commit
158886cd2cf4599e04f9b7e10cb767f5f39b14f1 "xHCI: fix bug in
xhci_clear_command_ring()", so revert the reset-on-resume quirk, as it's
not necessary.

Commit df711fc9962b9491af2b92bd0d21ecbfefe4e5fa was marked for stable
trees back to 2.6.37, but according to my mail, it has not made it into
Linus' tree or the stable trees yet.

Signed-off-by: Sarah Sharp 
Tested-by: Julian Sikorski 
Cc: Andiry Xu

xHCI: fix bug in xhci_clear_command_ring()

2011-12-01T18:38:27+00:00

When system enters suspend, xHCI driver clears command ring by writing zero
to all the TRBs. However, this also writes zero to the Link TRB, and the ring
is mangled. This may cause driver accesses wrong memory address and the
result is unpredicted.

When clear the command ring, keep the last Link TRB intact, only clear its
cycle bit. This should fix the "command ring full" issue reported by Oliver
Neukum.

This should be backported to stable kernels as old as 2.6.37, since the
commit 89821320 "xhci: Fix command ring replay after resume" is merged.

Signed-off-by: Andiry Xu 
Signed-off-by: Sarah Sharp 
Reported-by: Oliver Neukum

EHCI : Fix a regression in the ISO scheduler

2011-11-29T00:59:29+00:00

Fix a regression that was introduced by commit
811c926c538f7e8d3c08b630dd5844efd7e000f6 (USB: EHCI: fix HUB TT scheduling
issue with iso transfer).

We detect an error if next == start, but this means uframe 0 can't be allocated
anymore for iso transfer...

Reported-by: Sander Eikelenboom 
Signed-off-by: Matthieu CASTET 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

xHCI: reset-on-resume quirk for NEC uPD720200

2011-11-28T18:22:26+00:00

Julian Sikorski reports NEC uPD720200 does not work stable after suspend
and resume. Re-initialize the host in xhci_resume().

This should be backported to stable kernels as old as 2.6.37.  The
kernel will need to include
commit c877b3b2ad5cb9d4fe523c5496185cc328ff3ae9
"xhci: Add reset on resume quirk for asrock p67 host"
for this patch to work.

Signed-off-by: Andiry Xu 
Reported-by: Julian Sikorski 
Tested-by: Julian Sikorski 
Signed-off-by: Sarah Sharp

USB: whci-hcd: fix endian conversion in qset_clear()

2011-11-27T03:56:48+00:00

qset->qh.link is an __le64 field and we should be using cpu_to_le64()
to fill it.

Signed-off-by: Dan Carpenter 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

OHCI: final fix for NVIDIA problems (I hope)

2011-11-18T19:18:45+00:00

Problems with NVIDIA's OHCI host controllers persist.  After looking
carefully through the spec, I finally realized that when a controller
is reset it then automatically goes into a SUSPEND state in which it
is completely quiescent (no DMA and no IRQs) and from which it will
not awaken until the system puts it into the OPERATIONAL state.

Therefore there's no need to worry about controllers being in the
RESET state for extended periods, or remaining in the OPERATIONAL
state during system shutdown.  The proper action for device
initialization is to put the controller into the RESET state (if it's
not there already) and then to issue a software reset.  Similarly, the
proper action for device shutdown is simply to do a software reset.

This patch (as1499) implements such an approach.  It simplifies
initialization and shutdown, and allows the NVIDIA shutdown-quirk code
to be removed.

Signed-off-by: Alan Stern 
Tested-by: Andre "Osku" Schmidt 
Tested-by: Arno Augustin 
Cc: stable  [after tested in 3.2 for a while]
Signed-off-by: Greg Kroah-Hartman

usb: Netlogic: Fix HC_LENGTH call in ehci-xls.c

2011-11-18T19:16:36+00:00

Fix compile error, HC_LENGTH now takes two parameters and ehci
needs to be passed as the first parameter.

Signed-off-by: Jayachandran C 
Signed-off-by: Greg Kroah-Hartman

USB: at91: at91-ohci: fix set/get power

2011-11-14T23:52:11+00:00

in commit aa6e52a35 we introduce the support of overcurrent notification
but the set and get of the power without checking if the gpio is valid or not

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
Acked-by: Thomas Petazzoni 
Acked-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

USB: EHCI: fix HUB TT scheduling issue with iso transfer

2011-11-14T21:47:48+00:00

The current TT scheduling doesn't allow to play and then record on a
full-speed device connected to a high speed hub.

The IN iso stream can only start on the first uframe (0-2 for a 165 us)
because of CSPLIT transactions.
For the OUT iso stream there no such restriction. uframe 0-5 are possible.

The idea of this patch is that the first uframe are precious (for IN TT iso
stream) and we should allocate the last uframes first if possible.

For that we reverse the order of uframe allocation (last uframe first).

Here an example :

hid interrupt stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame | 13  |  0  |  0  |  0  |  0  |  0  |  0  |  0  |
----------------------------------------------------------------------

iso OUT stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame | 13  | 125 |  39 |  0  |  0  |  0  |  0  |  0  |
----------------------------------------------------------------------

There no place for iso IN stream  (uframe 0-2 are used) and we got "cannot
submit datapipe for urb 0, error -28: not enough bandwidth" error.

With the patch this become.

iso OUT stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame |  13 |  0  |  0  |  0  | 125 |  39 |  0  |  0  |
----------------------------------------------------------------------

iso IN stream
----------------------------------------------------------------------
uframe                |  0  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |
----------------------------------------------------------------------
max_tt_usecs          | 125 | 125 | 125 | 125 | 125 | 125 | 30  |  0  |
----------------------------------------------------------------------
used usecs on a frame |  13 |  0  | 125 | 40  | 125 |  39 |  0  |  0  |
----------------------------------------------------------------------

Signed-off-by: Matthieu Castet 
Signed-off-by: Thomas Poussevin 
Signed-off-by: Alan Stern 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

USB: XHCI: resume root hubs when the controller resumes

2011-11-14T21:47:48+00:00

This patch (as1494) fixes a problem in xhci-hcd's resume routine.
When the controller is runtime-resumed, this can only mean that one of
the two root hubs has made a wakeup request and therefore needs to be
resumed as well.  Rather than try to determine which root hub requires
attention (which might be difficult in the case where a new
non-SuperSpeed device has been plugged in), the patch simply resumes
both root hubs.

Without this change, there is a race: The controller might be put back
to sleep before it can activate its IRQ line, and the wakeup condition
might never get handled.

The patch also simplifies the logic in xhci_resume a little, combining
some repeated flag settings into a single pair of statements.

Signed-off-by: Alan Stern 
CC: Sarah Sharp 
Cc: stable 
Tested-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman