2009-04-28 10:53:56 +08:00
|
|
|
/*
|
|
|
|
* xHCI host controller driver
|
|
|
|
*
|
|
|
|
* Copyright (C) 2008 Intel Corp.
|
|
|
|
*
|
|
|
|
* Author: Sarah Sharp
|
|
|
|
* Some code borrowed from the Linux EHCI driver.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* 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., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ring initialization rules:
|
|
|
|
* 1. Each segment is initialized to zero, except for link TRBs.
|
|
|
|
* 2. Ring cycle state = 0. This represents Producer Cycle State (PCS) or
|
|
|
|
* Consumer Cycle State (CCS), depending on ring function.
|
|
|
|
* 3. Enqueue pointer = dequeue pointer = address of first TRB in the segment.
|
|
|
|
*
|
|
|
|
* Ring behavior rules:
|
|
|
|
* 1. A ring is empty if enqueue == dequeue. This means there will always be at
|
|
|
|
* least one free TRB in the ring. This is useful if you want to turn that
|
|
|
|
* into a link TRB and expand the ring.
|
|
|
|
* 2. When incrementing an enqueue or dequeue pointer, if the next TRB is a
|
|
|
|
* link TRB, then load the pointer with the address in the link TRB. If the
|
|
|
|
* link TRB had its toggle bit set, you may need to update the ring cycle
|
|
|
|
* state (see cycle bit rules). You may have to do this multiple times
|
|
|
|
* until you reach a non-link TRB.
|
|
|
|
* 3. A ring is full if enqueue++ (for the definition of increment above)
|
|
|
|
* equals the dequeue pointer.
|
|
|
|
*
|
|
|
|
* Cycle bit rules:
|
|
|
|
* 1. When a consumer increments a dequeue pointer and encounters a toggle bit
|
|
|
|
* in a link TRB, it must toggle the ring cycle state.
|
|
|
|
* 2. When a producer increments an enqueue pointer and encounters a toggle bit
|
|
|
|
* in a link TRB, it must toggle the ring cycle state.
|
|
|
|
*
|
|
|
|
* Producer rules:
|
|
|
|
* 1. Check if ring is full before you enqueue.
|
|
|
|
* 2. Write the ring cycle state to the cycle bit in the TRB you're enqueuing.
|
|
|
|
* Update enqueue pointer between each write (which may update the ring
|
|
|
|
* cycle state).
|
|
|
|
* 3. Notify consumer. If SW is producer, it rings the doorbell for command
|
|
|
|
* and endpoint rings. If HC is the producer for the event ring,
|
|
|
|
* and it generates an interrupt according to interrupt modulation rules.
|
|
|
|
*
|
|
|
|
* Consumer rules:
|
|
|
|
* 1. Check if TRB belongs to you. If the cycle bit == your ring cycle state,
|
|
|
|
* the TRB is owned by the consumer.
|
|
|
|
* 2. Update dequeue pointer (which may update the ring cycle state) and
|
|
|
|
* continue processing TRBs until you reach a TRB which is not owned by you.
|
|
|
|
* 3. Notify the producer. SW is the consumer for the event ring, and it
|
|
|
|
* updates event ring dequeue pointer. HC is the consumer for the command and
|
|
|
|
* endpoint rings; it generates events on the event ring for these.
|
|
|
|
*/
|
|
|
|
|
2009-04-28 10:59:19 +08:00
|
|
|
#include <linux/scatterlist.h>
|
2009-04-28 10:53:56 +08:00
|
|
|
#include "xhci.h"
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns zero if the TRB isn't in this segment, otherwise it returns the DMA
|
|
|
|
* address of the TRB.
|
|
|
|
*/
|
2009-04-30 10:05:20 +08:00
|
|
|
dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg,
|
2009-04-28 10:53:56 +08:00
|
|
|
union xhci_trb *trb)
|
|
|
|
{
|
2009-05-15 02:44:14 +08:00
|
|
|
unsigned long segment_offset;
|
2009-04-28 10:53:56 +08:00
|
|
|
|
2009-05-15 02:44:14 +08:00
|
|
|
if (!seg || !trb || trb < seg->trbs)
|
2009-04-28 10:53:56 +08:00
|
|
|
return 0;
|
2009-05-15 02:44:14 +08:00
|
|
|
/* offset in TRBs */
|
|
|
|
segment_offset = trb - seg->trbs;
|
|
|
|
if (segment_offset > TRBS_PER_SEGMENT)
|
2009-04-28 10:53:56 +08:00
|
|
|
return 0;
|
2009-05-15 02:44:14 +08:00
|
|
|
return seg->dma + (segment_offset * sizeof(*trb));
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Does this link TRB point to the first segment in a ring,
|
|
|
|
* or was the previous TRB the last TRB on the last segment in the ERST?
|
|
|
|
*/
|
|
|
|
static inline bool last_trb_on_last_seg(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
|
|
|
struct xhci_segment *seg, union xhci_trb *trb)
|
|
|
|
{
|
|
|
|
if (ring == xhci->event_ring)
|
|
|
|
return (trb == &seg->trbs[TRBS_PER_SEGMENT]) &&
|
|
|
|
(seg->next == xhci->event_ring->first_seg);
|
|
|
|
else
|
|
|
|
return trb->link.control & LINK_TOGGLE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Is this TRB a link TRB or was the last TRB the last TRB in this event ring
|
|
|
|
* segment? I.e. would the updated event TRB pointer step off the end of the
|
|
|
|
* event seg?
|
|
|
|
*/
|
|
|
|
static inline int last_trb(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
|
|
|
struct xhci_segment *seg, union xhci_trb *trb)
|
|
|
|
{
|
|
|
|
if (ring == xhci->event_ring)
|
|
|
|
return trb == &seg->trbs[TRBS_PER_SEGMENT];
|
|
|
|
else
|
|
|
|
return (trb->link.control & TRB_TYPE_BITMASK) == TRB_TYPE(TRB_LINK);
|
|
|
|
}
|
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/* Updates trb to point to the next TRB in the ring, and updates seg if the next
|
|
|
|
* TRB is in a new segment. This does not skip over link TRBs, and it does not
|
|
|
|
* effect the ring dequeue or enqueue pointers.
|
|
|
|
*/
|
|
|
|
static void next_trb(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_ring *ring,
|
|
|
|
struct xhci_segment **seg,
|
|
|
|
union xhci_trb **trb)
|
|
|
|
{
|
|
|
|
if (last_trb(xhci, ring, *seg, *trb)) {
|
|
|
|
*seg = (*seg)->next;
|
|
|
|
*trb = ((*seg)->trbs);
|
|
|
|
} else {
|
|
|
|
*trb = (*trb)++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:53:56 +08:00
|
|
|
/*
|
|
|
|
* See Cycle bit rules. SW is the consumer for the event ring only.
|
|
|
|
* Don't make a ring full of link TRBs. That would be dumb and this would loop.
|
|
|
|
*/
|
|
|
|
static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring *ring, bool consumer)
|
|
|
|
{
|
|
|
|
union xhci_trb *next = ++(ring->dequeue);
|
2009-07-28 03:03:46 +08:00
|
|
|
unsigned long long addr;
|
2009-04-28 10:53:56 +08:00
|
|
|
|
|
|
|
ring->deq_updates++;
|
|
|
|
/* Update the dequeue pointer further if that was a link TRB or we're at
|
|
|
|
* the end of an event ring segment (which doesn't have link TRBS)
|
|
|
|
*/
|
|
|
|
while (last_trb(xhci, ring, ring->deq_seg, next)) {
|
|
|
|
if (consumer && last_trb_on_last_seg(xhci, ring, ring->deq_seg, next)) {
|
|
|
|
ring->cycle_state = (ring->cycle_state ? 0 : 1);
|
|
|
|
if (!in_interrupt())
|
2009-04-30 10:14:08 +08:00
|
|
|
xhci_dbg(xhci, "Toggle cycle state for ring %p = %i\n",
|
|
|
|
ring,
|
2009-04-28 10:53:56 +08:00
|
|
|
(unsigned int) ring->cycle_state);
|
|
|
|
}
|
|
|
|
ring->deq_seg = ring->deq_seg->next;
|
|
|
|
ring->dequeue = ring->deq_seg->trbs;
|
|
|
|
next = ring->dequeue;
|
|
|
|
}
|
2009-07-28 03:03:46 +08:00
|
|
|
addr = (unsigned long long) xhci_trb_virt_to_dma(ring->deq_seg, ring->dequeue);
|
|
|
|
if (ring == xhci->event_ring)
|
|
|
|
xhci_dbg(xhci, "Event ring deq = 0x%llx (DMA)\n", addr);
|
|
|
|
else if (ring == xhci->cmd_ring)
|
|
|
|
xhci_dbg(xhci, "Command ring deq = 0x%llx (DMA)\n", addr);
|
|
|
|
else
|
|
|
|
xhci_dbg(xhci, "Ring deq = 0x%llx (DMA)\n", addr);
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* See Cycle bit rules. SW is the consumer for the event ring only.
|
|
|
|
* Don't make a ring full of link TRBs. That would be dumb and this would loop.
|
|
|
|
*
|
|
|
|
* If we've just enqueued a TRB that is in the middle of a TD (meaning the
|
|
|
|
* chain bit is set), then set the chain bit in all the following link TRBs.
|
|
|
|
* If we've enqueued the last TRB in a TD, make sure the following link TRBs
|
|
|
|
* have their chain bit cleared (so that each Link TRB is a separate TD).
|
|
|
|
*
|
|
|
|
* Section 6.4.4.1 of the 0.95 spec says link TRBs cannot have the chain bit
|
2009-08-08 05:04:36 +08:00
|
|
|
* set, but other sections talk about dealing with the chain bit set. This was
|
|
|
|
* fixed in the 0.96 specification errata, but we have to assume that all 0.95
|
|
|
|
* xHCI hardware can't handle the chain bit being cleared on a link TRB.
|
2009-04-28 10:53:56 +08:00
|
|
|
*/
|
|
|
|
static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring *ring, bool consumer)
|
|
|
|
{
|
|
|
|
u32 chain;
|
|
|
|
union xhci_trb *next;
|
2009-07-28 03:03:46 +08:00
|
|
|
unsigned long long addr;
|
2009-04-28 10:53:56 +08:00
|
|
|
|
|
|
|
chain = ring->enqueue->generic.field[3] & TRB_CHAIN;
|
|
|
|
next = ++(ring->enqueue);
|
|
|
|
|
|
|
|
ring->enq_updates++;
|
|
|
|
/* Update the dequeue pointer further if that was a link TRB or we're at
|
|
|
|
* the end of an event ring segment (which doesn't have link TRBS)
|
|
|
|
*/
|
|
|
|
while (last_trb(xhci, ring, ring->enq_seg, next)) {
|
|
|
|
if (!consumer) {
|
|
|
|
if (ring != xhci->event_ring) {
|
2009-08-08 05:04:36 +08:00
|
|
|
/* If we're not dealing with 0.95 hardware,
|
|
|
|
* carry over the chain bit of the previous TRB
|
|
|
|
* (which may mean the chain bit is cleared).
|
|
|
|
*/
|
|
|
|
if (!xhci_link_trb_quirk(xhci)) {
|
|
|
|
next->link.control &= ~TRB_CHAIN;
|
|
|
|
next->link.control |= chain;
|
|
|
|
}
|
2009-04-28 10:53:56 +08:00
|
|
|
/* Give this link TRB to the hardware */
|
2009-04-30 10:05:58 +08:00
|
|
|
wmb();
|
2009-04-28 10:53:56 +08:00
|
|
|
if (next->link.control & TRB_CYCLE)
|
|
|
|
next->link.control &= (u32) ~TRB_CYCLE;
|
|
|
|
else
|
|
|
|
next->link.control |= (u32) TRB_CYCLE;
|
|
|
|
}
|
|
|
|
/* Toggle the cycle bit after the last ring segment. */
|
|
|
|
if (last_trb_on_last_seg(xhci, ring, ring->enq_seg, next)) {
|
|
|
|
ring->cycle_state = (ring->cycle_state ? 0 : 1);
|
|
|
|
if (!in_interrupt())
|
2009-04-30 10:14:08 +08:00
|
|
|
xhci_dbg(xhci, "Toggle cycle state for ring %p = %i\n",
|
|
|
|
ring,
|
2009-04-28 10:53:56 +08:00
|
|
|
(unsigned int) ring->cycle_state);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ring->enq_seg = ring->enq_seg->next;
|
|
|
|
ring->enqueue = ring->enq_seg->trbs;
|
|
|
|
next = ring->enqueue;
|
|
|
|
}
|
2009-07-28 03:03:46 +08:00
|
|
|
addr = (unsigned long long) xhci_trb_virt_to_dma(ring->enq_seg, ring->enqueue);
|
|
|
|
if (ring == xhci->event_ring)
|
|
|
|
xhci_dbg(xhci, "Event ring enq = 0x%llx (DMA)\n", addr);
|
|
|
|
else if (ring == xhci->cmd_ring)
|
|
|
|
xhci_dbg(xhci, "Command ring enq = 0x%llx (DMA)\n", addr);
|
|
|
|
else
|
|
|
|
xhci_dbg(xhci, "Ring enq = 0x%llx (DMA)\n", addr);
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check to see if there's room to enqueue num_trbs on the ring. See rules
|
|
|
|
* above.
|
|
|
|
* FIXME: this would be simpler and faster if we just kept track of the number
|
|
|
|
* of free TRBs in a ring.
|
|
|
|
*/
|
|
|
|
static int room_on_ring(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
|
|
|
unsigned int num_trbs)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
union xhci_trb *enq = ring->enqueue;
|
|
|
|
struct xhci_segment *enq_seg = ring->enq_seg;
|
|
|
|
|
|
|
|
/* Check if ring is empty */
|
|
|
|
if (enq == ring->dequeue)
|
|
|
|
return 1;
|
|
|
|
/* Make sure there's an extra empty TRB available */
|
|
|
|
for (i = 0; i <= num_trbs; ++i) {
|
|
|
|
if (enq == ring->dequeue)
|
|
|
|
return 0;
|
|
|
|
enq++;
|
|
|
|
while (last_trb(xhci, ring, enq_seg, enq)) {
|
|
|
|
enq_seg = enq_seg->next;
|
|
|
|
enq = enq_seg->trbs;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
void xhci_set_hc_event_deq(struct xhci_hcd *xhci)
|
2009-04-28 10:53:56 +08:00
|
|
|
{
|
2009-07-28 03:03:31 +08:00
|
|
|
u64 temp;
|
2009-04-28 10:53:56 +08:00
|
|
|
dma_addr_t deq;
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
deq = xhci_trb_virt_to_dma(xhci->event_ring->deq_seg,
|
2009-04-28 10:53:56 +08:00
|
|
|
xhci->event_ring->dequeue);
|
|
|
|
if (deq == 0 && !in_interrupt())
|
|
|
|
xhci_warn(xhci, "WARN something wrong with SW event ring "
|
|
|
|
"dequeue ptr.\n");
|
|
|
|
/* Update HC event ring dequeue pointer */
|
2009-07-28 03:03:31 +08:00
|
|
|
temp = xhci_read_64(xhci, &xhci->ir_set->erst_dequeue);
|
2009-04-28 10:53:56 +08:00
|
|
|
temp &= ERST_PTR_MASK;
|
2009-07-28 03:03:40 +08:00
|
|
|
/* Don't clear the EHB bit (which is RW1C) because
|
|
|
|
* there might be more events to service.
|
|
|
|
*/
|
|
|
|
temp &= ~ERST_EHB;
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "// Write event ring dequeue pointer, preserving EHB bit\n");
|
2009-07-28 03:03:31 +08:00
|
|
|
xhci_write_64(xhci, ((u64) deq & (u64) ~ERST_PTR_MASK) | temp,
|
|
|
|
&xhci->ir_set->erst_dequeue);
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Ring the host controller doorbell after placing a command on the ring */
|
2009-04-30 10:05:20 +08:00
|
|
|
void xhci_ring_cmd_db(struct xhci_hcd *xhci)
|
2009-04-28 10:53:56 +08:00
|
|
|
{
|
|
|
|
u32 temp;
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "// Ding dong!\n");
|
|
|
|
temp = xhci_readl(xhci, &xhci->dba->doorbell[0]) & DB_MASK;
|
|
|
|
xhci_writel(xhci, temp | DB_TARGET_HOST, &xhci->dba->doorbell[0]);
|
|
|
|
/* Flush PCI posted writes */
|
|
|
|
xhci_readl(xhci, &xhci->dba->doorbell[0]);
|
|
|
|
}
|
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
static void ring_ep_doorbell(struct xhci_hcd *xhci,
|
|
|
|
unsigned int slot_id,
|
|
|
|
unsigned int ep_index)
|
|
|
|
{
|
2009-09-05 01:53:09 +08:00
|
|
|
struct xhci_virt_ep *ep;
|
|
|
|
unsigned int ep_state;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
u32 field;
|
|
|
|
__u32 __iomem *db_addr = &xhci->dba->doorbell[slot_id];
|
|
|
|
|
2009-09-05 01:53:09 +08:00
|
|
|
ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
ep_state = ep->ep_state;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/* Don't ring the doorbell for this endpoint if there are pending
|
|
|
|
* cancellations because the we don't want to interrupt processing.
|
|
|
|
*/
|
USB: xhci: Handle URB cancel, complete and resubmit race.
In the old code, there was a race condition between the stop endpoint
command and the URB submission process. When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell. The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.
However, the following race condition could occur with the old code:
1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
(at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted. An
event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
canceled, decrements ep->cancels_pending to 0, and removes it from the to
be canceled list.
5. The event handler drops the lock and gives back the URB. The
completion handler requeues the URB (or a different driver enqueues a new
URB). This causes the endpoint's doorbell to be rung, since
ep->cancels_pending == 0. The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command. The
handler assumes the endpoint is stopped, but it isn't. It attempts to
move the dequeue pointer or change TDs to cancel the second URB, while the
hardware is actively accessing the endpoint ring.
To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING. When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet. The endpoint doorbell should not be rung when this
is set. Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell. ep->cancels_pending is eliminated, because it is no longer
used.
Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty. All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:55:52 +08:00
|
|
|
if (!(ep_state & EP_HALT_PENDING) && !(ep_state & SET_DEQ_PENDING)
|
2009-09-05 01:53:09 +08:00
|
|
|
&& !(ep_state & EP_HALTED)) {
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
field = xhci_readl(xhci, db_addr) & DB_MASK;
|
|
|
|
xhci_writel(xhci, field | EPI_TO_DB(ep_index), db_addr);
|
|
|
|
/* Flush PCI posted writes - FIXME Matthew Wilcox says this
|
|
|
|
* isn't time-critical and we shouldn't make the CPU wait for
|
|
|
|
* the flush.
|
|
|
|
*/
|
|
|
|
xhci_readl(xhci, db_addr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the segment that trb is in. Start searching in start_seg.
|
|
|
|
* If we must move past a segment that has a link TRB with a toggle cycle state
|
|
|
|
* bit set, then we will toggle the value pointed at by cycle_state.
|
|
|
|
*/
|
|
|
|
static struct xhci_segment *find_trb_seg(
|
|
|
|
struct xhci_segment *start_seg,
|
|
|
|
union xhci_trb *trb, int *cycle_state)
|
|
|
|
{
|
|
|
|
struct xhci_segment *cur_seg = start_seg;
|
|
|
|
struct xhci_generic_trb *generic_trb;
|
|
|
|
|
|
|
|
while (cur_seg->trbs > trb ||
|
|
|
|
&cur_seg->trbs[TRBS_PER_SEGMENT - 1] < trb) {
|
|
|
|
generic_trb = &cur_seg->trbs[TRBS_PER_SEGMENT - 1].generic;
|
|
|
|
if (TRB_TYPE(generic_trb->field[3]) == TRB_LINK &&
|
|
|
|
(generic_trb->field[3] & LINK_TOGGLE))
|
|
|
|
*cycle_state = ~(*cycle_state) & 0x1;
|
|
|
|
cur_seg = cur_seg->next;
|
|
|
|
if (cur_seg == start_seg)
|
|
|
|
/* Looped over the entire list. Oops! */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return cur_seg;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Move the xHC's endpoint ring dequeue pointer past cur_td.
|
|
|
|
* Record the new state of the xHC's endpoint ring dequeue segment,
|
|
|
|
* dequeue pointer, and new consumer cycle state in state.
|
|
|
|
* Update our internal representation of the ring's dequeue pointer.
|
|
|
|
*
|
|
|
|
* We do this in three jumps:
|
|
|
|
* - First we update our new ring state to be the same as when the xHC stopped.
|
|
|
|
* - Then we traverse the ring to find the segment that contains
|
|
|
|
* the last TRB in the TD. We toggle the xHC's new cycle state when we pass
|
|
|
|
* any link TRBs with the toggle cycle bit set.
|
|
|
|
* - Finally we move the dequeue state one TRB further, toggling the cycle bit
|
|
|
|
* if we've moved it past a link TRB with the toggle cycle bit set.
|
|
|
|
*/
|
2009-07-28 03:05:21 +08:00
|
|
|
void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
2009-07-28 03:05:21 +08:00
|
|
|
struct xhci_td *cur_td, struct xhci_dequeue_state *state)
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
{
|
|
|
|
struct xhci_virt_device *dev = xhci->devs[slot_id];
|
2009-09-05 01:53:09 +08:00
|
|
|
struct xhci_ring *ep_ring = dev->eps[ep_index].ring;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
struct xhci_generic_trb *trb;
|
2009-07-28 03:05:15 +08:00
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
2009-07-28 03:05:21 +08:00
|
|
|
dma_addr_t addr;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
|
|
|
state->new_cycle_state = 0;
|
2009-07-28 03:05:21 +08:00
|
|
|
xhci_dbg(xhci, "Finding segment containing stopped TRB.\n");
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
state->new_deq_seg = find_trb_seg(cur_td->start_seg,
|
2009-09-05 01:53:09 +08:00
|
|
|
dev->eps[ep_index].stopped_trb,
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
&state->new_cycle_state);
|
|
|
|
if (!state->new_deq_seg)
|
|
|
|
BUG();
|
|
|
|
/* Dig out the cycle state saved by the xHC during the stop ep cmd */
|
2009-07-28 03:05:21 +08:00
|
|
|
xhci_dbg(xhci, "Finding endpoint context\n");
|
2009-07-28 03:05:15 +08:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
|
|
|
|
state->new_cycle_state = 0x1 & ep_ctx->deq;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
|
|
|
state->new_deq_ptr = cur_td->last_trb;
|
2009-07-28 03:05:21 +08:00
|
|
|
xhci_dbg(xhci, "Finding segment containing last TRB in TD.\n");
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
state->new_deq_seg = find_trb_seg(state->new_deq_seg,
|
|
|
|
state->new_deq_ptr,
|
|
|
|
&state->new_cycle_state);
|
|
|
|
if (!state->new_deq_seg)
|
|
|
|
BUG();
|
|
|
|
|
|
|
|
trb = &state->new_deq_ptr->generic;
|
|
|
|
if (TRB_TYPE(trb->field[3]) == TRB_LINK &&
|
|
|
|
(trb->field[3] & LINK_TOGGLE))
|
|
|
|
state->new_cycle_state = ~(state->new_cycle_state) & 0x1;
|
|
|
|
next_trb(xhci, ep_ring, &state->new_deq_seg, &state->new_deq_ptr);
|
|
|
|
|
|
|
|
/* Don't update the ring cycle state for the producer (us). */
|
2009-07-28 03:05:21 +08:00
|
|
|
xhci_dbg(xhci, "New dequeue segment = %p (virtual)\n",
|
|
|
|
state->new_deq_seg);
|
|
|
|
addr = xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr);
|
|
|
|
xhci_dbg(xhci, "New dequeue pointer = 0x%llx (DMA)\n",
|
|
|
|
(unsigned long long) addr);
|
|
|
|
xhci_dbg(xhci, "Setting dequeue pointer in internal ring state.\n");
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
ep_ring->dequeue = state->new_deq_ptr;
|
|
|
|
ep_ring->deq_seg = state->new_deq_seg;
|
|
|
|
}
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
static void td_to_noop(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
struct xhci_td *cur_td)
|
|
|
|
{
|
|
|
|
struct xhci_segment *cur_seg;
|
|
|
|
union xhci_trb *cur_trb;
|
|
|
|
|
|
|
|
for (cur_seg = cur_td->start_seg, cur_trb = cur_td->first_trb;
|
|
|
|
true;
|
|
|
|
next_trb(xhci, ep_ring, &cur_seg, &cur_trb)) {
|
|
|
|
if ((cur_trb->generic.field[3] & TRB_TYPE_BITMASK) ==
|
|
|
|
TRB_TYPE(TRB_LINK)) {
|
|
|
|
/* Unchain any chained Link TRBs, but
|
|
|
|
* leave the pointers intact.
|
|
|
|
*/
|
|
|
|
cur_trb->generic.field[3] &= ~TRB_CHAIN;
|
|
|
|
xhci_dbg(xhci, "Cancel (unchain) link TRB\n");
|
2009-04-30 10:14:08 +08:00
|
|
|
xhci_dbg(xhci, "Address = %p (0x%llx dma); "
|
|
|
|
"in seg %p (0x%llx dma)\n",
|
|
|
|
cur_trb,
|
2009-04-30 10:05:20 +08:00
|
|
|
(unsigned long long)xhci_trb_virt_to_dma(cur_seg, cur_trb),
|
2009-04-30 10:14:08 +08:00
|
|
|
cur_seg,
|
|
|
|
(unsigned long long)cur_seg->dma);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
} else {
|
|
|
|
cur_trb->generic.field[0] = 0;
|
|
|
|
cur_trb->generic.field[1] = 0;
|
|
|
|
cur_trb->generic.field[2] = 0;
|
|
|
|
/* Preserve only the cycle bit of this TRB */
|
|
|
|
cur_trb->generic.field[3] &= TRB_CYCLE;
|
|
|
|
cur_trb->generic.field[3] |= TRB_TYPE(TRB_TR_NOOP);
|
2009-04-30 10:14:08 +08:00
|
|
|
xhci_dbg(xhci, "Cancel TRB %p (0x%llx dma) "
|
|
|
|
"in seg %p (0x%llx dma)\n",
|
|
|
|
cur_trb,
|
2009-04-30 10:05:20 +08:00
|
|
|
(unsigned long long)xhci_trb_virt_to_dma(cur_seg, cur_trb),
|
2009-04-30 10:14:08 +08:00
|
|
|
cur_seg,
|
|
|
|
(unsigned long long)cur_seg->dma);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
}
|
|
|
|
if (cur_trb == cur_td->last_trb)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
|
|
|
|
unsigned int ep_index, struct xhci_segment *deq_seg,
|
|
|
|
union xhci_trb *deq_ptr, u32 cycle_state);
|
|
|
|
|
2009-07-28 03:05:21 +08:00
|
|
|
void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
|
2009-09-05 01:53:09 +08:00
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
|
|
|
struct xhci_dequeue_state *deq_state)
|
2009-07-28 03:05:21 +08:00
|
|
|
{
|
2009-09-05 01:53:09 +08:00
|
|
|
struct xhci_virt_ep *ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
|
2009-07-28 03:05:21 +08:00
|
|
|
xhci_dbg(xhci, "Set TR Deq Ptr cmd, new deq seg = %p (0x%llx dma), "
|
|
|
|
"new deq ptr = %p (0x%llx dma), new cycle = %u\n",
|
|
|
|
deq_state->new_deq_seg,
|
|
|
|
(unsigned long long)deq_state->new_deq_seg->dma,
|
|
|
|
deq_state->new_deq_ptr,
|
|
|
|
(unsigned long long)xhci_trb_virt_to_dma(deq_state->new_deq_seg, deq_state->new_deq_ptr),
|
|
|
|
deq_state->new_cycle_state);
|
|
|
|
queue_set_tr_deq(xhci, slot_id, ep_index,
|
|
|
|
deq_state->new_deq_seg,
|
|
|
|
deq_state->new_deq_ptr,
|
|
|
|
(u32) deq_state->new_cycle_state);
|
|
|
|
/* Stop the TD queueing code from ringing the doorbell until
|
|
|
|
* this command completes. The HC won't set the dequeue pointer
|
|
|
|
* if the ring is running, and ringing the doorbell starts the
|
|
|
|
* ring running.
|
|
|
|
*/
|
2009-09-05 01:53:09 +08:00
|
|
|
ep->ep_state |= SET_DEQ_PENDING;
|
2009-07-28 03:05:21 +08:00
|
|
|
}
|
|
|
|
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
static inline void xhci_stop_watchdog_timer_in_irq(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_virt_ep *ep)
|
|
|
|
{
|
|
|
|
ep->ep_state &= ~EP_HALT_PENDING;
|
|
|
|
/* Can't del_timer_sync in interrupt, so we attempt to cancel. If the
|
|
|
|
* timer is running on another CPU, we don't decrement stop_cmds_pending
|
|
|
|
* (since we didn't successfully stop the watchdog timer).
|
|
|
|
*/
|
|
|
|
if (del_timer(&ep->stop_cmd_timer))
|
|
|
|
ep->stop_cmds_pending--;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Must be called with xhci->lock held in interrupt context */
|
|
|
|
static void xhci_giveback_urb_in_irq(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_td *cur_td, int status, char *adjective)
|
|
|
|
{
|
|
|
|
struct usb_hcd *hcd = xhci_to_hcd(xhci);
|
|
|
|
|
|
|
|
cur_td->urb->hcpriv = NULL;
|
|
|
|
usb_hcd_unlink_urb_from_ep(hcd, cur_td->urb);
|
|
|
|
xhci_dbg(xhci, "Giveback %s URB %p\n", adjective, cur_td->urb);
|
|
|
|
|
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
usb_hcd_giveback_urb(hcd, cur_td->urb, status);
|
|
|
|
kfree(cur_td);
|
|
|
|
spin_lock(&xhci->lock);
|
|
|
|
xhci_dbg(xhci, "%s URB given back\n", adjective);
|
|
|
|
}
|
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/*
|
|
|
|
* When we get a command completion for a Stop Endpoint Command, we need to
|
|
|
|
* unlink any cancelled TDs from the ring. There are two ways to do that:
|
|
|
|
*
|
|
|
|
* 1. If the HW was in the middle of processing the TD that needs to be
|
|
|
|
* cancelled, then we must move the ring's dequeue pointer past the last TRB
|
|
|
|
* in the TD with a Set Dequeue Pointer Command.
|
|
|
|
* 2. Otherwise, we turn all the TRBs in the TD into No-op TRBs (with the chain
|
|
|
|
* bit cleared) so that the HW will skip over them.
|
|
|
|
*/
|
|
|
|
static void handle_stopped_endpoint(struct xhci_hcd *xhci,
|
|
|
|
union xhci_trb *trb)
|
|
|
|
{
|
|
|
|
unsigned int slot_id;
|
|
|
|
unsigned int ep_index;
|
|
|
|
struct xhci_ring *ep_ring;
|
2009-09-05 01:53:09 +08:00
|
|
|
struct xhci_virt_ep *ep;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
struct list_head *entry;
|
|
|
|
struct xhci_td *cur_td = 0;
|
|
|
|
struct xhci_td *last_unlinked_td;
|
|
|
|
|
2009-07-28 03:05:21 +08:00
|
|
|
struct xhci_dequeue_state deq_state;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
|
|
|
memset(&deq_state, 0, sizeof(deq_state));
|
|
|
|
slot_id = TRB_TO_SLOT_ID(trb->generic.field[3]);
|
|
|
|
ep_index = TRB_TO_EP_INDEX(trb->generic.field[3]);
|
2009-09-05 01:53:09 +08:00
|
|
|
ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
ep_ring = ep->ring;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
USB: xhci: Handle URB cancel, complete and resubmit race.
In the old code, there was a race condition between the stop endpoint
command and the URB submission process. When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell. The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.
However, the following race condition could occur with the old code:
1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
(at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted. An
event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
canceled, decrements ep->cancels_pending to 0, and removes it from the to
be canceled list.
5. The event handler drops the lock and gives back the URB. The
completion handler requeues the URB (or a different driver enqueues a new
URB). This causes the endpoint's doorbell to be rung, since
ep->cancels_pending == 0. The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command. The
handler assumes the endpoint is stopped, but it isn't. It attempts to
move the dequeue pointer or change TDs to cancel the second URB, while the
hardware is actively accessing the endpoint ring.
To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING. When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet. The endpoint doorbell should not be rung when this
is set. Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell. ep->cancels_pending is eliminated, because it is no longer
used.
Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty. All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:55:52 +08:00
|
|
|
if (list_empty(&ep->cancelled_td_list)) {
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
xhci_stop_watchdog_timer_in_irq(xhci, ep);
|
USB: xhci: Handle URB cancel, complete and resubmit race.
In the old code, there was a race condition between the stop endpoint
command and the URB submission process. When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell. The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.
However, the following race condition could occur with the old code:
1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
(at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted. An
event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
canceled, decrements ep->cancels_pending to 0, and removes it from the to
be canceled list.
5. The event handler drops the lock and gives back the URB. The
completion handler requeues the URB (or a different driver enqueues a new
URB). This causes the endpoint's doorbell to be rung, since
ep->cancels_pending == 0. The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command. The
handler assumes the endpoint is stopped, but it isn't. It attempts to
move the dequeue pointer or change TDs to cancel the second URB, while the
hardware is actively accessing the endpoint ring.
To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING. When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet. The endpoint doorbell should not be rung when this
is set. Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell. ep->cancels_pending is eliminated, because it is no longer
used.
Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty. All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:55:52 +08:00
|
|
|
ring_ep_doorbell(xhci, slot_id, ep_index);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
return;
|
USB: xhci: Handle URB cancel, complete and resubmit race.
In the old code, there was a race condition between the stop endpoint
command and the URB submission process. When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell. The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.
However, the following race condition could occur with the old code:
1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
(at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted. An
event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
canceled, decrements ep->cancels_pending to 0, and removes it from the to
be canceled list.
5. The event handler drops the lock and gives back the URB. The
completion handler requeues the URB (or a different driver enqueues a new
URB). This causes the endpoint's doorbell to be rung, since
ep->cancels_pending == 0. The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command. The
handler assumes the endpoint is stopped, but it isn't. It attempts to
move the dequeue pointer or change TDs to cancel the second URB, while the
hardware is actively accessing the endpoint ring.
To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING. When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet. The endpoint doorbell should not be rung when this
is set. Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell. ep->cancels_pending is eliminated, because it is no longer
used.
Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty. All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:55:52 +08:00
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
|
|
|
/* Fix up the ep ring first, so HW stops executing cancelled TDs.
|
|
|
|
* We have the xHCI lock, so nothing can modify this list until we drop
|
|
|
|
* it. We're also in the event handler, so we can't get re-interrupted
|
|
|
|
* if another Stop Endpoint command completes
|
|
|
|
*/
|
2009-09-05 01:53:09 +08:00
|
|
|
list_for_each(entry, &ep->cancelled_td_list) {
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
cur_td = list_entry(entry, struct xhci_td, cancelled_td_list);
|
2009-04-30 10:14:08 +08:00
|
|
|
xhci_dbg(xhci, "Cancelling TD starting at %p, 0x%llx (dma).\n",
|
|
|
|
cur_td->first_trb,
|
2009-04-30 10:05:20 +08:00
|
|
|
(unsigned long long)xhci_trb_virt_to_dma(cur_td->start_seg, cur_td->first_trb));
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/*
|
|
|
|
* If we stopped on the TD we need to cancel, then we have to
|
|
|
|
* move the xHC endpoint ring dequeue pointer past this TD.
|
|
|
|
*/
|
2009-09-05 01:53:09 +08:00
|
|
|
if (cur_td == ep->stopped_td)
|
2009-07-28 03:05:21 +08:00
|
|
|
xhci_find_new_dequeue_state(xhci, slot_id, ep_index, cur_td,
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
&deq_state);
|
|
|
|
else
|
|
|
|
td_to_noop(xhci, ep_ring, cur_td);
|
|
|
|
/*
|
|
|
|
* The event handler won't see a completion for this TD anymore,
|
|
|
|
* so remove it from the endpoint ring's TD list. Keep it in
|
|
|
|
* the cancelled TD list for URB completion later.
|
|
|
|
*/
|
|
|
|
list_del(&cur_td->td_list);
|
|
|
|
}
|
|
|
|
last_unlinked_td = cur_td;
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
xhci_stop_watchdog_timer_in_irq(xhci, ep);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
|
|
|
/* If necessary, queue a Set Transfer Ring Dequeue Pointer command */
|
|
|
|
if (deq_state.new_deq_ptr && deq_state.new_deq_seg) {
|
2009-09-05 01:53:09 +08:00
|
|
|
xhci_queue_new_dequeue_state(xhci,
|
2009-07-28 03:05:21 +08:00
|
|
|
slot_id, ep_index, &deq_state);
|
2009-08-08 05:04:55 +08:00
|
|
|
xhci_ring_cmd_db(xhci);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
} else {
|
|
|
|
/* Otherwise just ring the doorbell to restart the ring */
|
|
|
|
ring_ep_doorbell(xhci, slot_id, ep_index);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Drop the lock and complete the URBs in the cancelled TD list.
|
|
|
|
* New TDs to be cancelled might be added to the end of the list before
|
|
|
|
* we can complete all the URBs for the TDs we already unlinked.
|
|
|
|
* So stop when we've completed the URB for the last TD we unlinked.
|
|
|
|
*/
|
|
|
|
do {
|
2009-09-05 01:53:09 +08:00
|
|
|
cur_td = list_entry(ep->cancelled_td_list.next,
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
struct xhci_td, cancelled_td_list);
|
|
|
|
list_del(&cur_td->cancelled_td_list);
|
|
|
|
|
|
|
|
/* Clean up the cancelled URB */
|
|
|
|
/* Doesn't matter what we pass for status, since the core will
|
|
|
|
* just overwrite it (because the URB has been unlinked).
|
|
|
|
*/
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
xhci_giveback_urb_in_irq(xhci, cur_td, 0, "cancelled");
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
/* Stop processing the cancelled list if the watchdog timer is
|
|
|
|
* running.
|
|
|
|
*/
|
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING)
|
|
|
|
return;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
} while (cur_td != last_unlinked_td);
|
|
|
|
|
|
|
|
/* Return to the event handler with xhci->lock re-acquired */
|
|
|
|
}
|
|
|
|
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
/* Watchdog timer function for when a stop endpoint command fails to complete.
|
|
|
|
* In this case, we assume the host controller is broken or dying or dead. The
|
|
|
|
* host may still be completing some other events, so we have to be careful to
|
|
|
|
* let the event ring handler and the URB dequeueing/enqueueing functions know
|
|
|
|
* through xhci->state.
|
|
|
|
*
|
|
|
|
* The timer may also fire if the host takes a very long time to respond to the
|
|
|
|
* command, and the stop endpoint command completion handler cannot delete the
|
|
|
|
* timer before the timer function is called. Another endpoint cancellation may
|
|
|
|
* sneak in before the timer function can grab the lock, and that may queue
|
|
|
|
* another stop endpoint command and add the timer back. So we cannot use a
|
|
|
|
* simple flag to say whether there is a pending stop endpoint command for a
|
|
|
|
* particular endpoint.
|
|
|
|
*
|
|
|
|
* Instead we use a combination of that flag and a counter for the number of
|
|
|
|
* pending stop endpoint commands. If the timer is the tail end of the last
|
|
|
|
* stop endpoint command, and the endpoint's command is still pending, we assume
|
|
|
|
* the host is dying.
|
|
|
|
*/
|
|
|
|
void xhci_stop_endpoint_command_watchdog(unsigned long arg)
|
|
|
|
{
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
struct xhci_virt_ep *ep;
|
|
|
|
struct xhci_virt_ep *temp_ep;
|
|
|
|
struct xhci_ring *ring;
|
|
|
|
struct xhci_td *cur_td;
|
|
|
|
int ret, i, j;
|
|
|
|
|
|
|
|
ep = (struct xhci_virt_ep *) arg;
|
|
|
|
xhci = ep->xhci;
|
|
|
|
|
|
|
|
spin_lock(&xhci->lock);
|
|
|
|
|
|
|
|
ep->stop_cmds_pending--;
|
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING) {
|
|
|
|
xhci_dbg(xhci, "Stop EP timer ran, but another timer marked "
|
|
|
|
"xHCI as DYING, exiting.\n");
|
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (!(ep->stop_cmds_pending == 0 && (ep->ep_state & EP_HALT_PENDING))) {
|
|
|
|
xhci_dbg(xhci, "Stop EP timer ran, but no command pending, "
|
|
|
|
"exiting.\n");
|
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
xhci_warn(xhci, "xHCI host not responding to stop endpoint command.\n");
|
|
|
|
xhci_warn(xhci, "Assuming host is dying, halting host.\n");
|
|
|
|
/* Oops, HC is dead or dying or at least not responding to the stop
|
|
|
|
* endpoint command.
|
|
|
|
*/
|
|
|
|
xhci->xhc_state |= XHCI_STATE_DYING;
|
|
|
|
/* Disable interrupts from the host controller and start halting it */
|
|
|
|
xhci_quiesce(xhci);
|
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
|
|
|
|
ret = xhci_halt(xhci);
|
|
|
|
|
|
|
|
spin_lock(&xhci->lock);
|
|
|
|
if (ret < 0) {
|
|
|
|
/* This is bad; the host is not responding to commands and it's
|
|
|
|
* not allowing itself to be halted. At least interrupts are
|
|
|
|
* disabled, so we can set HC_STATE_HALT and notify the
|
|
|
|
* USB core. But if we call usb_hc_died(), it will attempt to
|
|
|
|
* disconnect all device drivers under this host. Those
|
|
|
|
* disconnect() methods will wait for all URBs to be unlinked,
|
|
|
|
* so we must complete them.
|
|
|
|
*/
|
|
|
|
xhci_warn(xhci, "Non-responsive xHCI host is not halting.\n");
|
|
|
|
xhci_warn(xhci, "Completing active URBs anyway.\n");
|
|
|
|
/* We could turn all TDs on the rings to no-ops. This won't
|
|
|
|
* help if the host has cached part of the ring, and is slow if
|
|
|
|
* we want to preserve the cycle bit. Skip it and hope the host
|
|
|
|
* doesn't touch the memory.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
for (i = 0; i < MAX_HC_SLOTS; i++) {
|
|
|
|
if (!xhci->devs[i])
|
|
|
|
continue;
|
|
|
|
for (j = 0; j < 31; j++) {
|
|
|
|
temp_ep = &xhci->devs[i]->eps[j];
|
|
|
|
ring = temp_ep->ring;
|
|
|
|
if (!ring)
|
|
|
|
continue;
|
|
|
|
xhci_dbg(xhci, "Killing URBs for slot ID %u, "
|
|
|
|
"ep index %u\n", i, j);
|
|
|
|
while (!list_empty(&ring->td_list)) {
|
|
|
|
cur_td = list_first_entry(&ring->td_list,
|
|
|
|
struct xhci_td,
|
|
|
|
td_list);
|
|
|
|
list_del(&cur_td->td_list);
|
|
|
|
if (!list_empty(&cur_td->cancelled_td_list))
|
|
|
|
list_del(&cur_td->cancelled_td_list);
|
|
|
|
xhci_giveback_urb_in_irq(xhci, cur_td,
|
|
|
|
-ESHUTDOWN, "killed");
|
|
|
|
}
|
|
|
|
while (!list_empty(&temp_ep->cancelled_td_list)) {
|
|
|
|
cur_td = list_first_entry(
|
|
|
|
&temp_ep->cancelled_td_list,
|
|
|
|
struct xhci_td,
|
|
|
|
cancelled_td_list);
|
|
|
|
list_del(&cur_td->cancelled_td_list);
|
|
|
|
xhci_giveback_urb_in_irq(xhci, cur_td,
|
|
|
|
-ESHUTDOWN, "killed");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
xhci_to_hcd(xhci)->state = HC_STATE_HALT;
|
|
|
|
xhci_dbg(xhci, "Calling usb_hc_died()\n");
|
|
|
|
usb_hc_died(xhci_to_hcd(xhci));
|
|
|
|
xhci_dbg(xhci, "xHCI host controller is dead.\n");
|
|
|
|
}
|
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/*
|
|
|
|
* When we get a completion for a Set Transfer Ring Dequeue Pointer command,
|
|
|
|
* we need to clear the set deq pending flag in the endpoint ring state, so that
|
|
|
|
* the TD queueing code can ring the doorbell again. We also need to ring the
|
|
|
|
* endpoint doorbell to restart the ring, but only if there aren't more
|
|
|
|
* cancellations pending.
|
|
|
|
*/
|
|
|
|
static void handle_set_deq_completion(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_event_cmd *event,
|
|
|
|
union xhci_trb *trb)
|
|
|
|
{
|
|
|
|
unsigned int slot_id;
|
|
|
|
unsigned int ep_index;
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
struct xhci_virt_device *dev;
|
2009-07-28 03:05:15 +08:00
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
struct xhci_slot_ctx *slot_ctx;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
|
|
|
slot_id = TRB_TO_SLOT_ID(trb->generic.field[3]);
|
|
|
|
ep_index = TRB_TO_EP_INDEX(trb->generic.field[3]);
|
|
|
|
dev = xhci->devs[slot_id];
|
2009-09-05 01:53:09 +08:00
|
|
|
ep_ring = dev->eps[ep_index].ring;
|
2009-07-28 03:05:15 +08:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
|
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, dev->out_ctx);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
|
|
|
if (GET_COMP_CODE(event->status) != COMP_SUCCESS) {
|
|
|
|
unsigned int ep_state;
|
|
|
|
unsigned int slot_state;
|
|
|
|
|
|
|
|
switch (GET_COMP_CODE(event->status)) {
|
|
|
|
case COMP_TRB_ERR:
|
|
|
|
xhci_warn(xhci, "WARN Set TR Deq Ptr cmd invalid because "
|
|
|
|
"of stream ID configuration\n");
|
|
|
|
break;
|
|
|
|
case COMP_CTX_STATE:
|
|
|
|
xhci_warn(xhci, "WARN Set TR Deq Ptr cmd failed due "
|
|
|
|
"to incorrect slot or ep state.\n");
|
2009-07-28 03:05:15 +08:00
|
|
|
ep_state = ep_ctx->ep_info;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
ep_state &= EP_STATE_MASK;
|
2009-07-28 03:05:15 +08:00
|
|
|
slot_state = slot_ctx->dev_state;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
slot_state = GET_SLOT_STATE(slot_state);
|
|
|
|
xhci_dbg(xhci, "Slot state = %u, EP state = %u\n",
|
|
|
|
slot_state, ep_state);
|
|
|
|
break;
|
|
|
|
case COMP_EBADSLT:
|
|
|
|
xhci_warn(xhci, "WARN Set TR Deq Ptr cmd failed because "
|
|
|
|
"slot %u was not enabled.\n", slot_id);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
xhci_warn(xhci, "WARN Set TR Deq Ptr cmd with unknown "
|
|
|
|
"completion code of %u.\n",
|
|
|
|
GET_COMP_CODE(event->status));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* OK what do we do now? The endpoint state is hosed, and we
|
|
|
|
* should never get to this point if the synchronization between
|
|
|
|
* queueing, and endpoint state are correct. This might happen
|
|
|
|
* if the device gets disconnected after we've finished
|
|
|
|
* cancelling URBs, which might not be an error...
|
|
|
|
*/
|
|
|
|
} else {
|
2009-07-28 03:03:31 +08:00
|
|
|
xhci_dbg(xhci, "Successful Set TR Deq Ptr cmd, deq = @%08llx\n",
|
2009-07-28 03:05:15 +08:00
|
|
|
ep_ctx->deq);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
}
|
|
|
|
|
2009-09-05 01:53:09 +08:00
|
|
|
dev->eps[ep_index].ep_state &= ~SET_DEQ_PENDING;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
ring_ep_doorbell(xhci, slot_id, ep_index);
|
|
|
|
}
|
|
|
|
|
2009-07-28 03:03:15 +08:00
|
|
|
static void handle_reset_ep_completion(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_event_cmd *event,
|
|
|
|
union xhci_trb *trb)
|
|
|
|
{
|
|
|
|
int slot_id;
|
|
|
|
unsigned int ep_index;
|
2009-08-08 05:04:55 +08:00
|
|
|
struct xhci_ring *ep_ring;
|
2009-07-28 03:03:15 +08:00
|
|
|
|
|
|
|
slot_id = TRB_TO_SLOT_ID(trb->generic.field[3]);
|
|
|
|
ep_index = TRB_TO_EP_INDEX(trb->generic.field[3]);
|
2009-09-05 01:53:09 +08:00
|
|
|
ep_ring = xhci->devs[slot_id]->eps[ep_index].ring;
|
2009-07-28 03:03:15 +08:00
|
|
|
/* This command will only fail if the endpoint wasn't halted,
|
|
|
|
* but we don't care.
|
|
|
|
*/
|
|
|
|
xhci_dbg(xhci, "Ignoring reset ep completion code of %u\n",
|
|
|
|
(unsigned int) GET_COMP_CODE(event->status));
|
|
|
|
|
2009-08-08 05:04:55 +08:00
|
|
|
/* HW with the reset endpoint quirk needs to have a configure endpoint
|
|
|
|
* command complete before the endpoint can be used. Queue that here
|
|
|
|
* because the HW can't handle two commands being queued in a row.
|
|
|
|
*/
|
|
|
|
if (xhci->quirks & XHCI_RESET_EP_QUIRK) {
|
|
|
|
xhci_dbg(xhci, "Queueing configure endpoint command\n");
|
|
|
|
xhci_queue_configure_endpoint(xhci,
|
2009-09-05 01:53:13 +08:00
|
|
|
xhci->devs[slot_id]->in_ctx->dma, slot_id,
|
|
|
|
false);
|
2009-08-08 05:04:55 +08:00
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
} else {
|
|
|
|
/* Clear our internal halted state and restart the ring */
|
2009-09-05 01:53:09 +08:00
|
|
|
xhci->devs[slot_id]->eps[ep_index].ep_state &= ~EP_HALTED;
|
2009-08-08 05:04:55 +08:00
|
|
|
ring_ep_doorbell(xhci, slot_id, ep_index);
|
|
|
|
}
|
2009-07-28 03:03:15 +08:00
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
2009-09-05 01:53:15 +08:00
|
|
|
/* Check to see if a command in the device's command queue matches this one.
|
|
|
|
* Signal the completion or free the command, and return 1. Return 0 if the
|
|
|
|
* completed command isn't at the head of the command list.
|
|
|
|
*/
|
|
|
|
static int handle_cmd_in_cmd_wait_list(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
struct xhci_event_cmd *event)
|
|
|
|
{
|
|
|
|
struct xhci_command *command;
|
|
|
|
|
|
|
|
if (list_empty(&virt_dev->cmd_list))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
command = list_entry(virt_dev->cmd_list.next,
|
|
|
|
struct xhci_command, cmd_list);
|
|
|
|
if (xhci->cmd_ring->dequeue != command->command_trb)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
command->status =
|
|
|
|
GET_COMP_CODE(event->status);
|
|
|
|
list_del(&command->cmd_list);
|
|
|
|
if (command->completion)
|
|
|
|
complete(command->completion);
|
|
|
|
else
|
|
|
|
xhci_free_command(xhci, command);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:53:56 +08:00
|
|
|
static void handle_cmd_completion(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_event_cmd *event)
|
|
|
|
{
|
2009-04-28 10:57:38 +08:00
|
|
|
int slot_id = TRB_TO_SLOT_ID(event->flags);
|
2009-04-28 10:53:56 +08:00
|
|
|
u64 cmd_dma;
|
|
|
|
dma_addr_t cmd_dequeue_dma;
|
2009-08-08 05:04:55 +08:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
2009-09-05 01:53:13 +08:00
|
|
|
struct xhci_virt_device *virt_dev;
|
2009-08-08 05:04:55 +08:00
|
|
|
unsigned int ep_index;
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
unsigned int ep_state;
|
2009-04-28 10:53:56 +08:00
|
|
|
|
2009-07-28 03:03:31 +08:00
|
|
|
cmd_dma = event->cmd_trb;
|
2009-04-30 10:05:20 +08:00
|
|
|
cmd_dequeue_dma = xhci_trb_virt_to_dma(xhci->cmd_ring->deq_seg,
|
2009-04-28 10:53:56 +08:00
|
|
|
xhci->cmd_ring->dequeue);
|
|
|
|
/* Is the command ring deq ptr out of sync with the deq seg ptr? */
|
|
|
|
if (cmd_dequeue_dma == 0) {
|
|
|
|
xhci->error_bitmask |= 1 << 4;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* Does the DMA address match our internal dequeue pointer address? */
|
|
|
|
if (cmd_dma != (u64) cmd_dequeue_dma) {
|
|
|
|
xhci->error_bitmask |= 1 << 5;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
switch (xhci->cmd_ring->dequeue->generic.field[3] & TRB_TYPE_BITMASK) {
|
2009-04-28 10:57:38 +08:00
|
|
|
case TRB_TYPE(TRB_ENABLE_SLOT):
|
|
|
|
if (GET_COMP_CODE(event->status) == COMP_SUCCESS)
|
|
|
|
xhci->slot_id = slot_id;
|
|
|
|
else
|
|
|
|
xhci->slot_id = 0;
|
|
|
|
complete(&xhci->addr_dev);
|
|
|
|
break;
|
|
|
|
case TRB_TYPE(TRB_DISABLE_SLOT):
|
|
|
|
if (xhci->devs[slot_id])
|
|
|
|
xhci_free_virt_device(xhci, slot_id);
|
|
|
|
break;
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:58:38 +08:00
|
|
|
case TRB_TYPE(TRB_CONFIG_EP):
|
2009-09-05 01:53:13 +08:00
|
|
|
virt_dev = xhci->devs[slot_id];
|
2009-09-05 01:53:15 +08:00
|
|
|
if (handle_cmd_in_cmd_wait_list(xhci, virt_dev, event))
|
2009-09-05 01:53:13 +08:00
|
|
|
break;
|
2009-08-08 05:04:55 +08:00
|
|
|
/*
|
|
|
|
* Configure endpoint commands can come from the USB core
|
|
|
|
* configuration or alt setting changes, or because the HW
|
|
|
|
* needed an extra configure endpoint command after a reset
|
|
|
|
* endpoint command. In the latter case, the xHCI driver is
|
|
|
|
* not waiting on the configure endpoint command.
|
|
|
|
*/
|
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci,
|
2009-09-05 01:53:13 +08:00
|
|
|
virt_dev->in_ctx);
|
2009-08-08 05:04:55 +08:00
|
|
|
/* Input ctx add_flags are the endpoint index plus one */
|
|
|
|
ep_index = xhci_last_valid_endpoint(ctrl_ctx->add_flags) - 1;
|
2009-12-04 01:44:31 +08:00
|
|
|
/* A usb_set_interface() call directly after clearing a halted
|
|
|
|
* condition may race on this quirky hardware.
|
|
|
|
* Not worth worrying about, since this is prototype hardware.
|
|
|
|
*/
|
2009-08-08 05:04:55 +08:00
|
|
|
if (xhci->quirks & XHCI_RESET_EP_QUIRK &&
|
2009-12-04 01:44:31 +08:00
|
|
|
ep_index != (unsigned int) -1 &&
|
|
|
|
ctrl_ctx->add_flags - SLOT_FLAG ==
|
|
|
|
ctrl_ctx->drop_flags) {
|
|
|
|
ep_ring = xhci->devs[slot_id]->eps[ep_index].ring;
|
|
|
|
ep_state = xhci->devs[slot_id]->eps[ep_index].ep_state;
|
|
|
|
if (!(ep_state & EP_HALTED))
|
|
|
|
goto bandwidth_change;
|
|
|
|
xhci_dbg(xhci, "Completed config ep cmd - "
|
|
|
|
"last ep index = %d, state = %d\n",
|
|
|
|
ep_index, ep_state);
|
2009-08-08 05:04:55 +08:00
|
|
|
/* Clear our internal halted state and restart ring */
|
2009-09-05 01:53:09 +08:00
|
|
|
xhci->devs[slot_id]->eps[ep_index].ep_state &=
|
2009-08-08 05:04:55 +08:00
|
|
|
~EP_HALTED;
|
|
|
|
ring_ep_doorbell(xhci, slot_id, ep_index);
|
2009-12-04 01:44:31 +08:00
|
|
|
break;
|
2009-08-08 05:04:55 +08:00
|
|
|
}
|
2009-12-04 01:44:31 +08:00
|
|
|
bandwidth_change:
|
|
|
|
xhci_dbg(xhci, "Completed config ep cmd\n");
|
|
|
|
xhci->devs[slot_id]->cmd_status =
|
|
|
|
GET_COMP_CODE(event->status);
|
|
|
|
complete(&xhci->devs[slot_id]->cmd_completion);
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:58:38 +08:00
|
|
|
break;
|
2009-08-08 05:04:49 +08:00
|
|
|
case TRB_TYPE(TRB_EVAL_CONTEXT):
|
2009-09-05 01:53:20 +08:00
|
|
|
virt_dev = xhci->devs[slot_id];
|
|
|
|
if (handle_cmd_in_cmd_wait_list(xhci, virt_dev, event))
|
|
|
|
break;
|
2009-08-08 05:04:49 +08:00
|
|
|
xhci->devs[slot_id]->cmd_status = GET_COMP_CODE(event->status);
|
|
|
|
complete(&xhci->devs[slot_id]->cmd_completion);
|
|
|
|
break;
|
2009-04-28 10:57:38 +08:00
|
|
|
case TRB_TYPE(TRB_ADDR_DEV):
|
|
|
|
xhci->devs[slot_id]->cmd_status = GET_COMP_CODE(event->status);
|
|
|
|
complete(&xhci->addr_dev);
|
|
|
|
break;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
case TRB_TYPE(TRB_STOP_RING):
|
|
|
|
handle_stopped_endpoint(xhci, xhci->cmd_ring->dequeue);
|
|
|
|
break;
|
|
|
|
case TRB_TYPE(TRB_SET_DEQ):
|
|
|
|
handle_set_deq_completion(xhci, event, xhci->cmd_ring->dequeue);
|
|
|
|
break;
|
2009-04-28 10:53:56 +08:00
|
|
|
case TRB_TYPE(TRB_CMD_NOOP):
|
|
|
|
++xhci->noops_handled;
|
|
|
|
break;
|
2009-07-28 03:03:15 +08:00
|
|
|
case TRB_TYPE(TRB_RESET_EP):
|
|
|
|
handle_reset_ep_completion(xhci, event, xhci->cmd_ring->dequeue);
|
|
|
|
break;
|
2009-04-28 10:53:56 +08:00
|
|
|
default:
|
|
|
|
/* Skip over unknown commands on the event ring */
|
|
|
|
xhci->error_bitmask |= 1 << 6;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
inc_deq(xhci, xhci->cmd_ring, false);
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:57:12 +08:00
|
|
|
static void handle_port_status(struct xhci_hcd *xhci,
|
|
|
|
union xhci_trb *event)
|
|
|
|
{
|
|
|
|
u32 port_id;
|
|
|
|
|
|
|
|
/* Port status change events always have a successful completion code */
|
|
|
|
if (GET_COMP_CODE(event->generic.field[2]) != COMP_SUCCESS) {
|
|
|
|
xhci_warn(xhci, "WARN: xHC returned failed port status event\n");
|
|
|
|
xhci->error_bitmask |= 1 << 8;
|
|
|
|
}
|
|
|
|
/* FIXME: core doesn't care about all port link state changes yet */
|
|
|
|
port_id = GET_PORT_ID(event->generic.field[0]);
|
|
|
|
xhci_dbg(xhci, "Port Status Change Event for port %d\n", port_id);
|
|
|
|
|
|
|
|
/* Update event ring dequeue pointer before dropping the lock */
|
|
|
|
inc_deq(xhci, xhci->event_ring, true);
|
2009-04-30 10:05:20 +08:00
|
|
|
xhci_set_hc_event_deq(xhci);
|
2009-04-28 10:57:12 +08:00
|
|
|
|
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
/* Pass this up to the core */
|
|
|
|
usb_hcd_poll_rh_status(xhci_to_hcd(xhci));
|
|
|
|
spin_lock(&xhci->lock);
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:58:01 +08:00
|
|
|
/*
|
|
|
|
* This TD is defined by the TRBs starting at start_trb in start_seg and ending
|
|
|
|
* at end_trb, which may be in another segment. If the suspect DMA address is a
|
|
|
|
* TRB in this TD, this function returns that TRB's segment. Otherwise it
|
|
|
|
* returns 0.
|
|
|
|
*/
|
2009-11-10 05:35:23 +08:00
|
|
|
struct xhci_segment *trb_in_td(struct xhci_segment *start_seg,
|
2009-04-28 10:58:01 +08:00
|
|
|
union xhci_trb *start_trb,
|
|
|
|
union xhci_trb *end_trb,
|
|
|
|
dma_addr_t suspect_dma)
|
|
|
|
{
|
|
|
|
dma_addr_t start_dma;
|
|
|
|
dma_addr_t end_seg_dma;
|
|
|
|
dma_addr_t end_trb_dma;
|
|
|
|
struct xhci_segment *cur_seg;
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
start_dma = xhci_trb_virt_to_dma(start_seg, start_trb);
|
2009-04-28 10:58:01 +08:00
|
|
|
cur_seg = start_seg;
|
|
|
|
|
|
|
|
do {
|
2009-11-04 14:02:24 +08:00
|
|
|
if (start_dma == 0)
|
|
|
|
return 0;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/* We may get an event for a Link TRB in the middle of a TD */
|
2009-04-30 10:05:20 +08:00
|
|
|
end_seg_dma = xhci_trb_virt_to_dma(cur_seg,
|
2009-11-04 14:02:24 +08:00
|
|
|
&cur_seg->trbs[TRBS_PER_SEGMENT - 1]);
|
2009-04-28 10:58:01 +08:00
|
|
|
/* If the end TRB isn't in this segment, this is set to 0 */
|
2009-04-30 10:05:20 +08:00
|
|
|
end_trb_dma = xhci_trb_virt_to_dma(cur_seg, end_trb);
|
2009-04-28 10:58:01 +08:00
|
|
|
|
|
|
|
if (end_trb_dma > 0) {
|
|
|
|
/* The end TRB is in this segment, so suspect should be here */
|
|
|
|
if (start_dma <= end_trb_dma) {
|
|
|
|
if (suspect_dma >= start_dma && suspect_dma <= end_trb_dma)
|
|
|
|
return cur_seg;
|
|
|
|
} else {
|
|
|
|
/* Case for one segment with
|
|
|
|
* a TD wrapped around to the top
|
|
|
|
*/
|
|
|
|
if ((suspect_dma >= start_dma &&
|
|
|
|
suspect_dma <= end_seg_dma) ||
|
|
|
|
(suspect_dma >= cur_seg->dma &&
|
|
|
|
suspect_dma <= end_trb_dma))
|
|
|
|
return cur_seg;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
} else {
|
|
|
|
/* Might still be somewhere in this segment */
|
|
|
|
if (suspect_dma >= start_dma && suspect_dma <= end_seg_dma)
|
|
|
|
return cur_seg;
|
|
|
|
}
|
|
|
|
cur_seg = cur_seg->next;
|
2009-04-30 10:05:20 +08:00
|
|
|
start_dma = xhci_trb_virt_to_dma(cur_seg, &cur_seg->trbs[0]);
|
2009-11-04 14:02:24 +08:00
|
|
|
} while (cur_seg != start_seg);
|
2009-04-28 10:58:01 +08:00
|
|
|
|
2009-11-04 14:02:24 +08:00
|
|
|
return 0;
|
2009-04-28 10:58:01 +08:00
|
|
|
}
|
|
|
|
|
2009-11-12 02:28:44 +08:00
|
|
|
static void xhci_cleanup_halted_endpoint(struct xhci_hcd *xhci,
|
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
|
|
|
struct xhci_td *td, union xhci_trb *event_trb)
|
|
|
|
{
|
|
|
|
struct xhci_virt_ep *ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
ep->ep_state |= EP_HALTED;
|
|
|
|
ep->stopped_td = td;
|
|
|
|
ep->stopped_trb = event_trb;
|
|
|
|
xhci_queue_reset_ep(xhci, slot_id, ep_index);
|
|
|
|
xhci_cleanup_stalled_ring(xhci, td->urb->dev, ep_index);
|
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if an error has halted the endpoint ring. The class driver will
|
|
|
|
* cleanup the halt for a non-default control endpoint if we indicate a stall.
|
|
|
|
* However, a babble and other errors also halt the endpoint ring, and the class
|
|
|
|
* driver won't clear the halt in that case, so we need to issue a Set Transfer
|
|
|
|
* Ring Dequeue Pointer command manually.
|
|
|
|
*/
|
|
|
|
static int xhci_requires_manual_halt_cleanup(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_ep_ctx *ep_ctx,
|
|
|
|
unsigned int trb_comp_code)
|
|
|
|
{
|
|
|
|
/* TRB completion codes that may require a manual halt cleanup */
|
|
|
|
if (trb_comp_code == COMP_TX_ERR ||
|
|
|
|
trb_comp_code == COMP_BABBLE ||
|
|
|
|
trb_comp_code == COMP_SPLIT_ERR)
|
|
|
|
/* The 0.96 spec says a babbling control endpoint
|
|
|
|
* is not halted. The 0.96 spec says it is. Some HW
|
|
|
|
* claims to be 0.95 compliant, but it halts the control
|
|
|
|
* endpoint anyway. Check if a babble halted the
|
|
|
|
* endpoint.
|
|
|
|
*/
|
|
|
|
if ((ep_ctx->ep_info & EP_STATE_MASK) == EP_STATE_HALTED)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:58:01 +08:00
|
|
|
/*
|
|
|
|
* If this function returns an error condition, it means it got a Transfer
|
|
|
|
* event with a corrupted Slot ID, Endpoint ID, or TRB DMA address.
|
|
|
|
* At this point, the host controller is probably hosed and should be reset.
|
|
|
|
*/
|
|
|
|
static int handle_tx_event(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_transfer_event *event)
|
|
|
|
{
|
|
|
|
struct xhci_virt_device *xdev;
|
2009-09-05 01:53:09 +08:00
|
|
|
struct xhci_virt_ep *ep;
|
2009-04-28 10:58:01 +08:00
|
|
|
struct xhci_ring *ep_ring;
|
2009-08-08 05:04:52 +08:00
|
|
|
unsigned int slot_id;
|
2009-04-28 10:58:01 +08:00
|
|
|
int ep_index;
|
|
|
|
struct xhci_td *td = 0;
|
|
|
|
dma_addr_t event_dma;
|
|
|
|
struct xhci_segment *event_seg;
|
|
|
|
union xhci_trb *event_trb;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
struct urb *urb = 0;
|
2009-04-28 10:58:01 +08:00
|
|
|
int status = -EINPROGRESS;
|
2009-07-28 03:05:15 +08:00
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
2009-08-28 05:35:53 +08:00
|
|
|
u32 trb_comp_code;
|
2009-04-28 10:58:01 +08:00
|
|
|
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "In %s\n", __func__);
|
2009-08-08 05:04:52 +08:00
|
|
|
slot_id = TRB_TO_SLOT_ID(event->flags);
|
|
|
|
xdev = xhci->devs[slot_id];
|
2009-04-28 10:58:01 +08:00
|
|
|
if (!xdev) {
|
|
|
|
xhci_err(xhci, "ERROR Transfer event pointed to bad slot\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Endpoint ID is 1 based, our index is zero based */
|
|
|
|
ep_index = TRB_TO_EP_ID(event->flags) - 1;
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - ep index = %d\n", __func__, ep_index);
|
2009-09-05 01:53:09 +08:00
|
|
|
ep = &xdev->eps[ep_index];
|
|
|
|
ep_ring = ep->ring;
|
2009-07-28 03:05:15 +08:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
|
|
|
if (!ep_ring || (ep_ctx->ep_info & EP_STATE_MASK) == EP_STATE_DISABLED) {
|
2009-04-28 10:58:01 +08:00
|
|
|
xhci_err(xhci, "ERROR Transfer event pointed to disabled endpoint\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2009-07-28 03:03:31 +08:00
|
|
|
event_dma = event->buffer;
|
2009-04-28 10:58:01 +08:00
|
|
|
/* This TRB should be in the TD at the head of this ring's TD list */
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - checking for list empty\n", __func__);
|
2009-04-28 10:58:01 +08:00
|
|
|
if (list_empty(&ep_ring->td_list)) {
|
|
|
|
xhci_warn(xhci, "WARN Event TRB for slot %d ep %d with no TDs queued?\n",
|
|
|
|
TRB_TO_SLOT_ID(event->flags), ep_index);
|
|
|
|
xhci_dbg(xhci, "Event TRB with TRB type ID %u\n",
|
|
|
|
(unsigned int) (event->flags & TRB_TYPE_BITMASK)>>10);
|
|
|
|
xhci_print_trb_offsets(xhci, (union xhci_trb *) event);
|
|
|
|
urb = NULL;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - getting list entry\n", __func__);
|
2009-04-28 10:58:01 +08:00
|
|
|
td = list_entry(ep_ring->td_list.next, struct xhci_td, td_list);
|
|
|
|
|
|
|
|
/* Is this a TRB in the currently executing TD? */
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - looking for TD\n", __func__);
|
2009-04-28 10:58:01 +08:00
|
|
|
event_seg = trb_in_td(ep_ring->deq_seg, ep_ring->dequeue,
|
|
|
|
td->last_trb, event_dma);
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - found event_seg = %p\n", __func__, event_seg);
|
2009-04-28 10:58:01 +08:00
|
|
|
if (!event_seg) {
|
|
|
|
/* HC is busted, give up! */
|
|
|
|
xhci_err(xhci, "ERROR Transfer event TRB DMA ptr not part of current TD\n");
|
|
|
|
return -ESHUTDOWN;
|
|
|
|
}
|
|
|
|
event_trb = &event_seg->trbs[(event_dma - event_seg->dma) / sizeof(*event_trb)];
|
2009-04-28 10:58:50 +08:00
|
|
|
xhci_dbg(xhci, "Event TRB with TRB type ID %u\n",
|
|
|
|
(unsigned int) (event->flags & TRB_TYPE_BITMASK)>>10);
|
2009-07-28 03:03:31 +08:00
|
|
|
xhci_dbg(xhci, "Offset 0x00 (buffer lo) = 0x%x\n",
|
|
|
|
lower_32_bits(event->buffer));
|
|
|
|
xhci_dbg(xhci, "Offset 0x04 (buffer hi) = 0x%x\n",
|
|
|
|
upper_32_bits(event->buffer));
|
2009-04-28 10:58:50 +08:00
|
|
|
xhci_dbg(xhci, "Offset 0x08 (transfer length) = 0x%x\n",
|
|
|
|
(unsigned int) event->transfer_len);
|
|
|
|
xhci_dbg(xhci, "Offset 0x0C (flags) = 0x%x\n",
|
|
|
|
(unsigned int) event->flags);
|
|
|
|
|
|
|
|
/* Look for common error cases */
|
2009-08-28 05:35:53 +08:00
|
|
|
trb_comp_code = GET_COMP_CODE(event->transfer_len);
|
|
|
|
switch (trb_comp_code) {
|
2009-04-28 10:58:50 +08:00
|
|
|
/* Skip codes that require special handling depending on
|
|
|
|
* transfer type
|
|
|
|
*/
|
|
|
|
case COMP_SUCCESS:
|
|
|
|
case COMP_SHORT_TX:
|
|
|
|
break;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
case COMP_STOP:
|
|
|
|
xhci_dbg(xhci, "Stopped on Transfer TRB\n");
|
|
|
|
break;
|
|
|
|
case COMP_STOP_INVAL:
|
|
|
|
xhci_dbg(xhci, "Stopped on No-op or Link TRB\n");
|
|
|
|
break;
|
2009-04-28 10:58:50 +08:00
|
|
|
case COMP_STALL:
|
|
|
|
xhci_warn(xhci, "WARN: Stalled endpoint\n");
|
2009-09-05 01:53:09 +08:00
|
|
|
ep->ep_state |= EP_HALTED;
|
2009-04-28 10:58:50 +08:00
|
|
|
status = -EPIPE;
|
|
|
|
break;
|
|
|
|
case COMP_TRB_ERR:
|
|
|
|
xhci_warn(xhci, "WARN: TRB error on endpoint\n");
|
|
|
|
status = -EILSEQ;
|
|
|
|
break;
|
2009-11-12 02:28:36 +08:00
|
|
|
case COMP_SPLIT_ERR:
|
2009-04-28 10:58:50 +08:00
|
|
|
case COMP_TX_ERR:
|
|
|
|
xhci_warn(xhci, "WARN: transfer error on endpoint\n");
|
|
|
|
status = -EPROTO;
|
|
|
|
break;
|
2009-07-28 03:04:32 +08:00
|
|
|
case COMP_BABBLE:
|
|
|
|
xhci_warn(xhci, "WARN: babble error on endpoint\n");
|
|
|
|
status = -EOVERFLOW;
|
|
|
|
break;
|
2009-04-28 10:58:50 +08:00
|
|
|
case COMP_DB_ERR:
|
|
|
|
xhci_warn(xhci, "WARN: HC couldn't access mem fast enough\n");
|
|
|
|
status = -ENOSR;
|
|
|
|
break;
|
|
|
|
default:
|
2009-11-12 02:28:40 +08:00
|
|
|
if (trb_comp_code >= 224 && trb_comp_code <= 255) {
|
|
|
|
/* Vendor defined "informational" completion code,
|
|
|
|
* treat as not-an-error.
|
|
|
|
*/
|
|
|
|
xhci_dbg(xhci, "Vendor defined info completion code %u\n",
|
|
|
|
trb_comp_code);
|
|
|
|
xhci_dbg(xhci, "Treating code as success.\n");
|
|
|
|
status = 0;
|
|
|
|
break;
|
|
|
|
}
|
2009-04-28 10:58:50 +08:00
|
|
|
xhci_warn(xhci, "ERROR Unknown event condition, HC probably busted\n");
|
|
|
|
urb = NULL;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2009-04-28 10:58:01 +08:00
|
|
|
/* Now update the urb's actual_length and give back to the core */
|
|
|
|
/* Was this a control transfer? */
|
|
|
|
if (usb_endpoint_xfer_control(&td->urb->ep->desc)) {
|
|
|
|
xhci_debug_trb(xhci, xhci->event_ring->dequeue);
|
2009-08-28 05:35:53 +08:00
|
|
|
switch (trb_comp_code) {
|
2009-04-28 10:58:01 +08:00
|
|
|
case COMP_SUCCESS:
|
|
|
|
if (event_trb == ep_ring->dequeue) {
|
|
|
|
xhci_warn(xhci, "WARN: Success on ctrl setup TRB without IOC set??\n");
|
|
|
|
status = -ESHUTDOWN;
|
|
|
|
} else if (event_trb != td->last_trb) {
|
|
|
|
xhci_warn(xhci, "WARN: Success on ctrl data TRB without IOC set??\n");
|
|
|
|
status = -ESHUTDOWN;
|
|
|
|
} else {
|
|
|
|
xhci_dbg(xhci, "Successful control transfer!\n");
|
|
|
|
status = 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case COMP_SHORT_TX:
|
|
|
|
xhci_warn(xhci, "WARN: short transfer on control ep\n");
|
2009-08-29 05:28:15 +08:00
|
|
|
if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
|
|
|
|
status = -EREMOTEIO;
|
|
|
|
else
|
|
|
|
status = 0;
|
2009-04-28 10:58:01 +08:00
|
|
|
break;
|
2009-11-12 02:28:44 +08:00
|
|
|
|
|
|
|
default:
|
|
|
|
if (!xhci_requires_manual_halt_cleanup(xhci,
|
|
|
|
ep_ctx, trb_comp_code))
|
2009-08-28 05:36:03 +08:00
|
|
|
break;
|
2009-11-12 02:28:44 +08:00
|
|
|
xhci_dbg(xhci, "TRB error code %u, "
|
|
|
|
"halted endpoint index = %u\n",
|
|
|
|
trb_comp_code, ep_index);
|
2009-08-28 05:36:03 +08:00
|
|
|
/* else fall through */
|
2009-08-08 05:04:52 +08:00
|
|
|
case COMP_STALL:
|
|
|
|
/* Did we transfer part of the data (middle) phase? */
|
|
|
|
if (event_trb != ep_ring->dequeue &&
|
|
|
|
event_trb != td->last_trb)
|
|
|
|
td->urb->actual_length =
|
|
|
|
td->urb->transfer_buffer_length
|
|
|
|
- TRB_LEN(event->transfer_len);
|
|
|
|
else
|
|
|
|
td->urb->actual_length = 0;
|
|
|
|
|
2009-11-12 02:28:44 +08:00
|
|
|
xhci_cleanup_halted_endpoint(xhci,
|
|
|
|
slot_id, ep_index, td, event_trb);
|
2009-08-08 05:04:52 +08:00
|
|
|
goto td_cleanup;
|
2009-04-28 10:58:01 +08:00
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Did we transfer any data, despite the errors that might have
|
|
|
|
* happened? I.e. did we get past the setup stage?
|
|
|
|
*/
|
|
|
|
if (event_trb != ep_ring->dequeue) {
|
|
|
|
/* The event was for the status stage */
|
|
|
|
if (event_trb == td->last_trb) {
|
2009-07-28 03:05:21 +08:00
|
|
|
if (td->urb->actual_length != 0) {
|
|
|
|
/* Don't overwrite a previously set error code */
|
2009-08-29 05:28:15 +08:00
|
|
|
if ((status == -EINPROGRESS ||
|
|
|
|
status == 0) &&
|
|
|
|
(td->urb->transfer_flags
|
|
|
|
& URB_SHORT_NOT_OK))
|
2009-07-28 03:05:21 +08:00
|
|
|
/* Did we already see a short data stage? */
|
|
|
|
status = -EREMOTEIO;
|
|
|
|
} else {
|
2009-07-28 03:03:36 +08:00
|
|
|
td->urb->actual_length =
|
|
|
|
td->urb->transfer_buffer_length;
|
2009-07-28 03:05:21 +08:00
|
|
|
}
|
2009-04-28 10:58:01 +08:00
|
|
|
} else {
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/* Maybe the event was for the data stage? */
|
2009-08-28 05:35:53 +08:00
|
|
|
if (trb_comp_code != COMP_STOP_INVAL) {
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/* We didn't stop on a link TRB in the middle */
|
|
|
|
td->urb->actual_length =
|
|
|
|
td->urb->transfer_buffer_length -
|
|
|
|
TRB_LEN(event->transfer_len);
|
2009-07-28 03:03:36 +08:00
|
|
|
xhci_dbg(xhci, "Waiting for status stage event\n");
|
|
|
|
urb = NULL;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2009-04-28 10:58:01 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
2009-08-28 05:35:53 +08:00
|
|
|
switch (trb_comp_code) {
|
2009-04-28 10:58:50 +08:00
|
|
|
case COMP_SUCCESS:
|
|
|
|
/* Double check that the HW transferred everything. */
|
|
|
|
if (event_trb != td->last_trb) {
|
|
|
|
xhci_warn(xhci, "WARN Successful completion "
|
|
|
|
"on short TX\n");
|
|
|
|
if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
|
|
|
|
status = -EREMOTEIO;
|
|
|
|
else
|
|
|
|
status = 0;
|
|
|
|
} else {
|
2009-09-03 03:14:28 +08:00
|
|
|
if (usb_endpoint_xfer_bulk(&td->urb->ep->desc))
|
|
|
|
xhci_dbg(xhci, "Successful bulk "
|
|
|
|
"transfer!\n");
|
|
|
|
else
|
|
|
|
xhci_dbg(xhci, "Successful interrupt "
|
|
|
|
"transfer!\n");
|
2009-04-28 10:58:50 +08:00
|
|
|
status = 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case COMP_SHORT_TX:
|
|
|
|
if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
|
|
|
|
status = -EREMOTEIO;
|
|
|
|
else
|
|
|
|
status = 0;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* Others already handled above */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
dev_dbg(&td->urb->dev->dev,
|
|
|
|
"ep %#x - asked for %d bytes, "
|
|
|
|
"%d bytes untransferred\n",
|
|
|
|
td->urb->ep->desc.bEndpointAddress,
|
|
|
|
td->urb->transfer_buffer_length,
|
|
|
|
TRB_LEN(event->transfer_len));
|
|
|
|
/* Fast path - was this the last TRB in the TD for this URB? */
|
|
|
|
if (event_trb == td->last_trb) {
|
|
|
|
if (TRB_LEN(event->transfer_len) != 0) {
|
|
|
|
td->urb->actual_length =
|
|
|
|
td->urb->transfer_buffer_length -
|
|
|
|
TRB_LEN(event->transfer_len);
|
2009-08-28 05:36:24 +08:00
|
|
|
if (td->urb->transfer_buffer_length <
|
|
|
|
td->urb->actual_length) {
|
2009-04-28 10:58:50 +08:00
|
|
|
xhci_warn(xhci, "HC gave bad length "
|
|
|
|
"of %d bytes left\n",
|
|
|
|
TRB_LEN(event->transfer_len));
|
|
|
|
td->urb->actual_length = 0;
|
2009-08-29 05:28:18 +08:00
|
|
|
if (td->urb->transfer_flags &
|
|
|
|
URB_SHORT_NOT_OK)
|
|
|
|
status = -EREMOTEIO;
|
|
|
|
else
|
|
|
|
status = 0;
|
2009-04-28 10:58:50 +08:00
|
|
|
}
|
2009-07-28 03:05:21 +08:00
|
|
|
/* Don't overwrite a previously set error code */
|
|
|
|
if (status == -EINPROGRESS) {
|
|
|
|
if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
|
|
|
|
status = -EREMOTEIO;
|
|
|
|
else
|
|
|
|
status = 0;
|
|
|
|
}
|
2009-04-28 10:58:50 +08:00
|
|
|
} else {
|
|
|
|
td->urb->actual_length = td->urb->transfer_buffer_length;
|
|
|
|
/* Ignore a short packet completion if the
|
|
|
|
* untransferred length was zero.
|
|
|
|
*/
|
2009-07-28 03:05:21 +08:00
|
|
|
if (status == -EREMOTEIO)
|
|
|
|
status = 0;
|
2009-04-28 10:58:50 +08:00
|
|
|
}
|
|
|
|
} else {
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/* Slow path - walk the list, starting from the dequeue
|
|
|
|
* pointer, to get the actual length transferred.
|
2009-04-28 10:58:50 +08:00
|
|
|
*/
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
union xhci_trb *cur_trb;
|
|
|
|
struct xhci_segment *cur_seg;
|
|
|
|
|
2009-04-28 10:58:50 +08:00
|
|
|
td->urb->actual_length = 0;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
for (cur_trb = ep_ring->dequeue, cur_seg = ep_ring->deq_seg;
|
|
|
|
cur_trb != event_trb;
|
|
|
|
next_trb(xhci, ep_ring, &cur_seg, &cur_trb)) {
|
|
|
|
if (TRB_TYPE(cur_trb->generic.field[3]) != TRB_TR_NOOP &&
|
|
|
|
TRB_TYPE(cur_trb->generic.field[3]) != TRB_LINK)
|
|
|
|
td->urb->actual_length +=
|
|
|
|
TRB_LEN(cur_trb->generic.field[2]);
|
2009-04-28 10:58:50 +08:00
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/* If the ring didn't stop on a Link or No-op TRB, add
|
|
|
|
* in the actual bytes transferred from the Normal TRB
|
|
|
|
*/
|
2009-08-28 05:35:53 +08:00
|
|
|
if (trb_comp_code != COMP_STOP_INVAL)
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
td->urb->actual_length +=
|
|
|
|
TRB_LEN(cur_trb->generic.field[2]) -
|
|
|
|
TRB_LEN(event->transfer_len);
|
2009-04-28 10:58:50 +08:00
|
|
|
}
|
2009-04-28 10:58:01 +08:00
|
|
|
}
|
2009-08-28 05:35:53 +08:00
|
|
|
if (trb_comp_code == COMP_STOP_INVAL ||
|
|
|
|
trb_comp_code == COMP_STOP) {
|
2009-07-28 03:05:21 +08:00
|
|
|
/* The Endpoint Stop Command completion will take care of any
|
|
|
|
* stopped TDs. A stopped TD may be restarted, so don't update
|
|
|
|
* the ring dequeue pointer or take this TD off any lists yet.
|
|
|
|
*/
|
2009-09-05 01:53:09 +08:00
|
|
|
ep->stopped_td = td;
|
|
|
|
ep->stopped_trb = event_trb;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
} else {
|
2009-11-12 02:28:44 +08:00
|
|
|
if (trb_comp_code == COMP_STALL) {
|
2009-07-28 03:05:21 +08:00
|
|
|
/* The transfer is completed from the driver's
|
|
|
|
* perspective, but we need to issue a set dequeue
|
|
|
|
* command for this stalled endpoint to move the dequeue
|
|
|
|
* pointer past the TD. We can't do that here because
|
2009-11-12 02:28:44 +08:00
|
|
|
* the halt condition must be cleared first. Let the
|
|
|
|
* USB class driver clear the stall later.
|
2009-07-28 03:05:21 +08:00
|
|
|
*/
|
2009-09-05 01:53:09 +08:00
|
|
|
ep->stopped_td = td;
|
|
|
|
ep->stopped_trb = event_trb;
|
2009-11-12 02:28:44 +08:00
|
|
|
} else if (xhci_requires_manual_halt_cleanup(xhci,
|
|
|
|
ep_ctx, trb_comp_code)) {
|
|
|
|
/* Other types of errors halt the endpoint, but the
|
|
|
|
* class driver doesn't call usb_reset_endpoint() unless
|
|
|
|
* the error is -EPIPE. Clear the halted status in the
|
|
|
|
* xHCI hardware manually.
|
|
|
|
*/
|
|
|
|
xhci_cleanup_halted_endpoint(xhci,
|
|
|
|
slot_id, ep_index, td, event_trb);
|
2009-07-28 03:05:21 +08:00
|
|
|
} else {
|
|
|
|
/* Update ring dequeue pointer */
|
|
|
|
while (ep_ring->dequeue != td->last_trb)
|
|
|
|
inc_deq(xhci, ep_ring, false);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
inc_deq(xhci, ep_ring, false);
|
2009-07-28 03:05:21 +08:00
|
|
|
}
|
2009-04-28 10:58:50 +08:00
|
|
|
|
2009-08-08 05:04:52 +08:00
|
|
|
td_cleanup:
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/* Clean up the endpoint's TD list */
|
|
|
|
urb = td->urb;
|
2009-08-28 05:36:24 +08:00
|
|
|
/* Do one last check of the actual transfer length.
|
|
|
|
* If the host controller said we transferred more data than
|
|
|
|
* the buffer length, urb->actual_length will be a very big
|
|
|
|
* number (since it's unsigned). Play it safe and say we didn't
|
|
|
|
* transfer anything.
|
|
|
|
*/
|
|
|
|
if (urb->actual_length > urb->transfer_buffer_length) {
|
|
|
|
xhci_warn(xhci, "URB transfer length is wrong, "
|
|
|
|
"xHC issue? req. len = %u, "
|
|
|
|
"act. len = %u\n",
|
|
|
|
urb->transfer_buffer_length,
|
|
|
|
urb->actual_length);
|
|
|
|
urb->actual_length = 0;
|
2009-08-29 05:28:18 +08:00
|
|
|
if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
|
|
|
|
status = -EREMOTEIO;
|
|
|
|
else
|
|
|
|
status = 0;
|
2009-08-28 05:36:24 +08:00
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
list_del(&td->td_list);
|
|
|
|
/* Was this TD slated to be cancelled but completed anyway? */
|
USB: xhci: Handle URB cancel, complete and resubmit race.
In the old code, there was a race condition between the stop endpoint
command and the URB submission process. When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell. The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.
However, the following race condition could occur with the old code:
1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
(at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted. An
event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
canceled, decrements ep->cancels_pending to 0, and removes it from the to
be canceled list.
5. The event handler drops the lock and gives back the URB. The
completion handler requeues the URB (or a different driver enqueues a new
URB). This causes the endpoint's doorbell to be rung, since
ep->cancels_pending == 0. The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command. The
handler assumes the endpoint is stopped, but it isn't. It attempts to
move the dequeue pointer or change TDs to cancel the second URB, while the
hardware is actively accessing the endpoint ring.
To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING. When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet. The endpoint doorbell should not be rung when this
is set. Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell. ep->cancels_pending is eliminated, because it is no longer
used.
Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty. All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:55:52 +08:00
|
|
|
if (!list_empty(&td->cancelled_td_list))
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
list_del(&td->cancelled_td_list);
|
USB: xhci: Handle URB cancel, complete and resubmit race.
In the old code, there was a race condition between the stop endpoint
command and the URB submission process. When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell. The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.
However, the following race condition could occur with the old code:
1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
(at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted. An
event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
canceled, decrements ep->cancels_pending to 0, and removes it from the to
be canceled list.
5. The event handler drops the lock and gives back the URB. The
completion handler requeues the URB (or a different driver enqueues a new
URB). This causes the endpoint's doorbell to be rung, since
ep->cancels_pending == 0. The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command. The
handler assumes the endpoint is stopped, but it isn't. It attempts to
move the dequeue pointer or change TDs to cancel the second URB, while the
hardware is actively accessing the endpoint ring.
To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING. When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet. The endpoint doorbell should not be rung when this
is set. Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell. ep->cancels_pending is eliminated, because it is no longer
used.
Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty. All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:55:52 +08:00
|
|
|
|
2009-08-08 05:04:52 +08:00
|
|
|
/* Leave the TD around for the reset endpoint function to use
|
|
|
|
* (but only if it's not a control endpoint, since we already
|
|
|
|
* queued the Set TR dequeue pointer command for stalled
|
|
|
|
* control endpoints).
|
|
|
|
*/
|
|
|
|
if (usb_endpoint_xfer_control(&urb->ep->desc) ||
|
2009-08-28 05:36:03 +08:00
|
|
|
(trb_comp_code != COMP_STALL &&
|
|
|
|
trb_comp_code != COMP_BABBLE)) {
|
2009-07-28 03:05:21 +08:00
|
|
|
kfree(td);
|
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
urb->hcpriv = NULL;
|
|
|
|
}
|
2009-04-28 10:58:01 +08:00
|
|
|
cleanup:
|
|
|
|
inc_deq(xhci, xhci->event_ring, true);
|
2009-04-30 10:05:20 +08:00
|
|
|
xhci_set_hc_event_deq(xhci);
|
2009-04-28 10:58:01 +08:00
|
|
|
|
2009-04-28 10:58:50 +08:00
|
|
|
/* FIXME for multi-TD URBs (who have buffers bigger than 64MB) */
|
2009-04-28 10:58:01 +08:00
|
|
|
if (urb) {
|
|
|
|
usb_hcd_unlink_urb_from_ep(xhci_to_hcd(xhci), urb);
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "Giveback URB %p, len = %d, status = %d\n",
|
2009-08-28 05:36:14 +08:00
|
|
|
urb, urb->actual_length, status);
|
2009-04-28 10:58:01 +08:00
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
usb_hcd_giveback_urb(xhci_to_hcd(xhci), urb, status);
|
|
|
|
spin_lock(&xhci->lock);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:57:12 +08:00
|
|
|
/*
|
|
|
|
* This function handles all OS-owned events on the event ring. It may drop
|
|
|
|
* xhci->lock between event processing (e.g. to pass up port status changes).
|
|
|
|
*/
|
2009-04-30 10:02:47 +08:00
|
|
|
void xhci_handle_event(struct xhci_hcd *xhci)
|
2009-04-28 10:53:56 +08:00
|
|
|
{
|
|
|
|
union xhci_trb *event;
|
2009-04-28 10:57:12 +08:00
|
|
|
int update_ptrs = 1;
|
2009-04-28 10:58:01 +08:00
|
|
|
int ret;
|
2009-04-28 10:53:56 +08:00
|
|
|
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "In %s\n", __func__);
|
2009-04-28 10:53:56 +08:00
|
|
|
if (!xhci->event_ring || !xhci->event_ring->dequeue) {
|
|
|
|
xhci->error_bitmask |= 1 << 1;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
event = xhci->event_ring->dequeue;
|
|
|
|
/* Does the HC or OS own the TRB? */
|
|
|
|
if ((event->event_cmd.flags & TRB_CYCLE) !=
|
|
|
|
xhci->event_ring->cycle_state) {
|
|
|
|
xhci->error_bitmask |= 1 << 2;
|
|
|
|
return;
|
|
|
|
}
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - OS owns TRB\n", __func__);
|
2009-04-28 10:53:56 +08:00
|
|
|
|
2009-04-28 10:57:12 +08:00
|
|
|
/* FIXME: Handle more event types. */
|
2009-04-28 10:53:56 +08:00
|
|
|
switch ((event->event_cmd.flags & TRB_TYPE_BITMASK)) {
|
|
|
|
case TRB_TYPE(TRB_COMPLETION):
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - calling handle_cmd_completion\n", __func__);
|
2009-04-28 10:53:56 +08:00
|
|
|
handle_cmd_completion(xhci, &event->event_cmd);
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - returned from handle_cmd_completion\n", __func__);
|
2009-04-28 10:53:56 +08:00
|
|
|
break;
|
2009-04-28 10:57:12 +08:00
|
|
|
case TRB_TYPE(TRB_PORT_STATUS):
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - calling handle_port_status\n", __func__);
|
2009-04-28 10:57:12 +08:00
|
|
|
handle_port_status(xhci, event);
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - returned from handle_port_status\n", __func__);
|
2009-04-28 10:57:12 +08:00
|
|
|
update_ptrs = 0;
|
|
|
|
break;
|
2009-04-28 10:58:01 +08:00
|
|
|
case TRB_TYPE(TRB_TRANSFER):
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - calling handle_tx_event\n", __func__);
|
2009-04-28 10:58:01 +08:00
|
|
|
ret = handle_tx_event(xhci, &event->trans_event);
|
2009-07-28 03:03:46 +08:00
|
|
|
xhci_dbg(xhci, "%s - returned from handle_tx_event\n", __func__);
|
2009-04-28 10:58:01 +08:00
|
|
|
if (ret < 0)
|
|
|
|
xhci->error_bitmask |= 1 << 9;
|
|
|
|
else
|
|
|
|
update_ptrs = 0;
|
|
|
|
break;
|
2009-04-28 10:53:56 +08:00
|
|
|
default:
|
|
|
|
xhci->error_bitmask |= 1 << 3;
|
|
|
|
}
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
/* Any of the above functions may drop and re-acquire the lock, so check
|
|
|
|
* to make sure a watchdog timer didn't mark the host as non-responsive.
|
|
|
|
*/
|
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING) {
|
|
|
|
xhci_dbg(xhci, "xHCI host dying, returning from "
|
|
|
|
"event handler.\n");
|
|
|
|
return;
|
|
|
|
}
|
2009-04-28 10:53:56 +08:00
|
|
|
|
2009-04-28 10:57:12 +08:00
|
|
|
if (update_ptrs) {
|
|
|
|
/* Update SW and HC event ring dequeue pointer */
|
|
|
|
inc_deq(xhci, xhci->event_ring, true);
|
2009-04-30 10:05:20 +08:00
|
|
|
xhci_set_hc_event_deq(xhci);
|
2009-04-28 10:57:12 +08:00
|
|
|
}
|
2009-04-28 10:53:56 +08:00
|
|
|
/* Are there more items on the event ring? */
|
2009-04-30 10:02:47 +08:00
|
|
|
xhci_handle_event(xhci);
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
2009-04-28 10:58:01 +08:00
|
|
|
/**** Endpoint Ring Operations ****/
|
|
|
|
|
2009-04-28 10:53:56 +08:00
|
|
|
/*
|
|
|
|
* Generic function for queueing a TRB on a ring.
|
|
|
|
* The caller must have checked to make sure there's room on the ring.
|
|
|
|
*/
|
|
|
|
static void queue_trb(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
|
|
|
bool consumer,
|
|
|
|
u32 field1, u32 field2, u32 field3, u32 field4)
|
|
|
|
{
|
|
|
|
struct xhci_generic_trb *trb;
|
|
|
|
|
|
|
|
trb = &ring->enqueue->generic;
|
|
|
|
trb->field[0] = field1;
|
|
|
|
trb->field[1] = field2;
|
|
|
|
trb->field[2] = field3;
|
|
|
|
trb->field[3] = field4;
|
|
|
|
inc_enq(xhci, ring, consumer);
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:58:01 +08:00
|
|
|
/*
|
|
|
|
* Does various checks on the endpoint ring, and makes it ready to queue num_trbs.
|
|
|
|
* FIXME allocate segments if the ring is full.
|
|
|
|
*/
|
|
|
|
static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
|
|
|
|
u32 ep_state, unsigned int num_trbs, gfp_t mem_flags)
|
|
|
|
{
|
|
|
|
/* Make sure the endpoint has been added to xHC schedule */
|
|
|
|
xhci_dbg(xhci, "Endpoint state = 0x%x\n", ep_state);
|
|
|
|
switch (ep_state) {
|
|
|
|
case EP_STATE_DISABLED:
|
|
|
|
/*
|
|
|
|
* USB core changed config/interfaces without notifying us,
|
|
|
|
* or hardware is reporting the wrong state.
|
|
|
|
*/
|
|
|
|
xhci_warn(xhci, "WARN urb submitted to disabled ep\n");
|
|
|
|
return -ENOENT;
|
|
|
|
case EP_STATE_ERROR:
|
2009-07-28 03:05:21 +08:00
|
|
|
xhci_warn(xhci, "WARN waiting for error on ep to be cleared\n");
|
2009-04-28 10:58:01 +08:00
|
|
|
/* FIXME event handling code for error needs to clear it */
|
|
|
|
/* XXX not sure if this should be -ENOENT or not */
|
|
|
|
return -EINVAL;
|
2009-07-28 03:05:21 +08:00
|
|
|
case EP_STATE_HALTED:
|
|
|
|
xhci_dbg(xhci, "WARN halted endpoint, queueing URB anyway.\n");
|
2009-04-28 10:58:01 +08:00
|
|
|
case EP_STATE_STOPPED:
|
|
|
|
case EP_STATE_RUNNING:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
xhci_err(xhci, "ERROR unknown endpoint state for ep\n");
|
|
|
|
/*
|
|
|
|
* FIXME issue Configure Endpoint command to try to get the HC
|
|
|
|
* back into a known state.
|
|
|
|
*/
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
if (!room_on_ring(xhci, ep_ring, num_trbs)) {
|
|
|
|
/* FIXME allocate more room */
|
|
|
|
xhci_err(xhci, "ERROR no room on ep ring\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
static int prepare_transfer(struct xhci_hcd *xhci,
|
2009-04-28 10:58:01 +08:00
|
|
|
struct xhci_virt_device *xdev,
|
|
|
|
unsigned int ep_index,
|
|
|
|
unsigned int num_trbs,
|
|
|
|
struct urb *urb,
|
|
|
|
struct xhci_td **td,
|
|
|
|
gfp_t mem_flags)
|
|
|
|
{
|
|
|
|
int ret;
|
2009-07-28 03:05:15 +08:00
|
|
|
struct xhci_ep_ctx *ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
2009-09-05 01:53:09 +08:00
|
|
|
ret = prepare_ring(xhci, xdev->eps[ep_index].ring,
|
2009-07-28 03:05:15 +08:00
|
|
|
ep_ctx->ep_info & EP_STATE_MASK,
|
2009-04-28 10:58:01 +08:00
|
|
|
num_trbs, mem_flags);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
*td = kzalloc(sizeof(struct xhci_td), mem_flags);
|
|
|
|
if (!*td)
|
|
|
|
return -ENOMEM;
|
|
|
|
INIT_LIST_HEAD(&(*td)->td_list);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
INIT_LIST_HEAD(&(*td)->cancelled_td_list);
|
2009-04-28 10:58:01 +08:00
|
|
|
|
|
|
|
ret = usb_hcd_link_urb_to_ep(xhci_to_hcd(xhci), urb);
|
|
|
|
if (unlikely(ret)) {
|
|
|
|
kfree(*td);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
(*td)->urb = urb;
|
|
|
|
urb->hcpriv = (void *) (*td);
|
|
|
|
/* Add this TD to the tail of the endpoint ring's TD list */
|
2009-09-05 01:53:09 +08:00
|
|
|
list_add_tail(&(*td)->td_list, &xdev->eps[ep_index].ring->td_list);
|
|
|
|
(*td)->start_seg = xdev->eps[ep_index].ring->enq_seg;
|
|
|
|
(*td)->first_trb = xdev->eps[ep_index].ring->enqueue;
|
2009-04-28 10:58:01 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
static unsigned int count_sg_trbs_needed(struct xhci_hcd *xhci, struct urb *urb)
|
2009-04-28 10:59:19 +08:00
|
|
|
{
|
|
|
|
int num_sgs, num_trbs, running_total, temp, i;
|
|
|
|
struct scatterlist *sg;
|
|
|
|
|
|
|
|
sg = NULL;
|
|
|
|
num_sgs = urb->num_sgs;
|
|
|
|
temp = urb->transfer_buffer_length;
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "count sg list trbs: \n");
|
|
|
|
num_trbs = 0;
|
|
|
|
for_each_sg(urb->sg->sg, sg, num_sgs, i) {
|
|
|
|
unsigned int previous_total_trbs = num_trbs;
|
|
|
|
unsigned int len = sg_dma_len(sg);
|
|
|
|
|
|
|
|
/* Scatter gather list entries may cross 64KB boundaries */
|
|
|
|
running_total = TRB_MAX_BUFF_SIZE -
|
|
|
|
(sg_dma_address(sg) & ((1 << TRB_MAX_BUFF_SHIFT) - 1));
|
|
|
|
if (running_total != 0)
|
|
|
|
num_trbs++;
|
|
|
|
|
|
|
|
/* How many more 64KB chunks to transfer, how many more TRBs? */
|
|
|
|
while (running_total < sg_dma_len(sg)) {
|
|
|
|
num_trbs++;
|
|
|
|
running_total += TRB_MAX_BUFF_SIZE;
|
|
|
|
}
|
2009-04-30 10:14:08 +08:00
|
|
|
xhci_dbg(xhci, " sg #%d: dma = %#llx, len = %#x (%d), num_trbs = %d\n",
|
|
|
|
i, (unsigned long long)sg_dma_address(sg),
|
|
|
|
len, len, num_trbs - previous_total_trbs);
|
2009-04-28 10:59:19 +08:00
|
|
|
|
|
|
|
len = min_t(int, len, temp);
|
|
|
|
temp -= len;
|
|
|
|
if (temp == 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
xhci_dbg(xhci, "\n");
|
|
|
|
if (!in_interrupt())
|
|
|
|
dev_dbg(&urb->dev->dev, "ep %#x - urb len = %d, sglist used, num_trbs = %d\n",
|
|
|
|
urb->ep->desc.bEndpointAddress,
|
|
|
|
urb->transfer_buffer_length,
|
|
|
|
num_trbs);
|
|
|
|
return num_trbs;
|
|
|
|
}
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
static void check_trb_math(struct urb *urb, int num_trbs, int running_total)
|
2009-04-28 10:59:19 +08:00
|
|
|
{
|
|
|
|
if (num_trbs != 0)
|
|
|
|
dev_dbg(&urb->dev->dev, "%s - ep %#x - Miscalculated number of "
|
|
|
|
"TRBs, %d left\n", __func__,
|
|
|
|
urb->ep->desc.bEndpointAddress, num_trbs);
|
|
|
|
if (running_total != urb->transfer_buffer_length)
|
|
|
|
dev_dbg(&urb->dev->dev, "%s - ep %#x - Miscalculated tx length, "
|
|
|
|
"queued %#x (%d), asked for %#x (%d)\n",
|
|
|
|
__func__,
|
|
|
|
urb->ep->desc.bEndpointAddress,
|
|
|
|
running_total, running_total,
|
|
|
|
urb->transfer_buffer_length,
|
|
|
|
urb->transfer_buffer_length);
|
|
|
|
}
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
static void giveback_first_trb(struct xhci_hcd *xhci, int slot_id,
|
2009-04-28 10:59:19 +08:00
|
|
|
unsigned int ep_index, int start_cycle,
|
|
|
|
struct xhci_generic_trb *start_trb, struct xhci_td *td)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Pass all the TRBs to the hardware at once and make sure this write
|
|
|
|
* isn't reordered.
|
|
|
|
*/
|
|
|
|
wmb();
|
|
|
|
start_trb->field[3] |= start_cycle;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
ring_ep_doorbell(xhci, slot_id, ep_index);
|
2009-04-28 10:59:19 +08:00
|
|
|
}
|
|
|
|
|
2009-09-03 03:14:28 +08:00
|
|
|
/*
|
|
|
|
* xHCI uses normal TRBs for both bulk and interrupt. When the interrupt
|
|
|
|
* endpoint is to be serviced, the xHC will consume (at most) one TD. A TD
|
|
|
|
* (comprised of sg list entries) can take several service intervals to
|
|
|
|
* transmit.
|
|
|
|
*/
|
|
|
|
int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
|
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index)
|
|
|
|
{
|
|
|
|
struct xhci_ep_ctx *ep_ctx = xhci_get_ep_ctx(xhci,
|
|
|
|
xhci->devs[slot_id]->out_ctx, ep_index);
|
|
|
|
int xhci_interval;
|
|
|
|
int ep_interval;
|
|
|
|
|
|
|
|
xhci_interval = EP_INTERVAL_TO_UFRAMES(ep_ctx->ep_info);
|
|
|
|
ep_interval = urb->interval;
|
|
|
|
/* Convert to microframes */
|
|
|
|
if (urb->dev->speed == USB_SPEED_LOW ||
|
|
|
|
urb->dev->speed == USB_SPEED_FULL)
|
|
|
|
ep_interval *= 8;
|
|
|
|
/* FIXME change this to a warning and a suggestion to use the new API
|
|
|
|
* to set the polling interval (once the API is added).
|
|
|
|
*/
|
|
|
|
if (xhci_interval != ep_interval) {
|
|
|
|
if (!printk_ratelimit())
|
|
|
|
dev_dbg(&urb->dev->dev, "Driver uses different interval"
|
|
|
|
" (%d microframe%s) than xHCI "
|
|
|
|
"(%d microframe%s)\n",
|
|
|
|
ep_interval,
|
|
|
|
ep_interval == 1 ? "" : "s",
|
|
|
|
xhci_interval,
|
|
|
|
xhci_interval == 1 ? "" : "s");
|
|
|
|
urb->interval = xhci_interval;
|
|
|
|
/* Convert back to frames for LS/FS devices */
|
|
|
|
if (urb->dev->speed == USB_SPEED_LOW ||
|
|
|
|
urb->dev->speed == USB_SPEED_FULL)
|
|
|
|
urb->interval /= 8;
|
|
|
|
}
|
|
|
|
return xhci_queue_bulk_tx(xhci, GFP_ATOMIC, urb, slot_id, ep_index);
|
|
|
|
}
|
|
|
|
|
2009-11-12 02:28:30 +08:00
|
|
|
/*
|
|
|
|
* The TD size is the number of bytes remaining in the TD (including this TRB),
|
|
|
|
* right shifted by 10.
|
|
|
|
* It must fit in bits 21:17, so it can't be bigger than 31.
|
|
|
|
*/
|
|
|
|
static u32 xhci_td_remainder(unsigned int remainder)
|
|
|
|
{
|
|
|
|
u32 max = (1 << (21 - 17 + 1)) - 1;
|
|
|
|
|
|
|
|
if ((remainder >> 10) >= max)
|
|
|
|
return max << 17;
|
|
|
|
else
|
|
|
|
return (remainder >> 10) << 17;
|
|
|
|
}
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
static int queue_bulk_sg_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
|
2009-04-28 10:59:19 +08:00
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
unsigned int num_trbs;
|
|
|
|
struct xhci_td *td;
|
|
|
|
struct scatterlist *sg;
|
|
|
|
int num_sgs;
|
|
|
|
int trb_buff_len, this_sg_len, running_total;
|
|
|
|
bool first_trb;
|
|
|
|
u64 addr;
|
|
|
|
|
|
|
|
struct xhci_generic_trb *start_trb;
|
|
|
|
int start_cycle;
|
|
|
|
|
2009-09-05 01:53:09 +08:00
|
|
|
ep_ring = xhci->devs[slot_id]->eps[ep_index].ring;
|
2009-04-28 10:59:19 +08:00
|
|
|
num_trbs = count_sg_trbs_needed(xhci, urb);
|
|
|
|
num_sgs = urb->num_sgs;
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
trb_buff_len = prepare_transfer(xhci, xhci->devs[slot_id],
|
2009-04-28 10:59:19 +08:00
|
|
|
ep_index, num_trbs, urb, &td, mem_flags);
|
|
|
|
if (trb_buff_len < 0)
|
|
|
|
return trb_buff_len;
|
|
|
|
/*
|
|
|
|
* Don't give the first TRB to the hardware (by toggling the cycle bit)
|
|
|
|
* until we've finished creating all the other TRBs. The ring's cycle
|
|
|
|
* state may change as we enqueue the other TRBs, so save it too.
|
|
|
|
*/
|
|
|
|
start_trb = &ep_ring->enqueue->generic;
|
|
|
|
start_cycle = ep_ring->cycle_state;
|
|
|
|
|
|
|
|
running_total = 0;
|
|
|
|
/*
|
|
|
|
* How much data is in the first TRB?
|
|
|
|
*
|
|
|
|
* There are three forces at work for TRB buffer pointers and lengths:
|
|
|
|
* 1. We don't want to walk off the end of this sg-list entry buffer.
|
|
|
|
* 2. The transfer length that the driver requested may be smaller than
|
|
|
|
* the amount of memory allocated for this scatter-gather list.
|
|
|
|
* 3. TRBs buffers can't cross 64KB boundaries.
|
|
|
|
*/
|
|
|
|
sg = urb->sg->sg;
|
|
|
|
addr = (u64) sg_dma_address(sg);
|
|
|
|
this_sg_len = sg_dma_len(sg);
|
|
|
|
trb_buff_len = TRB_MAX_BUFF_SIZE -
|
|
|
|
(addr & ((1 << TRB_MAX_BUFF_SHIFT) - 1));
|
|
|
|
trb_buff_len = min_t(int, trb_buff_len, this_sg_len);
|
|
|
|
if (trb_buff_len > urb->transfer_buffer_length)
|
|
|
|
trb_buff_len = urb->transfer_buffer_length;
|
|
|
|
xhci_dbg(xhci, "First length to xfer from 1st sglist entry = %u\n",
|
|
|
|
trb_buff_len);
|
|
|
|
|
|
|
|
first_trb = true;
|
|
|
|
/* Queue the first TRB, even if it's zero-length */
|
|
|
|
do {
|
|
|
|
u32 field = 0;
|
2009-07-28 03:03:07 +08:00
|
|
|
u32 length_field = 0;
|
2009-11-12 02:28:30 +08:00
|
|
|
u32 remainder = 0;
|
2009-04-28 10:59:19 +08:00
|
|
|
|
|
|
|
/* Don't change the cycle bit of the first TRB until later */
|
|
|
|
if (first_trb)
|
|
|
|
first_trb = false;
|
|
|
|
else
|
|
|
|
field |= ep_ring->cycle_state;
|
|
|
|
|
|
|
|
/* Chain all the TRBs together; clear the chain bit in the last
|
|
|
|
* TRB to indicate it's the last TRB in the chain.
|
|
|
|
*/
|
|
|
|
if (num_trbs > 1) {
|
|
|
|
field |= TRB_CHAIN;
|
|
|
|
} else {
|
|
|
|
/* FIXME - add check for ZERO_PACKET flag before this */
|
|
|
|
td->last_trb = ep_ring->enqueue;
|
|
|
|
field |= TRB_IOC;
|
|
|
|
}
|
|
|
|
xhci_dbg(xhci, " sg entry: dma = %#x, len = %#x (%d), "
|
|
|
|
"64KB boundary at %#x, end dma = %#x\n",
|
|
|
|
(unsigned int) addr, trb_buff_len, trb_buff_len,
|
|
|
|
(unsigned int) (addr + TRB_MAX_BUFF_SIZE) & ~(TRB_MAX_BUFF_SIZE - 1),
|
|
|
|
(unsigned int) addr + trb_buff_len);
|
|
|
|
if (TRB_MAX_BUFF_SIZE -
|
|
|
|
(addr & ((1 << TRB_MAX_BUFF_SHIFT) - 1)) < trb_buff_len) {
|
|
|
|
xhci_warn(xhci, "WARN: sg dma xfer crosses 64KB boundaries!\n");
|
|
|
|
xhci_dbg(xhci, "Next boundary at %#x, end dma = %#x\n",
|
|
|
|
(unsigned int) (addr + TRB_MAX_BUFF_SIZE) & ~(TRB_MAX_BUFF_SIZE - 1),
|
|
|
|
(unsigned int) addr + trb_buff_len);
|
|
|
|
}
|
2009-11-12 02:28:30 +08:00
|
|
|
remainder = xhci_td_remainder(urb->transfer_buffer_length -
|
|
|
|
running_total) ;
|
2009-07-28 03:03:07 +08:00
|
|
|
length_field = TRB_LEN(trb_buff_len) |
|
2009-11-12 02:28:30 +08:00
|
|
|
remainder |
|
2009-07-28 03:03:07 +08:00
|
|
|
TRB_INTR_TARGET(0);
|
2009-04-28 10:59:19 +08:00
|
|
|
queue_trb(xhci, ep_ring, false,
|
2009-07-28 03:03:31 +08:00
|
|
|
lower_32_bits(addr),
|
|
|
|
upper_32_bits(addr),
|
2009-07-28 03:03:07 +08:00
|
|
|
length_field,
|
2009-04-28 10:59:19 +08:00
|
|
|
/* We always want to know if the TRB was short,
|
|
|
|
* or we won't get an event when it completes.
|
|
|
|
* (Unless we use event data TRBs, which are a
|
|
|
|
* waste of space and HC resources.)
|
|
|
|
*/
|
|
|
|
field | TRB_ISP | TRB_TYPE(TRB_NORMAL));
|
|
|
|
--num_trbs;
|
|
|
|
running_total += trb_buff_len;
|
|
|
|
|
|
|
|
/* Calculate length for next transfer --
|
|
|
|
* Are we done queueing all the TRBs for this sg entry?
|
|
|
|
*/
|
|
|
|
this_sg_len -= trb_buff_len;
|
|
|
|
if (this_sg_len == 0) {
|
|
|
|
--num_sgs;
|
|
|
|
if (num_sgs == 0)
|
|
|
|
break;
|
|
|
|
sg = sg_next(sg);
|
|
|
|
addr = (u64) sg_dma_address(sg);
|
|
|
|
this_sg_len = sg_dma_len(sg);
|
|
|
|
} else {
|
|
|
|
addr += trb_buff_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
trb_buff_len = TRB_MAX_BUFF_SIZE -
|
|
|
|
(addr & ((1 << TRB_MAX_BUFF_SHIFT) - 1));
|
|
|
|
trb_buff_len = min_t(int, trb_buff_len, this_sg_len);
|
|
|
|
if (running_total + trb_buff_len > urb->transfer_buffer_length)
|
|
|
|
trb_buff_len =
|
|
|
|
urb->transfer_buffer_length - running_total;
|
|
|
|
} while (running_total < urb->transfer_buffer_length);
|
|
|
|
|
|
|
|
check_trb_math(urb, num_trbs, running_total);
|
|
|
|
giveback_first_trb(xhci, slot_id, ep_index, start_cycle, start_trb, td);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:58:50 +08:00
|
|
|
/* This is very similar to what ehci-q.c qtd_fill() does */
|
2009-04-30 10:05:20 +08:00
|
|
|
int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
|
2009-04-28 10:58:50 +08:00
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
struct xhci_td *td;
|
|
|
|
int num_trbs;
|
|
|
|
struct xhci_generic_trb *start_trb;
|
|
|
|
bool first_trb;
|
|
|
|
int start_cycle;
|
2009-07-28 03:03:07 +08:00
|
|
|
u32 field, length_field;
|
2009-04-28 10:58:50 +08:00
|
|
|
|
|
|
|
int running_total, trb_buff_len, ret;
|
|
|
|
u64 addr;
|
|
|
|
|
2009-04-28 10:59:19 +08:00
|
|
|
if (urb->sg)
|
|
|
|
return queue_bulk_sg_tx(xhci, mem_flags, urb, slot_id, ep_index);
|
|
|
|
|
2009-09-05 01:53:09 +08:00
|
|
|
ep_ring = xhci->devs[slot_id]->eps[ep_index].ring;
|
2009-04-28 10:58:50 +08:00
|
|
|
|
|
|
|
num_trbs = 0;
|
|
|
|
/* How much data is (potentially) left before the 64KB boundary? */
|
|
|
|
running_total = TRB_MAX_BUFF_SIZE -
|
|
|
|
(urb->transfer_dma & ((1 << TRB_MAX_BUFF_SHIFT) - 1));
|
|
|
|
|
|
|
|
/* If there's some data on this 64KB chunk, or we have to send a
|
|
|
|
* zero-length transfer, we need at least one TRB
|
|
|
|
*/
|
|
|
|
if (running_total != 0 || urb->transfer_buffer_length == 0)
|
|
|
|
num_trbs++;
|
|
|
|
/* How many more 64KB chunks to transfer, how many more TRBs? */
|
|
|
|
while (running_total < urb->transfer_buffer_length) {
|
|
|
|
num_trbs++;
|
|
|
|
running_total += TRB_MAX_BUFF_SIZE;
|
|
|
|
}
|
|
|
|
/* FIXME: this doesn't deal with URB_ZERO_PACKET - need one more */
|
|
|
|
|
|
|
|
if (!in_interrupt())
|
2009-04-30 10:14:08 +08:00
|
|
|
dev_dbg(&urb->dev->dev, "ep %#x - urb len = %#x (%d), addr = %#llx, num_trbs = %d\n",
|
2009-04-28 10:58:50 +08:00
|
|
|
urb->ep->desc.bEndpointAddress,
|
2009-04-28 10:59:19 +08:00
|
|
|
urb->transfer_buffer_length,
|
|
|
|
urb->transfer_buffer_length,
|
2009-04-30 10:14:08 +08:00
|
|
|
(unsigned long long)urb->transfer_dma,
|
2009-04-28 10:58:50 +08:00
|
|
|
num_trbs);
|
2009-04-28 10:59:19 +08:00
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
ret = prepare_transfer(xhci, xhci->devs[slot_id], ep_index,
|
2009-04-28 10:58:50 +08:00
|
|
|
num_trbs, urb, &td, mem_flags);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't give the first TRB to the hardware (by toggling the cycle bit)
|
|
|
|
* until we've finished creating all the other TRBs. The ring's cycle
|
|
|
|
* state may change as we enqueue the other TRBs, so save it too.
|
|
|
|
*/
|
|
|
|
start_trb = &ep_ring->enqueue->generic;
|
|
|
|
start_cycle = ep_ring->cycle_state;
|
|
|
|
|
|
|
|
running_total = 0;
|
|
|
|
/* How much data is in the first TRB? */
|
|
|
|
addr = (u64) urb->transfer_dma;
|
|
|
|
trb_buff_len = TRB_MAX_BUFF_SIZE -
|
|
|
|
(urb->transfer_dma & ((1 << TRB_MAX_BUFF_SHIFT) - 1));
|
|
|
|
if (urb->transfer_buffer_length < trb_buff_len)
|
|
|
|
trb_buff_len = urb->transfer_buffer_length;
|
|
|
|
|
|
|
|
first_trb = true;
|
|
|
|
|
|
|
|
/* Queue the first TRB, even if it's zero-length */
|
|
|
|
do {
|
2009-11-12 02:28:30 +08:00
|
|
|
u32 remainder = 0;
|
2009-04-28 10:58:50 +08:00
|
|
|
field = 0;
|
|
|
|
|
|
|
|
/* Don't change the cycle bit of the first TRB until later */
|
|
|
|
if (first_trb)
|
|
|
|
first_trb = false;
|
|
|
|
else
|
|
|
|
field |= ep_ring->cycle_state;
|
|
|
|
|
|
|
|
/* Chain all the TRBs together; clear the chain bit in the last
|
|
|
|
* TRB to indicate it's the last TRB in the chain.
|
|
|
|
*/
|
|
|
|
if (num_trbs > 1) {
|
|
|
|
field |= TRB_CHAIN;
|
|
|
|
} else {
|
|
|
|
/* FIXME - add check for ZERO_PACKET flag before this */
|
|
|
|
td->last_trb = ep_ring->enqueue;
|
|
|
|
field |= TRB_IOC;
|
|
|
|
}
|
2009-11-12 02:28:30 +08:00
|
|
|
remainder = xhci_td_remainder(urb->transfer_buffer_length -
|
|
|
|
running_total);
|
2009-07-28 03:03:07 +08:00
|
|
|
length_field = TRB_LEN(trb_buff_len) |
|
2009-11-12 02:28:30 +08:00
|
|
|
remainder |
|
2009-07-28 03:03:07 +08:00
|
|
|
TRB_INTR_TARGET(0);
|
2009-04-28 10:58:50 +08:00
|
|
|
queue_trb(xhci, ep_ring, false,
|
2009-07-28 03:03:31 +08:00
|
|
|
lower_32_bits(addr),
|
|
|
|
upper_32_bits(addr),
|
2009-07-28 03:03:07 +08:00
|
|
|
length_field,
|
2009-04-28 10:58:50 +08:00
|
|
|
/* We always want to know if the TRB was short,
|
|
|
|
* or we won't get an event when it completes.
|
|
|
|
* (Unless we use event data TRBs, which are a
|
|
|
|
* waste of space and HC resources.)
|
|
|
|
*/
|
|
|
|
field | TRB_ISP | TRB_TYPE(TRB_NORMAL));
|
|
|
|
--num_trbs;
|
|
|
|
running_total += trb_buff_len;
|
|
|
|
|
|
|
|
/* Calculate length for next transfer */
|
|
|
|
addr += trb_buff_len;
|
|
|
|
trb_buff_len = urb->transfer_buffer_length - running_total;
|
|
|
|
if (trb_buff_len > TRB_MAX_BUFF_SIZE)
|
|
|
|
trb_buff_len = TRB_MAX_BUFF_SIZE;
|
|
|
|
} while (running_total < urb->transfer_buffer_length);
|
|
|
|
|
2009-04-28 10:59:19 +08:00
|
|
|
check_trb_math(urb, num_trbs, running_total);
|
|
|
|
giveback_first_trb(xhci, slot_id, ep_index, start_cycle, start_trb, td);
|
2009-04-28 10:58:50 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:58:01 +08:00
|
|
|
/* Caller must have locked xhci->lock */
|
2009-04-30 10:05:20 +08:00
|
|
|
int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
|
2009-04-28 10:58:01 +08:00
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
int num_trbs;
|
|
|
|
int ret;
|
|
|
|
struct usb_ctrlrequest *setup;
|
|
|
|
struct xhci_generic_trb *start_trb;
|
|
|
|
int start_cycle;
|
2009-07-28 03:03:07 +08:00
|
|
|
u32 field, length_field;
|
2009-04-28 10:58:01 +08:00
|
|
|
struct xhci_td *td;
|
|
|
|
|
2009-09-05 01:53:09 +08:00
|
|
|
ep_ring = xhci->devs[slot_id]->eps[ep_index].ring;
|
2009-04-28 10:58:01 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Need to copy setup packet into setup TRB, so we can't use the setup
|
|
|
|
* DMA address.
|
|
|
|
*/
|
|
|
|
if (!urb->setup_packet)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!in_interrupt())
|
|
|
|
xhci_dbg(xhci, "Queueing ctrl tx for slot id %d, ep %d\n",
|
|
|
|
slot_id, ep_index);
|
|
|
|
/* 1 TRB for setup, 1 for status */
|
|
|
|
num_trbs = 2;
|
|
|
|
/*
|
|
|
|
* Don't need to check if we need additional event data and normal TRBs,
|
|
|
|
* since data in control transfers will never get bigger than 16MB
|
|
|
|
* XXX: can we get a buffer that crosses 64KB boundaries?
|
|
|
|
*/
|
|
|
|
if (urb->transfer_buffer_length > 0)
|
|
|
|
num_trbs++;
|
2009-04-30 10:05:20 +08:00
|
|
|
ret = prepare_transfer(xhci, xhci->devs[slot_id], ep_index, num_trbs,
|
2009-04-28 10:58:01 +08:00
|
|
|
urb, &td, mem_flags);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't give the first TRB to the hardware (by toggling the cycle bit)
|
|
|
|
* until we've finished creating all the other TRBs. The ring's cycle
|
|
|
|
* state may change as we enqueue the other TRBs, so save it too.
|
|
|
|
*/
|
|
|
|
start_trb = &ep_ring->enqueue->generic;
|
|
|
|
start_cycle = ep_ring->cycle_state;
|
|
|
|
|
|
|
|
/* Queue setup TRB - see section 6.4.1.2.1 */
|
|
|
|
/* FIXME better way to translate setup_packet into two u32 fields? */
|
|
|
|
setup = (struct usb_ctrlrequest *) urb->setup_packet;
|
|
|
|
queue_trb(xhci, ep_ring, false,
|
|
|
|
/* FIXME endianness is probably going to bite my ass here. */
|
|
|
|
setup->bRequestType | setup->bRequest << 8 | setup->wValue << 16,
|
|
|
|
setup->wIndex | setup->wLength << 16,
|
|
|
|
TRB_LEN(8) | TRB_INTR_TARGET(0),
|
|
|
|
/* Immediate data in pointer */
|
|
|
|
TRB_IDT | TRB_TYPE(TRB_SETUP));
|
|
|
|
|
|
|
|
/* If there's data, queue data TRBs */
|
|
|
|
field = 0;
|
2009-07-28 03:03:07 +08:00
|
|
|
length_field = TRB_LEN(urb->transfer_buffer_length) |
|
2009-11-12 02:28:30 +08:00
|
|
|
xhci_td_remainder(urb->transfer_buffer_length) |
|
2009-07-28 03:03:07 +08:00
|
|
|
TRB_INTR_TARGET(0);
|
2009-04-28 10:58:01 +08:00
|
|
|
if (urb->transfer_buffer_length > 0) {
|
|
|
|
if (setup->bRequestType & USB_DIR_IN)
|
|
|
|
field |= TRB_DIR_IN;
|
|
|
|
queue_trb(xhci, ep_ring, false,
|
|
|
|
lower_32_bits(urb->transfer_dma),
|
|
|
|
upper_32_bits(urb->transfer_dma),
|
2009-07-28 03:03:07 +08:00
|
|
|
length_field,
|
2009-04-28 10:58:01 +08:00
|
|
|
/* Event on short tx */
|
|
|
|
field | TRB_ISP | TRB_TYPE(TRB_DATA) | ep_ring->cycle_state);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Save the DMA address of the last TRB in the TD */
|
|
|
|
td->last_trb = ep_ring->enqueue;
|
|
|
|
|
|
|
|
/* Queue status TRB - see Table 7 and sections 4.11.2.2 and 6.4.1.2.3 */
|
|
|
|
/* If the device sent data, the status stage is an OUT transfer */
|
|
|
|
if (urb->transfer_buffer_length > 0 && setup->bRequestType & USB_DIR_IN)
|
|
|
|
field = 0;
|
|
|
|
else
|
|
|
|
field = TRB_DIR_IN;
|
|
|
|
queue_trb(xhci, ep_ring, false,
|
|
|
|
0,
|
|
|
|
0,
|
|
|
|
TRB_INTR_TARGET(0),
|
|
|
|
/* Event on completion */
|
|
|
|
field | TRB_IOC | TRB_TYPE(TRB_STATUS) | ep_ring->cycle_state);
|
|
|
|
|
2009-04-28 10:59:19 +08:00
|
|
|
giveback_first_trb(xhci, slot_id, ep_index, start_cycle, start_trb, td);
|
2009-04-28 10:58:01 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**** Command Ring Operations ****/
|
|
|
|
|
2009-09-05 01:53:13 +08:00
|
|
|
/* Generic function for queueing a command TRB on the command ring.
|
|
|
|
* Check to make sure there's room on the command ring for one command TRB.
|
|
|
|
* Also check that there's room reserved for commands that must not fail.
|
|
|
|
* If this is a command that must not fail, meaning command_must_succeed = TRUE,
|
|
|
|
* then only check for the number of reserved spots.
|
|
|
|
* Don't decrement xhci->cmd_ring_reserved_trbs after we've queued the TRB
|
|
|
|
* because the command event handler may want to resubmit a failed command.
|
|
|
|
*/
|
|
|
|
static int queue_command(struct xhci_hcd *xhci, u32 field1, u32 field2,
|
|
|
|
u32 field3, u32 field4, bool command_must_succeed)
|
2009-04-28 10:53:56 +08:00
|
|
|
{
|
2009-09-05 01:53:13 +08:00
|
|
|
int reserved_trbs = xhci->cmd_ring_reserved_trbs;
|
|
|
|
if (!command_must_succeed)
|
|
|
|
reserved_trbs++;
|
|
|
|
|
|
|
|
if (!room_on_ring(xhci, xhci->cmd_ring, reserved_trbs)) {
|
2009-04-28 10:53:56 +08:00
|
|
|
if (!in_interrupt())
|
|
|
|
xhci_err(xhci, "ERR: No room for command on command ring\n");
|
2009-09-05 01:53:13 +08:00
|
|
|
if (command_must_succeed)
|
|
|
|
xhci_err(xhci, "ERR: Reserved TRB counting for "
|
|
|
|
"unfailable commands failed.\n");
|
2009-04-28 10:53:56 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
queue_trb(xhci, xhci->cmd_ring, false, field1, field2, field3,
|
|
|
|
field4 | xhci->cmd_ring->cycle_state);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Queue a no-op command on the command ring */
|
|
|
|
static int queue_cmd_noop(struct xhci_hcd *xhci)
|
|
|
|
{
|
2009-09-05 01:53:13 +08:00
|
|
|
return queue_command(xhci, 0, 0, 0, TRB_TYPE(TRB_CMD_NOOP), false);
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Place a no-op command on the command ring to test the command and
|
|
|
|
* event ring.
|
|
|
|
*/
|
2009-04-30 10:05:20 +08:00
|
|
|
void *xhci_setup_one_noop(struct xhci_hcd *xhci)
|
2009-04-28 10:53:56 +08:00
|
|
|
{
|
|
|
|
if (queue_cmd_noop(xhci) < 0)
|
|
|
|
return NULL;
|
|
|
|
xhci->noops_submitted++;
|
2009-04-30 10:05:20 +08:00
|
|
|
return xhci_ring_cmd_db;
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
|
|
/* Queue a slot enable or disable request on the command ring */
|
2009-04-30 10:05:20 +08:00
|
|
|
int xhci_queue_slot_control(struct xhci_hcd *xhci, u32 trb_type, u32 slot_id)
|
2009-04-28 10:57:38 +08:00
|
|
|
{
|
|
|
|
return queue_command(xhci, 0, 0, 0,
|
2009-09-05 01:53:13 +08:00
|
|
|
TRB_TYPE(trb_type) | SLOT_ID_FOR_TRB(slot_id), false);
|
2009-04-28 10:57:38 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Queue an address device command TRB */
|
2009-04-30 10:05:20 +08:00
|
|
|
int xhci_queue_address_device(struct xhci_hcd *xhci, dma_addr_t in_ctx_ptr,
|
|
|
|
u32 slot_id)
|
2009-04-28 10:57:38 +08:00
|
|
|
{
|
2009-07-28 03:03:31 +08:00
|
|
|
return queue_command(xhci, lower_32_bits(in_ctx_ptr),
|
|
|
|
upper_32_bits(in_ctx_ptr), 0,
|
2009-09-05 01:53:13 +08:00
|
|
|
TRB_TYPE(TRB_ADDR_DEV) | SLOT_ID_FOR_TRB(slot_id),
|
|
|
|
false);
|
2009-04-28 10:57:38 +08:00
|
|
|
}
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:58:38 +08:00
|
|
|
|
|
|
|
/* Queue a configure endpoint command TRB */
|
2009-04-30 10:05:20 +08:00
|
|
|
int xhci_queue_configure_endpoint(struct xhci_hcd *xhci, dma_addr_t in_ctx_ptr,
|
2009-09-05 01:53:13 +08:00
|
|
|
u32 slot_id, bool command_must_succeed)
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:58:38 +08:00
|
|
|
{
|
2009-07-28 03:03:31 +08:00
|
|
|
return queue_command(xhci, lower_32_bits(in_ctx_ptr),
|
|
|
|
upper_32_bits(in_ctx_ptr), 0,
|
2009-09-05 01:53:13 +08:00
|
|
|
TRB_TYPE(TRB_CONFIG_EP) | SLOT_ID_FOR_TRB(slot_id),
|
|
|
|
command_must_succeed);
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:58:38 +08:00
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
2009-08-08 05:04:43 +08:00
|
|
|
/* Queue an evaluate context command TRB */
|
|
|
|
int xhci_queue_evaluate_context(struct xhci_hcd *xhci, dma_addr_t in_ctx_ptr,
|
|
|
|
u32 slot_id)
|
|
|
|
{
|
|
|
|
return queue_command(xhci, lower_32_bits(in_ctx_ptr),
|
|
|
|
upper_32_bits(in_ctx_ptr), 0,
|
2009-09-05 01:53:13 +08:00
|
|
|
TRB_TYPE(TRB_EVAL_CONTEXT) | SLOT_ID_FOR_TRB(slot_id),
|
|
|
|
false);
|
2009-08-08 05:04:43 +08:00
|
|
|
}
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
int xhci_queue_stop_endpoint(struct xhci_hcd *xhci, int slot_id,
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
unsigned int ep_index)
|
|
|
|
{
|
|
|
|
u32 trb_slot_id = SLOT_ID_FOR_TRB(slot_id);
|
|
|
|
u32 trb_ep_index = EP_ID_FOR_TRB(ep_index);
|
|
|
|
u32 type = TRB_TYPE(TRB_STOP_RING);
|
|
|
|
|
|
|
|
return queue_command(xhci, 0, 0, 0,
|
2009-09-05 01:53:13 +08:00
|
|
|
trb_slot_id | trb_ep_index | type, false);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Set Transfer Ring Dequeue Pointer command.
|
|
|
|
* This should not be used for endpoints that have streams enabled.
|
|
|
|
*/
|
|
|
|
static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
|
|
|
|
unsigned int ep_index, struct xhci_segment *deq_seg,
|
|
|
|
union xhci_trb *deq_ptr, u32 cycle_state)
|
|
|
|
{
|
|
|
|
dma_addr_t addr;
|
|
|
|
u32 trb_slot_id = SLOT_ID_FOR_TRB(slot_id);
|
|
|
|
u32 trb_ep_index = EP_ID_FOR_TRB(ep_index);
|
|
|
|
u32 type = TRB_TYPE(TRB_SET_DEQ);
|
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
addr = xhci_trb_virt_to_dma(deq_seg, deq_ptr);
|
2009-07-28 03:05:21 +08:00
|
|
|
if (addr == 0) {
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
xhci_warn(xhci, "WARN Cannot submit Set TR Deq Ptr\n");
|
2009-04-30 10:14:08 +08:00
|
|
|
xhci_warn(xhci, "WARN deq seg = %p, deq pt = %p\n",
|
|
|
|
deq_seg, deq_ptr);
|
2009-07-28 03:05:21 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2009-07-28 03:03:31 +08:00
|
|
|
return queue_command(xhci, lower_32_bits(addr) | cycle_state,
|
|
|
|
upper_32_bits(addr), 0,
|
2009-09-05 01:53:13 +08:00
|
|
|
trb_slot_id | trb_ep_index | type, false);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
}
|
2009-07-28 03:03:15 +08:00
|
|
|
|
|
|
|
int xhci_queue_reset_ep(struct xhci_hcd *xhci, int slot_id,
|
|
|
|
unsigned int ep_index)
|
|
|
|
{
|
|
|
|
u32 trb_slot_id = SLOT_ID_FOR_TRB(slot_id);
|
|
|
|
u32 trb_ep_index = EP_ID_FOR_TRB(ep_index);
|
|
|
|
u32 type = TRB_TYPE(TRB_RESET_EP);
|
|
|
|
|
2009-09-05 01:53:13 +08:00
|
|
|
return queue_command(xhci, 0, 0, 0, trb_slot_id | trb_ep_index | type,
|
|
|
|
false);
|
2009-07-28 03:03:15 +08:00
|
|
|
}
|