aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/usb/host/xhci-ring.c
diff options
context:
space:
mode:
authorSarah Sharp <sarah.a.sharp@linux.intel.com>2009-08-07 17:04:36 -0400
committerGreg Kroah-Hartman <gregkh@suse.de>2009-09-23 09:46:17 -0400
commitb0567b3f635db72c881a0d561cebb544ec085073 (patch)
treeb6294a55ea42d54a352be21c42eaf7594a3c79be /drivers/usb/host/xhci-ring.c
parent11eaf170363d264ff587f300e41c927ba5a33967 (diff)
USB: xhci: Work around for chain bit in link TRBs.
Different sections of the xHCI 0.95 specification had opposing requirements for the chain bit in a link transaction request buffer (TRB). The chain bit is used to designate that adjacent TRBs are all part of the same scatter gather list that should be sent to the device. Link TRBs can be in the middle, or at the beginning or end of these chained TRBs. Sections 4.11.5.1 and 6.4.4.1 both stated the link TRB "shall have the chain bit set to 1", meaning it is always chained to the next TRB. However, section 4.6.9 on the stop endpoint command has specific cases for what the hardware must do for a link TRB with the chain bit set to 0. The 0.96 specification errata later cleared up this issue by fixing the 4.11.5.1 and 6.4.4.1 sections to state that a link TRB can have the chain bit set to 1 or 0. The problem is that the xHCI cancellation code depends on the chain bit of the link TRB being cleared when it's at the end of a TD, and some 0.95 xHCI hardware simply stops processing the ring when it encounters a link TRB with the chain bit cleared. Allow users who are testing 0.95 xHCI prototypes to set a module parameter (link_quirk) to turn on this link TRB work around. Cancellation may not work if the ring is stopped exactly on a link TRB with chain bit set, but cancellation should be a relatively uncommon case. 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>
Diffstat (limited to 'drivers/usb/host/xhci-ring.c')
-rw-r--r--drivers/usb/host/xhci-ring.c15
1 files changed, 11 insertions, 4 deletions
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index aa88a067148b..011458f4d9ce 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -172,8 +172,9 @@ static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring *ring, bool consumer
172 * have their chain bit cleared (so that each Link TRB is a separate TD). 172 * have their chain bit cleared (so that each Link TRB is a separate TD).
173 * 173 *
174 * Section 6.4.4.1 of the 0.95 spec says link TRBs cannot have the chain bit 174 * Section 6.4.4.1 of the 0.95 spec says link TRBs cannot have the chain bit
175 * set, but other sections talk about dealing with the chain bit set. 175 * set, but other sections talk about dealing with the chain bit set. This was
176 * Assume section 6.4.4.1 is wrong, and the chain bit can be set in a Link TRB. 176 * fixed in the 0.96 specification errata, but we have to assume that all 0.95
177 * xHCI hardware can't handle the chain bit being cleared on a link TRB.
177 */ 178 */
178static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring *ring, bool consumer) 179static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring *ring, bool consumer)
179{ 180{
@@ -191,8 +192,14 @@ static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring *ring, bool consumer
191 while (last_trb(xhci, ring, ring->enq_seg, next)) { 192 while (last_trb(xhci, ring, ring->enq_seg, next)) {
192 if (!consumer) { 193 if (!consumer) {
193 if (ring != xhci->event_ring) { 194 if (ring != xhci->event_ring) {
194 next->link.control &= ~TRB_CHAIN; 195 /* If we're not dealing with 0.95 hardware,
195 next->link.control |= chain; 196 * carry over the chain bit of the previous TRB
197 * (which may mean the chain bit is cleared).
198 */
199 if (!xhci_link_trb_quirk(xhci)) {
200 next->link.control &= ~TRB_CHAIN;
201 next->link.control |= chain;
202 }
196 /* Give this link TRB to the hardware */ 203 /* Give this link TRB to the hardware */
197 wmb(); 204 wmb();
198 if (next->link.control & TRB_CYCLE) 205 if (next->link.control & TRB_CYCLE)