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>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2009-04-28 10:53:56 +08:00
|
|
|
#include "xhci.h"
|
|
|
|
|
2010-10-14 22:22:57 +08:00
|
|
|
static int handle_cmd_in_cmd_wait_list(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
struct xhci_event_cmd *event);
|
|
|
|
|
2009-04-28 10:53:56 +08:00
|
|
|
/*
|
|
|
|
* 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?
|
|
|
|
*/
|
2011-03-20 17:15:16 +08:00
|
|
|
static bool last_trb_on_last_seg(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
2009-04-28 10:53:56 +08:00
|
|
|
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
|
2011-03-29 10:40:46 +08:00
|
|
|
return le32_to_cpu(trb->link.control) & LINK_TOGGLE;
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* 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?
|
|
|
|
*/
|
2011-03-20 17:15:16 +08:00
|
|
|
static int last_trb(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
2009-04-28 10:53:56 +08:00
|
|
|
struct xhci_segment *seg, union xhci_trb *trb)
|
|
|
|
{
|
|
|
|
if (ring == xhci->event_ring)
|
|
|
|
return trb == &seg->trbs[TRBS_PER_SEGMENT];
|
|
|
|
else
|
2011-06-01 08:22:55 +08:00
|
|
|
return TRB_TYPE_LINK_LE32(trb->link.control);
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
2011-03-20 17:15:16 +08:00
|
|
|
static int enqueue_is_link_trb(struct xhci_ring *ring)
|
2010-05-11 06:33:00 +08:00
|
|
|
{
|
|
|
|
struct xhci_link_trb *link = &ring->enqueue->link;
|
2011-06-01 08:22:55 +08:00
|
|
|
return TRB_TYPE_LINK_LE32(link->control);
|
2010-05-11 06:33:00 +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
|
|
|
/* 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 {
|
2010-08-10 04:56:11 +08:00
|
|
|
(*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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
*/
|
2012-03-05 17:49:32 +08:00
|
|
|
static void inc_deq(struct xhci_hcd *xhci, struct xhci_ring *ring)
|
2009-04-28 10:53:56 +08:00
|
|
|
{
|
2009-07-28 03:03:46 +08:00
|
|
|
unsigned long long addr;
|
2009-04-28 10:53:56 +08:00
|
|
|
|
|
|
|
ring->deq_updates++;
|
2012-03-05 17:49:34 +08:00
|
|
|
|
xhci: Fix bug after deq ptr set to link TRB.
This patch fixes a particularly nasty bug that was revealed by the ring
expansion patches. The bug has been present since the very beginning of
the xHCI driver history, and could have caused general protection faults
from bad memory accesses.
The first thing to note is that a Set TR Dequeue Pointer command can
move the dequeue pointer to a link TRB, if the canceled or stalled
transfer TD ended just before a link TRB. The function to increment the
dequeue pointer, inc_deq, was written before cancellation and stall
support was added. It assumed that the dequeue pointer could never
point to a link TRB. It would unconditionally increment the dequeue
pointer at the start of the function, check if the pointer was now on a
link TRB, and move it to the top of the next segment if so.
This means that if a Set TR Dequeue Point command moved the dequeue
pointer to a link TRB, a subsequent call to inc_deq() would move the
pointer off the segment and into la-la-land. It would then read from
that memory to determine if it was a link TRB. Other functions would
often call inc_deq() until the dequeue pointer matched some other
pointer, which means this function would quite happily read all of
system memory before wrapping around to the right pointer value.
Often, there would be another endpoint segment from a different ring
allocated from the same DMA pool, which would be contiguous to the
segment inc_deq just stepped off of. inc_deq would eventually find the
link TRB in that segment, and blindly move the dequeue pointer back to
the top of the correct ring segment.
The only reason the original code worked at all is because there was
only one ring segment. With the ring expansion patches, the dequeue
pointer would eventually wrap into place, but the dequeue segment would
be out-of-sync. On the second TD after the dequeue pointer was moved to
a link TRB, trb_in_td() would fail (because the dequeue pointer and
dequeue segment were out-of-sync), and this message would appear:
ERROR Transfer event TRB DMA ptr not part of current TD
This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0
port: "Transfer event TRB DMA ptr not part of current TD", "rejecting
I/O to offline device"),
https://bugzilla.kernel.org/show_bug.cgi?id=43333
and possibly other general protection fault bugs as well.
This patch should be backported to kernels as old as 2.6.31. A separate
patch will be created for kernels older than 3.4, since inc_deq was
modified in 3.4 and this patch will not apply.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Tested-by: Matthew Hall <mhall@mhcomputing.net>
Cc: stable@vger.kernel.org
2012-07-27 03:03:59 +08:00
|
|
|
/*
|
|
|
|
* If this is not event ring, and the dequeue pointer
|
|
|
|
* is not on a link TRB, there is one more usable TRB
|
|
|
|
*/
|
2012-03-05 17:49:34 +08:00
|
|
|
if (ring->type != TYPE_EVENT &&
|
|
|
|
!last_trb(xhci, ring, ring->deq_seg, ring->dequeue))
|
|
|
|
ring->num_trbs_free++;
|
|
|
|
|
xhci: Fix bug after deq ptr set to link TRB.
This patch fixes a particularly nasty bug that was revealed by the ring
expansion patches. The bug has been present since the very beginning of
the xHCI driver history, and could have caused general protection faults
from bad memory accesses.
The first thing to note is that a Set TR Dequeue Pointer command can
move the dequeue pointer to a link TRB, if the canceled or stalled
transfer TD ended just before a link TRB. The function to increment the
dequeue pointer, inc_deq, was written before cancellation and stall
support was added. It assumed that the dequeue pointer could never
point to a link TRB. It would unconditionally increment the dequeue
pointer at the start of the function, check if the pointer was now on a
link TRB, and move it to the top of the next segment if so.
This means that if a Set TR Dequeue Point command moved the dequeue
pointer to a link TRB, a subsequent call to inc_deq() would move the
pointer off the segment and into la-la-land. It would then read from
that memory to determine if it was a link TRB. Other functions would
often call inc_deq() until the dequeue pointer matched some other
pointer, which means this function would quite happily read all of
system memory before wrapping around to the right pointer value.
Often, there would be another endpoint segment from a different ring
allocated from the same DMA pool, which would be contiguous to the
segment inc_deq just stepped off of. inc_deq would eventually find the
link TRB in that segment, and blindly move the dequeue pointer back to
the top of the correct ring segment.
The only reason the original code worked at all is because there was
only one ring segment. With the ring expansion patches, the dequeue
pointer would eventually wrap into place, but the dequeue segment would
be out-of-sync. On the second TD after the dequeue pointer was moved to
a link TRB, trb_in_td() would fail (because the dequeue pointer and
dequeue segment were out-of-sync), and this message would appear:
ERROR Transfer event TRB DMA ptr not part of current TD
This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0
port: "Transfer event TRB DMA ptr not part of current TD", "rejecting
I/O to offline device"),
https://bugzilla.kernel.org/show_bug.cgi?id=43333
and possibly other general protection fault bugs as well.
This patch should be backported to kernels as old as 2.6.31. A separate
patch will be created for kernels older than 3.4, since inc_deq was
modified in 3.4 and this patch will not apply.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Tested-by: Matthew Hall <mhall@mhcomputing.net>
Cc: stable@vger.kernel.org
2012-07-27 03:03:59 +08:00
|
|
|
do {
|
|
|
|
/*
|
|
|
|
* 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)
|
|
|
|
*/
|
|
|
|
if (last_trb(xhci, ring, ring->deq_seg, ring->dequeue)) {
|
|
|
|
if (ring->type == TYPE_EVENT &&
|
|
|
|
last_trb_on_last_seg(xhci, ring,
|
|
|
|
ring->deq_seg, ring->dequeue)) {
|
|
|
|
ring->cycle_state = (ring->cycle_state ? 0 : 1);
|
|
|
|
}
|
|
|
|
ring->deq_seg = ring->deq_seg->next;
|
|
|
|
ring->dequeue = ring->deq_seg->trbs;
|
|
|
|
} else {
|
|
|
|
ring->dequeue++;
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
xhci: Fix bug after deq ptr set to link TRB.
This patch fixes a particularly nasty bug that was revealed by the ring
expansion patches. The bug has been present since the very beginning of
the xHCI driver history, and could have caused general protection faults
from bad memory accesses.
The first thing to note is that a Set TR Dequeue Pointer command can
move the dequeue pointer to a link TRB, if the canceled or stalled
transfer TD ended just before a link TRB. The function to increment the
dequeue pointer, inc_deq, was written before cancellation and stall
support was added. It assumed that the dequeue pointer could never
point to a link TRB. It would unconditionally increment the dequeue
pointer at the start of the function, check if the pointer was now on a
link TRB, and move it to the top of the next segment if so.
This means that if a Set TR Dequeue Point command moved the dequeue
pointer to a link TRB, a subsequent call to inc_deq() would move the
pointer off the segment and into la-la-land. It would then read from
that memory to determine if it was a link TRB. Other functions would
often call inc_deq() until the dequeue pointer matched some other
pointer, which means this function would quite happily read all of
system memory before wrapping around to the right pointer value.
Often, there would be another endpoint segment from a different ring
allocated from the same DMA pool, which would be contiguous to the
segment inc_deq just stepped off of. inc_deq would eventually find the
link TRB in that segment, and blindly move the dequeue pointer back to
the top of the correct ring segment.
The only reason the original code worked at all is because there was
only one ring segment. With the ring expansion patches, the dequeue
pointer would eventually wrap into place, but the dequeue segment would
be out-of-sync. On the second TD after the dequeue pointer was moved to
a link TRB, trb_in_td() would fail (because the dequeue pointer and
dequeue segment were out-of-sync), and this message would appear:
ERROR Transfer event TRB DMA ptr not part of current TD
This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0
port: "Transfer event TRB DMA ptr not part of current TD", "rejecting
I/O to offline device"),
https://bugzilla.kernel.org/show_bug.cgi?id=43333
and possibly other general protection fault bugs as well.
This patch should be backported to kernels as old as 2.6.31. A separate
patch will be created for kernels older than 3.4, since inc_deq was
modified in 3.4 and this patch will not apply.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Tested-by: Matthew Hall <mhall@mhcomputing.net>
Cc: stable@vger.kernel.org
2012-07-27 03:03:59 +08:00
|
|
|
} while (last_trb(xhci, ring, ring->deq_seg, ring->dequeue));
|
|
|
|
|
2009-07-28 03:03:46 +08:00
|
|
|
addr = (unsigned long long) xhci_trb_virt_to_dma(ring->deq_seg, ring->dequeue);
|
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.
|
2010-06-11 03:25:28 +08:00
|
|
|
*
|
|
|
|
* @more_trbs_coming: Will you enqueue more TRBs before calling
|
|
|
|
* prepare_transfer()?
|
2009-04-28 10:53:56 +08:00
|
|
|
*/
|
2010-06-11 03:25:28 +08:00
|
|
|
static void inc_enq(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
2012-03-05 17:49:32 +08:00
|
|
|
bool more_trbs_coming)
|
2009-04-28 10:53:56 +08:00
|
|
|
{
|
|
|
|
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
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
chain = le32_to_cpu(ring->enqueue->generic.field[3]) & TRB_CHAIN;
|
2012-03-05 17:49:34 +08:00
|
|
|
/* If this is not event ring, there is one less usable TRB */
|
|
|
|
if (ring->type != TYPE_EVENT &&
|
|
|
|
!last_trb(xhci, ring, ring->enq_seg, ring->enqueue))
|
|
|
|
ring->num_trbs_free--;
|
2009-04-28 10:53:56 +08:00
|
|
|
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)) {
|
2012-03-05 17:49:32 +08:00
|
|
|
if (ring->type != TYPE_EVENT) {
|
|
|
|
/*
|
|
|
|
* If the caller doesn't plan on enqueueing more
|
|
|
|
* TDs before ringing the doorbell, then we
|
|
|
|
* don't want to give the link TRB to the
|
|
|
|
* hardware just yet. We'll give the link TRB
|
|
|
|
* back in prepare_ring() just before we enqueue
|
|
|
|
* the TD at the top of the ring.
|
|
|
|
*/
|
|
|
|
if (!chain && !more_trbs_coming)
|
|
|
|
break;
|
2010-06-11 03:25:28 +08:00
|
|
|
|
2012-03-05 17:49:32 +08:00
|
|
|
/* If we're not dealing with 0.95 hardware or
|
|
|
|
* isoc rings on AMD 0.96 host,
|
|
|
|
* carry over the chain bit of the previous TRB
|
|
|
|
* (which may mean the chain bit is cleared).
|
|
|
|
*/
|
|
|
|
if (!(ring->type == TYPE_ISOC &&
|
|
|
|
(xhci->quirks & XHCI_AMD_0x96_HOST))
|
xHCI: AMD isoc link TRB chain bit quirk
Setting the chain (CH) bit in the link TRB of isochronous transfer rings
is required by AMD 0.96 xHCI host controller to successfully transverse
multi-TRB TD that span through different memory segments.
When a Missed Service Error event occurs, if the chain bit is not set in
the link TRB and the host skips TDs which just across a link TRB, the
host may falsely recognize the link TRB as a normal TRB. You can see
this may cause big trouble - the host does not jump to the right address
which is pointed by the link TRB, but continue fetching the memory which
is after the link TRB address, which may not even belong to the host,
and the result cannot be predicted.
This causes some big problems. Without the former patch I sent: "xHCI:
prevent infinite loop when processing MSE event", the system may hang.
With that patch applied, system does not hang, but the host still access
wrong memory address and isoc transfer will fail. With this patch,
isochronous transfer works as expected.
This patch should be applied to kernels as old as 2.6.36, which was when
the first isochronous support was added for the xHCI host controller.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-24 05:19:54 +08:00
|
|
|
&& !xhci_link_trb_quirk(xhci)) {
|
2012-03-05 17:49:32 +08:00
|
|
|
next->link.control &=
|
|
|
|
cpu_to_le32(~TRB_CHAIN);
|
|
|
|
next->link.control |=
|
|
|
|
cpu_to_le32(chain);
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
2012-03-05 17:49:32 +08:00
|
|
|
/* Give this link TRB to the hardware */
|
|
|
|
wmb();
|
|
|
|
next->link.control ^= cpu_to_le32(TRB_CYCLE);
|
|
|
|
|
2009-04-28 10:53:56 +08:00
|
|
|
/* 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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
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);
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2012-03-05 17:49:40 +08:00
|
|
|
* Check to see if there's room to enqueue num_trbs on the ring and make sure
|
|
|
|
* enqueue pointer will not advance into dequeue segment. See rules above.
|
2009-04-28 10:53:56 +08:00
|
|
|
*/
|
2012-03-05 17:49:34 +08:00
|
|
|
static inline int room_on_ring(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
2009-04-28 10:53:56 +08:00
|
|
|
unsigned int num_trbs)
|
|
|
|
{
|
2012-03-05 17:49:40 +08:00
|
|
|
int num_trbs_in_deq_seg;
|
2012-03-05 17:49:34 +08:00
|
|
|
|
2012-03-05 17:49:40 +08:00
|
|
|
if (ring->num_trbs_free < num_trbs)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (ring->type != TYPE_COMMAND && ring->type != TYPE_EVENT) {
|
|
|
|
num_trbs_in_deq_seg = ring->dequeue - ring->deq_seg->trbs;
|
|
|
|
if (ring->num_trbs_free < num_trbs + num_trbs_in_deq_seg)
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
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
|
|
|
{
|
2012-06-27 16:30:57 +08:00
|
|
|
if (!(xhci->cmd_ring_state & CMD_RING_STATE_RUNNING))
|
|
|
|
return;
|
|
|
|
|
2009-04-28 10:53:56 +08:00
|
|
|
xhci_dbg(xhci, "// Ding dong!\n");
|
2010-12-16 03:18:11 +08:00
|
|
|
xhci_writel(xhci, DB_VALUE_HOST, &xhci->dba->doorbell[0]);
|
2009-04-28 10:53:56 +08:00
|
|
|
/* Flush PCI posted writes */
|
|
|
|
xhci_readl(xhci, &xhci->dba->doorbell[0]);
|
|
|
|
}
|
|
|
|
|
2012-06-27 16:31:12 +08:00
|
|
|
static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
|
|
|
|
{
|
|
|
|
u64 temp_64;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Abort command ring\n");
|
|
|
|
|
|
|
|
if (!(xhci->cmd_ring_state & CMD_RING_STATE_RUNNING)) {
|
|
|
|
xhci_dbg(xhci, "The command ring isn't running, "
|
|
|
|
"Have the command ring been stopped?\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
temp_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
|
|
|
|
if (!(temp_64 & CMD_RING_RUNNING)) {
|
|
|
|
xhci_dbg(xhci, "Command ring had been stopped\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
xhci->cmd_ring_state = CMD_RING_STATE_ABORTED;
|
|
|
|
xhci_write_64(xhci, temp_64 | CMD_RING_ABORT,
|
|
|
|
&xhci->op_regs->cmd_ring);
|
|
|
|
|
|
|
|
/* Section 4.6.1.2 of xHCI 1.0 spec says software should
|
|
|
|
* time the completion od all xHCI commands, including
|
|
|
|
* the Command Abort operation. If software doesn't see
|
|
|
|
* CRR negated in a timely manner (e.g. longer than 5
|
|
|
|
* seconds), then it should assume that the there are
|
|
|
|
* larger problems with the xHC and assert HCRST.
|
|
|
|
*/
|
2012-10-26 04:27:51 +08:00
|
|
|
ret = xhci_handshake(xhci, &xhci->op_regs->cmd_ring,
|
2012-06-27 16:31:12 +08:00
|
|
|
CMD_RING_RUNNING, 0, 5 * 1000 * 1000);
|
|
|
|
if (ret < 0) {
|
|
|
|
xhci_err(xhci, "Stopped the command ring failed, "
|
|
|
|
"maybe the host is dead\n");
|
|
|
|
xhci->xhc_state |= XHCI_STATE_DYING;
|
|
|
|
xhci_quiesce(xhci);
|
|
|
|
xhci_halt(xhci);
|
|
|
|
return -ESHUTDOWN;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int xhci_queue_cd(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_command *command,
|
|
|
|
union xhci_trb *cmd_trb)
|
|
|
|
{
|
|
|
|
struct xhci_cd *cd;
|
|
|
|
cd = kzalloc(sizeof(struct xhci_cd), GFP_ATOMIC);
|
|
|
|
if (!cd)
|
|
|
|
return -ENOMEM;
|
|
|
|
INIT_LIST_HEAD(&cd->cancel_cmd_list);
|
|
|
|
|
|
|
|
cd->command = command;
|
|
|
|
cd->cmd_trb = cmd_trb;
|
|
|
|
list_add_tail(&cd->cancel_cmd_list, &xhci->cancel_cmd_list);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Cancel the command which has issue.
|
|
|
|
*
|
|
|
|
* Some commands may hang due to waiting for acknowledgement from
|
|
|
|
* usb device. It is outside of the xHC's ability to control and
|
|
|
|
* will cause the command ring is blocked. When it occurs software
|
|
|
|
* should intervene to recover the command ring.
|
|
|
|
* See Section 4.6.1.1 and 4.6.1.2
|
|
|
|
*/
|
|
|
|
int xhci_cancel_cmd(struct xhci_hcd *xhci, struct xhci_command *command,
|
|
|
|
union xhci_trb *cmd_trb)
|
|
|
|
{
|
|
|
|
int retval = 0;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING) {
|
|
|
|
xhci_warn(xhci, "Abort the command ring,"
|
|
|
|
" but the xHCI is dead.\n");
|
|
|
|
retval = -ESHUTDOWN;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* queue the cmd desriptor to cancel_cmd_list */
|
|
|
|
retval = xhci_queue_cd(xhci, command, cmd_trb);
|
|
|
|
if (retval) {
|
|
|
|
xhci_warn(xhci, "Queuing command descriptor failed.\n");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* abort command ring */
|
|
|
|
retval = xhci_abort_cmd_ring(xhci);
|
|
|
|
if (retval) {
|
|
|
|
xhci_err(xhci, "Abort command ring failed\n");
|
|
|
|
if (unlikely(retval == -ESHUTDOWN)) {
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
usb_hc_died(xhci_to_hcd(xhci)->primary_hcd);
|
|
|
|
xhci_dbg(xhci, "xHCI host controller is dead.\n");
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fail:
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
2010-10-14 22:22:57 +08:00
|
|
|
void xhci_ring_ep_doorbell(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,
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int ep_index,
|
|
|
|
unsigned int stream_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
|
|
|
{
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 __iomem *db_addr = &xhci->dba->doorbell[slot_id];
|
2010-12-16 03:18:11 +08:00
|
|
|
struct xhci_virt_ep *ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
unsigned int 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
|
2010-12-16 03:18:11 +08:00
|
|
|
* cancellations because we don't want to interrupt processing.
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
* We don't want to restart any stream rings if there's a set dequeue
|
|
|
|
* pointer command pending because the device can choose to start any
|
|
|
|
* stream once the endpoint is on the HW schedule.
|
|
|
|
* FIXME - check all the stream rings for pending cancellations.
|
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
|
|
|
*/
|
2010-12-16 03:18:11 +08:00
|
|
|
if ((ep_state & EP_HALT_PENDING) || (ep_state & SET_DEQ_PENDING) ||
|
|
|
|
(ep_state & EP_HALTED))
|
|
|
|
return;
|
|
|
|
xhci_writel(xhci, DB_VALUE(ep_index, stream_id), db_addr);
|
|
|
|
/* The CPU has better things to do at this point than wait for a
|
|
|
|
* write-posting flush. It'll get there soon enough.
|
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
2010-04-03 06:34:43 +08:00
|
|
|
/* Ring the doorbell for any rings with pending URBs */
|
|
|
|
static void ring_doorbell_for_active_rings(struct xhci_hcd *xhci,
|
|
|
|
unsigned int slot_id,
|
|
|
|
unsigned int ep_index)
|
|
|
|
{
|
|
|
|
unsigned int stream_id;
|
|
|
|
struct xhci_virt_ep *ep;
|
|
|
|
|
|
|
|
ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
|
|
|
|
/* A ring has pending URBs if its TD list is not empty */
|
|
|
|
if (!(ep->ep_state & EP_HAS_STREAMS)) {
|
|
|
|
if (!(list_empty(&ep->ring->td_list)))
|
2010-10-14 22:22:57 +08:00
|
|
|
xhci_ring_ep_doorbell(xhci, slot_id, ep_index, 0);
|
2010-04-03 06:34:43 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (stream_id = 1; stream_id < ep->stream_info->num_streams;
|
|
|
|
stream_id++) {
|
|
|
|
struct xhci_stream_info *stream_info = ep->stream_info;
|
|
|
|
if (!list_empty(&stream_info->stream_rings[stream_id]->td_list))
|
2010-10-14 22:22:57 +08:00
|
|
|
xhci_ring_ep_doorbell(xhci, slot_id, ep_index,
|
|
|
|
stream_id);
|
2010-04-03 06:34:43 +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
|
|
|
/*
|
|
|
|
* 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;
|
2011-06-01 08:22:55 +08:00
|
|
|
if (generic_trb->field[3] & cpu_to_le32(LINK_TOGGLE))
|
2011-02-24 10:13:43 +08:00
|
|
|
*cycle_state ^= 0x1;
|
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_seg = cur_seg->next;
|
|
|
|
if (cur_seg == start_seg)
|
|
|
|
/* Looped over the entire list. Oops! */
|
2010-04-19 23:53:50 +08:00
|
|
|
return NULL;
|
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 cur_seg;
|
|
|
|
}
|
|
|
|
|
2010-07-30 13:12:20 +08:00
|
|
|
|
|
|
|
static struct xhci_ring *xhci_triad_to_transfer_ring(struct xhci_hcd *xhci,
|
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
|
|
|
unsigned int stream_id)
|
|
|
|
{
|
|
|
|
struct xhci_virt_ep *ep;
|
|
|
|
|
|
|
|
ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
/* Common case: no streams */
|
|
|
|
if (!(ep->ep_state & EP_HAS_STREAMS))
|
|
|
|
return ep->ring;
|
|
|
|
|
|
|
|
if (stream_id == 0) {
|
|
|
|
xhci_warn(xhci,
|
|
|
|
"WARN: Slot ID %u, ep index %u has streams, "
|
|
|
|
"but URB has no stream ID.\n",
|
|
|
|
slot_id, ep_index);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (stream_id < ep->stream_info->num_streams)
|
|
|
|
return ep->stream_info->stream_rings[stream_id];
|
|
|
|
|
|
|
|
xhci_warn(xhci,
|
|
|
|
"WARN: Slot ID %u, ep index %u has "
|
|
|
|
"stream IDs 1 to %u allocated, "
|
|
|
|
"but stream ID %u is requested.\n",
|
|
|
|
slot_id, ep_index,
|
|
|
|
ep->stream_info->num_streams - 1,
|
|
|
|
stream_id);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get the right ring for the given URB.
|
|
|
|
* If the endpoint supports streams, boundary check the URB's stream ID.
|
|
|
|
* If the endpoint doesn't support streams, return the singular endpoint ring.
|
|
|
|
*/
|
|
|
|
static struct xhci_ring *xhci_urb_to_transfer_ring(struct xhci_hcd *xhci,
|
|
|
|
struct urb *urb)
|
|
|
|
{
|
|
|
|
return xhci_triad_to_transfer_ring(xhci, urb->dev->slot_id,
|
|
|
|
xhci_get_endpoint_index(&urb->ep->desc), urb->stream_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
|
|
|
/*
|
|
|
|
* 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.
|
2011-03-29 10:40:46 +08:00
|
|
|
*
|
|
|
|
* Some of the uses of xhci_generic_trb are grotty, but if they're done
|
|
|
|
* with correct __le32 accesses they should work fine. Only users of this are
|
|
|
|
* in here.
|
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: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,
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int stream_id, 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];
|
2010-04-03 06:34:43 +08:00
|
|
|
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_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
|
|
|
|
2010-04-03 06:34:43 +08:00
|
|
|
ep_ring = xhci_triad_to_transfer_ring(xhci, slot_id,
|
|
|
|
ep_index, stream_id);
|
|
|
|
if (!ep_ring) {
|
|
|
|
xhci_warn(xhci, "WARN can't find new dequeue state "
|
|
|
|
"for invalid stream ID %u.\n",
|
|
|
|
stream_id);
|
|
|
|
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
|
|
|
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);
|
2011-02-13 06:06:06 +08:00
|
|
|
if (!state->new_deq_seg) {
|
|
|
|
WARN_ON(1);
|
|
|
|
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
|
|
|
/* 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);
|
2011-03-29 10:40:46 +08:00
|
|
|
state->new_cycle_state = 0x1 & le64_to_cpu(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);
|
2011-02-13 06:06:06 +08:00
|
|
|
if (!state->new_deq_seg) {
|
|
|
|
WARN_ON(1);
|
|
|
|
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
|
|
|
|
|
|
|
trb = &state->new_deq_ptr->generic;
|
2011-06-01 08:22:55 +08:00
|
|
|
if (TRB_TYPE_LINK_LE32(trb->field[3]) &&
|
|
|
|
(trb->field[3] & cpu_to_le32(LINK_TOGGLE)))
|
2011-02-24 10:13:43 +08:00
|
|
|
state->new_cycle_state ^= 0x1;
|
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
|
|
|
next_trb(xhci, ep_ring, &state->new_deq_seg, &state->new_deq_ptr);
|
|
|
|
|
2011-02-24 10:12:29 +08:00
|
|
|
/*
|
|
|
|
* If there is only one segment in a ring, find_trb_seg()'s while loop
|
|
|
|
* will not run, and it will return before it has a chance to see if it
|
|
|
|
* needs to toggle the cycle bit. It can't tell if the stalled transfer
|
|
|
|
* ended just before the link TRB on a one-segment ring, or if the TD
|
|
|
|
* wrapped around the top of the ring, because it doesn't have the TD in
|
|
|
|
* question. Look for the one-segment case where stalled TRB's address
|
|
|
|
* is greater than the new dequeue pointer address.
|
|
|
|
*/
|
|
|
|
if (ep_ring->first_seg == ep_ring->first_seg->next &&
|
|
|
|
state->new_deq_ptr < dev->eps[ep_index].stopped_trb)
|
|
|
|
state->new_cycle_state ^= 0x1;
|
|
|
|
xhci_dbg(xhci, "Cycle state = 0x%x\n", state->new_cycle_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 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);
|
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: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-30 03:44:32 +08:00
|
|
|
/* flip_cycle means flip the cycle bit of all but the first and last TRB.
|
|
|
|
* (The last TRB actually points to the ring enqueue pointer, which is not part
|
|
|
|
* of this TD.) This is used to remove partially enqueued isoc TDs from a ring.
|
|
|
|
*/
|
2009-04-30 10:05:20 +08:00
|
|
|
static void td_to_noop(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-30 03:44:32 +08:00
|
|
|
struct xhci_td *cur_td, bool flip_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
|
|
|
{
|
|
|
|
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)) {
|
2011-06-01 08:22:55 +08:00
|
|
|
if (TRB_TYPE_LINK_LE32(cur_trb->generic.field[3])) {
|
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
|
|
|
/* Unchain any chained Link TRBs, but
|
|
|
|
* leave the pointers intact.
|
|
|
|
*/
|
2011-03-29 10:40:46 +08:00
|
|
|
cur_trb->generic.field[3] &= cpu_to_le32(~TRB_CHAIN);
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-30 03:44:32 +08:00
|
|
|
/* Flip the cycle bit (link TRBs can't be the first
|
|
|
|
* or last TRB).
|
|
|
|
*/
|
|
|
|
if (flip_cycle)
|
|
|
|
cur_trb->generic.field[3] ^=
|
|
|
|
cpu_to_le32(TRB_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
|
|
|
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 */
|
2011-03-29 10:40:46 +08:00
|
|
|
cur_trb->generic.field[3] &= cpu_to_le32(TRB_CYCLE);
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-30 03:44:32 +08:00
|
|
|
/* Flip the cycle bit except on the first or last TRB */
|
|
|
|
if (flip_cycle && cur_trb != cur_td->first_trb &&
|
|
|
|
cur_trb != cur_td->last_trb)
|
|
|
|
cur_trb->generic.field[3] ^=
|
|
|
|
cpu_to_le32(TRB_CYCLE);
|
2011-03-29 10:40:46 +08:00
|
|
|
cur_trb->generic.field[3] |= cpu_to_le32(
|
|
|
|
TRB_TYPE(TRB_TR_NOOP));
|
2011-12-20 08:56:04 +08:00
|
|
|
xhci_dbg(xhci, "TRB to noop at offset 0x%llx\n",
|
|
|
|
(unsigned long long)
|
|
|
|
xhci_trb_virt_to_dma(cur_seg, cur_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 (cur_trb == cur_td->last_trb)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int queue_set_tr_deq(struct xhci_hcd *xhci, int slot_id,
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int ep_index, unsigned int stream_id,
|
|
|
|
struct xhci_segment *deq_seg,
|
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 *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,
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int stream_id,
|
2009-09-05 01:53:09 +08:00
|
|
|
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);
|
2010-04-03 06:34:43 +08:00
|
|
|
queue_set_tr_deq(xhci, slot_id, ep_index, stream_id,
|
2009-07-28 03:05:21 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2011-03-20 17:15:16 +08:00
|
|
|
static void xhci_stop_watchdog_timer_in_irq(struct xhci_hcd *xhci,
|
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
|
|
|
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)
|
|
|
|
{
|
2010-10-27 02:22:02 +08:00
|
|
|
struct usb_hcd *hcd;
|
2010-07-23 06:23:31 +08:00
|
|
|
struct urb *urb;
|
|
|
|
struct urb_priv *urb_priv;
|
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
|
|
|
|
2010-07-23 06:23:31 +08:00
|
|
|
urb = cur_td->urb;
|
|
|
|
urb_priv = urb->hcpriv;
|
|
|
|
urb_priv->td_cnt++;
|
2010-10-27 02:22:02 +08:00
|
|
|
hcd = bus_to_hcd(urb->dev->bus);
|
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
|
|
|
|
2010-07-23 06:23:31 +08:00
|
|
|
/* Only giveback urb when this is the last td in urb */
|
|
|
|
if (urb_priv->td_cnt == urb_priv->length) {
|
2011-03-22 17:08:14 +08:00
|
|
|
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS) {
|
|
|
|
xhci_to_hcd(xhci)->self.bandwidth_isoc_reqs--;
|
|
|
|
if (xhci_to_hcd(xhci)->self.bandwidth_isoc_reqs == 0) {
|
|
|
|
if (xhci->quirks & XHCI_AMD_PLL_FIX)
|
|
|
|
usb_amd_quirk_pll_enable();
|
|
|
|
}
|
|
|
|
}
|
2010-07-23 06:23:31 +08:00
|
|
|
usb_hcd_unlink_urb_from_ep(hcd, urb);
|
|
|
|
|
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
usb_hcd_giveback_urb(hcd, urb, status);
|
|
|
|
xhci_urb_free_priv(xhci, urb_priv);
|
|
|
|
spin_lock(&xhci->lock);
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
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,
|
2010-10-14 22:22:57 +08:00
|
|
|
union xhci_trb *trb, struct xhci_event_cmd *event)
|
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;
|
2010-10-14 22:22:57 +08:00
|
|
|
struct xhci_virt_device *virt_dev;
|
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_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;
|
2010-04-19 23:53:50 +08:00
|
|
|
struct xhci_td *cur_td = NULL;
|
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 *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
|
|
|
|
2010-10-14 22:22:57 +08:00
|
|
|
if (unlikely(TRB_TO_SUSPEND_PORT(
|
2011-03-29 10:40:46 +08:00
|
|
|
le32_to_cpu(xhci->cmd_ring->dequeue->generic.field[3])))) {
|
2010-10-14 22:22:57 +08:00
|
|
|
slot_id = TRB_TO_SLOT_ID(
|
2011-03-29 10:40:46 +08:00
|
|
|
le32_to_cpu(xhci->cmd_ring->dequeue->generic.field[3]));
|
2010-10-14 22:22:57 +08:00
|
|
|
virt_dev = xhci->devs[slot_id];
|
|
|
|
if (virt_dev)
|
|
|
|
handle_cmd_in_cmd_wait_list(xhci, virt_dev,
|
|
|
|
event);
|
|
|
|
else
|
|
|
|
xhci_warn(xhci, "Stop endpoint command "
|
|
|
|
"completion for disabled slot %u\n",
|
|
|
|
slot_id);
|
|
|
|
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
|
|
|
memset(&deq_state, 0, sizeof(deq_state));
|
2011-03-29 10:40:46 +08:00
|
|
|
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(trb->generic.field[3]));
|
|
|
|
ep_index = TRB_TO_EP_INDEX(le32_to_cpu(trb->generic.field[3]));
|
2009-09-05 01:53:09 +08:00
|
|
|
ep = &xhci->devs[slot_id]->eps[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
|
|
|
|
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);
|
2011-05-25 02:53:29 +08:00
|
|
|
ep->stopped_td = NULL;
|
|
|
|
ep->stopped_trb = NULL;
|
2010-04-03 06:34:43 +08:00
|
|
|
ring_doorbell_for_active_rings(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);
|
2011-12-20 08:56:04 +08:00
|
|
|
xhci_dbg(xhci, "Removing canceled TD starting at 0x%llx (dma).\n",
|
|
|
|
(unsigned long long)xhci_trb_virt_to_dma(
|
|
|
|
cur_td->start_seg, cur_td->first_trb));
|
2010-04-03 06:34:43 +08:00
|
|
|
ep_ring = xhci_urb_to_transfer_ring(xhci, cur_td->urb);
|
|
|
|
if (!ep_ring) {
|
|
|
|
/* This shouldn't happen unless a driver is mucking
|
|
|
|
* with the stream ID after submission. This will
|
|
|
|
* leave the TD on the hardware ring, and the hardware
|
|
|
|
* will try to execute it, and may access a buffer
|
|
|
|
* that has already been freed. In the best case, the
|
|
|
|
* hardware will execute it, and the event handler will
|
|
|
|
* ignore the completion event for that TD, since it was
|
|
|
|
* removed from the td_list for that endpoint. In
|
|
|
|
* short, don't muck with the stream ID after
|
|
|
|
* submission.
|
|
|
|
*/
|
|
|
|
xhci_warn(xhci, "WARN Cancelled URB %p "
|
|
|
|
"has invalid stream ID %u.\n",
|
|
|
|
cur_td->urb,
|
|
|
|
cur_td->urb->stream_id);
|
|
|
|
goto remove_finished_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
|
|
|
/*
|
|
|
|
* 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)
|
2010-04-03 06:34:43 +08:00
|
|
|
xhci_find_new_dequeue_state(xhci, slot_id, ep_index,
|
|
|
|
cur_td->urb->stream_id,
|
|
|
|
cur_td, &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
|
|
|
else
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-30 03:44:32 +08:00
|
|
|
td_to_noop(xhci, ep_ring, cur_td, false);
|
2010-04-03 06:34:43 +08:00
|
|
|
remove_finished_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
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
2011-08-03 06:43:40 +08:00
|
|
|
list_del_init(&cur_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
|
|
|
}
|
|
|
|
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,
|
2010-04-03 06:34:43 +08:00
|
|
|
slot_id, ep_index,
|
|
|
|
ep->stopped_td->urb->stream_id,
|
|
|
|
&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 {
|
2010-04-03 06:34:43 +08:00
|
|
|
/* Otherwise ring the doorbell(s) to restart queued transfers */
|
|
|
|
ring_doorbell_for_active_rings(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
|
|
|
}
|
2010-05-07 04:40:08 +08:00
|
|
|
ep->stopped_td = NULL;
|
|
|
|
ep->stopped_trb = NULL;
|
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
|
|
|
|
|
|
|
/*
|
|
|
|
* 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);
|
2011-08-03 06:43:40 +08:00
|
|
|
list_del_init(&cur_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
|
|
|
|
|
|
|
/* 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;
|
2011-10-21 11:52:14 +08:00
|
|
|
unsigned long flags;
|
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
|
|
|
|
|
|
|
ep = (struct xhci_virt_ep *) arg;
|
|
|
|
xhci = ep->xhci;
|
|
|
|
|
2011-10-21 11:52:14 +08:00
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
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
|
|
|
|
|
|
|
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");
|
2011-10-21 11:52:14 +08:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
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
|
|
|
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");
|
2011-10-21 11:52:14 +08:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
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
|
|
|
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);
|
2011-10-21 11:52:14 +08:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
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
|
|
|
|
|
|
|
ret = xhci_halt(xhci);
|
|
|
|
|
2011-10-21 11:52:14 +08:00
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
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
|
|
|
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
|
2011-03-12 00:47:33 +08:00
|
|
|
* disabled. If we call usb_hc_died(), it will attempt to
|
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
|
|
|
* 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);
|
2011-08-03 06:43:40 +08:00
|
|
|
list_del_init(&cur_td->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
|
|
|
if (!list_empty(&cur_td->cancelled_td_list))
|
2011-08-03 06:43:40 +08:00
|
|
|
list_del_init(&cur_td->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_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);
|
2011-08-03 06:43:40 +08:00
|
|
|
list_del_init(&cur_td->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_giveback_urb_in_irq(xhci, cur_td,
|
|
|
|
-ESHUTDOWN, "killed");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2011-10-21 11:52:14 +08:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
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_dbg(xhci, "Calling usb_hc_died()\n");
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
usb_hc_died(xhci_to_hcd(xhci)->primary_hcd);
|
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_dbg(xhci, "xHCI host controller is dead.\n");
|
|
|
|
}
|
|
|
|
|
2012-03-05 17:49:34 +08:00
|
|
|
|
|
|
|
static void update_ring_for_set_deq_completion(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_virt_device *dev,
|
|
|
|
struct xhci_ring *ep_ring,
|
|
|
|
unsigned int ep_index)
|
|
|
|
{
|
|
|
|
union xhci_trb *dequeue_temp;
|
|
|
|
int num_trbs_free_temp;
|
|
|
|
bool revert = false;
|
|
|
|
|
|
|
|
num_trbs_free_temp = ep_ring->num_trbs_free;
|
|
|
|
dequeue_temp = ep_ring->dequeue;
|
|
|
|
|
xhci: Fix hang on back-to-back Set TR Deq Ptr commands.
The Microsoft LifeChat 3000 USB headset was causing a very reproducible
hang whenever it was plugged in. At first, I thought the host
controller was producing bad transfer events, because the log was filled
with errors like:
xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD
However, it turned out to be an xHCI driver bug in the ring expansion
patches. The bug is triggered When there are two ring segments, and a
TD that ends just before a link TRB, like so:
______________ _____________
| | ---> | setup TRB B |
______________ | _____________
| | | | data TRB B |
______________ | _____________
| setup TRB A | <-- deq | | data TRB B |
______________ | _____________
| data TRB A | | | | <-- enq, deq''
______________ | _____________
| status TRB A | | | |
______________ | _____________
| link TRB |--------------- | link TRB |
_____________ <--- deq' _____________
TD A (the first control transfer) stalls on the data phase. That halts
the ring. The xHCI driver moves the hardware dequeue pointer to the
first TRB after the stalled transfer, which happens to be the link TRB.
Once the Set TR dequeue pointer command completes, the function
update_ring_for_set_deq_completion runs. That function is supposed to
update the xHCI driver's dequeue pointer to match the internal hardware
dequeue pointer. On the first call this would work fine, and the
software dequeue pointer would move to deq'.
However, if the transfer immediately after that stalled (TD B in this
case), another Set TR Dequeue command would be issued. That would move
the hardware dequeue pointer to deq''. Once that command completed,
update_ring_for_set_deq_completion would run again.
The original code would unconditionally increment the software dequeue
pointer, which moved the pointer off the ring segment into la-la-land.
The while loop would happy increment the dequeue pointer (possibly
wrapping it) until it matched the hardware pointer value.
The while loop would also access all the memory in between the first
ring segment and the second ring segment to determine if it was a link
TRB. This could cause general protection faults, although it was
unlikely because the ring segments came from a DMA pool, and would often
have consecutive memory addresses.
If nothing in that space looked like a link TRB, the deq_seg pointer for
the ring would remain on the first segment. Thus, the deq_seg and the
software dequeue pointer would get out of sync.
When the next transfer event came in after the stalled transfer, the
xHCI driver code would attempt to convert the software dequeue pointer
into a DMA address in order to compare the DMA address for the completed
transfer. Since the deq_seg and the dequeue pointer were out of sync,
xhci_trb_virt_to_dma would return NULL.
The transfer event would get ignored, the transfer would eventually
timeout, and we would mistakenly convert the finished transfer to no-op
TRBs. Some kernel driver (maybe xHCI?) would then get stuck in an
infinite loop in interrupt context, and the whole machine would hang.
This patch should be backported to kernels as old as 3.4, that contain
the commit b008df60c6369ba0290fa7daa177375407a12e07 "xHCI: count free
TRBs on transfer ring"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@vger.kernel.org
2012-06-22 07:28:30 +08:00
|
|
|
/* If we get two back-to-back stalls, and the first stalled transfer
|
|
|
|
* ends just before a link TRB, the dequeue pointer will be left on
|
|
|
|
* the link TRB by the code in the while loop. So we have to update
|
|
|
|
* the dequeue pointer one segment further, or we'll jump off
|
|
|
|
* the segment into la-la-land.
|
|
|
|
*/
|
|
|
|
if (last_trb(xhci, ep_ring, ep_ring->deq_seg, ep_ring->dequeue)) {
|
|
|
|
ep_ring->deq_seg = ep_ring->deq_seg->next;
|
|
|
|
ep_ring->dequeue = ep_ring->deq_seg->trbs;
|
|
|
|
}
|
|
|
|
|
2012-03-05 17:49:34 +08:00
|
|
|
while (ep_ring->dequeue != dev->eps[ep_index].queued_deq_ptr) {
|
|
|
|
/* We have more usable TRBs */
|
|
|
|
ep_ring->num_trbs_free++;
|
|
|
|
ep_ring->dequeue++;
|
|
|
|
if (last_trb(xhci, ep_ring, ep_ring->deq_seg,
|
|
|
|
ep_ring->dequeue)) {
|
|
|
|
if (ep_ring->dequeue ==
|
|
|
|
dev->eps[ep_index].queued_deq_ptr)
|
|
|
|
break;
|
|
|
|
ep_ring->deq_seg = ep_ring->deq_seg->next;
|
|
|
|
ep_ring->dequeue = ep_ring->deq_seg->trbs;
|
|
|
|
}
|
|
|
|
if (ep_ring->dequeue == dequeue_temp) {
|
|
|
|
revert = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (revert) {
|
|
|
|
xhci_dbg(xhci, "Unable to find new dequeue pointer\n");
|
|
|
|
ep_ring->num_trbs_free = num_trbs_free_temp;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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;
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int stream_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
|
|
|
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
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(trb->generic.field[3]));
|
|
|
|
ep_index = TRB_TO_EP_INDEX(le32_to_cpu(trb->generic.field[3]));
|
|
|
|
stream_id = TRB_TO_STREAM_ID(le32_to_cpu(trb->generic.field[2]));
|
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
|
|
|
dev = xhci->devs[slot_id];
|
2010-04-03 06:34:43 +08:00
|
|
|
|
|
|
|
ep_ring = xhci_stream_id_to_ring(dev, ep_index, stream_id);
|
|
|
|
if (!ep_ring) {
|
|
|
|
xhci_warn(xhci, "WARN Set TR deq ptr command for "
|
|
|
|
"freed stream ID %u\n",
|
|
|
|
stream_id);
|
|
|
|
/* XXX: Harmless??? */
|
|
|
|
dev->eps[ep_index].ep_state &= ~SET_DEQ_PENDING;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
if (GET_COMP_CODE(le32_to_cpu(event->status)) != COMP_SUCCESS) {
|
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_state;
|
|
|
|
unsigned int slot_state;
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
switch (GET_COMP_CODE(le32_to_cpu(event->status))) {
|
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_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");
|
2011-03-29 10:40:46 +08:00
|
|
|
ep_state = le32_to_cpu(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;
|
2011-03-29 10:40:46 +08:00
|
|
|
slot_state = le32_to_cpu(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",
|
2011-03-29 10:40:46 +08:00
|
|
|
GET_COMP_CODE(le32_to_cpu(event->status)));
|
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
|
|
|
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",
|
2011-03-29 10:40:46 +08:00
|
|
|
le64_to_cpu(ep_ctx->deq));
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 07:46:42 +08:00
|
|
|
if (xhci_trb_virt_to_dma(dev->eps[ep_index].queued_deq_seg,
|
2011-03-29 10:40:46 +08:00
|
|
|
dev->eps[ep_index].queued_deq_ptr) ==
|
|
|
|
(le64_to_cpu(ep_ctx->deq) & ~(EP_CTX_CYCLE_MASK))) {
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 07:46:42 +08:00
|
|
|
/* Update the ring's dequeue segment and dequeue pointer
|
|
|
|
* to reflect the new position.
|
|
|
|
*/
|
2012-03-05 17:49:34 +08:00
|
|
|
update_ring_for_set_deq_completion(xhci, dev,
|
|
|
|
ep_ring, ep_index);
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 07:46:42 +08:00
|
|
|
} else {
|
|
|
|
xhci_warn(xhci, "Mismatch between completed Set TR Deq "
|
|
|
|
"Ptr command & xHCI internal state.\n");
|
|
|
|
xhci_warn(xhci, "ep deq seg = %p, deq ptr = %p\n",
|
|
|
|
dev->eps[ep_index].queued_deq_seg,
|
|
|
|
dev->eps[ep_index].queued_deq_ptr);
|
|
|
|
}
|
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;
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 07:46:42 +08:00
|
|
|
dev->eps[ep_index].queued_deq_seg = NULL;
|
|
|
|
dev->eps[ep_index].queued_deq_ptr = NULL;
|
2010-04-03 06:34:43 +08:00
|
|
|
/* Restart any rings with pending URBs */
|
|
|
|
ring_doorbell_for_active_rings(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
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(trb->generic.field[3]));
|
|
|
|
ep_index = TRB_TO_EP_INDEX(le32_to_cpu(trb->generic.field[3]));
|
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",
|
2011-06-01 08:22:55 +08:00
|
|
|
GET_COMP_CODE(le32_to_cpu(event->status)));
|
2009-07-28 03:03:15 +08:00
|
|
|
|
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 {
|
2010-04-03 06:34:43 +08:00
|
|
|
/* Clear our internal halted state and restart the ring(s) */
|
2009-09-05 01:53:09 +08:00
|
|
|
xhci->devs[slot_id]->eps[ep_index].ep_state &= ~EP_HALTED;
|
2010-04-03 06:34:43 +08:00
|
|
|
ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
|
2009-08-08 05:04:55 +08:00
|
|
|
}
|
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
|
|
|
|
xHCI: handle command after aborting the command ring
According to xHCI spec section 4.6.1.1 and section 4.6.1.2,
after aborting a command on the command ring, xHC will
generate a command completion event with its completion
code set to Command Ring Stopped at least. If a command is
currently executing at the time of aborting a command, xHC
also generate a command completion event with its completion
code set to Command Abort. When the command ring is stopped,
software may remove, add, or rearrage Command Descriptors.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci. When the command ring is stopped,
software will find the command trbs described by command
descriptors in cancel_cmd_list and modify it to No Op
command. If software can't find the matched trbs, we can
think it had been finished.
This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Cc: stable@vger.kernel.org
2012-06-27 16:55:43 +08:00
|
|
|
/* Complete the command and detele it from the devcie's command queue.
|
|
|
|
*/
|
|
|
|
static void xhci_complete_cmd_in_cmd_wait_list(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_command *command, u32 status)
|
|
|
|
{
|
|
|
|
command->status = status;
|
|
|
|
list_del(&command->cmd_list);
|
|
|
|
if (command->completion)
|
|
|
|
complete(command->completion);
|
|
|
|
else
|
|
|
|
xhci_free_command(xhci, command);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
xHCI: handle command after aborting the command ring
According to xHCI spec section 4.6.1.1 and section 4.6.1.2,
after aborting a command on the command ring, xHC will
generate a command completion event with its completion
code set to Command Ring Stopped at least. If a command is
currently executing at the time of aborting a command, xHC
also generate a command completion event with its completion
code set to Command Abort. When the command ring is stopped,
software may remove, add, or rearrage Command Descriptors.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci. When the command ring is stopped,
software will find the command trbs described by command
descriptors in cancel_cmd_list and modify it to No Op
command. If software can't find the matched trbs, we can
think it had been finished.
This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Cc: stable@vger.kernel.org
2012-06-27 16:55:43 +08:00
|
|
|
xhci_complete_cmd_in_cmd_wait_list(xhci, command,
|
|
|
|
GET_COMP_CODE(le32_to_cpu(event->status)));
|
2009-09-05 01:53:15 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
xHCI: handle command after aborting the command ring
According to xHCI spec section 4.6.1.1 and section 4.6.1.2,
after aborting a command on the command ring, xHC will
generate a command completion event with its completion
code set to Command Ring Stopped at least. If a command is
currently executing at the time of aborting a command, xHC
also generate a command completion event with its completion
code set to Command Abort. When the command ring is stopped,
software may remove, add, or rearrage Command Descriptors.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci. When the command ring is stopped,
software will find the command trbs described by command
descriptors in cancel_cmd_list and modify it to No Op
command. If software can't find the matched trbs, we can
think it had been finished.
This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Cc: stable@vger.kernel.org
2012-06-27 16:55:43 +08:00
|
|
|
/*
|
|
|
|
* Finding the command trb need to be cancelled and modifying it to
|
|
|
|
* NO OP command. And if the command is in device's command wait
|
|
|
|
* list, finishing and freeing it.
|
|
|
|
*
|
|
|
|
* If we can't find the command trb, we think it had already been
|
|
|
|
* executed.
|
|
|
|
*/
|
|
|
|
static void xhci_cmd_to_noop(struct xhci_hcd *xhci, struct xhci_cd *cur_cd)
|
|
|
|
{
|
|
|
|
struct xhci_segment *cur_seg;
|
|
|
|
union xhci_trb *cmd_trb;
|
|
|
|
u32 cycle_state;
|
|
|
|
|
|
|
|
if (xhci->cmd_ring->dequeue == xhci->cmd_ring->enqueue)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* find the current segment of command ring */
|
|
|
|
cur_seg = find_trb_seg(xhci->cmd_ring->first_seg,
|
|
|
|
xhci->cmd_ring->dequeue, &cycle_state);
|
|
|
|
|
2012-10-17 04:17:43 +08:00
|
|
|
if (!cur_seg) {
|
|
|
|
xhci_warn(xhci, "Command ring mismatch, dequeue = %p %llx (dma)\n",
|
|
|
|
xhci->cmd_ring->dequeue,
|
|
|
|
(unsigned long long)
|
|
|
|
xhci_trb_virt_to_dma(xhci->cmd_ring->deq_seg,
|
|
|
|
xhci->cmd_ring->dequeue));
|
|
|
|
xhci_debug_ring(xhci, xhci->cmd_ring);
|
|
|
|
xhci_dbg_ring_ptrs(xhci, xhci->cmd_ring);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
xHCI: handle command after aborting the command ring
According to xHCI spec section 4.6.1.1 and section 4.6.1.2,
after aborting a command on the command ring, xHC will
generate a command completion event with its completion
code set to Command Ring Stopped at least. If a command is
currently executing at the time of aborting a command, xHC
also generate a command completion event with its completion
code set to Command Abort. When the command ring is stopped,
software may remove, add, or rearrage Command Descriptors.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci. When the command ring is stopped,
software will find the command trbs described by command
descriptors in cancel_cmd_list and modify it to No Op
command. If software can't find the matched trbs, we can
think it had been finished.
This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Cc: stable@vger.kernel.org
2012-06-27 16:55:43 +08:00
|
|
|
/* find the command trb matched by cd from command ring */
|
|
|
|
for (cmd_trb = xhci->cmd_ring->dequeue;
|
|
|
|
cmd_trb != xhci->cmd_ring->enqueue;
|
|
|
|
next_trb(xhci, xhci->cmd_ring, &cur_seg, &cmd_trb)) {
|
|
|
|
/* If the trb is link trb, continue */
|
|
|
|
if (TRB_TYPE_LINK_LE32(cmd_trb->generic.field[3]))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (cur_cd->cmd_trb == cmd_trb) {
|
|
|
|
|
|
|
|
/* If the command in device's command list, we should
|
|
|
|
* finish it and free the command structure.
|
|
|
|
*/
|
|
|
|
if (cur_cd->command)
|
|
|
|
xhci_complete_cmd_in_cmd_wait_list(xhci,
|
|
|
|
cur_cd->command, COMP_CMD_STOP);
|
|
|
|
|
|
|
|
/* get cycle state from the origin command trb */
|
|
|
|
cycle_state = le32_to_cpu(cmd_trb->generic.field[3])
|
|
|
|
& TRB_CYCLE;
|
|
|
|
|
|
|
|
/* modify the command trb to NO OP command */
|
|
|
|
cmd_trb->generic.field[0] = 0;
|
|
|
|
cmd_trb->generic.field[1] = 0;
|
|
|
|
cmd_trb->generic.field[2] = 0;
|
|
|
|
cmd_trb->generic.field[3] = cpu_to_le32(
|
|
|
|
TRB_TYPE(TRB_CMD_NOOP) | cycle_state);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void xhci_cancel_cmd_in_cd_list(struct xhci_hcd *xhci)
|
|
|
|
{
|
|
|
|
struct xhci_cd *cur_cd, *next_cd;
|
|
|
|
|
|
|
|
if (list_empty(&xhci->cancel_cmd_list))
|
|
|
|
return;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(cur_cd, next_cd,
|
|
|
|
&xhci->cancel_cmd_list, cancel_cmd_list) {
|
|
|
|
xhci_cmd_to_noop(xhci, cur_cd);
|
|
|
|
list_del(&cur_cd->cancel_cmd_list);
|
|
|
|
kfree(cur_cd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* traversing the cancel_cmd_list. If the command descriptor according
|
|
|
|
* to cmd_trb is found, the function free it and return 1, otherwise
|
|
|
|
* return 0.
|
|
|
|
*/
|
|
|
|
static int xhci_search_cmd_trb_in_cd_list(struct xhci_hcd *xhci,
|
|
|
|
union xhci_trb *cmd_trb)
|
|
|
|
{
|
|
|
|
struct xhci_cd *cur_cd, *next_cd;
|
|
|
|
|
|
|
|
if (list_empty(&xhci->cancel_cmd_list))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(cur_cd, next_cd,
|
|
|
|
&xhci->cancel_cmd_list, cancel_cmd_list) {
|
|
|
|
if (cur_cd->cmd_trb == cmd_trb) {
|
|
|
|
if (cur_cd->command)
|
|
|
|
xhci_complete_cmd_in_cmd_wait_list(xhci,
|
|
|
|
cur_cd->command, COMP_CMD_STOP);
|
|
|
|
list_del(&cur_cd->cancel_cmd_list);
|
|
|
|
kfree(cur_cd);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the cmd_trb_comp_code is COMP_CMD_ABORT, we just check whether the
|
|
|
|
* trb pointed by the command ring dequeue pointer is the trb we want to
|
|
|
|
* cancel or not. And if the cmd_trb_comp_code is COMP_CMD_STOP, we will
|
|
|
|
* traverse the cancel_cmd_list to trun the all of the commands according
|
|
|
|
* to command descriptor to NO-OP trb.
|
|
|
|
*/
|
|
|
|
static int handle_stopped_cmd_ring(struct xhci_hcd *xhci,
|
|
|
|
int cmd_trb_comp_code)
|
|
|
|
{
|
|
|
|
int cur_trb_is_good = 0;
|
|
|
|
|
|
|
|
/* Searching the cmd trb pointed by the command ring dequeue
|
|
|
|
* pointer in command descriptor list. If it is found, free it.
|
|
|
|
*/
|
|
|
|
cur_trb_is_good = xhci_search_cmd_trb_in_cd_list(xhci,
|
|
|
|
xhci->cmd_ring->dequeue);
|
|
|
|
|
|
|
|
if (cmd_trb_comp_code == COMP_CMD_ABORT)
|
|
|
|
xhci->cmd_ring_state = CMD_RING_STATE_STOPPED;
|
|
|
|
else if (cmd_trb_comp_code == COMP_CMD_STOP) {
|
|
|
|
/* traversing the cancel_cmd_list and canceling
|
|
|
|
* the command according to command descriptor
|
|
|
|
*/
|
|
|
|
xhci_cancel_cmd_in_cd_list(xhci);
|
|
|
|
|
|
|
|
xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
|
|
|
|
/*
|
|
|
|
* ring command ring doorbell again to restart the
|
|
|
|
* command ring
|
|
|
|
*/
|
|
|
|
if (xhci->cmd_ring->dequeue != xhci->cmd_ring->enqueue)
|
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
}
|
|
|
|
return cur_trb_is_good;
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:53:56 +08:00
|
|
|
static void handle_cmd_completion(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_event_cmd *event)
|
|
|
|
{
|
2011-03-29 10:40:46 +08:00
|
|
|
int slot_id = TRB_TO_SLOT_ID(le32_to_cpu(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
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
cmd_dma = le64_to_cpu(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;
|
|
|
|
}
|
xHCI: handle command after aborting the command ring
According to xHCI spec section 4.6.1.1 and section 4.6.1.2,
after aborting a command on the command ring, xHC will
generate a command completion event with its completion
code set to Command Ring Stopped at least. If a command is
currently executing at the time of aborting a command, xHC
also generate a command completion event with its completion
code set to Command Abort. When the command ring is stopped,
software may remove, add, or rearrage Command Descriptors.
To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci. When the command ring is stopped,
software will find the command trbs described by command
descriptors in cancel_cmd_list and modify it to No Op
command. If software can't find the matched trbs, we can
think it had been finished.
This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.
Signed-off-by: Elric Fu <elricfu1@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Miroslav Sabljic <miroslav.sabljic@avl.com>
Cc: stable@vger.kernel.org
2012-06-27 16:55:43 +08:00
|
|
|
|
|
|
|
if ((GET_COMP_CODE(le32_to_cpu(event->status)) == COMP_CMD_ABORT) ||
|
|
|
|
(GET_COMP_CODE(le32_to_cpu(event->status)) == COMP_CMD_STOP)) {
|
|
|
|
/* If the return value is 0, we think the trb pointed by
|
|
|
|
* command ring dequeue pointer is a good trb. The good
|
|
|
|
* trb means we don't want to cancel the trb, but it have
|
|
|
|
* been stopped by host. So we should handle it normally.
|
|
|
|
* Otherwise, driver should invoke inc_deq() and return.
|
|
|
|
*/
|
|
|
|
if (handle_stopped_cmd_ring(xhci,
|
|
|
|
GET_COMP_CODE(le32_to_cpu(event->status)))) {
|
|
|
|
inc_deq(xhci, xhci->cmd_ring);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
switch (le32_to_cpu(xhci->cmd_ring->dequeue->generic.field[3])
|
|
|
|
& TRB_TYPE_BITMASK) {
|
2009-04-28 10:57:38 +08:00
|
|
|
case TRB_TYPE(TRB_ENABLE_SLOT):
|
2011-03-29 10:40:46 +08:00
|
|
|
if (GET_COMP_CODE(le32_to_cpu(event->status)) == COMP_SUCCESS)
|
2009-04-28 10:57:38 +08:00
|
|
|
xhci->slot_id = slot_id;
|
|
|
|
else
|
|
|
|
xhci->slot_id = 0;
|
|
|
|
complete(&xhci->addr_dev);
|
|
|
|
break;
|
|
|
|
case TRB_TYPE(TRB_DISABLE_SLOT):
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-12 07:14:58 +08:00
|
|
|
if (xhci->devs[slot_id]) {
|
|
|
|
if (xhci->quirks & XHCI_EP_LIMIT_QUIRK)
|
|
|
|
/* Delete default control endpoint resources */
|
|
|
|
xhci_free_device_endpoint_resources(xhci,
|
|
|
|
xhci->devs[slot_id], true);
|
2009-04-28 10:57:38 +08:00
|
|
|
xhci_free_virt_device(xhci, slot_id);
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-12 07:14:58 +08:00
|
|
|
}
|
2009-04-28 10:57:38 +08:00
|
|
|
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
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
* endpoint command or streams were being configured.
|
|
|
|
* If the command was for a halted endpoint, the xHCI driver
|
|
|
|
* is not waiting on the configure endpoint command.
|
2009-08-08 05:04:55 +08:00
|
|
|
*/
|
|
|
|
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 */
|
2011-03-29 10:40:46 +08:00
|
|
|
ep_index = xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx->add_flags)) - 1;
|
2009-12-04 01:44:31 +08:00
|
|
|
/* A usb_set_interface() call directly after clearing a halted
|
2010-04-03 06:34:43 +08:00
|
|
|
* condition may race on this quirky hardware. Not worth
|
|
|
|
* worrying about, since this is prototype hardware. Not sure
|
|
|
|
* if this will work for streams, but streams support was
|
|
|
|
* untested on this prototype.
|
2009-12-04 01:44:31 +08:00
|
|
|
*/
|
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 &&
|
2011-03-29 10:40:46 +08:00
|
|
|
le32_to_cpu(ctrl_ctx->add_flags) - SLOT_FLAG ==
|
|
|
|
le32_to_cpu(ctrl_ctx->drop_flags)) {
|
2009-12-04 01:44:31 +08:00
|
|
|
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);
|
2010-04-03 06:34:43 +08:00
|
|
|
/* Clear internal halted state and restart ring(s) */
|
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;
|
2010-04-03 06:34:43 +08:00
|
|
|
ring_doorbell_for_active_rings(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 =
|
2011-03-29 10:40:46 +08:00
|
|
|
GET_COMP_CODE(le32_to_cpu(event->status));
|
2009-12-04 01:44:31 +08:00
|
|
|
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;
|
2011-03-29 10:40:46 +08:00
|
|
|
xhci->devs[slot_id]->cmd_status = GET_COMP_CODE(le32_to_cpu(event->status));
|
2009-08-08 05:04:49 +08:00
|
|
|
complete(&xhci->devs[slot_id]->cmd_completion);
|
|
|
|
break;
|
2009-04-28 10:57:38 +08:00
|
|
|
case TRB_TYPE(TRB_ADDR_DEV):
|
2011-03-29 10:40:46 +08:00
|
|
|
xhci->devs[slot_id]->cmd_status = GET_COMP_CODE(le32_to_cpu(event->status));
|
2009-04-28 10:57:38 +08:00
|
|
|
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):
|
2010-10-14 22:22:57 +08:00
|
|
|
handle_stopped_endpoint(xhci, xhci->cmd_ring->dequeue, event);
|
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
|
|
|
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):
|
|
|
|
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-12-10 07:59:13 +08:00
|
|
|
case TRB_TYPE(TRB_RESET_DEV):
|
|
|
|
xhci_dbg(xhci, "Completed reset device command.\n");
|
|
|
|
slot_id = TRB_TO_SLOT_ID(
|
2011-03-29 10:40:46 +08:00
|
|
|
le32_to_cpu(xhci->cmd_ring->dequeue->generic.field[3]));
|
2009-12-10 07:59:13 +08:00
|
|
|
virt_dev = xhci->devs[slot_id];
|
|
|
|
if (virt_dev)
|
|
|
|
handle_cmd_in_cmd_wait_list(xhci, virt_dev, event);
|
|
|
|
else
|
|
|
|
xhci_warn(xhci, "Reset device command completion "
|
|
|
|
"for disabled slot %u\n", slot_id);
|
|
|
|
break;
|
2010-05-25 04:25:28 +08:00
|
|
|
case TRB_TYPE(TRB_NEC_GET_FW):
|
|
|
|
if (!(xhci->quirks & XHCI_NEC_HOST)) {
|
|
|
|
xhci->error_bitmask |= 1 << 6;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
xhci_dbg(xhci, "NEC firmware version %2x.%02x\n",
|
2011-03-29 10:40:46 +08:00
|
|
|
NEC_FW_MAJOR(le32_to_cpu(event->status)),
|
|
|
|
NEC_FW_MINOR(le32_to_cpu(event->status)));
|
2010-05-25 04:25:28 +08:00
|
|
|
break;
|
2009-04-28 10:53:56 +08:00
|
|
|
default:
|
|
|
|
/* Skip over unknown commands on the event ring */
|
|
|
|
xhci->error_bitmask |= 1 << 6;
|
|
|
|
break;
|
|
|
|
}
|
2012-03-05 17:49:32 +08:00
|
|
|
inc_deq(xhci, xhci->cmd_ring);
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
2010-05-25 04:25:28 +08:00
|
|
|
static void handle_vendor_event(struct xhci_hcd *xhci,
|
|
|
|
union xhci_trb *event)
|
|
|
|
{
|
|
|
|
u32 trb_type;
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
trb_type = TRB_FIELD_TO_TYPE(le32_to_cpu(event->generic.field[3]));
|
2010-05-25 04:25:28 +08:00
|
|
|
xhci_dbg(xhci, "Vendor specific event TRB type = %u\n", trb_type);
|
|
|
|
if (trb_type == TRB_NEC_CMD_COMP && (xhci->quirks & XHCI_NEC_HOST))
|
|
|
|
handle_cmd_completion(xhci, &event->event_cmd);
|
|
|
|
}
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
/* @port_id: the one-based port ID from the hardware (indexed from array of all
|
|
|
|
* port registers -- USB 3.0 and USB 2.0).
|
|
|
|
*
|
|
|
|
* Returns a zero-based port number, which is suitable for indexing into each of
|
|
|
|
* the split roothubs' port arrays and bus state arrays.
|
2011-11-15 09:51:39 +08:00
|
|
|
* Add one to it in order to call xhci_find_slot_id_by_port.
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
*/
|
|
|
|
static unsigned int find_faked_portnum_from_hw_portnum(struct usb_hcd *hcd,
|
|
|
|
struct xhci_hcd *xhci, u32 port_id)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
unsigned int num_similar_speed_ports = 0;
|
|
|
|
|
|
|
|
/* port_id from the hardware is 1-based, but port_array[], usb3_ports[],
|
|
|
|
* and usb2_ports are 0-based indexes. Count the number of similar
|
|
|
|
* speed ports, up to 1 port before this port.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < (port_id - 1); i++) {
|
|
|
|
u8 port_speed = xhci->port_array[i];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip ports that don't have known speeds, or have duplicate
|
|
|
|
* Extended Capabilities port speed entries.
|
|
|
|
*/
|
2011-03-18 03:39:49 +08:00
|
|
|
if (port_speed == 0 || port_speed == DUPLICATE_ENTRY)
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* USB 3.0 ports are always under a USB 3.0 hub. USB 2.0 and
|
|
|
|
* 1.1 ports are under the USB 2.0 hub. If the port speed
|
|
|
|
* matches the device speed, it's a similar speed port.
|
|
|
|
*/
|
|
|
|
if ((port_speed == 0x03) == (hcd->speed == HCD_USB3))
|
|
|
|
num_similar_speed_ports++;
|
|
|
|
}
|
|
|
|
return num_similar_speed_ports;
|
|
|
|
}
|
|
|
|
|
2011-11-12 06:57:33 +08:00
|
|
|
static void handle_device_notification(struct xhci_hcd *xhci,
|
|
|
|
union xhci_trb *event)
|
|
|
|
{
|
|
|
|
u32 slot_id;
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 10:00:01 +08:00
|
|
|
struct usb_device *udev;
|
2011-11-12 06:57:33 +08:00
|
|
|
|
|
|
|
slot_id = TRB_TO_SLOT_ID(event->generic.field[3]);
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 10:00:01 +08:00
|
|
|
if (!xhci->devs[slot_id]) {
|
2011-11-12 06:57:33 +08:00
|
|
|
xhci_warn(xhci, "Device Notification event for "
|
|
|
|
"unused slot %u\n", slot_id);
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 10:00:01 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Device Wake Notification event for slot ID %u\n",
|
|
|
|
slot_id);
|
|
|
|
udev = xhci->devs[slot_id]->udev;
|
|
|
|
if (udev && udev->parent)
|
|
|
|
usb_wakeup_notification(udev->parent, udev->portnum);
|
2011-11-12 06:57:33 +08:00
|
|
|
}
|
|
|
|
|
2009-04-28 10:57:12 +08:00
|
|
|
static void handle_port_status(struct xhci_hcd *xhci,
|
|
|
|
union xhci_trb *event)
|
|
|
|
{
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
struct usb_hcd *hcd;
|
2009-04-28 10:57:12 +08:00
|
|
|
u32 port_id;
|
2010-10-14 22:23:00 +08:00
|
|
|
u32 temp, temp1;
|
2010-12-16 03:56:29 +08:00
|
|
|
int max_ports;
|
2010-10-14 22:23:00 +08:00
|
|
|
int slot_id;
|
2010-12-02 03:34:59 +08:00
|
|
|
unsigned int faked_port_index;
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
u8 major_revision;
|
2010-12-16 04:47:14 +08:00
|
|
|
struct xhci_bus_state *bus_state;
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 __iomem **port_array;
|
2011-03-24 23:02:58 +08:00
|
|
|
bool bogus_port_status = false;
|
2009-04-28 10:57:12 +08:00
|
|
|
|
|
|
|
/* Port status change events always have a successful completion code */
|
2011-03-29 10:40:46 +08:00
|
|
|
if (GET_COMP_CODE(le32_to_cpu(event->generic.field[2])) != COMP_SUCCESS) {
|
2009-04-28 10:57:12 +08:00
|
|
|
xhci_warn(xhci, "WARN: xHC returned failed port status event\n");
|
|
|
|
xhci->error_bitmask |= 1 << 8;
|
|
|
|
}
|
2011-03-29 10:40:46 +08:00
|
|
|
port_id = GET_PORT_ID(le32_to_cpu(event->generic.field[0]));
|
2009-04-28 10:57:12 +08:00
|
|
|
xhci_dbg(xhci, "Port Status Change Event for port %d\n", port_id);
|
|
|
|
|
2010-12-16 03:56:29 +08:00
|
|
|
max_ports = HCS_MAX_PORTS(xhci->hcs_params1);
|
|
|
|
if ((port_id <= 0) || (port_id > max_ports)) {
|
2010-10-14 22:23:00 +08:00
|
|
|
xhci_warn(xhci, "Invalid port id %d\n", port_id);
|
2013-03-20 09:30:00 +08:00
|
|
|
inc_deq(xhci, xhci->event_ring);
|
|
|
|
return;
|
2010-10-14 22:23:00 +08:00
|
|
|
}
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
/* Figure out which usb_hcd this port is attached to:
|
|
|
|
* is it a USB 3.0 port or a USB 2.0/1.1 port?
|
|
|
|
*/
|
|
|
|
major_revision = xhci->port_array[port_id - 1];
|
2013-03-20 09:30:00 +08:00
|
|
|
|
|
|
|
/* Find the right roothub. */
|
|
|
|
hcd = xhci_to_hcd(xhci);
|
|
|
|
if ((major_revision == 0x03) != (hcd->speed == HCD_USB3))
|
|
|
|
hcd = xhci->shared_hcd;
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
if (major_revision == 0) {
|
|
|
|
xhci_warn(xhci, "Event for port %u not in "
|
|
|
|
"Extended Capabilities, ignoring.\n",
|
|
|
|
port_id);
|
2011-03-24 23:02:58 +08:00
|
|
|
bogus_port_status = true;
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
goto cleanup;
|
2010-12-02 03:34:59 +08:00
|
|
|
}
|
2011-03-18 03:39:49 +08:00
|
|
|
if (major_revision == DUPLICATE_ENTRY) {
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
xhci_warn(xhci, "Event for port %u duplicated in"
|
|
|
|
"Extended Capabilities, ignoring.\n",
|
|
|
|
port_id);
|
2011-03-24 23:02:58 +08:00
|
|
|
bogus_port_status = true;
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Hardware port IDs reported by a Port Status Change Event include USB
|
|
|
|
* 3.0 and USB 2.0 ports. We want to check if the port has reported a
|
|
|
|
* resume event, but we first need to translate the hardware port ID
|
|
|
|
* into the index into the ports on the correct split roothub, and the
|
|
|
|
* correct bus_state structure.
|
|
|
|
*/
|
|
|
|
bus_state = &xhci->bus_state[hcd_index(hcd)];
|
|
|
|
if (hcd->speed == HCD_USB3)
|
|
|
|
port_array = xhci->usb3_ports;
|
|
|
|
else
|
|
|
|
port_array = xhci->usb2_ports;
|
|
|
|
/* Find the faked port hub number */
|
|
|
|
faked_port_index = find_faked_portnum_from_hw_portnum(hcd, xhci,
|
|
|
|
port_id);
|
2010-12-02 03:34:59 +08:00
|
|
|
|
|
|
|
temp = xhci_readl(xhci, port_array[faked_port_index]);
|
xhci: Resume bus on any port status change.
The original code that resumed the USB bus on a port status change would
only do so when there was a device connected to the port. If a device was
just disconnected, the event would be queued for khubd, but khubd wouldn't
run. That would leave the connect status change (CSC) bit set.
If a USB device was plugged into that same port, the xHCI host controller
would set the current connect status (CCS) bit. But since the CSC bit was
already set, it would not generate an interrupt for a port status change
event. That would mean the user could "Safely Remove" a device, have the
bus suspend, disconnect the device, re-plug it in, and then the device
would never be enumerated.
Plugging in a different device on another port would cause the bus to
resume, and khubd would notice the re-connected device. Running lsusb
would also resume the bus, leading users to report the problem "went away"
when using diagnostic tools.
The solution is to resume the bus when a port status change event is
received, regardless of the port status.
Thank you very much to Maddog for helping me track down this Heisenbug.
This patch should be queued for the 2.6.37 stable tree.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Jon 'maddog' Hall <maddog@li.org>
Tested-by: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2010-12-15 05:24:55 +08:00
|
|
|
if (hcd->state == HC_STATE_SUSPENDED) {
|
2010-10-14 22:23:00 +08:00
|
|
|
xhci_dbg(xhci, "resume root hub\n");
|
|
|
|
usb_hcd_resume_root_hub(hcd);
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((temp & PORT_PLC) && (temp & PORT_PLS_MASK) == XDEV_RESUME) {
|
|
|
|
xhci_dbg(xhci, "port resume event for port %d\n", port_id);
|
|
|
|
|
|
|
|
temp1 = xhci_readl(xhci, &xhci->op_regs->command);
|
|
|
|
if (!(temp1 & CMD_RUN)) {
|
|
|
|
xhci_warn(xhci, "xHC is not running.\n");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (DEV_SUPERSPEED(temp)) {
|
2012-01-25 08:39:02 +08:00
|
|
|
xhci_dbg(xhci, "remote wake SS port %d\n", port_id);
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 10:00:01 +08:00
|
|
|
/* Set a flag to say the port signaled remote wakeup,
|
|
|
|
* so we can tell the difference between the end of
|
|
|
|
* device and host initiated resume.
|
|
|
|
*/
|
|
|
|
bus_state->port_remote_wakeup |= 1 << faked_port_index;
|
2012-01-25 08:39:02 +08:00
|
|
|
xhci_test_and_clear_bit(xhci, port_array,
|
|
|
|
faked_port_index, PORT_PLC);
|
2011-09-24 05:19:48 +08:00
|
|
|
xhci_set_link_state(xhci, port_array, faked_port_index,
|
|
|
|
XDEV_U0);
|
2012-01-25 08:39:02 +08:00
|
|
|
/* Need to wait until the next link state change
|
|
|
|
* indicates the device is actually in U0.
|
|
|
|
*/
|
|
|
|
bogus_port_status = true;
|
|
|
|
goto cleanup;
|
2010-10-14 22:23:00 +08:00
|
|
|
} else {
|
|
|
|
xhci_dbg(xhci, "resume HS port %d\n", port_id);
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
bus_state->resume_done[faked_port_index] = jiffies +
|
2010-10-14 22:23:00 +08:00
|
|
|
msecs_to_jiffies(20);
|
2012-04-14 02:54:30 +08:00
|
|
|
set_bit(faked_port_index, &bus_state->resuming_ports);
|
2010-10-14 22:23:00 +08:00
|
|
|
mod_timer(&hcd->rh_timer,
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
bus_state->resume_done[faked_port_index]);
|
2010-10-14 22:23:00 +08:00
|
|
|
/* Do the rest in GetPortStatus */
|
|
|
|
}
|
|
|
|
}
|
2012-01-25 08:39:02 +08:00
|
|
|
|
|
|
|
if ((temp & PORT_PLC) && (temp & PORT_PLS_MASK) == XDEV_U0 &&
|
|
|
|
DEV_SUPERSPEED(temp)) {
|
|
|
|
xhci_dbg(xhci, "resume SS port %d finished\n", port_id);
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 10:00:01 +08:00
|
|
|
/* We've just brought the device into U0 through either the
|
|
|
|
* Resume state after a device remote wakeup, or through the
|
|
|
|
* U3Exit state after a host-initiated resume. If it's a device
|
|
|
|
* initiated remote wake, don't pass up the link state change,
|
|
|
|
* so the roothub behavior is consistent with external
|
|
|
|
* USB 3.0 hub behavior.
|
|
|
|
*/
|
2012-01-25 08:39:02 +08:00
|
|
|
slot_id = xhci_find_slot_id_by_port(hcd, xhci,
|
|
|
|
faked_port_index + 1);
|
|
|
|
if (slot_id && xhci->devs[slot_id])
|
|
|
|
xhci_ring_device(xhci, slot_id);
|
2013-01-08 11:39:31 +08:00
|
|
|
if (bus_state->port_remote_wakeup & (1 << faked_port_index)) {
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 10:00:01 +08:00
|
|
|
bus_state->port_remote_wakeup &=
|
|
|
|
~(1 << faked_port_index);
|
|
|
|
xhci_test_and_clear_bit(xhci, port_array,
|
|
|
|
faked_port_index, PORT_PLC);
|
|
|
|
usb_wakeup_notification(hcd->self.root_hub,
|
|
|
|
faked_port_index + 1);
|
|
|
|
bogus_port_status = true;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2012-01-25 08:39:02 +08:00
|
|
|
}
|
2010-10-14 22:23:00 +08:00
|
|
|
|
2011-09-24 05:19:50 +08:00
|
|
|
if (hcd->speed != HCD_USB3)
|
|
|
|
xhci_test_and_clear_bit(xhci, port_array, faked_port_index,
|
|
|
|
PORT_PLC);
|
|
|
|
|
2010-10-14 22:23:00 +08:00
|
|
|
cleanup:
|
2009-04-28 10:57:12 +08:00
|
|
|
/* Update event ring dequeue pointer before dropping the lock */
|
2012-03-05 17:49:32 +08:00
|
|
|
inc_deq(xhci, xhci->event_ring);
|
2009-04-28 10:57:12 +08:00
|
|
|
|
2011-03-24 23:02:58 +08:00
|
|
|
/* Don't make the USB core poll the roothub if we got a bad port status
|
|
|
|
* change event. Besides, at that point we can't tell which roothub
|
|
|
|
* (USB 2.0 or USB 3.0) to kick.
|
|
|
|
*/
|
|
|
|
if (bogus_port_status)
|
|
|
|
return;
|
|
|
|
|
xhci: Avoid "dead ports", add roothub port polling.
The USB core hub thread (khubd) is designed with external USB hubs in
mind. It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.
The xHCI host controller is designed to be edge-triggered on the logical
'OR' of all the port status change bits. When all port status change
bits are clear, and a new change bit is set, the xHC will generate a
Port Status Change Event. If another change bit is set in the same port
status register before the first bit is cleared, it will not send
another event.
This means that the hub code may lose port status changes because of
race conditions between clearing change bits. The user sees this as a
"dead port" that doesn't react to device connects.
The fix is to turn on port polling whenever a new change bit is set.
Once the USB core issues a hub status request that shows that no change
bits are set in any USB ports, turn off port polling.
We can't allow the USB core to poll the roothub for port events during
host suspend because if the PCI host is in D3cold, the port registers
will be all f's. Instead, stop the port polling timer, and
unconditionally restart it when the host resumes. If there are no port
change bits set after the resume, the first call to hub_status_data will
disable polling.
This patch should be backported to stable kernels with the first xHCI
support, 2.6.31 and newer, that include the commit
0f2a79300a1471cf92ab43af165ea13555c8b0a5 "USB: xhci: Root hub support."
There will be merge conflicts because the check for HC_STATE_SUSPENDED
was moved into xhci_suspend in 3.8.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
2012-11-28 04:30:23 +08:00
|
|
|
/*
|
|
|
|
* xHCI port-status-change events occur when the "or" of all the
|
|
|
|
* status-change bits in the portsc register changes from 0 to 1.
|
|
|
|
* New status changes won't cause an event if any other change
|
|
|
|
* bits are still set. When an event occurs, switch over to
|
|
|
|
* polling to avoid losing status changes.
|
|
|
|
*/
|
|
|
|
xhci_dbg(xhci, "%s: starting port polling.\n", __func__);
|
|
|
|
set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
|
2009-04-28 10:57:12 +08:00
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
/* Pass this up to the core */
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
usb_hcd_poll_rh_status(hcd);
|
2009-04-28 10:57:12 +08:00
|
|
|
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)
|
2010-04-19 23:53:50 +08:00
|
|
|
return NULL;
|
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;
|
|
|
|
}
|
2010-04-19 23:53:50 +08:00
|
|
|
return NULL;
|
2009-04-28 10:58:01 +08:00
|
|
|
} 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
|
|
|
|
2010-04-19 23:53:50 +08:00
|
|
|
return NULL;
|
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,
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int stream_id,
|
2009-11-12 02:28:44 +08:00
|
|
|
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;
|
2010-04-03 06:34:43 +08:00
|
|
|
ep->stopped_stream = stream_id;
|
2010-05-07 04:40:08 +08:00
|
|
|
|
2009-11-12 02:28:44 +08:00
|
|
|
xhci_queue_reset_ep(xhci, slot_id, ep_index);
|
|
|
|
xhci_cleanup_stalled_ring(xhci, td->urb->dev, ep_index);
|
2010-05-07 04:40:08 +08:00
|
|
|
|
|
|
|
ep->stopped_td = NULL;
|
|
|
|
ep->stopped_trb = NULL;
|
2010-05-07 04:40:18 +08:00
|
|
|
ep->stopped_stream = 0;
|
2010-05-07 04:40:08 +08:00
|
|
|
|
2009-11-12 02:28:44 +08:00
|
|
|
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.
|
|
|
|
*/
|
2011-06-01 08:22:55 +08:00
|
|
|
if ((ep_ctx->ep_info & cpu_to_le32(EP_STATE_MASK)) ==
|
|
|
|
cpu_to_le32(EP_STATE_HALTED))
|
2009-11-12 02:28:44 +08:00
|
|
|
return 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-12-10 07:59:06 +08:00
|
|
|
int xhci_is_vendor_info_code(struct xhci_hcd *xhci, unsigned int trb_comp_code)
|
|
|
|
{
|
|
|
|
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");
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-07-23 06:22:55 +08:00
|
|
|
/*
|
|
|
|
* Finish the td processing, remove the td from td list;
|
|
|
|
* Return 1 if the urb can be given back.
|
|
|
|
*/
|
|
|
|
static int finish_td(struct xhci_hcd *xhci, struct xhci_td *td,
|
|
|
|
union xhci_trb *event_trb, struct xhci_transfer_event *event,
|
|
|
|
struct xhci_virt_ep *ep, int *status, bool skip)
|
|
|
|
{
|
|
|
|
struct xhci_virt_device *xdev;
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
unsigned int slot_id;
|
|
|
|
int ep_index;
|
|
|
|
struct urb *urb = NULL;
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
int ret = 0;
|
2010-07-23 06:23:31 +08:00
|
|
|
struct urb_priv *urb_priv;
|
2010-07-23 06:22:55 +08:00
|
|
|
u32 trb_comp_code;
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
|
2010-07-23 06:22:55 +08:00
|
|
|
xdev = xhci->devs[slot_id];
|
2011-03-29 10:40:46 +08:00
|
|
|
ep_index = TRB_TO_EP_ID(le32_to_cpu(event->flags)) - 1;
|
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
2010-07-23 06:22:55 +08:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
2011-03-29 10:40:46 +08:00
|
|
|
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
|
2010-07-23 06:22:55 +08:00
|
|
|
|
|
|
|
if (skip)
|
|
|
|
goto td_cleanup;
|
|
|
|
|
|
|
|
if (trb_comp_code == COMP_STOP_INVAL ||
|
|
|
|
trb_comp_code == COMP_STOP) {
|
|
|
|
/* 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.
|
|
|
|
*/
|
|
|
|
ep->stopped_td = td;
|
|
|
|
ep->stopped_trb = event_trb;
|
|
|
|
return 0;
|
|
|
|
} else {
|
|
|
|
if (trb_comp_code == COMP_STALL) {
|
|
|
|
/* 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
|
|
|
|
* the halt condition must be cleared first. Let the
|
|
|
|
* USB class driver clear the stall later.
|
|
|
|
*/
|
|
|
|
ep->stopped_td = td;
|
|
|
|
ep->stopped_trb = event_trb;
|
|
|
|
ep->stopped_stream = ep_ring->stream_id;
|
|
|
|
} 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, ep_ring->stream_id,
|
|
|
|
td, event_trb);
|
|
|
|
} else {
|
|
|
|
/* Update ring dequeue pointer */
|
|
|
|
while (ep_ring->dequeue != td->last_trb)
|
2012-03-05 17:49:32 +08:00
|
|
|
inc_deq(xhci, ep_ring);
|
|
|
|
inc_deq(xhci, ep_ring);
|
2010-07-23 06:22:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
td_cleanup:
|
|
|
|
/* Clean up the endpoint's TD list */
|
|
|
|
urb = td->urb;
|
2010-07-23 06:23:31 +08:00
|
|
|
urb_priv = urb->hcpriv;
|
2010-07-23 06:22:55 +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;
|
|
|
|
if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
|
|
|
|
*status = -EREMOTEIO;
|
|
|
|
else
|
|
|
|
*status = 0;
|
|
|
|
}
|
2011-08-03 06:43:40 +08:00
|
|
|
list_del_init(&td->td_list);
|
2010-07-23 06:22:55 +08:00
|
|
|
/* Was this TD slated to be cancelled but completed anyway? */
|
|
|
|
if (!list_empty(&td->cancelled_td_list))
|
2011-08-03 06:43:40 +08:00
|
|
|
list_del_init(&td->cancelled_td_list);
|
2010-07-23 06:22:55 +08:00
|
|
|
|
2010-07-23 06:23:31 +08:00
|
|
|
urb_priv->td_cnt++;
|
|
|
|
/* Giveback the urb when all the tds are completed */
|
2011-03-22 17:08:14 +08:00
|
|
|
if (urb_priv->td_cnt == urb_priv->length) {
|
2010-07-23 06:23:31 +08:00
|
|
|
ret = 1;
|
2011-03-22 17:08:14 +08:00
|
|
|
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS) {
|
|
|
|
xhci_to_hcd(xhci)->self.bandwidth_isoc_reqs--;
|
|
|
|
if (xhci_to_hcd(xhci)->self.bandwidth_isoc_reqs
|
|
|
|
== 0) {
|
|
|
|
if (xhci->quirks & XHCI_AMD_PLL_FIX)
|
|
|
|
usb_amd_quirk_pll_enable();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2010-07-23 06:22:55 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2010-07-23 06:23:03 +08:00
|
|
|
/*
|
|
|
|
* Process control tds, update urb status and actual_length.
|
|
|
|
*/
|
|
|
|
static int process_ctrl_td(struct xhci_hcd *xhci, struct xhci_td *td,
|
|
|
|
union xhci_trb *event_trb, struct xhci_transfer_event *event,
|
|
|
|
struct xhci_virt_ep *ep, int *status)
|
|
|
|
{
|
|
|
|
struct xhci_virt_device *xdev;
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
unsigned int slot_id;
|
|
|
|
int ep_index;
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
u32 trb_comp_code;
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
|
2010-07-23 06:23:03 +08:00
|
|
|
xdev = xhci->devs[slot_id];
|
2011-03-29 10:40:46 +08:00
|
|
|
ep_index = TRB_TO_EP_ID(le32_to_cpu(event->flags)) - 1;
|
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
2010-07-23 06:23:03 +08:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
2011-03-29 10:40:46 +08:00
|
|
|
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
|
2010-07-23 06:23:03 +08:00
|
|
|
|
|
|
|
switch (trb_comp_code) {
|
|
|
|
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 {
|
|
|
|
*status = 0;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case COMP_SHORT_TX:
|
|
|
|
if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
|
|
|
|
*status = -EREMOTEIO;
|
|
|
|
else
|
|
|
|
*status = 0;
|
|
|
|
break;
|
xhci: Fix bug in control transfer cancellation.
When the xHCI driver attempts to cancel a transfer, it issues a Stop
Endpoint command and waits for the host controller to indicate which TRB
it was in the middle of processing. The host will put an event TRB with
completion code COMP_STOP on the event ring if it stops on a control
transfer TRB (or other types of transfer TRBs). The ring handling code
is supposed to set ep->stopped_trb to the TRB that the host stopped on
when this happens.
Unfortunately, there is a long-standing bug in the control transfer
completion code. It doesn't actually check to see if COMP_STOP is set
before attempting to process the transfer based on which part of the
control TD completed. So when we get an event on the data phase of the
control TRB with COMP_STOP set, it thinks it's a normal completion of
the transfer and doesn't set ep->stopped_td or ep->stopped_trb.
When the ring handling code goes on to process the completion of the Stop
Endpoint command, it sees that ep->stopped_trb is not a part of the TD
it's trying to cancel. It thinks the hardware has its enqueue pointer
somewhere further up in the ring, and thinks it's safe to turn the control
TRBs into no-op TRBs. Since the hardware was in the middle of the control
TRBs to be cancelled, the proper software behavior is to issue a Set TR
dequeue pointer command.
It turns out that the NEC host controllers can handle active TRBs being
set to no-op TRBs after a stop endpoint command, but other host
controllers have issues with this out-of-spec software behavior. Fix this
behavior.
This patch should be backported to kernels as far back as 2.6.31, but it
may be a bit challenging, since process_ctrl_td() was introduced in some
refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40
that touch the same lines.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: stable@kernel.org
2011-05-06 10:08:09 +08:00
|
|
|
case COMP_STOP_INVAL:
|
|
|
|
case COMP_STOP:
|
|
|
|
return finish_td(xhci, td, event_trb, event, ep, status, false);
|
2010-07-23 06:23:03 +08:00
|
|
|
default:
|
|
|
|
if (!xhci_requires_manual_halt_cleanup(xhci,
|
|
|
|
ep_ctx, trb_comp_code))
|
|
|
|
break;
|
|
|
|
xhci_dbg(xhci, "TRB error code %u, "
|
|
|
|
"halted endpoint index = %u\n",
|
|
|
|
trb_comp_code, ep_index);
|
|
|
|
/* else fall through */
|
|
|
|
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 =
|
2013-03-21 14:36:48 +08:00
|
|
|
td->urb->transfer_buffer_length -
|
|
|
|
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
|
2010-07-23 06:23:03 +08:00
|
|
|
else
|
|
|
|
td->urb->actual_length = 0;
|
|
|
|
|
|
|
|
xhci_cleanup_halted_endpoint(xhci,
|
|
|
|
slot_id, ep_index, 0, td, event_trb);
|
|
|
|
return finish_td(xhci, td, event_trb, event, ep, status, true);
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* 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) {
|
|
|
|
if (td->urb->actual_length != 0) {
|
|
|
|
/* Don't overwrite a previously set error code
|
|
|
|
*/
|
|
|
|
if ((*status == -EINPROGRESS || *status == 0) &&
|
|
|
|
(td->urb->transfer_flags
|
|
|
|
& URB_SHORT_NOT_OK))
|
|
|
|
/* Did we already see a short data
|
|
|
|
* stage? */
|
|
|
|
*status = -EREMOTEIO;
|
|
|
|
} else {
|
|
|
|
td->urb->actual_length =
|
|
|
|
td->urb->transfer_buffer_length;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* Maybe the event was for the data stage? */
|
xhci: Fix bug in control transfer cancellation.
When the xHCI driver attempts to cancel a transfer, it issues a Stop
Endpoint command and waits for the host controller to indicate which TRB
it was in the middle of processing. The host will put an event TRB with
completion code COMP_STOP on the event ring if it stops on a control
transfer TRB (or other types of transfer TRBs). The ring handling code
is supposed to set ep->stopped_trb to the TRB that the host stopped on
when this happens.
Unfortunately, there is a long-standing bug in the control transfer
completion code. It doesn't actually check to see if COMP_STOP is set
before attempting to process the transfer based on which part of the
control TD completed. So when we get an event on the data phase of the
control TRB with COMP_STOP set, it thinks it's a normal completion of
the transfer and doesn't set ep->stopped_td or ep->stopped_trb.
When the ring handling code goes on to process the completion of the Stop
Endpoint command, it sees that ep->stopped_trb is not a part of the TD
it's trying to cancel. It thinks the hardware has its enqueue pointer
somewhere further up in the ring, and thinks it's safe to turn the control
TRBs into no-op TRBs. Since the hardware was in the middle of the control
TRBs to be cancelled, the proper software behavior is to issue a Set TR
dequeue pointer command.
It turns out that the NEC host controllers can handle active TRBs being
set to no-op TRBs after a stop endpoint command, but other host
controllers have issues with this out-of-spec software behavior. Fix this
behavior.
This patch should be backported to kernels as far back as 2.6.31, but it
may be a bit challenging, since process_ctrl_td() was introduced in some
refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40
that touch the same lines.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: stable@kernel.org
2011-05-06 10:08:09 +08:00
|
|
|
td->urb->actual_length =
|
|
|
|
td->urb->transfer_buffer_length -
|
2013-03-21 14:36:48 +08:00
|
|
|
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
|
xhci: Fix bug in control transfer cancellation.
When the xHCI driver attempts to cancel a transfer, it issues a Stop
Endpoint command and waits for the host controller to indicate which TRB
it was in the middle of processing. The host will put an event TRB with
completion code COMP_STOP on the event ring if it stops on a control
transfer TRB (or other types of transfer TRBs). The ring handling code
is supposed to set ep->stopped_trb to the TRB that the host stopped on
when this happens.
Unfortunately, there is a long-standing bug in the control transfer
completion code. It doesn't actually check to see if COMP_STOP is set
before attempting to process the transfer based on which part of the
control TD completed. So when we get an event on the data phase of the
control TRB with COMP_STOP set, it thinks it's a normal completion of
the transfer and doesn't set ep->stopped_td or ep->stopped_trb.
When the ring handling code goes on to process the completion of the Stop
Endpoint command, it sees that ep->stopped_trb is not a part of the TD
it's trying to cancel. It thinks the hardware has its enqueue pointer
somewhere further up in the ring, and thinks it's safe to turn the control
TRBs into no-op TRBs. Since the hardware was in the middle of the control
TRBs to be cancelled, the proper software behavior is to issue a Set TR
dequeue pointer command.
It turns out that the NEC host controllers can handle active TRBs being
set to no-op TRBs after a stop endpoint command, but other host
controllers have issues with this out-of-spec software behavior. Fix this
behavior.
This patch should be backported to kernels as far back as 2.6.31, but it
may be a bit challenging, since process_ctrl_td() was introduced in some
refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40
that touch the same lines.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: stable@kernel.org
2011-05-06 10:08:09 +08:00
|
|
|
xhci_dbg(xhci, "Waiting for status "
|
|
|
|
"stage event\n");
|
|
|
|
return 0;
|
2010-07-23 06:23:03 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return finish_td(xhci, td, event_trb, event, ep, status, false);
|
|
|
|
}
|
|
|
|
|
2010-07-23 06:23:39 +08:00
|
|
|
/*
|
|
|
|
* Process isochronous tds, update urb packet status and actual_length.
|
|
|
|
*/
|
|
|
|
static int process_isoc_td(struct xhci_hcd *xhci, struct xhci_td *td,
|
|
|
|
union xhci_trb *event_trb, struct xhci_transfer_event *event,
|
|
|
|
struct xhci_virt_ep *ep, int *status)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
struct urb_priv *urb_priv;
|
|
|
|
int idx;
|
|
|
|
int len = 0;
|
|
|
|
union xhci_trb *cur_trb;
|
|
|
|
struct xhci_segment *cur_seg;
|
2011-03-24 11:47:05 +08:00
|
|
|
struct usb_iso_packet_descriptor *frame;
|
2010-07-23 06:23:39 +08:00
|
|
|
u32 trb_comp_code;
|
2011-03-24 11:47:05 +08:00
|
|
|
bool skip_td = false;
|
2010-07-23 06:23:39 +08:00
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
|
|
|
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
|
2010-07-23 06:23:39 +08:00
|
|
|
urb_priv = td->urb->hcpriv;
|
|
|
|
idx = urb_priv->td_cnt;
|
2011-03-24 11:47:05 +08:00
|
|
|
frame = &td->urb->iso_frame_desc[idx];
|
2010-07-23 06:23:39 +08:00
|
|
|
|
2011-03-24 11:47:05 +08:00
|
|
|
/* handle completion code */
|
|
|
|
switch (trb_comp_code) {
|
|
|
|
case COMP_SUCCESS:
|
2013-03-21 14:36:48 +08:00
|
|
|
if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) {
|
xhci: Add new short TX quirk for Fresco Logic host.
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 00:22:49 +08:00
|
|
|
frame->status = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if ((xhci->quirks & XHCI_TRUST_TX_LENGTH))
|
|
|
|
trb_comp_code = COMP_SHORT_TX;
|
2011-03-24 11:47:05 +08:00
|
|
|
case COMP_SHORT_TX:
|
|
|
|
frame->status = td->urb->transfer_flags & URB_SHORT_NOT_OK ?
|
|
|
|
-EREMOTEIO : 0;
|
|
|
|
break;
|
|
|
|
case COMP_BW_OVER:
|
|
|
|
frame->status = -ECOMM;
|
|
|
|
skip_td = true;
|
|
|
|
break;
|
|
|
|
case COMP_BUFF_OVER:
|
|
|
|
case COMP_BABBLE:
|
|
|
|
frame->status = -EOVERFLOW;
|
|
|
|
skip_td = true;
|
|
|
|
break;
|
2011-06-08 18:34:06 +08:00
|
|
|
case COMP_DEV_ERR:
|
2011-03-24 11:47:05 +08:00
|
|
|
case COMP_STALL:
|
2012-04-23 21:06:09 +08:00
|
|
|
case COMP_TX_ERR:
|
2011-03-24 11:47:05 +08:00
|
|
|
frame->status = -EPROTO;
|
|
|
|
skip_td = true;
|
|
|
|
break;
|
|
|
|
case COMP_STOP:
|
|
|
|
case COMP_STOP_INVAL:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
frame->status = -1;
|
|
|
|
break;
|
2010-07-23 06:23:39 +08:00
|
|
|
}
|
|
|
|
|
2011-03-24 11:47:05 +08:00
|
|
|
if (trb_comp_code == COMP_SUCCESS || skip_td) {
|
|
|
|
frame->actual_length = frame->length;
|
|
|
|
td->urb->actual_length += frame->length;
|
2010-07-23 06:23:39 +08:00
|
|
|
} else {
|
|
|
|
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)) {
|
2011-06-01 08:22:55 +08:00
|
|
|
if (!TRB_TYPE_NOOP_LE32(cur_trb->generic.field[3]) &&
|
|
|
|
!TRB_TYPE_LINK_LE32(cur_trb->generic.field[3]))
|
2011-03-29 10:40:46 +08:00
|
|
|
len += TRB_LEN(le32_to_cpu(cur_trb->generic.field[2]));
|
2010-07-23 06:23:39 +08:00
|
|
|
}
|
2011-03-29 10:40:46 +08:00
|
|
|
len += TRB_LEN(le32_to_cpu(cur_trb->generic.field[2])) -
|
2013-03-21 14:36:48 +08:00
|
|
|
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
|
2010-07-23 06:23:39 +08:00
|
|
|
|
|
|
|
if (trb_comp_code != COMP_STOP_INVAL) {
|
2011-03-24 11:47:05 +08:00
|
|
|
frame->actual_length = len;
|
2010-07-23 06:23:39 +08:00
|
|
|
td->urb->actual_length += len;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return finish_td(xhci, td, event_trb, event, ep, status, false);
|
|
|
|
}
|
|
|
|
|
2011-03-24 11:47:05 +08:00
|
|
|
static int skip_isoc_td(struct xhci_hcd *xhci, struct xhci_td *td,
|
|
|
|
struct xhci_transfer_event *event,
|
|
|
|
struct xhci_virt_ep *ep, int *status)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
struct urb_priv *urb_priv;
|
|
|
|
struct usb_iso_packet_descriptor *frame;
|
|
|
|
int idx;
|
|
|
|
|
2011-06-01 11:01:01 +08:00
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
2011-03-24 11:47:05 +08:00
|
|
|
urb_priv = td->urb->hcpriv;
|
|
|
|
idx = urb_priv->td_cnt;
|
|
|
|
frame = &td->urb->iso_frame_desc[idx];
|
|
|
|
|
xhci: Always set urb->status to zero for isoc endpoints.
When the xHCI driver encounters a Missed Service Interval event for an
isochronous endpoint ring, it means the host controller skipped over
one or more isochronous TDs. For TD that is skipped, skip_isoc_td() is
called. This sets the frame descriptor status to -EXDEV, and also sets
the value stored in the int pointed to by status to -EXDEV.
If the isochronous TD happens to be the last TD in an URB,
handle_tx_event() will use the status variable to give back the URB to
the USB core. That means drivers will see urb->status as -EXDEV.
It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for
an isochronous urb, regardless of what the frame status is. See
itd_complete() in ehci-sched.c:
} else {
/* URB was too late */
desc->status = -EXDEV;
}
}
/* handle completion now? */
if (likely ((urb_index + 1) != urb->number_of_packets))
goto done;
/* ASSERT: it's really the last itd for this urb
list_for_each_entry (itd, &stream->td_list, itd_list)
BUG_ON (itd->urb == urb);
*/
/* give urb back to the driver; completion often (re)submits */
dev = urb->dev;
ehci_urb_done(ehci, urb, 0);
ehci_urb_done() completes the URB with the status of the third argument, which
is always zero in this case.
It turns out that many USB webcam drivers, such as uvcvideo, cannot
handle urb->status set to a non-zero value. They will not resubmit
their isochronous URBs in that case, and userspace will see a frozen
video.
Change the xHCI driver to be consistent with the EHCI and UHCI driver,
and always set urb->status to 0 for isochronous URBs.
This patch should be backported to kernels as old as 2.6.36
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: "Xu, Andiry" <Andiry.Xu@amd.com>
Cc: stable@kernel.org
2011-06-16 10:57:46 +08:00
|
|
|
/* The transfer is partly done. */
|
2011-03-24 11:47:05 +08:00
|
|
|
frame->status = -EXDEV;
|
|
|
|
|
|
|
|
/* calc actual length */
|
|
|
|
frame->actual_length = 0;
|
|
|
|
|
|
|
|
/* Update ring dequeue pointer */
|
|
|
|
while (ep_ring->dequeue != td->last_trb)
|
2012-03-05 17:49:32 +08:00
|
|
|
inc_deq(xhci, ep_ring);
|
|
|
|
inc_deq(xhci, ep_ring);
|
2011-03-24 11:47:05 +08:00
|
|
|
|
|
|
|
return finish_td(xhci, td, NULL, event, ep, status, true);
|
|
|
|
}
|
|
|
|
|
2010-07-23 06:23:08 +08:00
|
|
|
/*
|
|
|
|
* Process bulk and interrupt tds, update urb status and actual_length.
|
|
|
|
*/
|
|
|
|
static int process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_td *td,
|
|
|
|
union xhci_trb *event_trb, struct xhci_transfer_event *event,
|
|
|
|
struct xhci_virt_ep *ep, int *status)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
union xhci_trb *cur_trb;
|
|
|
|
struct xhci_segment *cur_seg;
|
|
|
|
u32 trb_comp_code;
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
|
|
|
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
|
2010-07-23 06:23:08 +08:00
|
|
|
|
|
|
|
switch (trb_comp_code) {
|
|
|
|
case COMP_SUCCESS:
|
|
|
|
/* Double check that the HW transferred everything. */
|
xhci: Add new short TX quirk for Fresco Logic host.
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 00:22:49 +08:00
|
|
|
if (event_trb != td->last_trb ||
|
2013-03-21 14:36:48 +08:00
|
|
|
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
|
2010-07-23 06:23:08 +08:00
|
|
|
xhci_warn(xhci, "WARN Successful completion "
|
|
|
|
"on short TX\n");
|
|
|
|
if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
|
|
|
|
*status = -EREMOTEIO;
|
|
|
|
else
|
|
|
|
*status = 0;
|
xhci: Add new short TX quirk for Fresco Logic host.
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 00:22:49 +08:00
|
|
|
if ((xhci->quirks & XHCI_TRUST_TX_LENGTH))
|
|
|
|
trb_comp_code = COMP_SHORT_TX;
|
2010-07-23 06:23:08 +08:00
|
|
|
} else {
|
|
|
|
*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;
|
|
|
|
}
|
2011-04-06 06:53:47 +08:00
|
|
|
if (trb_comp_code == COMP_SHORT_TX)
|
|
|
|
xhci_dbg(xhci, "ep %#x - asked for %d bytes, "
|
|
|
|
"%d bytes untransferred\n",
|
|
|
|
td->urb->ep->desc.bEndpointAddress,
|
|
|
|
td->urb->transfer_buffer_length,
|
2013-03-21 14:36:48 +08:00
|
|
|
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)));
|
2010-07-23 06:23:08 +08:00
|
|
|
/* Fast path - was this the last TRB in the TD for this URB? */
|
|
|
|
if (event_trb == td->last_trb) {
|
2013-03-21 14:36:48 +08:00
|
|
|
if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
|
2010-07-23 06:23:08 +08:00
|
|
|
td->urb->actual_length =
|
|
|
|
td->urb->transfer_buffer_length -
|
2013-03-21 14:36:48 +08:00
|
|
|
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
|
2010-07-23 06:23:08 +08:00
|
|
|
if (td->urb->transfer_buffer_length <
|
|
|
|
td->urb->actual_length) {
|
|
|
|
xhci_warn(xhci, "HC gave bad length "
|
|
|
|
"of %d bytes left\n",
|
2013-03-21 14:36:48 +08:00
|
|
|
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)));
|
2010-07-23 06:23:08 +08:00
|
|
|
td->urb->actual_length = 0;
|
|
|
|
if (td->urb->transfer_flags & URB_SHORT_NOT_OK)
|
|
|
|
*status = -EREMOTEIO;
|
|
|
|
else
|
|
|
|
*status = 0;
|
|
|
|
}
|
|
|
|
/* 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;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
td->urb->actual_length =
|
|
|
|
td->urb->transfer_buffer_length;
|
|
|
|
/* Ignore a short packet completion if the
|
|
|
|
* untransferred length was zero.
|
|
|
|
*/
|
|
|
|
if (*status == -EREMOTEIO)
|
|
|
|
*status = 0;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* Slow path - walk the list, starting from the dequeue
|
|
|
|
* pointer, to get the actual length transferred.
|
|
|
|
*/
|
|
|
|
td->urb->actual_length = 0;
|
|
|
|
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)) {
|
2011-06-01 08:22:55 +08:00
|
|
|
if (!TRB_TYPE_NOOP_LE32(cur_trb->generic.field[3]) &&
|
|
|
|
!TRB_TYPE_LINK_LE32(cur_trb->generic.field[3]))
|
2010-07-23 06:23:08 +08:00
|
|
|
td->urb->actual_length +=
|
2011-03-29 10:40:46 +08:00
|
|
|
TRB_LEN(le32_to_cpu(cur_trb->generic.field[2]));
|
2010-07-23 06:23:08 +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
|
|
|
|
*/
|
|
|
|
if (trb_comp_code != COMP_STOP_INVAL)
|
|
|
|
td->urb->actual_length +=
|
2011-03-29 10:40:46 +08:00
|
|
|
TRB_LEN(le32_to_cpu(cur_trb->generic.field[2])) -
|
2013-03-21 14:36:48 +08:00
|
|
|
EVENT_TRB_LEN(le32_to_cpu(event->transfer_len));
|
2010-07-23 06:23:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return finish_td(xhci, td, event_trb, event, ep, status, false);
|
|
|
|
}
|
|
|
|
|
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)
|
2012-08-07 19:10:03 +08:00
|
|
|
__releases(&xhci->lock)
|
|
|
|
__acquires(&xhci->lock)
|
2009-04-28 10:58:01 +08:00
|
|
|
{
|
|
|
|
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;
|
2010-04-19 23:53:50 +08:00
|
|
|
struct xhci_td *td = NULL;
|
2009-04-28 10:58:01 +08:00
|
|
|
dma_addr_t event_dma;
|
|
|
|
struct xhci_segment *event_seg;
|
|
|
|
union xhci_trb *event_trb;
|
2010-04-19 23:53:50 +08:00
|
|
|
struct urb *urb = NULL;
|
2009-04-28 10:58:01 +08:00
|
|
|
int status = -EINPROGRESS;
|
2010-07-23 06:23:31 +08:00
|
|
|
struct urb_priv *urb_priv;
|
2009-07-28 03:05:15 +08:00
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
USB: xHCI: prevent infinite loop when processing MSE event
When a xHC host is unable to handle isochronous transfer in the
interval, it reports a Missed Service Error event and skips some tds.
Currently xhci driver handles MSE event in the following ways:
1. When encounter a MSE event, set ep->skip flag, update event ring
dequeue pointer and return.
2. When encounter the next event on this ep, the driver will run the
do-while loop, fetch td from ep's td_list to find the td
corresponding to this event. All tds missed are marked as short
transfer(-EXDEV).
The do-while loop will end in two ways:
1. If the td pointed by the event trb is found;
2. If the ep ring's td_list is empty.
However, if a buggy HW reports some unpredicted event (for example, an
overrun event following a MSE event while the ep ring is actually not
empty), the driver will never find the td, and it will loop until the
td_list is empty.
Unfortunately, the spinlock is dropped when give back a urb in the
do-while loop. During the spinlock released period, the class driver
may still submit urbs and add tds to the td_list. This may cause
disaster, since the td_list will never be empty and the loop never ends,
and the system hangs.
To fix this, count the number of TDs on the ep ring before skipping TDs,
and quit the loop when skipped that number of tds. This guarantees the
do-while loop will end after certain number of cycles, and driver will
not be trapped in an infinite loop.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-20 07:05:12 +08:00
|
|
|
struct list_head *tmp;
|
2009-08-28 05:35:53 +08:00
|
|
|
u32 trb_comp_code;
|
2010-07-23 06:22:55 +08:00
|
|
|
int ret = 0;
|
USB: xHCI: prevent infinite loop when processing MSE event
When a xHC host is unable to handle isochronous transfer in the
interval, it reports a Missed Service Error event and skips some tds.
Currently xhci driver handles MSE event in the following ways:
1. When encounter a MSE event, set ep->skip flag, update event ring
dequeue pointer and return.
2. When encounter the next event on this ep, the driver will run the
do-while loop, fetch td from ep's td_list to find the td
corresponding to this event. All tds missed are marked as short
transfer(-EXDEV).
The do-while loop will end in two ways:
1. If the td pointed by the event trb is found;
2. If the ep ring's td_list is empty.
However, if a buggy HW reports some unpredicted event (for example, an
overrun event following a MSE event while the ep ring is actually not
empty), the driver will never find the td, and it will loop until the
td_list is empty.
Unfortunately, the spinlock is dropped when give back a urb in the
do-while loop. During the spinlock released period, the class driver
may still submit urbs and add tds to the td_list. This may cause
disaster, since the td_list will never be empty and the loop never ends,
and the system hangs.
To fix this, count the number of TDs on the ep ring before skipping TDs,
and quit the loop when skipped that number of tds. This guarantees the
do-while loop will end after certain number of cycles, and driver will
not be trapped in an infinite loop.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-20 07:05:12 +08:00
|
|
|
int td_num = 0;
|
2009-04-28 10:58:01 +08:00
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
|
2009-08-08 05:04:52 +08:00
|
|
|
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");
|
2011-12-02 06:50:30 +08:00
|
|
|
xhci_err(xhci, "@%016llx %08x %08x %08x %08x\n",
|
2012-01-05 08:54:12 +08:00
|
|
|
(unsigned long long) xhci_trb_virt_to_dma(
|
|
|
|
xhci->event_ring->deq_seg,
|
2011-12-02 06:50:30 +08:00
|
|
|
xhci->event_ring->dequeue),
|
|
|
|
lower_32_bits(le64_to_cpu(event->buffer)),
|
|
|
|
upper_32_bits(le64_to_cpu(event->buffer)),
|
|
|
|
le32_to_cpu(event->transfer_len),
|
|
|
|
le32_to_cpu(event->flags));
|
|
|
|
xhci_dbg(xhci, "Event ring:\n");
|
|
|
|
xhci_debug_segment(xhci, xhci->event_ring->deq_seg);
|
2009-04-28 10:58:01 +08:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Endpoint ID is 1 based, our index is zero based */
|
2011-03-29 10:40:46 +08:00
|
|
|
ep_index = TRB_TO_EP_ID(le32_to_cpu(event->flags)) - 1;
|
2009-09-05 01:53:09 +08:00
|
|
|
ep = &xdev->eps[ep_index];
|
2011-03-29 10:40:46 +08:00
|
|
|
ep_ring = xhci_dma_to_transfer_ring(ep, le64_to_cpu(event->buffer));
|
2009-07-28 03:05:15 +08:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
2010-07-23 06:23:20 +08:00
|
|
|
if (!ep_ring ||
|
2011-03-29 10:40:46 +08:00
|
|
|
(le32_to_cpu(ep_ctx->ep_info) & EP_STATE_MASK) ==
|
|
|
|
EP_STATE_DISABLED) {
|
2010-04-03 06:34:43 +08:00
|
|
|
xhci_err(xhci, "ERROR Transfer event for disabled endpoint "
|
|
|
|
"or incorrect stream ring\n");
|
2011-12-02 06:50:30 +08:00
|
|
|
xhci_err(xhci, "@%016llx %08x %08x %08x %08x\n",
|
2012-01-05 08:54:12 +08:00
|
|
|
(unsigned long long) xhci_trb_virt_to_dma(
|
|
|
|
xhci->event_ring->deq_seg,
|
2011-12-02 06:50:30 +08:00
|
|
|
xhci->event_ring->dequeue),
|
|
|
|
lower_32_bits(le64_to_cpu(event->buffer)),
|
|
|
|
upper_32_bits(le64_to_cpu(event->buffer)),
|
|
|
|
le32_to_cpu(event->transfer_len),
|
|
|
|
le32_to_cpu(event->flags));
|
|
|
|
xhci_dbg(xhci, "Event ring:\n");
|
|
|
|
xhci_debug_segment(xhci, xhci->event_ring->deq_seg);
|
2009-04-28 10:58:01 +08:00
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
USB: xHCI: prevent infinite loop when processing MSE event
When a xHC host is unable to handle isochronous transfer in the
interval, it reports a Missed Service Error event and skips some tds.
Currently xhci driver handles MSE event in the following ways:
1. When encounter a MSE event, set ep->skip flag, update event ring
dequeue pointer and return.
2. When encounter the next event on this ep, the driver will run the
do-while loop, fetch td from ep's td_list to find the td
corresponding to this event. All tds missed are marked as short
transfer(-EXDEV).
The do-while loop will end in two ways:
1. If the td pointed by the event trb is found;
2. If the ep ring's td_list is empty.
However, if a buggy HW reports some unpredicted event (for example, an
overrun event following a MSE event while the ep ring is actually not
empty), the driver will never find the td, and it will loop until the
td_list is empty.
Unfortunately, the spinlock is dropped when give back a urb in the
do-while loop. During the spinlock released period, the class driver
may still submit urbs and add tds to the td_list. This may cause
disaster, since the td_list will never be empty and the loop never ends,
and the system hangs.
To fix this, count the number of TDs on the ep ring before skipping TDs,
and quit the loop when skipped that number of tds. This guarantees the
do-while loop will end after certain number of cycles, and driver will
not be trapped in an infinite loop.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-20 07:05:12 +08:00
|
|
|
/* Count current td numbers if ep->skip is set */
|
|
|
|
if (ep->skip) {
|
|
|
|
list_for_each(tmp, &ep_ring->td_list)
|
|
|
|
td_num++;
|
|
|
|
}
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
event_dma = le64_to_cpu(event->buffer);
|
|
|
|
trb_comp_code = GET_COMP_CODE(le32_to_cpu(event->transfer_len));
|
2010-07-23 06:23:20 +08:00
|
|
|
/* Look for common error cases */
|
2009-08-28 05:35:53 +08:00
|
|
|
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:
|
2013-03-21 14:36:48 +08:00
|
|
|
if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) == 0)
|
xhci: Add new short TX quirk for Fresco Logic host.
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 00:22:49 +08:00
|
|
|
break;
|
|
|
|
if (xhci->quirks & XHCI_TRUST_TX_LENGTH)
|
|
|
|
trb_comp_code = COMP_SHORT_TX;
|
|
|
|
else
|
2012-07-26 01:52:45 +08:00
|
|
|
xhci_warn_ratelimited(xhci,
|
|
|
|
"WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?\n");
|
2009-04-28 10:58:50 +08:00
|
|
|
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:
|
2011-10-25 19:55:30 +08:00
|
|
|
xhci_dbg(xhci, "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:
|
2011-10-25 19:55:30 +08:00
|
|
|
xhci_dbg(xhci, "Transfer error on endpoint\n");
|
2009-04-28 10:58:50 +08:00
|
|
|
status = -EPROTO;
|
|
|
|
break;
|
2009-07-28 03:04:32 +08:00
|
|
|
case COMP_BABBLE:
|
2011-10-25 19:55:30 +08:00
|
|
|
xhci_dbg(xhci, "Babble error on endpoint\n");
|
2009-07-28 03:04:32 +08:00
|
|
|
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;
|
2010-07-23 06:23:20 +08:00
|
|
|
case COMP_BW_OVER:
|
|
|
|
xhci_warn(xhci, "WARN: bandwidth overrun event on endpoint\n");
|
|
|
|
break;
|
|
|
|
case COMP_BUFF_OVER:
|
|
|
|
xhci_warn(xhci, "WARN: buffer overrun event on endpoint\n");
|
|
|
|
break;
|
|
|
|
case COMP_UNDERRUN:
|
|
|
|
/*
|
|
|
|
* When the Isoch ring is empty, the xHC will generate
|
|
|
|
* a Ring Overrun Event for IN Isoch endpoint or Ring
|
|
|
|
* Underrun Event for OUT Isoch endpoint.
|
|
|
|
*/
|
|
|
|
xhci_dbg(xhci, "underrun event on endpoint\n");
|
|
|
|
if (!list_empty(&ep_ring->td_list))
|
|
|
|
xhci_dbg(xhci, "Underrun Event for slot %d ep %d "
|
|
|
|
"still with TDs queued?\n",
|
2011-03-29 10:40:46 +08:00
|
|
|
TRB_TO_SLOT_ID(le32_to_cpu(event->flags)),
|
|
|
|
ep_index);
|
2010-07-23 06:23:20 +08:00
|
|
|
goto cleanup;
|
|
|
|
case COMP_OVERRUN:
|
|
|
|
xhci_dbg(xhci, "overrun event on endpoint\n");
|
|
|
|
if (!list_empty(&ep_ring->td_list))
|
|
|
|
xhci_dbg(xhci, "Overrun Event for slot %d ep %d "
|
|
|
|
"still with TDs queued?\n",
|
2011-03-29 10:40:46 +08:00
|
|
|
TRB_TO_SLOT_ID(le32_to_cpu(event->flags)),
|
|
|
|
ep_index);
|
2010-07-23 06:23:20 +08:00
|
|
|
goto cleanup;
|
2011-06-08 18:34:06 +08:00
|
|
|
case COMP_DEV_ERR:
|
|
|
|
xhci_warn(xhci, "WARN: detect an incompatible device");
|
|
|
|
status = -EPROTO;
|
|
|
|
break;
|
2010-07-23 06:23:25 +08:00
|
|
|
case COMP_MISSED_INT:
|
|
|
|
/*
|
|
|
|
* When encounter missed service error, one or more isoc tds
|
|
|
|
* may be missed by xHC.
|
|
|
|
* Set skip flag of the ep_ring; Complete the missed tds as
|
|
|
|
* short transfer when process the ep_ring next time.
|
|
|
|
*/
|
|
|
|
ep->skip = true;
|
|
|
|
xhci_dbg(xhci, "Miss service interval error, set skip flag\n");
|
|
|
|
goto cleanup;
|
2009-04-28 10:58:50 +08:00
|
|
|
default:
|
2009-12-10 07:59:06 +08:00
|
|
|
if (xhci_is_vendor_info_code(xhci, trb_comp_code)) {
|
2009-11-12 02:28:40 +08:00
|
|
|
status = 0;
|
|
|
|
break;
|
|
|
|
}
|
2010-07-23 06:23:20 +08:00
|
|
|
xhci_warn(xhci, "ERROR Unknown event condition, HC probably "
|
|
|
|
"busted\n");
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2010-07-23 06:23:25 +08:00
|
|
|
do {
|
|
|
|
/* This TRB should be in the TD at the head of this ring's
|
|
|
|
* TD list.
|
|
|
|
*/
|
|
|
|
if (list_empty(&ep_ring->td_list)) {
|
2013-03-19 01:19:51 +08:00
|
|
|
/*
|
|
|
|
* A stopped endpoint may generate an extra completion
|
|
|
|
* event if the device was suspended. Don't print
|
|
|
|
* warnings.
|
|
|
|
*/
|
|
|
|
if (!(trb_comp_code == COMP_STOP ||
|
|
|
|
trb_comp_code == COMP_STOP_INVAL)) {
|
|
|
|
xhci_warn(xhci, "WARN Event TRB for slot %d ep %d with no TDs queued?\n",
|
|
|
|
TRB_TO_SLOT_ID(le32_to_cpu(event->flags)),
|
|
|
|
ep_index);
|
|
|
|
xhci_dbg(xhci, "Event TRB with TRB type ID %u\n",
|
|
|
|
(le32_to_cpu(event->flags) &
|
|
|
|
TRB_TYPE_BITMASK)>>10);
|
|
|
|
xhci_print_trb_offsets(xhci, (union xhci_trb *) event);
|
|
|
|
}
|
2010-07-23 06:23:25 +08:00
|
|
|
if (ep->skip) {
|
|
|
|
ep->skip = false;
|
|
|
|
xhci_dbg(xhci, "td_list is empty while skip "
|
|
|
|
"flag set. Clear skip flag.\n");
|
|
|
|
}
|
|
|
|
ret = 0;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2010-07-23 06:23:20 +08:00
|
|
|
|
USB: xHCI: prevent infinite loop when processing MSE event
When a xHC host is unable to handle isochronous transfer in the
interval, it reports a Missed Service Error event and skips some tds.
Currently xhci driver handles MSE event in the following ways:
1. When encounter a MSE event, set ep->skip flag, update event ring
dequeue pointer and return.
2. When encounter the next event on this ep, the driver will run the
do-while loop, fetch td from ep's td_list to find the td
corresponding to this event. All tds missed are marked as short
transfer(-EXDEV).
The do-while loop will end in two ways:
1. If the td pointed by the event trb is found;
2. If the ep ring's td_list is empty.
However, if a buggy HW reports some unpredicted event (for example, an
overrun event following a MSE event while the ep ring is actually not
empty), the driver will never find the td, and it will loop until the
td_list is empty.
Unfortunately, the spinlock is dropped when give back a urb in the
do-while loop. During the spinlock released period, the class driver
may still submit urbs and add tds to the td_list. This may cause
disaster, since the td_list will never be empty and the loop never ends,
and the system hangs.
To fix this, count the number of TDs on the ep ring before skipping TDs,
and quit the loop when skipped that number of tds. This guarantees the
do-while loop will end after certain number of cycles, and driver will
not be trapped in an infinite loop.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-20 07:05:12 +08:00
|
|
|
/* We've skipped all the TDs on the ep ring when ep->skip set */
|
|
|
|
if (ep->skip && td_num == 0) {
|
|
|
|
ep->skip = false;
|
|
|
|
xhci_dbg(xhci, "All tds on the ep_ring skipped. "
|
|
|
|
"Clear skip flag.\n");
|
|
|
|
ret = 0;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2010-07-23 06:23:25 +08:00
|
|
|
td = list_entry(ep_ring->td_list.next, struct xhci_td, td_list);
|
USB: xHCI: prevent infinite loop when processing MSE event
When a xHC host is unable to handle isochronous transfer in the
interval, it reports a Missed Service Error event and skips some tds.
Currently xhci driver handles MSE event in the following ways:
1. When encounter a MSE event, set ep->skip flag, update event ring
dequeue pointer and return.
2. When encounter the next event on this ep, the driver will run the
do-while loop, fetch td from ep's td_list to find the td
corresponding to this event. All tds missed are marked as short
transfer(-EXDEV).
The do-while loop will end in two ways:
1. If the td pointed by the event trb is found;
2. If the ep ring's td_list is empty.
However, if a buggy HW reports some unpredicted event (for example, an
overrun event following a MSE event while the ep ring is actually not
empty), the driver will never find the td, and it will loop until the
td_list is empty.
Unfortunately, the spinlock is dropped when give back a urb in the
do-while loop. During the spinlock released period, the class driver
may still submit urbs and add tds to the td_list. This may cause
disaster, since the td_list will never be empty and the loop never ends,
and the system hangs.
To fix this, count the number of TDs on the ep ring before skipping TDs,
and quit the loop when skipped that number of tds. This guarantees the
do-while loop will end after certain number of cycles, and driver will
not be trapped in an infinite loop.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-09-20 07:05:12 +08:00
|
|
|
if (ep->skip)
|
|
|
|
td_num--;
|
2011-03-24 11:47:05 +08:00
|
|
|
|
2010-07-23 06:23:25 +08:00
|
|
|
/* Is this a TRB in the currently executing TD? */
|
|
|
|
event_seg = trb_in_td(ep_ring->deq_seg, ep_ring->dequeue,
|
|
|
|
td->last_trb, event_dma);
|
2011-06-03 15:58:25 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Skip the Force Stopped Event. The event_trb(event_dma) of FSE
|
|
|
|
* is not in the current TD pointed by ep_ring->dequeue because
|
|
|
|
* that the hardware dequeue pointer still at the previous TRB
|
|
|
|
* of the current TD. The previous TRB maybe a Link TD or the
|
|
|
|
* last TRB of the previous TD. The command completion handle
|
|
|
|
* will take care the rest.
|
|
|
|
*/
|
|
|
|
if (!event_seg && trb_comp_code == COMP_STOP_INVAL) {
|
|
|
|
ret = 0;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
2011-03-24 11:47:05 +08:00
|
|
|
if (!event_seg) {
|
|
|
|
if (!ep->skip ||
|
|
|
|
!usb_endpoint_xfer_isoc(&td->urb->ep->desc)) {
|
2011-05-26 01:43:56 +08:00
|
|
|
/* Some host controllers give a spurious
|
|
|
|
* successful event after a short transfer.
|
|
|
|
* Ignore it.
|
|
|
|
*/
|
|
|
|
if ((xhci->quirks & XHCI_SPURIOUS_SUCCESS) &&
|
|
|
|
ep_ring->last_td_was_short) {
|
|
|
|
ep_ring->last_td_was_short = false;
|
|
|
|
ret = 0;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2011-03-24 11:47:05 +08:00
|
|
|
/* HC is busted, give up! */
|
|
|
|
xhci_err(xhci,
|
|
|
|
"ERROR Transfer event TRB DMA ptr not "
|
|
|
|
"part of current TD\n");
|
|
|
|
return -ESHUTDOWN;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = skip_isoc_td(xhci, td, event, ep, &status);
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2011-05-26 01:43:56 +08:00
|
|
|
if (trb_comp_code == COMP_SHORT_TX)
|
|
|
|
ep_ring->last_td_was_short = true;
|
|
|
|
else
|
|
|
|
ep_ring->last_td_was_short = false;
|
2011-03-24 11:47:05 +08:00
|
|
|
|
|
|
|
if (ep->skip) {
|
2010-07-23 06:23:25 +08:00
|
|
|
xhci_dbg(xhci, "Found td. Clear skip flag.\n");
|
|
|
|
ep->skip = false;
|
|
|
|
}
|
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
|
|
|
|
2011-03-24 11:47:05 +08:00
|
|
|
event_trb = &event_seg->trbs[(event_dma - event_seg->dma) /
|
|
|
|
sizeof(*event_trb)];
|
|
|
|
/*
|
|
|
|
* No-op TRB should not trigger interrupts.
|
|
|
|
* If event_trb is a no-op TRB, it means the
|
|
|
|
* corresponding TD has been cancelled. Just ignore
|
|
|
|
* the TD.
|
|
|
|
*/
|
2011-06-01 08:22:55 +08:00
|
|
|
if (TRB_TYPE_NOOP_LE32(event_trb->generic.field[3])) {
|
2011-03-24 11:47:05 +08:00
|
|
|
xhci_dbg(xhci,
|
|
|
|
"event_trb is a no-op TRB. Skip it\n");
|
|
|
|
goto cleanup;
|
2010-07-23 06:23:25 +08:00
|
|
|
}
|
2010-07-23 06:22:55 +08:00
|
|
|
|
2010-07-23 06:23:25 +08:00
|
|
|
/* Now update the urb's actual_length and give back to
|
|
|
|
* the core
|
2009-08-08 05:04:52 +08:00
|
|
|
*/
|
2010-07-23 06:23:25 +08:00
|
|
|
if (usb_endpoint_xfer_control(&td->urb->ep->desc))
|
|
|
|
ret = process_ctrl_td(xhci, td, event_trb, event, ep,
|
|
|
|
&status);
|
2010-07-23 06:23:39 +08:00
|
|
|
else if (usb_endpoint_xfer_isoc(&td->urb->ep->desc))
|
|
|
|
ret = process_isoc_td(xhci, td, event_trb, event, ep,
|
|
|
|
&status);
|
2010-07-23 06:23:25 +08:00
|
|
|
else
|
|
|
|
ret = process_bulk_intr_td(xhci, td, event_trb, event,
|
|
|
|
ep, &status);
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
/*
|
|
|
|
* Do not update event ring dequeue pointer if ep->skip is set.
|
|
|
|
* Will roll back to continue process missed tds.
|
|
|
|
*/
|
|
|
|
if (trb_comp_code == COMP_MISSED_INT || !ep->skip) {
|
2012-03-05 17:49:32 +08:00
|
|
|
inc_deq(xhci, xhci->event_ring);
|
2010-07-23 06:23:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ret) {
|
|
|
|
urb = td->urb;
|
2010-07-23 06:23:31 +08:00
|
|
|
urb_priv = urb->hcpriv;
|
2010-07-23 06:23:25 +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) ||
|
|
|
|
(trb_comp_code != COMP_STALL &&
|
|
|
|
trb_comp_code != COMP_BABBLE))
|
2010-07-23 06:23:31 +08:00
|
|
|
xhci_urb_free_priv(xhci, urb_priv);
|
2013-01-17 23:32:16 +08:00
|
|
|
else
|
|
|
|
kfree(urb_priv);
|
2010-07-23 06:23:25 +08:00
|
|
|
|
2010-10-27 02:22:02 +08:00
|
|
|
usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb->dev->bus), urb);
|
2011-04-06 06:53:47 +08:00
|
|
|
if ((urb->actual_length != urb->transfer_buffer_length &&
|
|
|
|
(urb->transfer_flags &
|
|
|
|
URB_SHORT_NOT_OK)) ||
|
2011-09-03 02:05:56 +08:00
|
|
|
(status != 0 &&
|
|
|
|
!usb_endpoint_xfer_isoc(&urb->ep->desc)))
|
2011-04-06 06:53:47 +08:00
|
|
|
xhci_dbg(xhci, "Giveback URB %p, len = %d, "
|
2012-05-08 01:22:52 +08:00
|
|
|
"expected = %d, status = %d\n",
|
2011-04-06 06:53:47 +08:00
|
|
|
urb, urb->actual_length,
|
|
|
|
urb->transfer_buffer_length,
|
|
|
|
status);
|
2010-07-23 06:23:25 +08:00
|
|
|
spin_unlock(&xhci->lock);
|
xhci: Always set urb->status to zero for isoc endpoints.
When the xHCI driver encounters a Missed Service Interval event for an
isochronous endpoint ring, it means the host controller skipped over
one or more isochronous TDs. For TD that is skipped, skip_isoc_td() is
called. This sets the frame descriptor status to -EXDEV, and also sets
the value stored in the int pointed to by status to -EXDEV.
If the isochronous TD happens to be the last TD in an URB,
handle_tx_event() will use the status variable to give back the URB to
the USB core. That means drivers will see urb->status as -EXDEV.
It turns out that EHCI, UHCI, and OHCI always set urb->status to zero for
an isochronous urb, regardless of what the frame status is. See
itd_complete() in ehci-sched.c:
} else {
/* URB was too late */
desc->status = -EXDEV;
}
}
/* handle completion now? */
if (likely ((urb_index + 1) != urb->number_of_packets))
goto done;
/* ASSERT: it's really the last itd for this urb
list_for_each_entry (itd, &stream->td_list, itd_list)
BUG_ON (itd->urb == urb);
*/
/* give urb back to the driver; completion often (re)submits */
dev = urb->dev;
ehci_urb_done(ehci, urb, 0);
ehci_urb_done() completes the URB with the status of the third argument, which
is always zero in this case.
It turns out that many USB webcam drivers, such as uvcvideo, cannot
handle urb->status set to a non-zero value. They will not resubmit
their isochronous URBs in that case, and userspace will see a frozen
video.
Change the xHCI driver to be consistent with the EHCI and UHCI driver,
and always set urb->status to 0 for isochronous URBs.
This patch should be backported to kernels as old as 2.6.36
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: "Xu, Andiry" <Andiry.Xu@amd.com>
Cc: stable@kernel.org
2011-06-16 10:57:46 +08:00
|
|
|
/* EHCI, UHCI, and OHCI always unconditionally set the
|
|
|
|
* urb->status of an isochronous endpoint to 0.
|
|
|
|
*/
|
|
|
|
if (usb_pipetype(urb->pipe) == PIPE_ISOCHRONOUS)
|
|
|
|
status = 0;
|
2010-10-27 02:22:02 +08:00
|
|
|
usb_hcd_giveback_urb(bus_to_hcd(urb->dev->bus), urb, status);
|
2010-07-23 06:23:25 +08:00
|
|
|
spin_lock(&xhci->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If ep->skip is set, it means there are missed tds on the
|
|
|
|
* endpoint ring need to take care of.
|
|
|
|
* Process them as short transfer until reach the td pointed by
|
|
|
|
* the event.
|
|
|
|
*/
|
|
|
|
} while (ep->skip && trb_comp_code != COMP_MISSED_INT);
|
|
|
|
|
2009-04-28 10:58:01 +08:00
|
|
|
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).
|
2011-03-29 10:41:02 +08:00
|
|
|
* Returns >0 for "possibly more events to process" (caller should call again),
|
|
|
|
* otherwise 0 if done. In future, <0 returns should indicate error code.
|
2009-04-28 10:57:12 +08:00
|
|
|
*/
|
2011-03-29 10:41:02 +08:00
|
|
|
static int 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
|
|
|
|
|
|
|
if (!xhci->event_ring || !xhci->event_ring->dequeue) {
|
|
|
|
xhci->error_bitmask |= 1 << 1;
|
2011-03-29 10:41:02 +08:00
|
|
|
return 0;
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
event = xhci->event_ring->dequeue;
|
|
|
|
/* Does the HC or OS own the TRB? */
|
2011-03-29 10:40:46 +08:00
|
|
|
if ((le32_to_cpu(event->event_cmd.flags) & TRB_CYCLE) !=
|
|
|
|
xhci->event_ring->cycle_state) {
|
2009-04-28 10:53:56 +08:00
|
|
|
xhci->error_bitmask |= 1 << 2;
|
2011-03-29 10:41:02 +08:00
|
|
|
return 0;
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
2011-03-29 10:40:51 +08:00
|
|
|
/*
|
|
|
|
* Barrier between reading the TRB_CYCLE (valid) flag above and any
|
|
|
|
* speculative reads of the event's flags/data below.
|
|
|
|
*/
|
|
|
|
rmb();
|
2009-04-28 10:57:12 +08:00
|
|
|
/* FIXME: Handle more event types. */
|
2011-03-29 10:40:46 +08:00
|
|
|
switch ((le32_to_cpu(event->event_cmd.flags) & TRB_TYPE_BITMASK)) {
|
2009-04-28 10:53:56 +08:00
|
|
|
case TRB_TYPE(TRB_COMPLETION):
|
|
|
|
handle_cmd_completion(xhci, &event->event_cmd);
|
|
|
|
break;
|
2009-04-28 10:57:12 +08:00
|
|
|
case TRB_TYPE(TRB_PORT_STATUS):
|
|
|
|
handle_port_status(xhci, event);
|
|
|
|
update_ptrs = 0;
|
|
|
|
break;
|
2009-04-28 10:58:01 +08:00
|
|
|
case TRB_TYPE(TRB_TRANSFER):
|
|
|
|
ret = handle_tx_event(xhci, &event->trans_event);
|
|
|
|
if (ret < 0)
|
|
|
|
xhci->error_bitmask |= 1 << 9;
|
|
|
|
else
|
|
|
|
update_ptrs = 0;
|
|
|
|
break;
|
2011-11-12 06:57:33 +08:00
|
|
|
case TRB_TYPE(TRB_DEV_NOTE):
|
|
|
|
handle_device_notification(xhci, event);
|
|
|
|
break;
|
2009-04-28 10:53:56 +08:00
|
|
|
default:
|
2011-03-29 10:40:46 +08:00
|
|
|
if ((le32_to_cpu(event->event_cmd.flags) & TRB_TYPE_BITMASK) >=
|
|
|
|
TRB_TYPE(48))
|
2010-05-25 04:25:28 +08:00
|
|
|
handle_vendor_event(xhci, event);
|
|
|
|
else
|
|
|
|
xhci->error_bitmask |= 1 << 3;
|
2009-04-28 10:53:56 +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
|
|
|
/* 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");
|
2011-03-29 10:41:02 +08:00
|
|
|
return 0;
|
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
|
|
|
}
|
2009-04-28 10:53:56 +08:00
|
|
|
|
2010-07-30 13:12:49 +08:00
|
|
|
if (update_ptrs)
|
|
|
|
/* Update SW event ring dequeue pointer */
|
2012-03-05 17:49:32 +08:00
|
|
|
inc_deq(xhci, xhci->event_ring);
|
2010-07-30 13:12:49 +08:00
|
|
|
|
2011-03-29 10:41:02 +08:00
|
|
|
/* Are there more items on the event ring? Caller will call us again to
|
|
|
|
* check.
|
|
|
|
*/
|
|
|
|
return 1;
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
2010-07-30 13:12:29 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* xHCI spec says we can get an interrupt, and if the HC has an error condition,
|
|
|
|
* we might get bad data out of the event ring. Section 4.10.2.7 has a list of
|
|
|
|
* indicators of an event TRB error, but we check the status *first* to be safe.
|
|
|
|
*/
|
|
|
|
irqreturn_t xhci_irq(struct usb_hcd *hcd)
|
|
|
|
{
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
2010-07-30 13:13:00 +08:00
|
|
|
u32 status;
|
2010-07-30 13:12:38 +08:00
|
|
|
u64 temp_64;
|
2010-07-30 13:12:49 +08:00
|
|
|
union xhci_trb *event_ring_deq;
|
|
|
|
dma_addr_t deq;
|
2010-07-30 13:12:29 +08:00
|
|
|
|
|
|
|
spin_lock(&xhci->lock);
|
|
|
|
/* Check if the xHC generated the interrupt, or the irq is shared */
|
2010-07-30 13:12:43 +08:00
|
|
|
status = xhci_readl(xhci, &xhci->op_regs->status);
|
2010-07-30 13:13:00 +08:00
|
|
|
if (status == 0xffffffff)
|
2010-07-30 13:12:29 +08:00
|
|
|
goto hw_died;
|
|
|
|
|
2010-07-30 13:13:00 +08:00
|
|
|
if (!(status & STS_EINT)) {
|
2010-07-30 13:12:29 +08:00
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
return IRQ_NONE;
|
|
|
|
}
|
2010-07-30 13:12:43 +08:00
|
|
|
if (status & STS_FATAL) {
|
2010-07-30 13:12:29 +08:00
|
|
|
xhci_warn(xhci, "WARNING: Host System Error\n");
|
|
|
|
xhci_halt(xhci);
|
|
|
|
hw_died:
|
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
return -ESHUTDOWN;
|
|
|
|
}
|
|
|
|
|
2010-07-30 13:12:38 +08:00
|
|
|
/*
|
|
|
|
* Clear the op reg interrupt status first,
|
|
|
|
* so we can receive interrupts from other MSI-X interrupters.
|
|
|
|
* Write 1 to clear the interrupt status.
|
|
|
|
*/
|
2010-07-30 13:12:43 +08:00
|
|
|
status |= STS_EINT;
|
|
|
|
xhci_writel(xhci, status, &xhci->op_regs->status);
|
2010-07-30 13:12:38 +08:00
|
|
|
/* FIXME when MSI-X is supported and there are multiple vectors */
|
|
|
|
/* Clear the MSI-X event interrupt status */
|
|
|
|
|
2012-02-29 22:46:23 +08:00
|
|
|
if (hcd->irq) {
|
2010-07-30 13:13:00 +08:00
|
|
|
u32 irq_pending;
|
|
|
|
/* Acknowledge the PCI interrupt */
|
|
|
|
irq_pending = xhci_readl(xhci, &xhci->ir_set->irq_pending);
|
2012-03-15 22:37:08 +08:00
|
|
|
irq_pending |= IMAN_IP;
|
2010-07-30 13:13:00 +08:00
|
|
|
xhci_writel(xhci, irq_pending, &xhci->ir_set->irq_pending);
|
|
|
|
}
|
2010-07-30 13:12:38 +08:00
|
|
|
|
2010-07-30 13:12:49 +08:00
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING) {
|
2010-07-30 13:12:38 +08:00
|
|
|
xhci_dbg(xhci, "xHCI dying, ignoring interrupt. "
|
|
|
|
"Shouldn't IRQs be disabled?\n");
|
2010-07-30 13:12:49 +08:00
|
|
|
/* Clear the event handler busy flag (RW1C);
|
|
|
|
* the event ring should be empty.
|
2010-07-30 13:12:38 +08:00
|
|
|
*/
|
2010-07-30 13:12:49 +08:00
|
|
|
temp_64 = xhci_read_64(xhci, &xhci->ir_set->erst_dequeue);
|
|
|
|
xhci_write_64(xhci, temp_64 | ERST_EHB,
|
|
|
|
&xhci->ir_set->erst_dequeue);
|
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
|
|
|
event_ring_deq = xhci->event_ring->dequeue;
|
|
|
|
/* FIXME this should be a delayed service routine
|
|
|
|
* that clears the EHB.
|
|
|
|
*/
|
2011-03-29 10:41:02 +08:00
|
|
|
while (xhci_handle_event(xhci) > 0) {}
|
2010-07-30 13:12:38 +08:00
|
|
|
|
|
|
|
temp_64 = xhci_read_64(xhci, &xhci->ir_set->erst_dequeue);
|
2010-07-30 13:12:49 +08:00
|
|
|
/* If necessary, update the HW's version of the event ring deq ptr. */
|
|
|
|
if (event_ring_deq != xhci->event_ring->dequeue) {
|
|
|
|
deq = xhci_trb_virt_to_dma(xhci->event_ring->deq_seg,
|
|
|
|
xhci->event_ring->dequeue);
|
|
|
|
if (deq == 0)
|
|
|
|
xhci_warn(xhci, "WARN something wrong with SW event "
|
|
|
|
"ring dequeue ptr.\n");
|
|
|
|
/* Update HC event ring dequeue pointer */
|
|
|
|
temp_64 &= ERST_PTR_MASK;
|
|
|
|
temp_64 |= ((u64) deq & (u64) ~ERST_PTR_MASK);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Clear the event handler busy flag (RW1C); event ring is empty. */
|
|
|
|
temp_64 |= ERST_EHB;
|
|
|
|
xhci_write_64(xhci, temp_64, &xhci->ir_set->erst_dequeue);
|
|
|
|
|
2010-07-30 13:12:29 +08:00
|
|
|
spin_unlock(&xhci->lock);
|
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
|
|
|
irqreturn_t xhci_msi_irq(int irq, struct usb_hcd *hcd)
|
|
|
|
{
|
2011-11-04 00:03:38 +08:00
|
|
|
return xhci_irq(hcd);
|
2010-07-30 13:12:29 +08:00
|
|
|
}
|
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.
|
2010-06-11 03:25:28 +08:00
|
|
|
*
|
|
|
|
* @more_trbs_coming: Will you enqueue more TRBs before calling
|
|
|
|
* prepare_transfer()?
|
2009-04-28 10:53:56 +08:00
|
|
|
*/
|
|
|
|
static void queue_trb(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
2012-03-05 17:49:32 +08:00
|
|
|
bool more_trbs_coming,
|
2009-04-28 10:53:56 +08:00
|
|
|
u32 field1, u32 field2, u32 field3, u32 field4)
|
|
|
|
{
|
|
|
|
struct xhci_generic_trb *trb;
|
|
|
|
|
|
|
|
trb = &ring->enqueue->generic;
|
2011-03-29 10:40:46 +08:00
|
|
|
trb->field[0] = cpu_to_le32(field1);
|
|
|
|
trb->field[1] = cpu_to_le32(field2);
|
|
|
|
trb->field[2] = cpu_to_le32(field3);
|
|
|
|
trb->field[3] = cpu_to_le32(field4);
|
2012-03-05 17:49:32 +08:00
|
|
|
inc_enq(xhci, ring, more_trbs_coming);
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
|
|
|
|
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,
|
2012-03-05 17:49:32 +08:00
|
|
|
u32 ep_state, unsigned int num_trbs, gfp_t mem_flags)
|
2009-04-28 10:58:01 +08:00
|
|
|
{
|
2012-03-05 17:49:37 +08:00
|
|
|
unsigned int num_trbs_needed;
|
|
|
|
|
2009-04-28 10:58:01 +08:00
|
|
|
/* Make sure the endpoint has been added to xHC schedule */
|
|
|
|
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;
|
|
|
|
}
|
2012-03-05 17:49:37 +08:00
|
|
|
|
|
|
|
while (1) {
|
|
|
|
if (room_on_ring(xhci, ep_ring, num_trbs))
|
|
|
|
break;
|
|
|
|
|
|
|
|
if (ep_ring == xhci->cmd_ring) {
|
|
|
|
xhci_err(xhci, "Do not support expand command ring\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "ERROR no room on ep ring, "
|
|
|
|
"try ring expansion\n");
|
|
|
|
num_trbs_needed = num_trbs - ep_ring->num_trbs_free;
|
|
|
|
if (xhci_ring_expansion(xhci, ep_ring, num_trbs_needed,
|
|
|
|
mem_flags)) {
|
|
|
|
xhci_err(xhci, "Ring expansion failed\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
2012-09-13 01:03:17 +08:00
|
|
|
}
|
2010-05-11 06:33:00 +08:00
|
|
|
|
|
|
|
if (enqueue_is_link_trb(ep_ring)) {
|
|
|
|
struct xhci_ring *ring = ep_ring;
|
|
|
|
union xhci_trb *next;
|
|
|
|
|
|
|
|
next = ring->enqueue;
|
|
|
|
|
|
|
|
while (last_trb(xhci, ring, ring->enq_seg, next)) {
|
xHCI: AMD isoc link TRB chain bit quirk
Setting the chain (CH) bit in the link TRB of isochronous transfer rings
is required by AMD 0.96 xHCI host controller to successfully transverse
multi-TRB TD that span through different memory segments.
When a Missed Service Error event occurs, if the chain bit is not set in
the link TRB and the host skips TDs which just across a link TRB, the
host may falsely recognize the link TRB as a normal TRB. You can see
this may cause big trouble - the host does not jump to the right address
which is pointed by the link TRB, but continue fetching the memory which
is after the link TRB address, which may not even belong to the host,
and the result cannot be predicted.
This causes some big problems. Without the former patch I sent: "xHCI:
prevent infinite loop when processing MSE event", the system may hang.
With that patch applied, system does not hang, but the host still access
wrong memory address and isoc transfer will fail. With this patch,
isochronous transfer works as expected.
This patch should be applied to kernels as old as 2.6.36, which was when
the first isochronous support was added for the xHCI host controller.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-24 05:19:54 +08:00
|
|
|
/* If we're not dealing with 0.95 hardware or isoc rings
|
|
|
|
* on AMD 0.96 host, clear the chain bit.
|
2010-05-11 06:33:00 +08:00
|
|
|
*/
|
2012-03-05 17:49:32 +08:00
|
|
|
if (!xhci_link_trb_quirk(xhci) &&
|
|
|
|
!(ring->type == TYPE_ISOC &&
|
|
|
|
(xhci->quirks & XHCI_AMD_0x96_HOST)))
|
2011-03-29 10:40:46 +08:00
|
|
|
next->link.control &= cpu_to_le32(~TRB_CHAIN);
|
2010-05-11 06:33:00 +08:00
|
|
|
else
|
2011-03-29 10:40:46 +08:00
|
|
|
next->link.control |= cpu_to_le32(TRB_CHAIN);
|
2010-05-11 06:33:00 +08:00
|
|
|
|
|
|
|
wmb();
|
2011-06-01 08:22:55 +08:00
|
|
|
next->link.control ^= cpu_to_le32(TRB_CYCLE);
|
2010-05-11 06:33:00 +08:00
|
|
|
|
|
|
|
/* 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);
|
|
|
|
}
|
|
|
|
ring->enq_seg = ring->enq_seg->next;
|
|
|
|
ring->enqueue = ring->enq_seg->trbs;
|
|
|
|
next = ring->enqueue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-04-28 10:58:01 +08:00
|
|
|
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,
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int stream_id,
|
2009-04-28 10:58:01 +08:00
|
|
|
unsigned int num_trbs,
|
|
|
|
struct urb *urb,
|
2010-07-23 06:23:31 +08:00
|
|
|
unsigned int td_index,
|
2009-04-28 10:58:01 +08:00
|
|
|
gfp_t mem_flags)
|
|
|
|
{
|
|
|
|
int ret;
|
2010-07-23 06:23:31 +08:00
|
|
|
struct urb_priv *urb_priv;
|
|
|
|
struct xhci_td *td;
|
2010-04-03 06:34:43 +08:00
|
|
|
struct xhci_ring *ep_ring;
|
2009-07-28 03:05:15 +08:00
|
|
|
struct xhci_ep_ctx *ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
2010-04-03 06:34:43 +08:00
|
|
|
|
|
|
|
ep_ring = xhci_stream_id_to_ring(xdev, ep_index, stream_id);
|
|
|
|
if (!ep_ring) {
|
|
|
|
xhci_dbg(xhci, "Can't prepare ring for bad stream ID %u\n",
|
|
|
|
stream_id);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = prepare_ring(xhci, ep_ring,
|
2011-03-29 10:40:46 +08:00
|
|
|
le32_to_cpu(ep_ctx->ep_info) & EP_STATE_MASK,
|
2012-03-05 17:49:32 +08:00
|
|
|
num_trbs, mem_flags);
|
2009-04-28 10:58:01 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2010-07-23 06:23:31 +08:00
|
|
|
urb_priv = urb->hcpriv;
|
|
|
|
td = urb_priv->td[td_index];
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&td->td_list);
|
|
|
|
INIT_LIST_HEAD(&td->cancelled_td_list);
|
|
|
|
|
|
|
|
if (td_index == 0) {
|
2010-10-27 02:22:02 +08:00
|
|
|
ret = usb_hcd_link_urb_to_ep(bus_to_hcd(urb->dev->bus), urb);
|
xhci: Fix memory leak during failed enqueue.
When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.
xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.
xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail. Instead, it expects those functions to
free urb_priv if an error occurs. However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL. It will, however, get freed if prepare_transfer() fails in those
enqueue functions.
Several of the error paths in the isochronous endpoint enqueue function
also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB. If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.
This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.
This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-23 05:34:34 +08:00
|
|
|
if (unlikely(ret))
|
2010-07-23 06:23:31 +08:00
|
|
|
return ret;
|
2009-04-28 10:58:01 +08:00
|
|
|
}
|
|
|
|
|
2010-07-23 06:23:31 +08:00
|
|
|
td->urb = urb;
|
2009-04-28 10:58:01 +08:00
|
|
|
/* Add this TD to the tail of the endpoint ring's TD list */
|
2010-07-23 06:23:31 +08:00
|
|
|
list_add_tail(&td->td_list, &ep_ring->td_list);
|
|
|
|
td->start_seg = ep_ring->enq_seg;
|
|
|
|
td->first_trb = ep_ring->enqueue;
|
|
|
|
|
|
|
|
urb_priv->td[td_index] = td;
|
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;
|
2011-12-04 06:41:31 +08:00
|
|
|
num_sgs = urb->num_mapped_sgs;
|
2009-04-28 10:59:19 +08:00
|
|
|
temp = urb->transfer_buffer_length;
|
|
|
|
|
|
|
|
num_trbs = 0;
|
2010-05-02 02:20:01 +08:00
|
|
|
for_each_sg(urb->sg, sg, num_sgs, i) {
|
2009-04-28 10:59:19 +08:00
|
|
|
unsigned int len = sg_dma_len(sg);
|
|
|
|
|
|
|
|
/* Scatter gather list entries may cross 64KB boundaries */
|
|
|
|
running_total = TRB_MAX_BUFF_SIZE -
|
2011-02-13 06:06:44 +08:00
|
|
|
(sg_dma_address(sg) & (TRB_MAX_BUFF_SIZE - 1));
|
2011-02-13 06:07:20 +08:00
|
|
|
running_total &= TRB_MAX_BUFF_SIZE - 1;
|
2009-04-28 10:59:19 +08:00
|
|
|
if (running_total != 0)
|
|
|
|
num_trbs++;
|
|
|
|
|
|
|
|
/* How many more 64KB chunks to transfer, how many more TRBs? */
|
2011-02-13 06:07:57 +08:00
|
|
|
while (running_total < sg_dma_len(sg) && running_total < temp) {
|
2009-04-28 10:59:19 +08:00
|
|
|
num_trbs++;
|
|
|
|
running_total += TRB_MAX_BUFF_SIZE;
|
|
|
|
}
|
|
|
|
len = min_t(int, len, temp);
|
|
|
|
temp -= len;
|
|
|
|
if (temp == 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
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)
|
2011-02-13 06:06:44 +08:00
|
|
|
dev_err(&urb->dev->dev, "%s - ep %#x - Miscalculated number of "
|
2009-04-28 10:59:19 +08:00
|
|
|
"TRBs, %d left\n", __func__,
|
|
|
|
urb->ep->desc.bEndpointAddress, num_trbs);
|
|
|
|
if (running_total != urb->transfer_buffer_length)
|
2011-02-13 06:06:44 +08:00
|
|
|
dev_err(&urb->dev->dev, "%s - ep %#x - Miscalculated tx length, "
|
2009-04-28 10:59:19 +08:00
|
|
|
"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,
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int ep_index, unsigned int stream_id, int start_cycle,
|
2011-01-05 08:30:39 +08:00
|
|
|
struct xhci_generic_trb *start_trb)
|
2009-04-28 10:59:19 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Pass all the TRBs to the hardware at once and make sure this write
|
|
|
|
* isn't reordered.
|
|
|
|
*/
|
|
|
|
wmb();
|
2010-12-20 15:09:34 +08:00
|
|
|
if (start_cycle)
|
2011-03-29 10:40:46 +08:00
|
|
|
start_trb->field[3] |= cpu_to_le32(start_cycle);
|
2010-12-20 15:09:34 +08:00
|
|
|
else
|
2011-03-29 10:40:46 +08:00
|
|
|
start_trb->field[3] &= cpu_to_le32(~TRB_CYCLE);
|
2010-10-14 22:22:57 +08:00
|
|
|
xhci_ring_ep_doorbell(xhci, slot_id, ep_index, stream_id);
|
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;
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
xhci_interval = EP_INTERVAL_TO_UFRAMES(le32_to_cpu(ep_ctx->ep_info));
|
2009-09-03 03:14:28 +08:00
|
|
|
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) {
|
2010-12-20 17:14:20 +08:00
|
|
|
if (printk_ratelimit())
|
2009-09-03 03:14:28 +08:00
|
|
|
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;
|
|
|
|
}
|
2012-03-28 15:30:26 +08:00
|
|
|
return xhci_queue_bulk_tx(xhci, mem_flags, urb, slot_id, ep_index);
|
2009-09-03 03:14:28 +08:00
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2011-04-02 05:01:30 +08:00
|
|
|
/*
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
* For xHCI 1.0 host controllers, TD size is the number of max packet sized
|
|
|
|
* packets remaining in the TD (*not* including this TRB).
|
2011-04-02 05:01:30 +08:00
|
|
|
*
|
|
|
|
* Total TD packet count = total_packet_count =
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
* DIV_ROUND_UP(TD size in bytes / wMaxPacketSize)
|
2011-04-02 05:01:30 +08:00
|
|
|
*
|
|
|
|
* Packets transferred up to and including this TRB = packets_transferred =
|
|
|
|
* rounddown(total bytes transferred including this TRB / wMaxPacketSize)
|
|
|
|
*
|
|
|
|
* TD size = total_packet_count - packets_transferred
|
|
|
|
*
|
|
|
|
* It must fit in bits 21:17, so it can't be bigger than 31.
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
* The last TRB in a TD must have the TD size set to zero.
|
2011-04-02 05:01:30 +08:00
|
|
|
*/
|
|
|
|
static u32 xhci_v1_0_td_remainder(int running_total, int trb_buff_len,
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
unsigned int total_packet_count, struct urb *urb,
|
|
|
|
unsigned int num_trbs_left)
|
2011-04-02 05:01:30 +08:00
|
|
|
{
|
|
|
|
int packets_transferred;
|
|
|
|
|
2011-08-13 01:23:01 +08:00
|
|
|
/* One TRB with a zero-length data packet. */
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
if (num_trbs_left == 0 || (running_total == 0 && trb_buff_len == 0))
|
2011-08-13 01:23:01 +08:00
|
|
|
return 0;
|
|
|
|
|
2011-04-02 05:01:30 +08:00
|
|
|
/* All the TRB queueing functions don't count the current TRB in
|
|
|
|
* running_total.
|
|
|
|
*/
|
|
|
|
packets_transferred = (running_total + trb_buff_len) /
|
xhci: Fix TD size for isochronous URBs.
To calculate the TD size for a particular TRB in an isoc TD, we need
know the endpoint's max packet size. Isochronous endpoints also encode
the number of additional service opportunities in their wMaxPacketSize
field. The TD size calculation did not mask off those bits before using
the field. This resulted in incorrect TD size information for
isochronous TRBs when an URB frame buffer crossed a 64KB boundary.
For example:
- an isoc endpoint has 2 additional service opportunites and
a max packet size of 1020 bytes
- a frame transfer buffer contains 3060 bytes
- one frame buffer crosses a 64KB boundary, and must be split into
one 1276 byte TRB, and one 1784 byte TRB.
The TD size is is the number of packets that remain to be transferred
for a TD after processing all the max packet sized packets in the
current TRB and all previous TRBs.
For this TD, the number of packets to be transferred is (3060 / 1020),
or 3. The first TRB contains 1276 bytes, which means it contains one
full packet, and a 256 byte remainder. After processing all the max
packet-sized packets in the first TRB, the host will have 2 packets left
to transfer.
The old code would calculate the TD size for the first TRB as:
total packet count = DIV_ROUND_UP (TD length / endpoint wMaxPacketSize)
total packet count - (first TRB length / endpoint wMaxPacketSize)
The math should have been:
total packet count = DIV_ROUND_UP (3060 / 1020) = 3
3 - (1276 / 1020) = 2
Since the old code didn't mask off the additional service interval bits
from the wMaxPacketSize field, the math ended up as
total packet count = DIV_ROUND_UP (3060 / 5116) = 1
1 - (1276 / 5116) = 1
Fix this by masking off the number of additional service opportunities
in the wMaxPacketSize field.
This patch should be backported to stable kernels as old as 3.0, that
contain the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0:
Update TD size field format." It may not apply well to kernels older
than 3.2 because of commit 29cc88979a8818cd8c5019426e945aed118b400e
"USB: use usb_endpoint_maxp() instead of le16_to_cpu()".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-01-12 05:36:35 +08:00
|
|
|
GET_MAX_PACKET(usb_endpoint_maxp(&urb->ep->desc));
|
2011-04-02 05:01:30 +08:00
|
|
|
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
if ((total_packet_count - packets_transferred) > 31)
|
|
|
|
return 31 << 17;
|
|
|
|
return (total_packet_count - packets_transferred) << 17;
|
2011-04-02 05:01:30 +08:00
|
|
|
}
|
|
|
|
|
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;
|
2010-07-23 06:23:31 +08:00
|
|
|
struct urb_priv *urb_priv;
|
2009-04-28 10:59:19 +08:00
|
|
|
struct xhci_td *td;
|
|
|
|
struct scatterlist *sg;
|
|
|
|
int num_sgs;
|
|
|
|
int trb_buff_len, this_sg_len, running_total;
|
2011-04-02 05:01:30 +08:00
|
|
|
unsigned int total_packet_count;
|
2009-04-28 10:59:19 +08:00
|
|
|
bool first_trb;
|
|
|
|
u64 addr;
|
2010-06-11 03:25:28 +08:00
|
|
|
bool more_trbs_coming;
|
2009-04-28 10:59:19 +08:00
|
|
|
|
|
|
|
struct xhci_generic_trb *start_trb;
|
|
|
|
int start_cycle;
|
|
|
|
|
2010-04-03 06:34:43 +08:00
|
|
|
ep_ring = xhci_urb_to_transfer_ring(xhci, urb);
|
|
|
|
if (!ep_ring)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2009-04-28 10:59:19 +08:00
|
|
|
num_trbs = count_sg_trbs_needed(xhci, urb);
|
2011-12-04 06:41:31 +08:00
|
|
|
num_sgs = urb->num_mapped_sgs;
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
total_packet_count = DIV_ROUND_UP(urb->transfer_buffer_length,
|
2011-08-23 18:12:03 +08:00
|
|
|
usb_endpoint_maxp(&urb->ep->desc));
|
2009-04-28 10:59:19 +08:00
|
|
|
|
2009-04-30 10:05:20 +08:00
|
|
|
trb_buff_len = prepare_transfer(xhci, xhci->devs[slot_id],
|
2010-04-03 06:34:43 +08:00
|
|
|
ep_index, urb->stream_id,
|
2012-03-05 17:49:32 +08:00
|
|
|
num_trbs, urb, 0, mem_flags);
|
2009-04-28 10:59:19 +08:00
|
|
|
if (trb_buff_len < 0)
|
|
|
|
return trb_buff_len;
|
2010-07-23 06:23:31 +08:00
|
|
|
|
|
|
|
urb_priv = urb->hcpriv;
|
|
|
|
td = urb_priv->td[0];
|
|
|
|
|
2009-04-28 10:59:19 +08:00
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
2010-05-02 02:20:01 +08:00
|
|
|
sg = urb->sg;
|
2009-04-28 10:59:19 +08:00
|
|
|
addr = (u64) sg_dma_address(sg);
|
|
|
|
this_sg_len = sg_dma_len(sg);
|
2011-02-13 06:06:44 +08:00
|
|
|
trb_buff_len = TRB_MAX_BUFF_SIZE - (addr & (TRB_MAX_BUFF_SIZE - 1));
|
2009-04-28 10:59:19 +08:00
|
|
|
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;
|
|
|
|
|
|
|
|
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 */
|
2010-12-20 15:09:34 +08:00
|
|
|
if (first_trb) {
|
2009-04-28 10:59:19 +08:00
|
|
|
first_trb = false;
|
2010-12-20 15:09:34 +08:00
|
|
|
if (start_cycle == 0)
|
|
|
|
field |= 0x1;
|
|
|
|
} else
|
2009-04-28 10:59:19 +08:00
|
|
|
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;
|
|
|
|
}
|
2011-03-24 07:26:26 +08:00
|
|
|
|
|
|
|
/* Only set interrupt on short packet for IN endpoints */
|
|
|
|
if (usb_urb_dir_in(urb))
|
|
|
|
field |= TRB_ISP;
|
|
|
|
|
2009-04-28 10:59:19 +08:00
|
|
|
if (TRB_MAX_BUFF_SIZE -
|
2011-02-13 06:06:44 +08:00
|
|
|
(addr & (TRB_MAX_BUFF_SIZE - 1)) < trb_buff_len) {
|
2009-04-28 10:59:19 +08:00
|
|
|
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);
|
|
|
|
}
|
2011-04-02 05:01:30 +08:00
|
|
|
|
|
|
|
/* Set the TRB length, TD size, and interrupter fields. */
|
|
|
|
if (xhci->hci_version < 0x100) {
|
|
|
|
remainder = xhci_td_remainder(
|
|
|
|
urb->transfer_buffer_length -
|
|
|
|
running_total);
|
|
|
|
} else {
|
|
|
|
remainder = xhci_v1_0_td_remainder(running_total,
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
trb_buff_len, total_packet_count, urb,
|
|
|
|
num_trbs - 1);
|
2011-04-02 05:01:30 +08:00
|
|
|
}
|
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);
|
2011-04-02 05:01:30 +08:00
|
|
|
|
2010-06-11 03:25:28 +08:00
|
|
|
if (num_trbs > 1)
|
|
|
|
more_trbs_coming = true;
|
|
|
|
else
|
|
|
|
more_trbs_coming = false;
|
2012-03-05 17:49:32 +08:00
|
|
|
queue_trb(xhci, ep_ring, more_trbs_coming,
|
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,
|
2011-03-24 07:26:26 +08:00
|
|
|
field | TRB_TYPE(TRB_NORMAL));
|
2009-04-28 10:59:19 +08:00
|
|
|
--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 -
|
2011-02-13 06:06:44 +08:00
|
|
|
(addr & (TRB_MAX_BUFF_SIZE - 1));
|
2009-04-28 10:59:19 +08:00
|
|
|
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);
|
2010-04-03 06:34:43 +08:00
|
|
|
giveback_first_trb(xhci, slot_id, ep_index, urb->stream_id,
|
2011-01-05 08:30:39 +08:00
|
|
|
start_cycle, start_trb);
|
2009-04-28 10:59:19 +08:00
|
|
|
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;
|
2010-07-23 06:23:31 +08:00
|
|
|
struct urb_priv *urb_priv;
|
2009-04-28 10:58:50 +08:00
|
|
|
struct xhci_td *td;
|
|
|
|
int num_trbs;
|
|
|
|
struct xhci_generic_trb *start_trb;
|
|
|
|
bool first_trb;
|
2010-06-11 03:25:28 +08:00
|
|
|
bool more_trbs_coming;
|
2009-04-28 10:58:50 +08:00
|
|
|
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;
|
2011-04-02 05:01:30 +08:00
|
|
|
unsigned int total_packet_count;
|
2009-04-28 10:58:50 +08:00
|
|
|
u64 addr;
|
|
|
|
|
2010-04-03 01:27:28 +08:00
|
|
|
if (urb->num_sgs)
|
2009-04-28 10:59:19 +08:00
|
|
|
return queue_bulk_sg_tx(xhci, mem_flags, urb, slot_id, ep_index);
|
|
|
|
|
2010-04-03 06:34:43 +08:00
|
|
|
ep_ring = xhci_urb_to_transfer_ring(xhci, urb);
|
|
|
|
if (!ep_ring)
|
|
|
|
return -EINVAL;
|
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 -
|
2011-02-13 06:06:44 +08:00
|
|
|
(urb->transfer_dma & (TRB_MAX_BUFF_SIZE - 1));
|
2011-02-13 06:07:20 +08:00
|
|
|
running_total &= TRB_MAX_BUFF_SIZE - 1;
|
2009-04-28 10:58:50 +08:00
|
|
|
|
|
|
|
/* 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 */
|
|
|
|
|
2010-04-03 06:34:43 +08:00
|
|
|
ret = prepare_transfer(xhci, xhci->devs[slot_id],
|
|
|
|
ep_index, urb->stream_id,
|
2012-03-05 17:49:32 +08:00
|
|
|
num_trbs, urb, 0, mem_flags);
|
2009-04-28 10:58:50 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2010-07-23 06:23:31 +08:00
|
|
|
urb_priv = urb->hcpriv;
|
|
|
|
td = urb_priv->td[0];
|
|
|
|
|
2009-04-28 10:58:50 +08:00
|
|
|
/*
|
|
|
|
* 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;
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
total_packet_count = DIV_ROUND_UP(urb->transfer_buffer_length,
|
2011-08-23 18:12:03 +08:00
|
|
|
usb_endpoint_maxp(&urb->ep->desc));
|
2009-04-28 10:58:50 +08:00
|
|
|
/* How much data is in the first TRB? */
|
|
|
|
addr = (u64) urb->transfer_dma;
|
|
|
|
trb_buff_len = TRB_MAX_BUFF_SIZE -
|
2011-02-13 06:06:44 +08:00
|
|
|
(urb->transfer_dma & (TRB_MAX_BUFF_SIZE - 1));
|
|
|
|
if (trb_buff_len > urb->transfer_buffer_length)
|
2009-04-28 10:58:50 +08:00
|
|
|
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 */
|
2010-12-20 15:09:34 +08:00
|
|
|
if (first_trb) {
|
2009-04-28 10:58:50 +08:00
|
|
|
first_trb = false;
|
2010-12-20 15:09:34 +08:00
|
|
|
if (start_cycle == 0)
|
|
|
|
field |= 0x1;
|
|
|
|
} else
|
2009-04-28 10:58:50 +08:00
|
|
|
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;
|
|
|
|
}
|
2011-03-24 07:26:26 +08:00
|
|
|
|
|
|
|
/* Only set interrupt on short packet for IN endpoints */
|
|
|
|
if (usb_urb_dir_in(urb))
|
|
|
|
field |= TRB_ISP;
|
|
|
|
|
2011-04-02 05:01:30 +08:00
|
|
|
/* Set the TRB length, TD size, and interrupter fields. */
|
|
|
|
if (xhci->hci_version < 0x100) {
|
|
|
|
remainder = xhci_td_remainder(
|
|
|
|
urb->transfer_buffer_length -
|
|
|
|
running_total);
|
|
|
|
} else {
|
|
|
|
remainder = xhci_v1_0_td_remainder(running_total,
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
trb_buff_len, total_packet_count, urb,
|
|
|
|
num_trbs - 1);
|
2011-04-02 05:01:30 +08:00
|
|
|
}
|
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);
|
2011-04-02 05:01:30 +08:00
|
|
|
|
2010-06-11 03:25:28 +08:00
|
|
|
if (num_trbs > 1)
|
|
|
|
more_trbs_coming = true;
|
|
|
|
else
|
|
|
|
more_trbs_coming = false;
|
2012-03-05 17:49:32 +08:00
|
|
|
queue_trb(xhci, ep_ring, more_trbs_coming,
|
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,
|
2011-03-24 07:26:26 +08:00
|
|
|
field | TRB_TYPE(TRB_NORMAL));
|
2009-04-28 10:58:50 +08:00
|
|
|
--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);
|
2010-04-03 06:34:43 +08:00
|
|
|
giveback_first_trb(xhci, slot_id, ep_index, urb->stream_id,
|
2011-01-05 08:30:39 +08:00
|
|
|
start_cycle, start_trb);
|
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;
|
2010-07-23 06:23:31 +08:00
|
|
|
struct urb_priv *urb_priv;
|
2009-04-28 10:58:01 +08:00
|
|
|
struct xhci_td *td;
|
|
|
|
|
2010-04-03 06:34:43 +08:00
|
|
|
ep_ring = xhci_urb_to_transfer_ring(xhci, urb);
|
|
|
|
if (!ep_ring)
|
|
|
|
return -EINVAL;
|
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;
|
|
|
|
|
|
|
|
/* 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++;
|
2010-04-03 06:34:43 +08:00
|
|
|
ret = prepare_transfer(xhci, xhci->devs[slot_id],
|
|
|
|
ep_index, urb->stream_id,
|
2012-03-05 17:49:32 +08:00
|
|
|
num_trbs, urb, 0, mem_flags);
|
2009-04-28 10:58:01 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
|
2010-07-23 06:23:31 +08:00
|
|
|
urb_priv = urb->hcpriv;
|
|
|
|
td = urb_priv->td[0];
|
|
|
|
|
2009-04-28 10:58:01 +08:00
|
|
|
/*
|
|
|
|
* 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;
|
2010-12-20 15:09:34 +08:00
|
|
|
field = 0;
|
|
|
|
field |= TRB_IDT | TRB_TYPE(TRB_SETUP);
|
|
|
|
if (start_cycle == 0)
|
|
|
|
field |= 0x1;
|
2011-05-05 18:13:56 +08:00
|
|
|
|
|
|
|
/* xHCI 1.0 6.4.1.2.1: Transfer Type field */
|
|
|
|
if (xhci->hci_version == 0x100) {
|
|
|
|
if (urb->transfer_buffer_length > 0) {
|
|
|
|
if (setup->bRequestType & USB_DIR_IN)
|
|
|
|
field |= TRB_TX_TYPE(TRB_DATA_IN);
|
|
|
|
else
|
|
|
|
field |= TRB_TX_TYPE(TRB_DATA_OUT);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-05 17:49:32 +08:00
|
|
|
queue_trb(xhci, ep_ring, true,
|
2011-03-29 10:40:46 +08:00
|
|
|
setup->bRequestType | setup->bRequest << 8 | le16_to_cpu(setup->wValue) << 16,
|
|
|
|
le16_to_cpu(setup->wIndex) | le16_to_cpu(setup->wLength) << 16,
|
|
|
|
TRB_LEN(8) | TRB_INTR_TARGET(0),
|
|
|
|
/* Immediate data in pointer */
|
|
|
|
field);
|
2009-04-28 10:58:01 +08:00
|
|
|
|
|
|
|
/* If there's data, queue data TRBs */
|
2011-03-24 07:26:26 +08:00
|
|
|
/* Only set interrupt on short packet for IN endpoints */
|
|
|
|
if (usb_urb_dir_in(urb))
|
|
|
|
field = TRB_ISP | TRB_TYPE(TRB_DATA);
|
|
|
|
else
|
|
|
|
field = TRB_TYPE(TRB_DATA);
|
|
|
|
|
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;
|
2012-03-05 17:49:32 +08:00
|
|
|
queue_trb(xhci, ep_ring, true,
|
2009-04-28 10:58:01 +08:00
|
|
|
lower_32_bits(urb->transfer_dma),
|
|
|
|
upper_32_bits(urb->transfer_dma),
|
2009-07-28 03:03:07 +08:00
|
|
|
length_field,
|
2011-03-24 07:26:26 +08:00
|
|
|
field | ep_ring->cycle_state);
|
2009-04-28 10:58:01 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* 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;
|
2012-03-05 17:49:32 +08:00
|
|
|
queue_trb(xhci, ep_ring, false,
|
2009-04-28 10:58:01 +08:00
|
|
|
0,
|
|
|
|
0,
|
|
|
|
TRB_INTR_TARGET(0),
|
|
|
|
/* Event on completion */
|
|
|
|
field | TRB_IOC | TRB_TYPE(TRB_STATUS) | ep_ring->cycle_state);
|
|
|
|
|
2010-04-03 06:34:43 +08:00
|
|
|
giveback_first_trb(xhci, slot_id, ep_index, 0,
|
2011-01-05 08:30:39 +08:00
|
|
|
start_cycle, start_trb);
|
2009-04-28 10:58:01 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-07-23 06:23:39 +08:00
|
|
|
static int count_isoc_trbs_needed(struct xhci_hcd *xhci,
|
|
|
|
struct urb *urb, int i)
|
|
|
|
{
|
|
|
|
int num_trbs = 0;
|
2011-08-13 01:23:01 +08:00
|
|
|
u64 addr, td_len;
|
2010-07-23 06:23:39 +08:00
|
|
|
|
|
|
|
addr = (u64) (urb->transfer_dma + urb->iso_frame_desc[i].offset);
|
|
|
|
td_len = urb->iso_frame_desc[i].length;
|
|
|
|
|
2011-08-13 01:23:01 +08:00
|
|
|
num_trbs = DIV_ROUND_UP(td_len + (addr & (TRB_MAX_BUFF_SIZE - 1)),
|
|
|
|
TRB_MAX_BUFF_SIZE);
|
|
|
|
if (num_trbs == 0)
|
2010-07-23 06:23:39 +08:00
|
|
|
num_trbs++;
|
|
|
|
|
|
|
|
return num_trbs;
|
|
|
|
}
|
|
|
|
|
2011-04-09 00:37:29 +08:00
|
|
|
/*
|
|
|
|
* The transfer burst count field of the isochronous TRB defines the number of
|
|
|
|
* bursts that are required to move all packets in this TD. Only SuperSpeed
|
|
|
|
* devices can burst up to bMaxBurst number of packets per service interval.
|
|
|
|
* This field is zero based, meaning a value of zero in the field means one
|
|
|
|
* burst. Basically, for everything but SuperSpeed devices, this field will be
|
|
|
|
* zero. Only xHCI 1.0 host controllers support this field.
|
|
|
|
*/
|
|
|
|
static unsigned int xhci_get_burst_count(struct xhci_hcd *xhci,
|
|
|
|
struct usb_device *udev,
|
|
|
|
struct urb *urb, unsigned int total_packet_count)
|
|
|
|
{
|
|
|
|
unsigned int max_burst;
|
|
|
|
|
|
|
|
if (xhci->hci_version < 0x100 || udev->speed != USB_SPEED_SUPER)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
max_burst = urb->ep->ss_ep_comp.bMaxBurst;
|
|
|
|
return roundup(total_packet_count, max_burst + 1) - 1;
|
|
|
|
}
|
|
|
|
|
2011-04-20 08:43:33 +08:00
|
|
|
/*
|
|
|
|
* Returns the number of packets in the last "burst" of packets. This field is
|
|
|
|
* valid for all speeds of devices. USB 2.0 devices can only do one "burst", so
|
|
|
|
* the last burst packet count is equal to the total number of packets in the
|
|
|
|
* TD. SuperSpeed endpoints can have up to 3 bursts. All but the last burst
|
|
|
|
* must contain (bMaxBurst + 1) number of packets, but the last burst can
|
|
|
|
* contain 1 to (bMaxBurst + 1) packets.
|
|
|
|
*/
|
|
|
|
static unsigned int xhci_get_last_burst_packet_count(struct xhci_hcd *xhci,
|
|
|
|
struct usb_device *udev,
|
|
|
|
struct urb *urb, unsigned int total_packet_count)
|
|
|
|
{
|
|
|
|
unsigned int max_burst;
|
|
|
|
unsigned int residue;
|
|
|
|
|
|
|
|
if (xhci->hci_version < 0x100)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
switch (udev->speed) {
|
|
|
|
case USB_SPEED_SUPER:
|
|
|
|
/* bMaxBurst is zero based: 0 means 1 packet per burst */
|
|
|
|
max_burst = urb->ep->ss_ep_comp.bMaxBurst;
|
|
|
|
residue = total_packet_count % (max_burst + 1);
|
|
|
|
/* If residue is zero, the last burst contains (max_burst + 1)
|
|
|
|
* number of packets, but the TLBPC field is zero-based.
|
|
|
|
*/
|
|
|
|
if (residue == 0)
|
|
|
|
return max_burst;
|
|
|
|
return residue - 1;
|
|
|
|
default:
|
|
|
|
if (total_packet_count == 0)
|
|
|
|
return 0;
|
|
|
|
return total_packet_count - 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-07-23 06:23:39 +08:00
|
|
|
/* This is for isoc transfer */
|
|
|
|
static int xhci_queue_isoc_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
|
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index)
|
|
|
|
{
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
struct urb_priv *urb_priv;
|
|
|
|
struct xhci_td *td;
|
|
|
|
int num_tds, trbs_per_td;
|
|
|
|
struct xhci_generic_trb *start_trb;
|
|
|
|
bool first_trb;
|
|
|
|
int start_cycle;
|
|
|
|
u32 field, length_field;
|
|
|
|
int running_total, trb_buff_len, td_len, td_remain_len, ret;
|
|
|
|
u64 start_addr, addr;
|
|
|
|
int i, j;
|
2010-12-20 14:49:48 +08:00
|
|
|
bool more_trbs_coming;
|
2010-07-23 06:23:39 +08:00
|
|
|
|
|
|
|
ep_ring = xhci->devs[slot_id]->eps[ep_index].ring;
|
|
|
|
|
|
|
|
num_tds = urb->number_of_packets;
|
|
|
|
if (num_tds < 1) {
|
|
|
|
xhci_dbg(xhci, "Isoc URB with zero packets?\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
start_addr = (u64) urb->transfer_dma;
|
|
|
|
start_trb = &ep_ring->enqueue->generic;
|
|
|
|
start_cycle = ep_ring->cycle_state;
|
|
|
|
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-30 03:44:32 +08:00
|
|
|
urb_priv = urb->hcpriv;
|
2010-07-23 06:23:39 +08:00
|
|
|
/* Queue the first TRB, even if it's zero-length */
|
|
|
|
for (i = 0; i < num_tds; i++) {
|
2011-04-02 05:01:30 +08:00
|
|
|
unsigned int total_packet_count;
|
2011-04-09 00:37:29 +08:00
|
|
|
unsigned int burst_count;
|
2011-04-20 08:43:33 +08:00
|
|
|
unsigned int residue;
|
2010-07-23 06:23:39 +08:00
|
|
|
|
2011-04-02 05:01:30 +08:00
|
|
|
first_trb = true;
|
2010-07-23 06:23:39 +08:00
|
|
|
running_total = 0;
|
|
|
|
addr = start_addr + urb->iso_frame_desc[i].offset;
|
|
|
|
td_len = urb->iso_frame_desc[i].length;
|
|
|
|
td_remain_len = td_len;
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
total_packet_count = DIV_ROUND_UP(td_len,
|
xhci: Fix TD size for isochronous URBs.
To calculate the TD size for a particular TRB in an isoc TD, we need
know the endpoint's max packet size. Isochronous endpoints also encode
the number of additional service opportunities in their wMaxPacketSize
field. The TD size calculation did not mask off those bits before using
the field. This resulted in incorrect TD size information for
isochronous TRBs when an URB frame buffer crossed a 64KB boundary.
For example:
- an isoc endpoint has 2 additional service opportunites and
a max packet size of 1020 bytes
- a frame transfer buffer contains 3060 bytes
- one frame buffer crosses a 64KB boundary, and must be split into
one 1276 byte TRB, and one 1784 byte TRB.
The TD size is is the number of packets that remain to be transferred
for a TD after processing all the max packet sized packets in the
current TRB and all previous TRBs.
For this TD, the number of packets to be transferred is (3060 / 1020),
or 3. The first TRB contains 1276 bytes, which means it contains one
full packet, and a 256 byte remainder. After processing all the max
packet-sized packets in the first TRB, the host will have 2 packets left
to transfer.
The old code would calculate the TD size for the first TRB as:
total packet count = DIV_ROUND_UP (TD length / endpoint wMaxPacketSize)
total packet count - (first TRB length / endpoint wMaxPacketSize)
The math should have been:
total packet count = DIV_ROUND_UP (3060 / 1020) = 3
3 - (1276 / 1020) = 2
Since the old code didn't mask off the additional service interval bits
from the wMaxPacketSize field, the math ended up as
total packet count = DIV_ROUND_UP (3060 / 5116) = 1
1 - (1276 / 5116) = 1
Fix this by masking off the number of additional service opportunities
in the wMaxPacketSize field.
This patch should be backported to stable kernels as old as 3.0, that
contain the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0:
Update TD size field format." It may not apply well to kernels older
than 3.2 because of commit 29cc88979a8818cd8c5019426e945aed118b400e
"USB: use usb_endpoint_maxp() instead of le16_to_cpu()".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-01-12 05:36:35 +08:00
|
|
|
GET_MAX_PACKET(
|
|
|
|
usb_endpoint_maxp(&urb->ep->desc)));
|
2011-08-13 01:23:01 +08:00
|
|
|
/* A zero-length transfer still involves at least one packet. */
|
|
|
|
if (total_packet_count == 0)
|
|
|
|
total_packet_count++;
|
2011-04-09 00:37:29 +08:00
|
|
|
burst_count = xhci_get_burst_count(xhci, urb->dev, urb,
|
|
|
|
total_packet_count);
|
2011-04-20 08:43:33 +08:00
|
|
|
residue = xhci_get_last_burst_packet_count(xhci,
|
|
|
|
urb->dev, urb, total_packet_count);
|
2010-07-23 06:23:39 +08:00
|
|
|
|
|
|
|
trbs_per_td = count_isoc_trbs_needed(xhci, urb, i);
|
|
|
|
|
|
|
|
ret = prepare_transfer(xhci, xhci->devs[slot_id], ep_index,
|
2012-03-05 17:49:32 +08:00
|
|
|
urb->stream_id, trbs_per_td, urb, i, mem_flags);
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-30 03:44:32 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
if (i == 0)
|
|
|
|
return ret;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2010-07-23 06:23:39 +08:00
|
|
|
|
|
|
|
td = urb_priv->td[i];
|
|
|
|
for (j = 0; j < trbs_per_td; j++) {
|
|
|
|
u32 remainder = 0;
|
2013-01-12 03:19:07 +08:00
|
|
|
field = 0;
|
2010-07-23 06:23:39 +08:00
|
|
|
|
|
|
|
if (first_trb) {
|
2013-01-12 03:19:07 +08:00
|
|
|
field = TRB_TBC(burst_count) |
|
|
|
|
TRB_TLBPC(residue);
|
2010-07-23 06:23:39 +08:00
|
|
|
/* Queue the isoc TRB */
|
|
|
|
field |= TRB_TYPE(TRB_ISOC);
|
|
|
|
/* Assume URB_ISO_ASAP is set */
|
|
|
|
field |= TRB_SIA;
|
2010-12-20 15:09:34 +08:00
|
|
|
if (i == 0) {
|
|
|
|
if (start_cycle == 0)
|
|
|
|
field |= 0x1;
|
|
|
|
} else
|
2010-07-23 06:23:39 +08:00
|
|
|
field |= ep_ring->cycle_state;
|
|
|
|
first_trb = false;
|
|
|
|
} else {
|
|
|
|
/* Queue other normal TRBs */
|
|
|
|
field |= TRB_TYPE(TRB_NORMAL);
|
|
|
|
field |= ep_ring->cycle_state;
|
|
|
|
}
|
|
|
|
|
2011-03-24 07:26:26 +08:00
|
|
|
/* Only set interrupt on short packet for IN EPs */
|
|
|
|
if (usb_urb_dir_in(urb))
|
|
|
|
field |= TRB_ISP;
|
|
|
|
|
2010-07-23 06:23:39 +08:00
|
|
|
/* Chain all the TRBs together; clear the chain bit in
|
|
|
|
* the last TRB to indicate it's the last TRB in the
|
|
|
|
* chain.
|
|
|
|
*/
|
|
|
|
if (j < trbs_per_td - 1) {
|
|
|
|
field |= TRB_CHAIN;
|
2010-12-20 14:49:48 +08:00
|
|
|
more_trbs_coming = true;
|
2010-07-23 06:23:39 +08:00
|
|
|
} else {
|
|
|
|
td->last_trb = ep_ring->enqueue;
|
|
|
|
field |= TRB_IOC;
|
xhci: Intel Panther Point BEI quirk.
When a device with an isochronous endpoint is behind a hub plugged into
the Intel Panther Point xHCI host controller, and the driver submits
multiple frames per URB, the xHCI driver will set the Block Event
Interrupt (BEI) flag on all but the last TD for the URB. This causes
the host controller to place an event on the event ring, but not send an
interrupt. When the last TD for the URB completes, BEI is cleared, and
we get an interrupt for the whole URB.
However, under a Panther Point xHCI host controller, if the parent hub
is unplugged when one or more events from transfers with BEI set are on
the event ring, a port status change event is placed on the event ring,
but no interrupt is generated. This means URBs stop completing, and the
USB device disconnect is not noticed. Something like a USB headset will
cause mplayer to hang when the device is disconnected.
If another transfer is sent (such as running `sudo lsusb -v`), the next
transfer event seems to "unstick" the event ring, the xHCI driver gets
an interrupt, and the disconnect is reported to the USB core.
The fix is not to use the BEI flag under the Panther Point xHCI host.
This will impact power consumption and system responsiveness, because
the xHCI driver will receive an interrupt for every frame in all
isochronous URBs instead of once per URB.
Intel chipset developers confirm that this bug will be hit if the BEI
flag is used on any endpoint, not just ones that are behind a hub.
This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-09-20 07:27:26 +08:00
|
|
|
if (xhci->hci_version == 0x100 &&
|
|
|
|
!(xhci->quirks &
|
|
|
|
XHCI_AVOID_BEI)) {
|
2011-05-05 18:14:02 +08:00
|
|
|
/* Set BEI bit except for the last td */
|
|
|
|
if (i < num_tds - 1)
|
|
|
|
field |= TRB_BEI;
|
|
|
|
}
|
2010-12-20 14:49:48 +08:00
|
|
|
more_trbs_coming = false;
|
2010-07-23 06:23:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Calculate TRB length */
|
|
|
|
trb_buff_len = TRB_MAX_BUFF_SIZE -
|
|
|
|
(addr & ((1 << TRB_MAX_BUFF_SHIFT) - 1));
|
|
|
|
if (trb_buff_len > td_remain_len)
|
|
|
|
trb_buff_len = td_remain_len;
|
|
|
|
|
2011-04-02 05:01:30 +08:00
|
|
|
/* Set the TRB length, TD size, & interrupter fields. */
|
|
|
|
if (xhci->hci_version < 0x100) {
|
|
|
|
remainder = xhci_td_remainder(
|
|
|
|
td_len - running_total);
|
|
|
|
} else {
|
|
|
|
remainder = xhci_v1_0_td_remainder(
|
|
|
|
running_total, trb_buff_len,
|
xHCI: Fix TD Size calculation on 1.0 hosts.
The xHCI 1.0 specification made a change to the TD Size field in TRBs.
The value is now the number of packets that remain to be sent in the TD,
not including this TRB. The TD Size value for the last TRB in a TD must
always be zero.
The xHCI function xhci_v1_0_td_remainder() attempts to calculate this,
but it gets it wrong. First, it erroneously reuses the old
xhci_td_remainder function, which will right shift the value by 10. The
xHCI 1.0 spec as of June 2011 says nothing about right shifting by 10.
Second, it does not set the TD size for the last TRB in a TD to zero.
Third, it uses roundup instead of DIV_ROUND_UP. The total packet count
is supposed to be the total number of bytes in this TD, divided by the
max packet size, rounded up. DIV_ROUND_UP is the right function to use
in that case.
With the old code, a TD on an endpoint with max packet size 1024 would
be set up like so:
TRB 1, TRB length = 600 bytes, TD size = 0
TRB 1, TRB length = 200 bytes, TD size = 0
TRB 1, TRB length = 100 bytes, TD size = 0
With the new code, the TD would be set up like this:
TRB 1, TRB length = 600 bytes, TD size = 1
TRB 1, TRB length = 200 bytes, TD size = 1
TRB 1, TRB length = 100 bytes, TD size = 0
This commit should be backported to kernels as old as 3.0, that contain
the commit 4da6e6f247a2601ab9f1e63424e4d944ed4124f3 "xhci 1.0: Update TD
size field format."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Chintan Mehta <chintan.mehta@sibridgetech.com>
Reported-by: Shimmer Huang <shimmering.h@gmail.com>
Tested-by: Bhavik Kothari <bhavik.kothari@sibridgetech.com>
Tested-by: Shimmer Huang <shimmering.h@gmail.com>
Cc: stable@vger.kernel.org
2012-10-26 06:56:40 +08:00
|
|
|
total_packet_count, urb,
|
|
|
|
(trbs_per_td - j - 1));
|
2011-04-02 05:01:30 +08:00
|
|
|
}
|
2010-07-23 06:23:39 +08:00
|
|
|
length_field = TRB_LEN(trb_buff_len) |
|
|
|
|
remainder |
|
|
|
|
TRB_INTR_TARGET(0);
|
2011-04-02 05:01:30 +08:00
|
|
|
|
2012-03-05 17:49:32 +08:00
|
|
|
queue_trb(xhci, ep_ring, more_trbs_coming,
|
2010-07-23 06:23:39 +08:00
|
|
|
lower_32_bits(addr),
|
|
|
|
upper_32_bits(addr),
|
|
|
|
length_field,
|
2011-03-24 07:26:26 +08:00
|
|
|
field);
|
2010-07-23 06:23:39 +08:00
|
|
|
running_total += trb_buff_len;
|
|
|
|
|
|
|
|
addr += trb_buff_len;
|
|
|
|
td_remain_len -= trb_buff_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check TD length */
|
|
|
|
if (running_total != td_len) {
|
|
|
|
xhci_err(xhci, "ISOC TD length unmatch\n");
|
2012-01-18 17:47:12 +08:00
|
|
|
ret = -EINVAL;
|
|
|
|
goto cleanup;
|
2010-07-23 06:23:39 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-03-22 17:08:14 +08:00
|
|
|
if (xhci_to_hcd(xhci)->self.bandwidth_isoc_reqs == 0) {
|
|
|
|
if (xhci->quirks & XHCI_AMD_PLL_FIX)
|
|
|
|
usb_amd_quirk_pll_disable();
|
|
|
|
}
|
|
|
|
xhci_to_hcd(xhci)->self.bandwidth_isoc_reqs++;
|
|
|
|
|
2011-01-05 08:30:39 +08:00
|
|
|
giveback_first_trb(xhci, slot_id, ep_index, urb->stream_id,
|
|
|
|
start_cycle, start_trb);
|
2010-07-23 06:23:39 +08:00
|
|
|
return 0;
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-30 03:44:32 +08:00
|
|
|
cleanup:
|
|
|
|
/* Clean up a partially enqueued isoc transfer. */
|
|
|
|
|
|
|
|
for (i--; i >= 0; i--)
|
2011-08-03 06:43:40 +08:00
|
|
|
list_del_init(&urb_priv->td[i]->td_list);
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-30 03:44:32 +08:00
|
|
|
|
|
|
|
/* Use the first TD as a temporary variable to turn the TDs we've queued
|
|
|
|
* into No-ops with a software-owned cycle bit. That way the hardware
|
|
|
|
* won't accidentally start executing bogus TDs when we partially
|
|
|
|
* overwrite them. td->first_trb and td->start_seg are already set.
|
|
|
|
*/
|
|
|
|
urb_priv->td[0]->last_trb = ep_ring->enqueue;
|
|
|
|
/* Every TRB except the first & last will have its cycle bit flipped. */
|
|
|
|
td_to_noop(xhci, ep_ring, urb_priv->td[0], true);
|
|
|
|
|
|
|
|
/* Reset the ring enqueue back to the first TRB and its cycle bit. */
|
|
|
|
ep_ring->enqueue = urb_priv->td[0]->first_trb;
|
|
|
|
ep_ring->enq_seg = urb_priv->td[0]->start_seg;
|
|
|
|
ep_ring->cycle_state = start_cycle;
|
2012-03-05 17:49:34 +08:00
|
|
|
ep_ring->num_trbs_free = ep_ring->num_trbs_free_temp;
|
xhci: Fix failed enqueue in the middle of isoch TD.
When an isochronous transfer is enqueued, xhci_queue_isoc_tx_prepare()
will ensure that there is enough room on the transfer rings for all of the
isochronous TDs for that URB. However, when xhci_queue_isoc_tx() is
enqueueing individual isoc TDs, the prepare_transfer() function can fail
if the endpoint state has changed to disabled, error, or some other
unknown state.
With the current code, if Nth TD (not the first TD) fails, the ring is
left in a sorry state. The partially enqueued TDs are left on the ring,
and the first TRB of the TD is not given back to the hardware. The
enqueue pointer is left on the TRB after the last successfully enqueued
TD. This means the ring is basically useless. Any new transfers will be
enqueued after the failed TDs, which the hardware will never read because
the cycle bit indicates it does not own them. The ring will fill up with
untransferred TDs, and the endpoint will be basically unusable.
The untransferred TDs will also remain on the TD list. Since the td_list
is a FIFO, this basically means the ring handler will be waiting on TDs
that will never be completed (or worse, dereference memory that doesn't
exist any more).
Change the code to clean up the isochronous ring after a failed transfer.
If the first TD failed, simply return and allow the xhci_urb_enqueue
function to free the urb_priv. If the Nth TD failed, first remove the TDs
from the td_list. Then convert the TRBs that were enqueued into No-op
TRBs. Make sure to flip the cycle bit on all enqueued TRBs (including any
link TRBs in the middle or between TDs), but leave the cycle bit of the
first TRB (which will show software-owned) intact. Then move the ring
enqueue pointer back to the first TRB and make sure to change the
xhci_ring's cycle state to what is appropriate for that ring segment.
This ensures that the No-op TRBs will be overwritten by subsequent TDs,
and the hardware will not start executing random TRBs because the cycle
bit was left as hardware-owned.
This bug is unlikely to be hit, but it was something I noticed while
tracking down the watchdog timer issue. I verified that the fix works by
injecting some errors on the 250th isochronous URB queued, although I
could not verify that the ring is in the correct state because uvcvideo
refused to talk to the device after the first usb_submit_urb() failed.
Ring debugging shows that the ring looks correct, however.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-30 03:44:32 +08:00
|
|
|
usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb->dev->bus), urb);
|
|
|
|
return ret;
|
2010-07-23 06:23:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check transfer ring to guarantee there is enough room for the urb.
|
|
|
|
* Update ISO URB start_frame and interval.
|
|
|
|
* Update interval as xhci_queue_intr_tx does. Just use xhci frame_index to
|
|
|
|
* update the urb->start_frame by now.
|
|
|
|
* Always assume URB_ISO_ASAP set, and NEVER use urb->start_frame as input.
|
|
|
|
*/
|
|
|
|
int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci, gfp_t mem_flags,
|
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index)
|
|
|
|
{
|
|
|
|
struct xhci_virt_device *xdev;
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
int start_frame;
|
|
|
|
int xhci_interval;
|
|
|
|
int ep_interval;
|
|
|
|
int num_tds, num_trbs, i;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
xdev = xhci->devs[slot_id];
|
|
|
|
ep_ring = xdev->eps[ep_index].ring;
|
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, xdev->out_ctx, ep_index);
|
|
|
|
|
|
|
|
num_trbs = 0;
|
|
|
|
num_tds = urb->number_of_packets;
|
|
|
|
for (i = 0; i < num_tds; i++)
|
|
|
|
num_trbs += count_isoc_trbs_needed(xhci, urb, i);
|
|
|
|
|
|
|
|
/* Check the ring to guarantee there is enough room for the whole urb.
|
|
|
|
* Do not insert any td of the urb to the ring if the check failed.
|
|
|
|
*/
|
2011-03-29 10:40:46 +08:00
|
|
|
ret = prepare_ring(xhci, ep_ring, le32_to_cpu(ep_ctx->ep_info) & EP_STATE_MASK,
|
2012-03-05 17:49:32 +08:00
|
|
|
num_trbs, mem_flags);
|
2010-07-23 06:23:39 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
start_frame = xhci_readl(xhci, &xhci->run_regs->microframe_index);
|
|
|
|
start_frame &= 0x3fff;
|
|
|
|
|
|
|
|
urb->start_frame = start_frame;
|
|
|
|
if (urb->dev->speed == USB_SPEED_LOW ||
|
|
|
|
urb->dev->speed == USB_SPEED_FULL)
|
|
|
|
urb->start_frame >>= 3;
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
xhci_interval = EP_INTERVAL_TO_UFRAMES(le32_to_cpu(ep_ctx->ep_info));
|
2010-07-23 06:23:39 +08:00
|
|
|
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) {
|
2010-12-20 17:14:20 +08:00
|
|
|
if (printk_ratelimit())
|
2010-07-23 06:23:39 +08:00
|
|
|
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;
|
|
|
|
}
|
2012-03-05 17:49:34 +08:00
|
|
|
ep_ring->num_trbs_free_temp = ep_ring->num_trbs_free;
|
|
|
|
|
2012-03-28 15:30:26 +08:00
|
|
|
return xhci_queue_isoc_tx(xhci, mem_flags, urb, slot_id, ep_index);
|
2010-07-23 06:23:39 +08:00
|
|
|
}
|
|
|
|
|
2009-04-28 10:58:01 +08:00
|
|
|
/**** 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;
|
2010-07-09 23:08:38 +08:00
|
|
|
int ret;
|
|
|
|
|
2009-09-05 01:53:13 +08:00
|
|
|
if (!command_must_succeed)
|
|
|
|
reserved_trbs++;
|
|
|
|
|
2010-07-09 23:08:38 +08:00
|
|
|
ret = prepare_ring(xhci, xhci->cmd_ring, EP_STATE_RUNNING,
|
2012-03-05 17:49:32 +08:00
|
|
|
reserved_trbs, GFP_ATOMIC);
|
2010-07-09 23:08:38 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
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");
|
2010-07-09 23:08:38 +08:00
|
|
|
return ret;
|
2009-04-28 10:53:56 +08:00
|
|
|
}
|
2012-03-05 17:49:32 +08:00
|
|
|
queue_trb(xhci, xhci->cmd_ring, false, field1, field2, field3,
|
|
|
|
field4 | xhci->cmd_ring->cycle_state);
|
2009-04-28 10:53:56 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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),
|
2009-12-10 07:59:13 +08:00
|
|
|
false);
|
|
|
|
}
|
|
|
|
|
2010-05-25 04:25:28 +08:00
|
|
|
int xhci_queue_vendor_command(struct xhci_hcd *xhci,
|
|
|
|
u32 field1, u32 field2, u32 field3, u32 field4)
|
|
|
|
{
|
|
|
|
return queue_command(xhci, field1, field2, field3, field4, false);
|
|
|
|
}
|
|
|
|
|
2009-12-10 07:59:13 +08:00
|
|
|
/* Queue a reset device command TRB */
|
|
|
|
int xhci_queue_reset_device(struct xhci_hcd *xhci, u32 slot_id)
|
|
|
|
{
|
|
|
|
return queue_command(xhci, 0, 0, 0,
|
|
|
|
TRB_TYPE(TRB_RESET_DEV) | SLOT_ID_FOR_TRB(slot_id),
|
2009-09-05 01:53:13 +08:00
|
|
|
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,
|
2012-05-08 06:34:26 +08:00
|
|
|
u32 slot_id, bool command_must_succeed)
|
2009-08-08 05:04:43 +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_EVAL_CONTEXT) | SLOT_ID_FOR_TRB(slot_id),
|
2012-05-08 06:34:26 +08:00
|
|
|
command_must_succeed);
|
2009-08-08 05:04:43 +08:00
|
|
|
}
|
|
|
|
|
2010-10-14 22:22:57 +08:00
|
|
|
/*
|
|
|
|
* Suspend is set to indicate "Stop Endpoint Command" is being issued to stop
|
|
|
|
* activity on an endpoint that is about to be suspended.
|
|
|
|
*/
|
2009-04-30 10:05:20 +08:00
|
|
|
int xhci_queue_stop_endpoint(struct xhci_hcd *xhci, int slot_id,
|
2010-10-14 22:22:57 +08:00
|
|
|
unsigned int ep_index, int suspend)
|
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 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);
|
2010-10-14 22:22:57 +08:00
|
|
|
u32 trb_suspend = SUSPEND_PORT_FOR_TRB(suspend);
|
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 queue_command(xhci, 0, 0, 0,
|
2010-10-14 22:22:57 +08:00
|
|
|
trb_slot_id | trb_ep_index | type | trb_suspend, 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,
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int ep_index, unsigned int stream_id,
|
|
|
|
struct xhci_segment *deq_seg,
|
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 *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);
|
2010-04-03 06:34:43 +08:00
|
|
|
u32 trb_stream_id = STREAM_ID_FOR_TRB(stream_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
|
|
|
u32 type = TRB_TYPE(TRB_SET_DEQ);
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 07:46:42 +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
|
|
|
|
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;
|
|
|
|
}
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 07:46:42 +08:00
|
|
|
ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
if ((ep->ep_state & SET_DEQ_PENDING)) {
|
|
|
|
xhci_warn(xhci, "WARN Cannot submit Set TR Deq Ptr\n");
|
|
|
|
xhci_warn(xhci, "A Set TR Deq Ptr command is pending.\n");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
ep->queued_deq_seg = deq_seg;
|
|
|
|
ep->queued_deq_ptr = deq_ptr;
|
2009-07-28 03:03:31 +08:00
|
|
|
return queue_command(xhci, lower_32_bits(addr) | cycle_state,
|
2010-04-03 06:34:43 +08:00
|
|
|
upper_32_bits(addr), trb_stream_id,
|
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
|
|
|
}
|