Some xhci controllers (eg ASMedia) don't like processing a LINK TRB
when they don't own the linked-to TRB.
I think this can happen due to timing races between the host cpu and the
controller even when the driver is single-threading transfers.
This happens a lot more often with the patch that pads the ring with
NOP TRB, since it is then much more likely that a transfer will start
with a LINK TRB.
The first patch just changes the code that writes the ownership of ring
entries to ensure that the ownership of the correct TRB is set last.
It leaves a lot of code that sets up variables and values that are not used.
The 'cleanup' code for partially queued isoc transfers has not been fixed,
but since it is never executed (patch 2 removes it) it doesn't matter.
The first patch is a candiate for back-porting to 3.12 and 3.13.
The later patches remove the unused variables and values as well as
a moderate amount of code from 'normal' paths.
They must be applied in order, the driver should work with any of them
applied - but I've only tested with just patch 1 and all 5 patches.
I did consider making giveback_first_trb() ring the command doorbell,
but that opened another bag of worms.
David Laight (5):
xhci: Don't change the ownership of LINK TRB until all the TRB are
written
xhci: isoc transfers can't fail when partially queued - remove cleanup
code.
xhci: Pass the 'ep_ring' to prepare_transfer().
xhci: Don't pass TRB_CYCLE value to queue_trb()
xhci: Simpify processing LINK TRBs when writing trb.
drivers/usb/host/xhci-ring.c | 409 ++++++++++++-------------------------------
drivers/usb/host/xhci.h | 8 +
2 files changed, 117 insertions(+), 300 deletions(-)
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
