2009-04-28 10:52:28 +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.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/usb.h>
|
2009-04-28 10:52:34 +08:00
|
|
|
|
#include <linux/pci.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-30 10:06:56 +08:00
|
|
|
|
#include <linux/dmapool.h>
|
2013-07-26 20:34:43 +08:00
|
|
|
|
#include <linux/dma-mapping.h>
|
2009-04-28 10:52:28 +08:00
|
|
|
|
|
|
|
|
|
#include "xhci.h"
|
2013-07-31 12:35:27 +08:00
|
|
|
|
#include "xhci-trace.h"
|
2009-04-28 10:52:28 +08:00
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
|
/*
|
|
|
|
|
* Allocates a generic ring segment from the ring pool, sets the dma address,
|
|
|
|
|
* initializes the segment to zero, and sets the private next pointer to NULL.
|
|
|
|
|
*
|
|
|
|
|
* Section 4.11.1.1:
|
|
|
|
|
* "All components of all Command and Transfer TRBs shall be initialized to '0'"
|
|
|
|
|
*/
|
2012-03-05 17:49:36 +08:00
|
|
|
|
static struct xhci_segment *xhci_segment_alloc(struct xhci_hcd *xhci,
|
|
|
|
|
unsigned int cycle_state, gfp_t flags)
|
2009-04-28 10:52:34 +08:00
|
|
|
|
{
|
|
|
|
|
struct xhci_segment *seg;
|
|
|
|
|
dma_addr_t dma;
|
2012-03-05 17:49:36 +08:00
|
|
|
|
int i;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
|
|
seg = kzalloc(sizeof *seg, flags);
|
|
|
|
|
if (!seg)
|
2010-04-19 23:53:50 +08:00
|
|
|
|
return NULL;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
|
|
seg->trbs = dma_pool_alloc(xhci->segment_pool, flags, &dma);
|
|
|
|
|
if (!seg->trbs) {
|
|
|
|
|
kfree(seg);
|
2010-04-19 23:53:50 +08:00
|
|
|
|
return NULL;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
}
|
|
|
|
|
|
2013-03-29 02:48:35 +08:00
|
|
|
|
memset(seg->trbs, 0, TRB_SEGMENT_SIZE);
|
2012-03-05 17:49:36 +08:00
|
|
|
|
/* If the cycle state is 0, set the cycle bit to 1 for all the TRBs */
|
|
|
|
|
if (cycle_state == 0) {
|
|
|
|
|
for (i = 0; i < TRBS_PER_SEGMENT; i++)
|
2013-09-10 02:03:09 +08:00
|
|
|
|
seg->trbs[i].link.control |= cpu_to_le32(TRB_CYCLE);
|
2012-03-05 17:49:36 +08:00
|
|
|
|
}
|
2009-04-28 10:52:34 +08:00
|
|
|
|
seg->dma = dma;
|
|
|
|
|
seg->next = NULL;
|
|
|
|
|
|
|
|
|
|
return seg;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void xhci_segment_free(struct xhci_hcd *xhci, struct xhci_segment *seg)
|
|
|
|
|
{
|
|
|
|
|
if (seg->trbs) {
|
|
|
|
|
dma_pool_free(xhci->segment_pool, seg->trbs, seg->dma);
|
|
|
|
|
seg->trbs = NULL;
|
|
|
|
|
}
|
|
|
|
|
kfree(seg);
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-05 17:49:35 +08:00
|
|
|
|
static void xhci_free_segments_for_ring(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_segment *first)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_segment *seg;
|
|
|
|
|
|
|
|
|
|
seg = first->next;
|
|
|
|
|
while (seg != first) {
|
|
|
|
|
struct xhci_segment *next = seg->next;
|
|
|
|
|
xhci_segment_free(xhci, seg);
|
|
|
|
|
seg = next;
|
|
|
|
|
}
|
|
|
|
|
xhci_segment_free(xhci, first);
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
|
/*
|
|
|
|
|
* Make the prev segment point to the next segment.
|
|
|
|
|
*
|
|
|
|
|
* Change the last TRB in the prev segment to be a Link TRB which points to the
|
|
|
|
|
* DMA address of the next segment. The caller needs to set any Link TRB
|
|
|
|
|
* related flags, such as End TRB, Toggle Cycle, and no snoop.
|
|
|
|
|
*/
|
|
|
|
|
static void xhci_link_segments(struct xhci_hcd *xhci, struct xhci_segment *prev,
|
2012-03-05 17:49:32 +08:00
|
|
|
|
struct xhci_segment *next, enum xhci_ring_type type)
|
2009-04-28 10:52:34 +08:00
|
|
|
|
{
|
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
|
|
if (!prev || !next)
|
|
|
|
|
return;
|
|
|
|
|
prev->next = next;
|
2012-03-05 17:49:32 +08:00
|
|
|
|
if (type != TYPE_EVENT) {
|
2011-06-01 08:22:55 +08:00
|
|
|
|
prev->trbs[TRBS_PER_SEGMENT-1].link.segment_ptr =
|
|
|
|
|
cpu_to_le64(next->dma);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
|
|
/* Set the last TRB in the segment to have a TRB type ID of Link TRB */
|
2011-03-29 10:40:46 +08:00
|
|
|
|
val = le32_to_cpu(prev->trbs[TRBS_PER_SEGMENT-1].link.control);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
val &= ~TRB_TYPE_BITMASK;
|
|
|
|
|
val |= TRB_TYPE(TRB_LINK);
|
2009-08-08 05:04:36 +08:00
|
|
|
|
/* Always set the chain bit with 0.95 hardware */
|
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
|
|
|
|
/* Set chain bit for isoc rings on AMD 0.96 host */
|
|
|
|
|
if (xhci_link_trb_quirk(xhci) ||
|
2012-03-05 17:49:32 +08:00
|
|
|
|
(type == TYPE_ISOC &&
|
|
|
|
|
(xhci->quirks & XHCI_AMD_0x96_HOST)))
|
2009-08-08 05:04:36 +08:00
|
|
|
|
val |= TRB_CHAIN;
|
2011-03-29 10:40:46 +08:00
|
|
|
|
prev->trbs[TRBS_PER_SEGMENT-1].link.control = cpu_to_le32(val);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-05 17:49:37 +08:00
|
|
|
|
/*
|
|
|
|
|
* Link the ring to the new segments.
|
|
|
|
|
* Set Toggle Cycle for the new ring if needed.
|
|
|
|
|
*/
|
|
|
|
|
static void xhci_link_rings(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
|
|
|
|
struct xhci_segment *first, struct xhci_segment *last,
|
|
|
|
|
unsigned int num_segs)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_segment *next;
|
|
|
|
|
|
|
|
|
|
if (!ring || !first || !last)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
next = ring->enq_seg->next;
|
|
|
|
|
xhci_link_segments(xhci, ring->enq_seg, first, ring->type);
|
|
|
|
|
xhci_link_segments(xhci, last, next, ring->type);
|
|
|
|
|
ring->num_segs += num_segs;
|
|
|
|
|
ring->num_trbs_free += (TRBS_PER_SEGMENT - 1) * num_segs;
|
|
|
|
|
|
|
|
|
|
if (ring->type != TYPE_EVENT && ring->enq_seg == ring->last_seg) {
|
|
|
|
|
ring->last_seg->trbs[TRBS_PER_SEGMENT-1].link.control
|
|
|
|
|
&= ~cpu_to_le32(LINK_TOGGLE);
|
|
|
|
|
last->trbs[TRBS_PER_SEGMENT-1].link.control
|
|
|
|
|
|= cpu_to_le32(LINK_TOGGLE);
|
|
|
|
|
ring->last_seg = last;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-10-04 06:29:44 +08:00
|
|
|
|
/*
|
|
|
|
|
* We need a radix tree for mapping physical addresses of TRBs to which stream
|
|
|
|
|
* ID they belong to. We need to do this because the host controller won't tell
|
|
|
|
|
* us which stream ring the TRB came from. We could store the stream ID in an
|
|
|
|
|
* event data TRB, but that doesn't help us for the cancellation case, since the
|
|
|
|
|
* endpoint may stop before it reaches that event data TRB.
|
|
|
|
|
*
|
|
|
|
|
* The radix tree maps the upper portion of the TRB DMA address to a ring
|
|
|
|
|
* segment that has the same upper portion of DMA addresses. For example, say I
|
2013-11-05 22:50:03 +08:00
|
|
|
|
* have segments of size 1KB, that are always 1KB aligned. A segment may
|
2013-10-04 06:29:44 +08:00
|
|
|
|
* start at 0x10c91000 and end at 0x10c913f0. If I use the upper 10 bits, the
|
|
|
|
|
* key to the stream ID is 0x43244. I can use the DMA address of the TRB to
|
|
|
|
|
* pass the radix tree a key to get the right stream ID:
|
|
|
|
|
*
|
|
|
|
|
* 0x10c90fff >> 10 = 0x43243
|
|
|
|
|
* 0x10c912c0 >> 10 = 0x43244
|
|
|
|
|
* 0x10c91400 >> 10 = 0x43245
|
|
|
|
|
*
|
|
|
|
|
* Obviously, only those TRBs with DMA addresses that are within the segment
|
|
|
|
|
* will make the radix tree return the stream ID for that ring.
|
|
|
|
|
*
|
|
|
|
|
* Caveats for the radix tree:
|
|
|
|
|
*
|
|
|
|
|
* The radix tree uses an unsigned long as a key pair. On 32-bit systems, an
|
|
|
|
|
* unsigned long will be 32-bits; on a 64-bit system an unsigned long will be
|
|
|
|
|
* 64-bits. Since we only request 32-bit DMA addresses, we can use that as the
|
|
|
|
|
* key on 32-bit or 64-bit systems (it would also be fine if we asked for 64-bit
|
|
|
|
|
* PCI DMA addresses on a 64-bit system). There might be a problem on 32-bit
|
|
|
|
|
* extended systems (where the DMA address can be bigger than 32-bits),
|
|
|
|
|
* if we allow the PCI dma mask to be bigger than 32-bits. So don't do that.
|
|
|
|
|
*/
|
2013-10-18 03:44:58 +08:00
|
|
|
|
static int xhci_insert_segment_mapping(struct radix_tree_root *trb_address_map,
|
|
|
|
|
struct xhci_ring *ring,
|
|
|
|
|
struct xhci_segment *seg,
|
|
|
|
|
gfp_t mem_flags)
|
2013-10-04 06:29:44 +08:00
|
|
|
|
{
|
|
|
|
|
unsigned long key;
|
|
|
|
|
int ret;
|
|
|
|
|
|
2013-10-18 03:44:58 +08:00
|
|
|
|
key = (unsigned long)(seg->dma >> TRB_SEGMENT_SHIFT);
|
|
|
|
|
/* Skip any segments that were already added. */
|
|
|
|
|
if (radix_tree_lookup(trb_address_map, key))
|
2013-10-04 06:29:44 +08:00
|
|
|
|
return 0;
|
|
|
|
|
|
2013-10-18 03:44:58 +08:00
|
|
|
|
ret = radix_tree_maybe_preload(mem_flags);
|
|
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
|
|
|
|
ret = radix_tree_insert(trb_address_map,
|
|
|
|
|
key, ring);
|
|
|
|
|
radix_tree_preload_end();
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
2013-10-04 06:29:44 +08:00
|
|
|
|
|
2013-10-18 03:44:58 +08:00
|
|
|
|
static void xhci_remove_segment_mapping(struct radix_tree_root *trb_address_map,
|
|
|
|
|
struct xhci_segment *seg)
|
|
|
|
|
{
|
|
|
|
|
unsigned long key;
|
|
|
|
|
|
|
|
|
|
key = (unsigned long)(seg->dma >> TRB_SEGMENT_SHIFT);
|
|
|
|
|
if (radix_tree_lookup(trb_address_map, key))
|
|
|
|
|
radix_tree_delete(trb_address_map, key);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int xhci_update_stream_segment_mapping(
|
|
|
|
|
struct radix_tree_root *trb_address_map,
|
|
|
|
|
struct xhci_ring *ring,
|
|
|
|
|
struct xhci_segment *first_seg,
|
|
|
|
|
struct xhci_segment *last_seg,
|
|
|
|
|
gfp_t mem_flags)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_segment *seg;
|
|
|
|
|
struct xhci_segment *failed_seg;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
if (WARN_ON_ONCE(trb_address_map == NULL))
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
seg = first_seg;
|
|
|
|
|
do {
|
|
|
|
|
ret = xhci_insert_segment_mapping(trb_address_map,
|
|
|
|
|
ring, seg, mem_flags);
|
2013-10-04 06:29:44 +08:00
|
|
|
|
if (ret)
|
2013-10-18 03:44:58 +08:00
|
|
|
|
goto remove_streams;
|
|
|
|
|
if (seg == last_seg)
|
|
|
|
|
return 0;
|
2013-10-04 06:29:44 +08:00
|
|
|
|
seg = seg->next;
|
2013-10-18 03:44:58 +08:00
|
|
|
|
} while (seg != first_seg);
|
2013-10-04 06:29:44 +08:00
|
|
|
|
|
|
|
|
|
return 0;
|
2013-10-18 03:44:58 +08:00
|
|
|
|
|
|
|
|
|
remove_streams:
|
|
|
|
|
failed_seg = seg;
|
|
|
|
|
seg = first_seg;
|
|
|
|
|
do {
|
|
|
|
|
xhci_remove_segment_mapping(trb_address_map, seg);
|
|
|
|
|
if (seg == failed_seg)
|
|
|
|
|
return ret;
|
|
|
|
|
seg = seg->next;
|
|
|
|
|
} while (seg != first_seg);
|
|
|
|
|
|
|
|
|
|
return ret;
|
2013-10-04 06:29:44 +08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void xhci_remove_stream_mapping(struct xhci_ring *ring)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_segment *seg;
|
|
|
|
|
|
|
|
|
|
if (WARN_ON_ONCE(ring->trb_address_map == NULL))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
seg = ring->first_seg;
|
|
|
|
|
do {
|
2013-10-18 03:44:58 +08:00
|
|
|
|
xhci_remove_segment_mapping(ring->trb_address_map, seg);
|
2013-10-04 06:29:44 +08:00
|
|
|
|
seg = seg->next;
|
|
|
|
|
} while (seg != ring->first_seg);
|
|
|
|
|
}
|
|
|
|
|
|
2013-10-18 03:44:58 +08:00
|
|
|
|
static int xhci_update_stream_mapping(struct xhci_ring *ring, gfp_t mem_flags)
|
|
|
|
|
{
|
|
|
|
|
return xhci_update_stream_segment_mapping(ring->trb_address_map, ring,
|
|
|
|
|
ring->first_seg, ring->last_seg, mem_flags);
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
|
/* XXX: Do we need the hcd structure in all these functions? */
|
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
|
|
|
|
void xhci_ring_free(struct xhci_hcd *xhci, struct xhci_ring *ring)
|
2009-04-28 10:52:34 +08:00
|
|
|
|
{
|
2011-09-20 07:53:12 +08:00
|
|
|
|
if (!ring)
|
2009-04-28 10:52:34 +08:00
|
|
|
|
return;
|
2012-03-05 17:49:35 +08:00
|
|
|
|
|
2013-10-04 06:29:44 +08:00
|
|
|
|
if (ring->first_seg) {
|
|
|
|
|
if (ring->type == TYPE_STREAM)
|
|
|
|
|
xhci_remove_stream_mapping(ring);
|
2012-03-05 17:49:35 +08:00
|
|
|
|
xhci_free_segments_for_ring(xhci, ring->first_seg);
|
2013-10-04 06:29:44 +08:00
|
|
|
|
}
|
2012-03-05 17:49:35 +08:00
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
|
kfree(ring);
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-05 17:49:36 +08:00
|
|
|
|
static void xhci_initialize_ring_info(struct xhci_ring *ring,
|
|
|
|
|
unsigned int cycle_state)
|
2009-12-04 01:44:29 +08:00
|
|
|
|
{
|
|
|
|
|
/* The ring is empty, so the enqueue pointer == dequeue pointer */
|
|
|
|
|
ring->enqueue = ring->first_seg->trbs;
|
|
|
|
|
ring->enq_seg = ring->first_seg;
|
|
|
|
|
ring->dequeue = ring->enqueue;
|
|
|
|
|
ring->deq_seg = ring->first_seg;
|
|
|
|
|
/* The ring is initialized to 0. The producer must write 1 to the cycle
|
|
|
|
|
* bit to handover ownership of the TRB, so PCS = 1. The consumer must
|
|
|
|
|
* compare CCS to the cycle bit to check ownership, so CCS = 1.
|
2012-03-05 17:49:36 +08:00
|
|
|
|
*
|
|
|
|
|
* New rings are initialized with cycle state equal to 1; if we are
|
|
|
|
|
* handling ring expansion, set the cycle state equal to the old ring.
|
2009-12-04 01:44:29 +08:00
|
|
|
|
*/
|
2012-03-05 17:49:36 +08:00
|
|
|
|
ring->cycle_state = cycle_state;
|
2009-12-04 01:44:29 +08:00
|
|
|
|
/* Not necessary for new rings, but needed for re-initialized rings */
|
|
|
|
|
ring->enq_updates = 0;
|
|
|
|
|
ring->deq_updates = 0;
|
2012-03-05 17:49:34 +08:00
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Each segment has a link TRB, and leave an extra TRB for SW
|
|
|
|
|
* accounting purpose
|
|
|
|
|
*/
|
|
|
|
|
ring->num_trbs_free = ring->num_segs * (TRBS_PER_SEGMENT - 1) - 1;
|
2009-12-04 01:44:29 +08:00
|
|
|
|
}
|
|
|
|
|
|
2012-03-05 17:49:35 +08:00
|
|
|
|
/* Allocate segments and link them for a ring */
|
|
|
|
|
static int xhci_alloc_segments_for_ring(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_segment **first, struct xhci_segment **last,
|
2012-03-05 17:49:36 +08:00
|
|
|
|
unsigned int num_segs, unsigned int cycle_state,
|
|
|
|
|
enum xhci_ring_type type, gfp_t flags)
|
2012-03-05 17:49:35 +08:00
|
|
|
|
{
|
|
|
|
|
struct xhci_segment *prev;
|
|
|
|
|
|
2012-03-05 17:49:36 +08:00
|
|
|
|
prev = xhci_segment_alloc(xhci, cycle_state, flags);
|
2012-03-05 17:49:35 +08:00
|
|
|
|
if (!prev)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
num_segs--;
|
|
|
|
|
|
|
|
|
|
*first = prev;
|
|
|
|
|
while (num_segs > 0) {
|
|
|
|
|
struct xhci_segment *next;
|
|
|
|
|
|
2012-03-05 17:49:36 +08:00
|
|
|
|
next = xhci_segment_alloc(xhci, cycle_state, flags);
|
2012-03-05 17:49:35 +08:00
|
|
|
|
if (!next) {
|
2012-11-02 03:47:59 +08:00
|
|
|
|
prev = *first;
|
|
|
|
|
while (prev) {
|
|
|
|
|
next = prev->next;
|
|
|
|
|
xhci_segment_free(xhci, prev);
|
|
|
|
|
prev = next;
|
|
|
|
|
}
|
2012-03-05 17:49:35 +08:00
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
xhci_link_segments(xhci, prev, next, type);
|
|
|
|
|
|
|
|
|
|
prev = next;
|
|
|
|
|
num_segs--;
|
|
|
|
|
}
|
|
|
|
|
xhci_link_segments(xhci, prev, *first, type);
|
|
|
|
|
*last = prev;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
|
/**
|
|
|
|
|
* Create a new ring with zero or more segments.
|
|
|
|
|
*
|
|
|
|
|
* Link each segment together into a ring.
|
|
|
|
|
* Set the end flag and the cycle toggle bit on the last segment.
|
|
|
|
|
* See section 4.9.1 and figures 15 and 16.
|
|
|
|
|
*/
|
|
|
|
|
static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
|
2012-03-05 17:49:36 +08:00
|
|
|
|
unsigned int num_segs, unsigned int cycle_state,
|
|
|
|
|
enum xhci_ring_type type, gfp_t flags)
|
2009-04-28 10:52:34 +08:00
|
|
|
|
{
|
|
|
|
|
struct xhci_ring *ring;
|
2012-03-05 17:49:35 +08:00
|
|
|
|
int ret;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
|
|
ring = kzalloc(sizeof *(ring), flags);
|
|
|
|
|
if (!ring)
|
2010-04-19 23:53:50 +08:00
|
|
|
|
return NULL;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
2012-03-05 17:49:33 +08:00
|
|
|
|
ring->num_segs = num_segs;
|
2009-04-28 10:58:01 +08:00
|
|
|
|
INIT_LIST_HEAD(&ring->td_list);
|
2012-03-05 17:49:32 +08:00
|
|
|
|
ring->type = type;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
if (num_segs == 0)
|
|
|
|
|
return ring;
|
|
|
|
|
|
2012-03-05 17:49:35 +08:00
|
|
|
|
ret = xhci_alloc_segments_for_ring(xhci, &ring->first_seg,
|
2012-03-05 17:49:36 +08:00
|
|
|
|
&ring->last_seg, num_segs, cycle_state, type, flags);
|
2012-03-05 17:49:35 +08:00
|
|
|
|
if (ret)
|
2009-04-28 10:52:34 +08:00
|
|
|
|
goto fail;
|
|
|
|
|
|
2012-03-05 17:49:32 +08:00
|
|
|
|
/* Only event ring does not use link TRB */
|
|
|
|
|
if (type != TYPE_EVENT) {
|
2009-04-28 10:52:34 +08:00
|
|
|
|
/* See section 4.9.2.1 and 6.4.4.1 */
|
2012-03-05 17:49:35 +08:00
|
|
|
|
ring->last_seg->trbs[TRBS_PER_SEGMENT - 1].link.control |=
|
2011-06-01 08:22:55 +08:00
|
|
|
|
cpu_to_le32(LINK_TOGGLE);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
}
|
2012-03-05 17:49:36 +08:00
|
|
|
|
xhci_initialize_ring_info(ring, cycle_state);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
return ring;
|
|
|
|
|
|
|
|
|
|
fail:
|
2012-11-02 03:47:59 +08:00
|
|
|
|
kfree(ring);
|
2010-04-19 23:53:50 +08:00
|
|
|
|
return NULL;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
}
|
|
|
|
|
|
2009-12-10 07:59:01 +08:00
|
|
|
|
void xhci_free_or_cache_endpoint_ring(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
|
unsigned int ep_index)
|
|
|
|
|
{
|
|
|
|
|
int rings_cached;
|
|
|
|
|
|
|
|
|
|
rings_cached = virt_dev->num_rings_cached;
|
|
|
|
|
if (rings_cached < XHCI_MAX_RINGS_CACHED) {
|
|
|
|
|
virt_dev->ring_cache[rings_cached] =
|
|
|
|
|
virt_dev->eps[ep_index].ring;
|
xhci: Fix memory leak in ring cache deallocation.
When an endpoint ring is freed, it is either cached in a per-device ring
cache, or simply freed if the ring cache is full. If the ring was added
to the cache, then virt_dev->num_rings_cached is incremented. The cache
is designed to hold up to 31 endpoint rings, in array indexes 0 to 30.
When the device is freed (when the slot was disabled),
xhci_free_virt_device() is called, it would free the cached rings in
array indexes 0 to virt_dev->num_rings_cached.
Unfortunately, the original code in xhci_free_or_cache_endpoint_ring()
would put the first entry into the ring cache in array index 1, instead of
array index 0. This was caused by the second assignment to rings_cached:
rings_cached = virt_dev->num_rings_cached;
if (rings_cached < XHCI_MAX_RINGS_CACHED) {
virt_dev->num_rings_cached++;
rings_cached = virt_dev->num_rings_cached;
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;
This meant that when the device was freed, cached rings with indexes 0 to
N would be freed, and the last cached ring in index N+1 would not be
freed. When the driver was unloaded, this caused interesting messages
like:
xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy
This should be queued to stable kernels back to 2.6.33.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
2011-05-17 04:09:08 +08:00
|
|
|
|
virt_dev->num_rings_cached++;
|
2009-12-10 07:59:01 +08:00
|
|
|
|
xhci_dbg(xhci, "Cached old ring, "
|
|
|
|
|
"%d ring%s cached\n",
|
xhci: Fix memory leak in ring cache deallocation.
When an endpoint ring is freed, it is either cached in a per-device ring
cache, or simply freed if the ring cache is full. If the ring was added
to the cache, then virt_dev->num_rings_cached is incremented. The cache
is designed to hold up to 31 endpoint rings, in array indexes 0 to 30.
When the device is freed (when the slot was disabled),
xhci_free_virt_device() is called, it would free the cached rings in
array indexes 0 to virt_dev->num_rings_cached.
Unfortunately, the original code in xhci_free_or_cache_endpoint_ring()
would put the first entry into the ring cache in array index 1, instead of
array index 0. This was caused by the second assignment to rings_cached:
rings_cached = virt_dev->num_rings_cached;
if (rings_cached < XHCI_MAX_RINGS_CACHED) {
virt_dev->num_rings_cached++;
rings_cached = virt_dev->num_rings_cached;
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;
This meant that when the device was freed, cached rings with indexes 0 to
N would be freed, and the last cached ring in index N+1 would not be
freed. When the driver was unloaded, this caused interesting messages
like:
xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy
This should be queued to stable kernels back to 2.6.33.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
2011-05-17 04:09:08 +08:00
|
|
|
|
virt_dev->num_rings_cached,
|
|
|
|
|
(virt_dev->num_rings_cached > 1) ? "s" : "");
|
2009-12-10 07:59:01 +08:00
|
|
|
|
} else {
|
|
|
|
|
xhci_ring_free(xhci, virt_dev->eps[ep_index].ring);
|
|
|
|
|
xhci_dbg(xhci, "Ring cache full (%d rings), "
|
|
|
|
|
"freeing ring\n",
|
|
|
|
|
virt_dev->num_rings_cached);
|
|
|
|
|
}
|
|
|
|
|
virt_dev->eps[ep_index].ring = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-04 01:44:29 +08:00
|
|
|
|
/* Zero an endpoint ring (except for link TRBs) and move the enqueue and dequeue
|
|
|
|
|
* pointers to the beginning of the ring.
|
|
|
|
|
*/
|
|
|
|
|
static void xhci_reinit_cached_ring(struct xhci_hcd *xhci,
|
2012-03-05 17:49:36 +08:00
|
|
|
|
struct xhci_ring *ring, unsigned int cycle_state,
|
|
|
|
|
enum xhci_ring_type type)
|
2009-12-04 01:44:29 +08:00
|
|
|
|
{
|
|
|
|
|
struct xhci_segment *seg = ring->first_seg;
|
2012-03-05 17:49:36 +08:00
|
|
|
|
int i;
|
|
|
|
|
|
2009-12-04 01:44:29 +08:00
|
|
|
|
do {
|
|
|
|
|
memset(seg->trbs, 0,
|
|
|
|
|
sizeof(union xhci_trb)*TRBS_PER_SEGMENT);
|
2012-03-05 17:49:36 +08:00
|
|
|
|
if (cycle_state == 0) {
|
|
|
|
|
for (i = 0; i < TRBS_PER_SEGMENT; i++)
|
2013-09-10 02:03:09 +08:00
|
|
|
|
seg->trbs[i].link.control |=
|
|
|
|
|
cpu_to_le32(TRB_CYCLE);
|
2012-03-05 17:49:36 +08:00
|
|
|
|
}
|
2009-12-04 01:44:29 +08:00
|
|
|
|
/* All endpoint rings have link TRBs */
|
2012-03-05 17:49:32 +08:00
|
|
|
|
xhci_link_segments(xhci, seg, seg->next, type);
|
2009-12-04 01:44:29 +08:00
|
|
|
|
seg = seg->next;
|
|
|
|
|
} while (seg != ring->first_seg);
|
2012-03-05 17:49:32 +08:00
|
|
|
|
ring->type = type;
|
2012-03-05 17:49:36 +08:00
|
|
|
|
xhci_initialize_ring_info(ring, cycle_state);
|
2009-12-04 01:44:29 +08:00
|
|
|
|
/* td list should be empty since all URBs have been cancelled,
|
|
|
|
|
* but just in case...
|
|
|
|
|
*/
|
|
|
|
|
INIT_LIST_HEAD(&ring->td_list);
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-05 17:49:37 +08:00
|
|
|
|
/*
|
|
|
|
|
* Expand an existing ring.
|
|
|
|
|
* Look for a cached ring or allocate a new ring which has same segment numbers
|
|
|
|
|
* and link the two rings.
|
|
|
|
|
*/
|
|
|
|
|
int xhci_ring_expansion(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
|
|
|
|
unsigned int num_trbs, gfp_t flags)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_segment *first;
|
|
|
|
|
struct xhci_segment *last;
|
|
|
|
|
unsigned int num_segs;
|
|
|
|
|
unsigned int num_segs_needed;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
num_segs_needed = (num_trbs + (TRBS_PER_SEGMENT - 1) - 1) /
|
|
|
|
|
(TRBS_PER_SEGMENT - 1);
|
|
|
|
|
|
|
|
|
|
/* Allocate number of segments we needed, or double the ring size */
|
|
|
|
|
num_segs = ring->num_segs > num_segs_needed ?
|
|
|
|
|
ring->num_segs : num_segs_needed;
|
|
|
|
|
|
|
|
|
|
ret = xhci_alloc_segments_for_ring(xhci, &first, &last,
|
|
|
|
|
num_segs, ring->cycle_state, ring->type, flags);
|
|
|
|
|
if (ret)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
2013-10-18 03:44:58 +08:00
|
|
|
|
if (ring->type == TYPE_STREAM)
|
|
|
|
|
ret = xhci_update_stream_segment_mapping(ring->trb_address_map,
|
|
|
|
|
ring, first, last, flags);
|
|
|
|
|
if (ret) {
|
|
|
|
|
struct xhci_segment *next;
|
|
|
|
|
do {
|
|
|
|
|
next = first->next;
|
|
|
|
|
xhci_segment_free(xhci, first);
|
|
|
|
|
if (first == last)
|
|
|
|
|
break;
|
|
|
|
|
first = next;
|
|
|
|
|
} while (true);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-05 17:49:37 +08:00
|
|
|
|
xhci_link_rings(xhci, ring, first, last, num_segs);
|
2013-08-14 11:33:56 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_ring_expansion,
|
|
|
|
|
"ring expansion succeed, now has %d segments",
|
2012-03-05 17:49:37 +08:00
|
|
|
|
ring->num_segs);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-28 03:05:15 +08:00
|
|
|
|
#define CTX_SIZE(_hcc) (HCC_64BYTE_CONTEXT(_hcc) ? 64 : 32)
|
|
|
|
|
|
2010-04-19 23:53:50 +08:00
|
|
|
|
static struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd *xhci,
|
2009-07-28 03:05:15 +08:00
|
|
|
|
int type, gfp_t flags)
|
|
|
|
|
{
|
2013-04-24 06:49:47 +08:00
|
|
|
|
struct xhci_container_ctx *ctx;
|
|
|
|
|
|
|
|
|
|
if ((type != XHCI_CTX_TYPE_DEVICE) && (type != XHCI_CTX_TYPE_INPUT))
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
ctx = kzalloc(sizeof(*ctx), flags);
|
2009-07-28 03:05:15 +08:00
|
|
|
|
if (!ctx)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
ctx->type = type;
|
|
|
|
|
ctx->size = HCC_64BYTE_CONTEXT(xhci->hcc_params) ? 2048 : 1024;
|
|
|
|
|
if (type == XHCI_CTX_TYPE_INPUT)
|
|
|
|
|
ctx->size += CTX_SIZE(xhci->hcc_params);
|
|
|
|
|
|
|
|
|
|
ctx->bytes = dma_pool_alloc(xhci->device_pool, flags, &ctx->dma);
|
2013-06-18 00:56:33 +08:00
|
|
|
|
if (!ctx->bytes) {
|
|
|
|
|
kfree(ctx);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2009-07-28 03:05:15 +08:00
|
|
|
|
memset(ctx->bytes, 0, ctx->size);
|
|
|
|
|
return ctx;
|
|
|
|
|
}
|
|
|
|
|
|
2010-04-19 23:53:50 +08:00
|
|
|
|
static void xhci_free_container_ctx(struct xhci_hcd *xhci,
|
2009-07-28 03:05:15 +08:00
|
|
|
|
struct xhci_container_ctx *ctx)
|
|
|
|
|
{
|
2009-12-10 07:59:03 +08:00
|
|
|
|
if (!ctx)
|
|
|
|
|
return;
|
2009-07-28 03:05:15 +08:00
|
|
|
|
dma_pool_free(xhci->device_pool, ctx->bytes, ctx->dma);
|
|
|
|
|
kfree(ctx);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct xhci_input_control_ctx *xhci_get_input_control_ctx(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_container_ctx *ctx)
|
|
|
|
|
{
|
2013-04-24 08:11:14 +08:00
|
|
|
|
if (ctx->type != XHCI_CTX_TYPE_INPUT)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2009-07-28 03:05:15 +08:00
|
|
|
|
return (struct xhci_input_control_ctx *)ctx->bytes;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct xhci_slot_ctx *xhci_get_slot_ctx(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_container_ctx *ctx)
|
|
|
|
|
{
|
|
|
|
|
if (ctx->type == XHCI_CTX_TYPE_DEVICE)
|
|
|
|
|
return (struct xhci_slot_ctx *)ctx->bytes;
|
|
|
|
|
|
|
|
|
|
return (struct xhci_slot_ctx *)
|
|
|
|
|
(ctx->bytes + CTX_SIZE(xhci->hcc_params));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_container_ctx *ctx,
|
|
|
|
|
unsigned int ep_index)
|
|
|
|
|
{
|
|
|
|
|
/* increment ep index by offset of start of ep ctx array */
|
|
|
|
|
ep_index++;
|
|
|
|
|
if (ctx->type == XHCI_CTX_TYPE_INPUT)
|
|
|
|
|
ep_index++;
|
|
|
|
|
|
|
|
|
|
return (struct xhci_ep_ctx *)
|
|
|
|
|
(ctx->bytes + (ep_index * CTX_SIZE(xhci->hcc_params)));
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
/***************** Streams structures manipulation *************************/
|
|
|
|
|
|
2011-02-09 05:55:59 +08:00
|
|
|
|
static void xhci_free_stream_ctx(struct xhci_hcd *xhci,
|
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
|
|
|
|
unsigned int num_stream_ctxs,
|
|
|
|
|
struct xhci_stream_ctx *stream_ctx, dma_addr_t dma)
|
|
|
|
|
{
|
2013-11-15 09:18:08 +08:00
|
|
|
|
struct device *dev = xhci_to_hcd(xhci)->self.controller;
|
2013-10-04 06:29:46 +08:00
|
|
|
|
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
|
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
|
|
|
|
|
2013-10-04 06:29:46 +08:00
|
|
|
|
if (size > MEDIUM_STREAM_ARRAY_SIZE)
|
|
|
|
|
dma_free_coherent(dev, size,
|
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
|
|
|
|
stream_ctx, dma);
|
2013-10-04 06:29:46 +08:00
|
|
|
|
else if (size <= SMALL_STREAM_ARRAY_SIZE)
|
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
|
|
|
|
return dma_pool_free(xhci->small_streams_pool,
|
|
|
|
|
stream_ctx, dma);
|
|
|
|
|
else
|
|
|
|
|
return dma_pool_free(xhci->medium_streams_pool,
|
|
|
|
|
stream_ctx, dma);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The stream context array for each endpoint with bulk streams enabled can
|
|
|
|
|
* vary in size, based on:
|
|
|
|
|
* - how many streams the endpoint supports,
|
|
|
|
|
* - the maximum primary stream array size the host controller supports,
|
|
|
|
|
* - and how many streams the device driver asks for.
|
|
|
|
|
*
|
|
|
|
|
* The stream context array must be a power of 2, and can be as small as
|
|
|
|
|
* 64 bytes or as large as 1MB.
|
|
|
|
|
*/
|
2011-02-09 05:55:59 +08:00
|
|
|
|
static struct xhci_stream_ctx *xhci_alloc_stream_ctx(struct xhci_hcd *xhci,
|
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
|
|
|
|
unsigned int num_stream_ctxs, dma_addr_t *dma,
|
|
|
|
|
gfp_t mem_flags)
|
|
|
|
|
{
|
2013-11-15 09:18:08 +08:00
|
|
|
|
struct device *dev = xhci_to_hcd(xhci)->self.controller;
|
2013-10-04 06:29:46 +08:00
|
|
|
|
size_t size = sizeof(struct xhci_stream_ctx) * num_stream_ctxs;
|
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
|
|
|
|
|
2013-10-04 06:29:46 +08:00
|
|
|
|
if (size > MEDIUM_STREAM_ARRAY_SIZE)
|
|
|
|
|
return dma_alloc_coherent(dev, size,
|
2011-09-24 05:19:59 +08:00
|
|
|
|
dma, mem_flags);
|
2013-10-04 06:29:46 +08:00
|
|
|
|
else if (size <= SMALL_STREAM_ARRAY_SIZE)
|
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
|
|
|
|
return dma_pool_alloc(xhci->small_streams_pool,
|
|
|
|
|
mem_flags, dma);
|
|
|
|
|
else
|
|
|
|
|
return dma_pool_alloc(xhci->medium_streams_pool,
|
|
|
|
|
mem_flags, dma);
|
|
|
|
|
}
|
|
|
|
|
|
2010-04-03 06:34:43 +08:00
|
|
|
|
struct xhci_ring *xhci_dma_to_transfer_ring(
|
|
|
|
|
struct xhci_virt_ep *ep,
|
|
|
|
|
u64 address)
|
|
|
|
|
{
|
|
|
|
|
if (ep->ep_state & EP_HAS_STREAMS)
|
|
|
|
|
return radix_tree_lookup(&ep->stream_info->trb_address_map,
|
2013-03-29 02:48:35 +08:00
|
|
|
|
address >> TRB_SEGMENT_SHIFT);
|
2010-04-03 06:34:43 +08:00
|
|
|
|
return ep->ring;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct xhci_ring *xhci_stream_id_to_ring(
|
|
|
|
|
struct xhci_virt_device *dev,
|
|
|
|
|
unsigned int ep_index,
|
|
|
|
|
unsigned int stream_id)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_virt_ep *ep = &dev->eps[ep_index];
|
|
|
|
|
|
|
|
|
|
if (stream_id == 0)
|
|
|
|
|
return ep->ring;
|
|
|
|
|
if (!ep->stream_info)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
|
|
if (stream_id > ep->stream_info->num_streams)
|
|
|
|
|
return NULL;
|
|
|
|
|
return ep->stream_info->stream_rings[stream_id];
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
/*
|
|
|
|
|
* Change an endpoint's internal structure so it supports stream IDs. The
|
|
|
|
|
* number of requested streams includes stream 0, which cannot be used by device
|
|
|
|
|
* drivers.
|
|
|
|
|
*
|
|
|
|
|
* The number of stream contexts in the stream context array may be bigger than
|
|
|
|
|
* the number of streams the driver wants to use. This is because the number of
|
|
|
|
|
* stream context array entries must be a power of two.
|
|
|
|
|
*/
|
|
|
|
|
struct xhci_stream_info *xhci_alloc_stream_info(struct xhci_hcd *xhci,
|
|
|
|
|
unsigned int num_stream_ctxs,
|
|
|
|
|
unsigned int num_streams, gfp_t mem_flags)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_stream_info *stream_info;
|
|
|
|
|
u32 cur_stream;
|
|
|
|
|
struct xhci_ring *cur_ring;
|
|
|
|
|
u64 addr;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Allocating %u streams and %u "
|
|
|
|
|
"stream context array entries.\n",
|
|
|
|
|
num_streams, num_stream_ctxs);
|
|
|
|
|
if (xhci->cmd_ring_reserved_trbs == MAX_RSVD_CMD_TRBS) {
|
|
|
|
|
xhci_dbg(xhci, "Command ring has no reserved TRBs available\n");
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
xhci->cmd_ring_reserved_trbs++;
|
|
|
|
|
|
|
|
|
|
stream_info = kzalloc(sizeof(struct xhci_stream_info), mem_flags);
|
|
|
|
|
if (!stream_info)
|
|
|
|
|
goto cleanup_trbs;
|
|
|
|
|
|
|
|
|
|
stream_info->num_streams = num_streams;
|
|
|
|
|
stream_info->num_stream_ctxs = num_stream_ctxs;
|
|
|
|
|
|
|
|
|
|
/* Initialize the array of virtual pointers to stream rings. */
|
|
|
|
|
stream_info->stream_rings = kzalloc(
|
|
|
|
|
sizeof(struct xhci_ring *)*num_streams,
|
|
|
|
|
mem_flags);
|
|
|
|
|
if (!stream_info->stream_rings)
|
|
|
|
|
goto cleanup_info;
|
|
|
|
|
|
|
|
|
|
/* Initialize the array of DMA addresses for stream rings for the HW. */
|
|
|
|
|
stream_info->stream_ctx_array = xhci_alloc_stream_ctx(xhci,
|
|
|
|
|
num_stream_ctxs, &stream_info->ctx_array_dma,
|
|
|
|
|
mem_flags);
|
|
|
|
|
if (!stream_info->stream_ctx_array)
|
|
|
|
|
goto cleanup_ctx;
|
|
|
|
|
memset(stream_info->stream_ctx_array, 0,
|
|
|
|
|
sizeof(struct xhci_stream_ctx)*num_stream_ctxs);
|
|
|
|
|
|
|
|
|
|
/* Allocate everything needed to free the stream rings later */
|
|
|
|
|
stream_info->free_streams_command =
|
|
|
|
|
xhci_alloc_command(xhci, true, true, mem_flags);
|
|
|
|
|
if (!stream_info->free_streams_command)
|
|
|
|
|
goto cleanup_ctx;
|
|
|
|
|
|
|
|
|
|
INIT_RADIX_TREE(&stream_info->trb_address_map, GFP_ATOMIC);
|
|
|
|
|
|
|
|
|
|
/* Allocate rings for all the streams that the driver will use,
|
|
|
|
|
* and add their segment DMA addresses to the radix tree.
|
|
|
|
|
* Stream 0 is reserved.
|
|
|
|
|
*/
|
|
|
|
|
for (cur_stream = 1; cur_stream < num_streams; cur_stream++) {
|
|
|
|
|
stream_info->stream_rings[cur_stream] =
|
2012-03-05 17:49:39 +08:00
|
|
|
|
xhci_ring_alloc(xhci, 2, 1, TYPE_STREAM, mem_flags);
|
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
|
|
|
|
cur_ring = stream_info->stream_rings[cur_stream];
|
|
|
|
|
if (!cur_ring)
|
|
|
|
|
goto cleanup_rings;
|
2010-04-03 06:34:43 +08:00
|
|
|
|
cur_ring->stream_id = cur_stream;
|
2013-10-04 06:29:44 +08:00
|
|
|
|
cur_ring->trb_address_map = &stream_info->trb_address_map;
|
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
|
|
|
|
/* Set deq ptr, cycle bit, and stream context type */
|
|
|
|
|
addr = cur_ring->first_seg->dma |
|
|
|
|
|
SCT_FOR_CTX(SCT_PRI_TR) |
|
|
|
|
|
cur_ring->cycle_state;
|
2011-06-01 08:22:55 +08:00
|
|
|
|
stream_info->stream_ctx_array[cur_stream].stream_ring =
|
|
|
|
|
cpu_to_le64(addr);
|
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
|
|
|
|
xhci_dbg(xhci, "Setting stream %d ring ptr to 0x%08llx\n",
|
|
|
|
|
cur_stream, (unsigned long long) addr);
|
|
|
|
|
|
2013-10-04 06:29:44 +08:00
|
|
|
|
ret = xhci_update_stream_mapping(cur_ring, mem_flags);
|
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
|
|
|
|
if (ret) {
|
|
|
|
|
xhci_ring_free(xhci, cur_ring);
|
|
|
|
|
stream_info->stream_rings[cur_stream] = NULL;
|
|
|
|
|
goto cleanup_rings;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
/* Leave the other unused stream ring pointers in the stream context
|
|
|
|
|
* array initialized to zero. This will cause the xHC to give us an
|
|
|
|
|
* error if the device asks for a stream ID we don't have setup (if it
|
|
|
|
|
* was any other way, the host controller would assume the ring is
|
|
|
|
|
* "empty" and wait forever for data to be queued to that stream ID).
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
return stream_info;
|
|
|
|
|
|
|
|
|
|
cleanup_rings:
|
|
|
|
|
for (cur_stream = 1; cur_stream < num_streams; cur_stream++) {
|
|
|
|
|
cur_ring = stream_info->stream_rings[cur_stream];
|
|
|
|
|
if (cur_ring) {
|
|
|
|
|
xhci_ring_free(xhci, cur_ring);
|
|
|
|
|
stream_info->stream_rings[cur_stream] = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
xhci_free_command(xhci, stream_info->free_streams_command);
|
|
|
|
|
cleanup_ctx:
|
|
|
|
|
kfree(stream_info->stream_rings);
|
|
|
|
|
cleanup_info:
|
|
|
|
|
kfree(stream_info);
|
|
|
|
|
cleanup_trbs:
|
|
|
|
|
xhci->cmd_ring_reserved_trbs--;
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
/*
|
|
|
|
|
* Sets the MaxPStreams field and the Linear Stream Array field.
|
|
|
|
|
* Sets the dequeue pointer to the stream context array.
|
|
|
|
|
*/
|
|
|
|
|
void xhci_setup_streams_ep_input_ctx(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx,
|
|
|
|
|
struct xhci_stream_info *stream_info)
|
|
|
|
|
{
|
|
|
|
|
u32 max_primary_streams;
|
|
|
|
|
/* MaxPStreams is the number of stream context array entries, not the
|
|
|
|
|
* number we're actually using. Must be in 2^(MaxPstreams + 1) format.
|
|
|
|
|
* fls(0) = 0, fls(0x1) = 1, fls(0x10) = 2, fls(0x100) = 3, etc.
|
|
|
|
|
*/
|
|
|
|
|
max_primary_streams = fls(stream_info->num_stream_ctxs) - 2;
|
2013-07-31 12:35:27 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
|
|
|
|
|
"Setting number of stream ctx array entries to %u",
|
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
|
|
|
|
1 << (max_primary_streams + 1));
|
2011-03-29 10:40:46 +08:00
|
|
|
|
ep_ctx->ep_info &= cpu_to_le32(~EP_MAXPSTREAMS_MASK);
|
|
|
|
|
ep_ctx->ep_info |= cpu_to_le32(EP_MAXPSTREAMS(max_primary_streams)
|
|
|
|
|
| EP_HAS_LSA);
|
|
|
|
|
ep_ctx->deq = cpu_to_le64(stream_info->ctx_array_dma);
|
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
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Sets the MaxPStreams field and the Linear Stream Array field to 0.
|
|
|
|
|
* Reinstalls the "normal" endpoint ring (at its previous dequeue mark,
|
|
|
|
|
* not at the beginning of the ring).
|
|
|
|
|
*/
|
|
|
|
|
void xhci_setup_no_streams_ep_input_ctx(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx,
|
|
|
|
|
struct xhci_virt_ep *ep)
|
|
|
|
|
{
|
|
|
|
|
dma_addr_t addr;
|
2011-03-29 10:40:46 +08:00
|
|
|
|
ep_ctx->ep_info &= cpu_to_le32(~(EP_MAXPSTREAMS_MASK | EP_HAS_LSA));
|
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
|
|
|
|
addr = xhci_trb_virt_to_dma(ep->ring->deq_seg, ep->ring->dequeue);
|
2011-03-29 10:40:46 +08:00
|
|
|
|
ep_ctx->deq = cpu_to_le64(addr | ep->ring->cycle_state);
|
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
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Frees all stream contexts associated with the endpoint,
|
|
|
|
|
*
|
|
|
|
|
* Caller should fix the endpoint context streams fields.
|
|
|
|
|
*/
|
|
|
|
|
void xhci_free_stream_info(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_stream_info *stream_info)
|
|
|
|
|
{
|
|
|
|
|
int cur_stream;
|
|
|
|
|
struct xhci_ring *cur_ring;
|
|
|
|
|
|
|
|
|
|
if (!stream_info)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
for (cur_stream = 1; cur_stream < stream_info->num_streams;
|
|
|
|
|
cur_stream++) {
|
|
|
|
|
cur_ring = stream_info->stream_rings[cur_stream];
|
|
|
|
|
if (cur_ring) {
|
|
|
|
|
xhci_ring_free(xhci, cur_ring);
|
|
|
|
|
stream_info->stream_rings[cur_stream] = NULL;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
xhci_free_command(xhci, stream_info->free_streams_command);
|
|
|
|
|
xhci->cmd_ring_reserved_trbs--;
|
|
|
|
|
if (stream_info->stream_ctx_array)
|
|
|
|
|
xhci_free_stream_ctx(xhci,
|
|
|
|
|
stream_info->num_stream_ctxs,
|
|
|
|
|
stream_info->stream_ctx_array,
|
|
|
|
|
stream_info->ctx_array_dma);
|
|
|
|
|
|
2013-08-27 04:29:48 +08:00
|
|
|
|
kfree(stream_info->stream_rings);
|
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
|
|
|
|
kfree(stream_info);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/***************** Device context manipulation *************************/
|
|
|
|
|
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
|
static void xhci_init_endpoint_timer(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_ep *ep)
|
|
|
|
|
{
|
2015-01-09 22:06:30 +08:00
|
|
|
|
setup_timer(&ep->stop_cmd_timer, xhci_stop_endpoint_command_watchdog,
|
|
|
|
|
(unsigned long)ep);
|
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->xhci = xhci;
|
|
|
|
|
}
|
|
|
|
|
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
|
static void xhci_free_tt_info(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
|
int slot_id)
|
|
|
|
|
{
|
|
|
|
|
struct list_head *tt_list_head;
|
2012-06-01 16:06:23 +08:00
|
|
|
|
struct xhci_tt_bw_info *tt_info, *next;
|
|
|
|
|
bool slot_found = false;
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
|
|
|
|
|
|
/* If the device never made it past the Set Address stage,
|
|
|
|
|
* it may not have the real_port set correctly.
|
|
|
|
|
*/
|
|
|
|
|
if (virt_dev->real_port == 0 ||
|
|
|
|
|
virt_dev->real_port > HCS_MAX_PORTS(xhci->hcs_params1)) {
|
|
|
|
|
xhci_dbg(xhci, "Bad real port.\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
tt_list_head = &(xhci->rh_bw[virt_dev->real_port - 1].tts);
|
2012-06-01 16:06:23 +08:00
|
|
|
|
list_for_each_entry_safe(tt_info, next, tt_list_head, tt_list) {
|
|
|
|
|
/* Multi-TT hubs will have more than one entry */
|
|
|
|
|
if (tt_info->slot_id == slot_id) {
|
|
|
|
|
slot_found = true;
|
|
|
|
|
list_del(&tt_info->tt_list);
|
|
|
|
|
kfree(tt_info);
|
|
|
|
|
} else if (slot_found) {
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
|
break;
|
2012-06-01 16:06:23 +08:00
|
|
|
|
}
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int xhci_alloc_tt_info(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
|
struct usb_device *hdev,
|
|
|
|
|
struct usb_tt *tt, gfp_t mem_flags)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_tt_bw_info *tt_info;
|
|
|
|
|
unsigned int num_ports;
|
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
|
|
if (!tt->multi)
|
|
|
|
|
num_ports = 1;
|
|
|
|
|
else
|
|
|
|
|
num_ports = hdev->maxchild;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < num_ports; i++, tt_info++) {
|
|
|
|
|
struct xhci_interval_bw_table *bw_table;
|
|
|
|
|
|
|
|
|
|
tt_info = kzalloc(sizeof(*tt_info), mem_flags);
|
|
|
|
|
if (!tt_info)
|
|
|
|
|
goto free_tts;
|
|
|
|
|
INIT_LIST_HEAD(&tt_info->tt_list);
|
|
|
|
|
list_add(&tt_info->tt_list,
|
|
|
|
|
&xhci->rh_bw[virt_dev->real_port - 1].tts);
|
|
|
|
|
tt_info->slot_id = virt_dev->udev->slot_id;
|
|
|
|
|
if (tt->multi)
|
|
|
|
|
tt_info->ttport = i+1;
|
|
|
|
|
bw_table = &tt_info->bw_table;
|
|
|
|
|
for (j = 0; j < XHCI_MAX_INTERVAL; j++)
|
|
|
|
|
INIT_LIST_HEAD(&bw_table->interval_bw[j].endpoints);
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
free_tts:
|
|
|
|
|
xhci_free_tt_info(xhci, virt_dev, virt_dev->udev->slot_id);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
/* All the xhci_tds in the ring's TD list should be freed at this point.
|
|
|
|
|
* Should be called with xhci->lock held if there is any chance the TT lists
|
|
|
|
|
* will be manipulated by the configure endpoint, allocate device, or update
|
|
|
|
|
* hub functions while this function is removing the TT entries from the list.
|
|
|
|
|
*/
|
2009-04-28 10:57:38 +08:00
|
|
|
|
void xhci_free_virt_device(struct xhci_hcd *xhci, int slot_id)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_virt_device *dev;
|
|
|
|
|
int i;
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
|
int old_active_eps = 0;
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
|
|
|
|
/* Slot ID 0 is reserved */
|
|
|
|
|
if (slot_id == 0 || !xhci->devs[slot_id])
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
dev = xhci->devs[slot_id];
|
2009-07-28 03:03:31 +08:00
|
|
|
|
xhci->dcbaa->dev_context_ptrs[slot_id] = 0;
|
2009-04-28 10:57:38 +08:00
|
|
|
|
if (!dev)
|
|
|
|
|
return;
|
|
|
|
|
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
|
if (dev->tt_info)
|
|
|
|
|
old_active_eps = dev->tt_info->active_eps;
|
|
|
|
|
|
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
|
|
|
|
for (i = 0; i < 31; ++i) {
|
2009-09-05 01:53:09 +08:00
|
|
|
|
if (dev->eps[i].ring)
|
|
|
|
|
xhci_ring_free(xhci, dev->eps[i].ring);
|
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
|
|
|
|
if (dev->eps[i].stream_info)
|
|
|
|
|
xhci_free_stream_info(xhci,
|
|
|
|
|
dev->eps[i].stream_info);
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
|
/* Endpoints on the TT/root port lists should have been removed
|
|
|
|
|
* when usb_disable_device() was called for the device.
|
|
|
|
|
* We can't drop them anyway, because the udev might have gone
|
|
|
|
|
* away by this point, and we can't tell what speed it was.
|
|
|
|
|
*/
|
|
|
|
|
if (!list_empty(&dev->eps[i].bw_endpoint_list))
|
|
|
|
|
xhci_warn(xhci, "Slot %u endpoint %u "
|
|
|
|
|
"not removed from BW list!\n",
|
|
|
|
|
slot_id, i);
|
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
|
|
|
|
}
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
|
/* If this is a hub, free the TT(s) from the TT list */
|
|
|
|
|
xhci_free_tt_info(xhci, dev, slot_id);
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
|
/* If necessary, update the number of active TTs on this root port */
|
|
|
|
|
xhci_update_tt_active_eps(xhci, dev, old_active_eps);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
2009-12-04 01:44:29 +08:00
|
|
|
|
if (dev->ring_cache) {
|
|
|
|
|
for (i = 0; i < dev->num_rings_cached; i++)
|
|
|
|
|
xhci_ring_free(xhci, dev->ring_cache[i]);
|
|
|
|
|
kfree(dev->ring_cache);
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
|
if (dev->in_ctx)
|
2009-07-28 03:05:15 +08:00
|
|
|
|
xhci_free_container_ctx(xhci, dev->in_ctx);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
if (dev->out_ctx)
|
2009-07-28 03:05:15 +08:00
|
|
|
|
xhci_free_container_ctx(xhci, dev->out_ctx);
|
|
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
|
kfree(xhci->devs[slot_id]);
|
2010-04-19 23:53:50 +08:00
|
|
|
|
xhci->devs[slot_id] = NULL;
|
2009-04-28 10:57:38 +08:00
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int xhci_alloc_virt_device(struct xhci_hcd *xhci, int slot_id,
|
|
|
|
|
struct usb_device *udev, gfp_t flags)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_virt_device *dev;
|
2009-09-05 01:53:09 +08:00
|
|
|
|
int i;
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
|
|
|
|
/* Slot ID 0 is reserved */
|
|
|
|
|
if (slot_id == 0 || xhci->devs[slot_id]) {
|
|
|
|
|
xhci_warn(xhci, "Bad Slot ID %d\n", slot_id);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
xhci->devs[slot_id] = kzalloc(sizeof(*xhci->devs[slot_id]), flags);
|
|
|
|
|
if (!xhci->devs[slot_id])
|
|
|
|
|
return 0;
|
|
|
|
|
dev = xhci->devs[slot_id];
|
|
|
|
|
|
2009-07-28 03:05:15 +08:00
|
|
|
|
/* Allocate the (output) device context that will be used in the HC. */
|
|
|
|
|
dev->out_ctx = xhci_alloc_container_ctx(xhci, XHCI_CTX_TYPE_DEVICE, flags);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
if (!dev->out_ctx)
|
|
|
|
|
goto fail;
|
2009-07-28 03:05:15 +08:00
|
|
|
|
|
2009-04-30 10:14:08 +08:00
|
|
|
|
xhci_dbg(xhci, "Slot %d output ctx = 0x%llx (dma)\n", slot_id,
|
2009-07-28 03:05:15 +08:00
|
|
|
|
(unsigned long long)dev->out_ctx->dma);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
|
|
|
|
/* Allocate the (input) device context for address device command */
|
2009-07-28 03:05:15 +08:00
|
|
|
|
dev->in_ctx = xhci_alloc_container_ctx(xhci, XHCI_CTX_TYPE_INPUT, flags);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
if (!dev->in_ctx)
|
|
|
|
|
goto fail;
|
2009-07-28 03:05:15 +08:00
|
|
|
|
|
2009-04-30 10:14:08 +08:00
|
|
|
|
xhci_dbg(xhci, "Slot %d input ctx = 0x%llx (dma)\n", slot_id,
|
2009-07-28 03:05:15 +08:00
|
|
|
|
(unsigned long long)dev->in_ctx->dma);
|
2009-04-28 10:57:38 +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
|
|
|
|
/* Initialize the cancellation list and watchdog timers for each ep */
|
|
|
|
|
for (i = 0; i < 31; i++) {
|
|
|
|
|
xhci_init_endpoint_timer(xhci, &dev->eps[i]);
|
2009-09-05 01:53:09 +08:00
|
|
|
|
INIT_LIST_HEAD(&dev->eps[i].cancelled_td_list);
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
|
INIT_LIST_HEAD(&dev->eps[i].bw_endpoint_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
|
|
|
|
}
|
2009-09-05 01:53:09 +08:00
|
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
|
/* Allocate endpoint 0 ring */
|
2012-03-05 17:49:39 +08:00
|
|
|
|
dev->eps[0].ring = xhci_ring_alloc(xhci, 2, 1, TYPE_CTRL, flags);
|
2009-09-05 01:53:09 +08:00
|
|
|
|
if (!dev->eps[0].ring)
|
2009-04-28 10:57:38 +08:00
|
|
|
|
goto fail;
|
|
|
|
|
|
2009-12-04 01:44:29 +08:00
|
|
|
|
/* Allocate pointers to the ring cache */
|
|
|
|
|
dev->ring_cache = kzalloc(
|
|
|
|
|
sizeof(struct xhci_ring *)*XHCI_MAX_RINGS_CACHED,
|
|
|
|
|
flags);
|
|
|
|
|
if (!dev->ring_cache)
|
|
|
|
|
goto fail;
|
|
|
|
|
dev->num_rings_cached = 0;
|
|
|
|
|
|
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
|
|
|
|
init_completion(&dev->cmd_completion);
|
2010-10-14 22:22:45 +08:00
|
|
|
|
dev->udev = udev;
|
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:05:08 +08:00
|
|
|
|
/* Point to output device context in dcbaa. */
|
2011-03-29 10:40:46 +08:00
|
|
|
|
xhci->dcbaa->dev_context_ptrs[slot_id] = cpu_to_le64(dev->out_ctx->dma);
|
2009-04-30 10:14:08 +08:00
|
|
|
|
xhci_dbg(xhci, "Set slot id %d dcbaa entry %p to 0x%llx\n",
|
2011-03-29 10:40:46 +08:00
|
|
|
|
slot_id,
|
|
|
|
|
&xhci->dcbaa->dev_context_ptrs[slot_id],
|
2011-06-01 08:22:55 +08:00
|
|
|
|
le64_to_cpu(xhci->dcbaa->dev_context_ptrs[slot_id]));
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
fail:
|
|
|
|
|
xhci_free_virt_device(xhci, slot_id);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2010-07-09 23:08:54 +08:00
|
|
|
|
void xhci_copy_ep0_dequeue_into_input_ctx(struct xhci_hcd *xhci,
|
|
|
|
|
struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_virt_device *virt_dev;
|
|
|
|
|
struct xhci_ep_ctx *ep0_ctx;
|
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
|
|
|
|
|
|
virt_dev = xhci->devs[udev->slot_id];
|
|
|
|
|
ep0_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, 0);
|
|
|
|
|
ep_ring = virt_dev->eps[0].ring;
|
|
|
|
|
/*
|
|
|
|
|
* FIXME we don't keep track of the dequeue pointer very well after a
|
|
|
|
|
* Set TR dequeue pointer, so we're setting the dequeue pointer of the
|
|
|
|
|
* host to our enqueue pointer. This should only be called after a
|
|
|
|
|
* configured device has reset, so all control transfers should have
|
|
|
|
|
* been completed or cancelled before the reset.
|
|
|
|
|
*/
|
2011-03-29 10:40:46 +08:00
|
|
|
|
ep0_ctx->deq = cpu_to_le64(xhci_trb_virt_to_dma(ep_ring->enq_seg,
|
|
|
|
|
ep_ring->enqueue)
|
|
|
|
|
| ep_ring->cycle_state);
|
2010-07-09 23:08:54 +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
|
|
|
|
/*
|
|
|
|
|
* The xHCI roothub may have ports of differing speeds in any order in the port
|
|
|
|
|
* status registers. xhci->port_array provides an array of the port speed for
|
|
|
|
|
* each offset into the port status registers.
|
|
|
|
|
*
|
|
|
|
|
* The xHCI hardware wants to know the roothub port number that the USB device
|
|
|
|
|
* is attached to (or the roothub port its ancestor hub is attached to). All we
|
|
|
|
|
* know is the index of that port under either the USB 2.0 or the USB 3.0
|
|
|
|
|
* roothub, but that doesn't give us the real index into the HW port status
|
2013-03-19 16:48:12 +08:00
|
|
|
|
* registers. Call xhci_find_raw_port_number() to get real 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
|
|
|
|
*/
|
|
|
|
|
static u32 xhci_find_real_port_number(struct xhci_hcd *xhci,
|
|
|
|
|
struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
struct usb_device *top_dev;
|
2013-03-19 16:48:12 +08:00
|
|
|
|
struct usb_hcd *hcd;
|
|
|
|
|
|
|
|
|
|
if (udev->speed == USB_SPEED_SUPER)
|
|
|
|
|
hcd = xhci->shared_hcd;
|
|
|
|
|
else
|
|
|
|
|
hcd = xhci->main_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
|
|
|
|
|
|
|
|
|
for (top_dev = udev; top_dev->parent && top_dev->parent->parent;
|
|
|
|
|
top_dev = top_dev->parent)
|
|
|
|
|
/* Found device below root hub */;
|
|
|
|
|
|
2013-03-19 16:48:12 +08:00
|
|
|
|
return xhci_find_raw_port_number(hcd, top_dev->portnum);
|
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
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
|
/* Setup an xHCI virtual device for a Set Address command */
|
|
|
|
|
int xhci_setup_addressable_virt_dev(struct xhci_hcd *xhci, struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_virt_device *dev;
|
|
|
|
|
struct xhci_ep_ctx *ep0_ctx;
|
2009-07-28 03:05:15 +08:00
|
|
|
|
struct xhci_slot_ctx *slot_ctx;
|
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
|
|
|
|
u32 port_num;
|
2013-04-24 08:17:40 +08:00
|
|
|
|
u32 max_packets;
|
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_device *top_dev;
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
|
|
|
|
dev = xhci->devs[udev->slot_id];
|
|
|
|
|
/* Slot ID 0 is reserved */
|
|
|
|
|
if (udev->slot_id == 0 || !dev) {
|
|
|
|
|
xhci_warn(xhci, "Slot ID %d is not assigned to this device\n",
|
|
|
|
|
udev->slot_id);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2009-07-28 03:05:15 +08:00
|
|
|
|
ep0_ctx = xhci_get_ep_ctx(xhci, dev->in_ctx, 0);
|
|
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, dev->in_ctx);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
|
|
|
|
/* 3) Only the control endpoint is valid - one endpoint context */
|
2011-06-01 08:22:55 +08:00
|
|
|
|
slot_ctx->dev_info |= cpu_to_le32(LAST_CTX(1) | udev->route);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
switch (udev->speed) {
|
|
|
|
|
case USB_SPEED_SUPER:
|
2011-06-01 08:22:55 +08:00
|
|
|
|
slot_ctx->dev_info |= cpu_to_le32(SLOT_SPEED_SS);
|
2013-04-24 08:17:40 +08:00
|
|
|
|
max_packets = MAX_PACKET(512);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
break;
|
|
|
|
|
case USB_SPEED_HIGH:
|
2011-06-01 08:22:55 +08:00
|
|
|
|
slot_ctx->dev_info |= cpu_to_le32(SLOT_SPEED_HS);
|
2013-04-24 08:17:40 +08:00
|
|
|
|
max_packets = MAX_PACKET(64);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
break;
|
2013-04-24 08:17:40 +08:00
|
|
|
|
/* USB core guesses at a 64-byte max packet first for FS devices */
|
2009-04-28 10:57:38 +08:00
|
|
|
|
case USB_SPEED_FULL:
|
2011-06-01 08:22:55 +08:00
|
|
|
|
slot_ctx->dev_info |= cpu_to_le32(SLOT_SPEED_FS);
|
2013-04-24 08:17:40 +08:00
|
|
|
|
max_packets = MAX_PACKET(64);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
break;
|
|
|
|
|
case USB_SPEED_LOW:
|
2011-06-01 08:22:55 +08:00
|
|
|
|
slot_ctx->dev_info |= cpu_to_le32(SLOT_SPEED_LS);
|
2013-04-24 08:17:40 +08:00
|
|
|
|
max_packets = MAX_PACKET(8);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
break;
|
2010-01-15 03:08:04 +08:00
|
|
|
|
case USB_SPEED_WIRELESS:
|
2009-04-28 10:57:38 +08:00
|
|
|
|
xhci_dbg(xhci, "FIXME xHCI doesn't support wireless speeds\n");
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
/* Speed was set earlier, this shouldn't happen. */
|
2013-04-24 08:17:40 +08:00
|
|
|
|
return -EINVAL;
|
2009-04-28 10:57:38 +08:00
|
|
|
|
}
|
|
|
|
|
/* Find the root hub port this device is under */
|
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_num = xhci_find_real_port_number(xhci, udev);
|
|
|
|
|
if (!port_num)
|
|
|
|
|
return -EINVAL;
|
2011-06-01 08:22:55 +08:00
|
|
|
|
slot_ctx->dev_info2 |= cpu_to_le32(ROOT_HUB_PORT(port_num));
|
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
|
|
|
|
/* Set the port number in the virtual_device to the faked port number */
|
2009-04-28 10:57:38 +08:00
|
|
|
|
for (top_dev = udev; top_dev->parent && top_dev->parent->parent;
|
|
|
|
|
top_dev = top_dev->parent)
|
|
|
|
|
/* Found device below root hub */;
|
2011-09-03 02:05:41 +08:00
|
|
|
|
dev->fake_port = top_dev->portnum;
|
2011-09-03 02:05:45 +08:00
|
|
|
|
dev->real_port = port_num;
|
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_dbg(xhci, "Set root hub portnum to %d\n", port_num);
|
2011-09-03 02:05:41 +08:00
|
|
|
|
xhci_dbg(xhci, "Set fake root hub portnum to %d\n", dev->fake_port);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
|
/* Find the right bandwidth table that this device will be a part of.
|
|
|
|
|
* If this is a full speed device attached directly to a root port (or a
|
|
|
|
|
* decendent of one), it counts as a primary bandwidth domain, not a
|
|
|
|
|
* secondary bandwidth domain under a TT. An xhci_tt_info structure
|
|
|
|
|
* will never be created for the HS root hub.
|
|
|
|
|
*/
|
|
|
|
|
if (!udev->tt || !udev->tt->hub->parent) {
|
|
|
|
|
dev->bw_table = &xhci->rh_bw[port_num - 1].bw_table;
|
|
|
|
|
} else {
|
|
|
|
|
struct xhci_root_port_bw_info *rh_bw;
|
|
|
|
|
struct xhci_tt_bw_info *tt_bw;
|
|
|
|
|
|
|
|
|
|
rh_bw = &xhci->rh_bw[port_num - 1];
|
|
|
|
|
/* Find the right TT. */
|
|
|
|
|
list_for_each_entry(tt_bw, &rh_bw->tts, tt_list) {
|
|
|
|
|
if (tt_bw->slot_id != udev->tt->hub->slot_id)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (!dev->udev->tt->multi ||
|
|
|
|
|
(udev->tt->multi &&
|
|
|
|
|
tt_bw->ttport == dev->udev->ttport)) {
|
|
|
|
|
dev->bw_table = &tt_bw->bw_table;
|
|
|
|
|
dev->tt_info = tt_bw;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (!dev->tt_info)
|
|
|
|
|
xhci_warn(xhci, "WARN: Didn't find a matching TT\n");
|
|
|
|
|
}
|
|
|
|
|
|
2011-03-03 21:40:51 +08:00
|
|
|
|
/* Is this a LS/FS device under an external HS hub? */
|
|
|
|
|
if (udev->tt && udev->tt->hub->parent) {
|
2011-03-29 10:40:46 +08:00
|
|
|
|
slot_ctx->tt_info = cpu_to_le32(udev->tt->hub->slot_id |
|
|
|
|
|
(udev->ttport << 8));
|
2009-09-05 01:53:19 +08:00
|
|
|
|
if (udev->tt->multi)
|
2011-03-29 10:40:46 +08:00
|
|
|
|
slot_ctx->dev_info |= cpu_to_le32(DEV_MTT);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
}
|
2009-04-30 10:14:08 +08:00
|
|
|
|
xhci_dbg(xhci, "udev->tt = %p\n", udev->tt);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
xhci_dbg(xhci, "udev->ttport = 0x%x\n", udev->ttport);
|
|
|
|
|
|
|
|
|
|
/* Step 4 - ring already allocated */
|
|
|
|
|
/* Step 5 */
|
2011-03-29 10:40:46 +08:00
|
|
|
|
ep0_ctx->ep_info2 = cpu_to_le32(EP_TYPE(CTRL_EP));
|
2013-04-24 08:17:40 +08:00
|
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
|
/* EP 0 can handle "burst" sizes of 1, so Max Burst Size field is 0 */
|
2013-04-24 08:17:40 +08:00
|
|
|
|
ep0_ctx->ep_info2 |= cpu_to_le32(MAX_BURST(0) | ERROR_COUNT(3) |
|
|
|
|
|
max_packets);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
|
ep0_ctx->deq = cpu_to_le64(dev->eps[0].ring->first_seg->dma |
|
|
|
|
|
dev->eps[0].ring->cycle_state);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
|
|
|
|
/* Steps 7 and 8 were done in xhci_alloc_virt_device() */
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2011-03-24 13:41:23 +08:00
|
|
|
|
/*
|
|
|
|
|
* Convert interval expressed as 2^(bInterval - 1) == interval into
|
|
|
|
|
* straight exponent value 2^n == interval.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
static unsigned int xhci_parse_exponent_interval(struct usb_device *udev,
|
|
|
|
|
struct usb_host_endpoint *ep)
|
|
|
|
|
{
|
|
|
|
|
unsigned int interval;
|
|
|
|
|
|
|
|
|
|
interval = clamp_val(ep->desc.bInterval, 1, 16) - 1;
|
|
|
|
|
if (interval != ep->desc.bInterval - 1)
|
|
|
|
|
dev_warn(&udev->dev,
|
2011-06-01 05:37:23 +08:00
|
|
|
|
"ep %#x - rounding interval to %d %sframes\n",
|
2011-03-24 13:41:23 +08:00
|
|
|
|
ep->desc.bEndpointAddress,
|
2011-06-01 05:37:23 +08:00
|
|
|
|
1 << interval,
|
|
|
|
|
udev->speed == USB_SPEED_FULL ? "" : "micro");
|
|
|
|
|
|
|
|
|
|
if (udev->speed == USB_SPEED_FULL) {
|
|
|
|
|
/*
|
|
|
|
|
* Full speed isoc endpoints specify interval in frames,
|
|
|
|
|
* not microframes. We are using microframes everywhere,
|
|
|
|
|
* so adjust accordingly.
|
|
|
|
|
*/
|
|
|
|
|
interval += 3; /* 1 frame = 2^3 uframes */
|
|
|
|
|
}
|
2011-03-24 13:41:23 +08:00
|
|
|
|
|
|
|
|
|
return interval;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2012-02-14 06:42:11 +08:00
|
|
|
|
* Convert bInterval expressed in microframes (in 1-255 range) to exponent of
|
2011-03-24 13:41:23 +08:00
|
|
|
|
* microframes, rounded down to nearest power of 2.
|
|
|
|
|
*/
|
2012-02-14 06:42:11 +08:00
|
|
|
|
static unsigned int xhci_microframes_to_exponent(struct usb_device *udev,
|
|
|
|
|
struct usb_host_endpoint *ep, unsigned int desc_interval,
|
|
|
|
|
unsigned int min_exponent, unsigned int max_exponent)
|
2011-03-24 13:41:23 +08:00
|
|
|
|
{
|
|
|
|
|
unsigned int interval;
|
|
|
|
|
|
2012-02-14 06:42:11 +08:00
|
|
|
|
interval = fls(desc_interval) - 1;
|
|
|
|
|
interval = clamp_val(interval, min_exponent, max_exponent);
|
|
|
|
|
if ((1 << interval) != desc_interval)
|
2011-03-24 13:41:23 +08:00
|
|
|
|
dev_warn(&udev->dev,
|
|
|
|
|
"ep %#x - rounding interval to %d microframes, ep desc says %d microframes\n",
|
|
|
|
|
ep->desc.bEndpointAddress,
|
|
|
|
|
1 << interval,
|
2012-02-14 06:42:11 +08:00
|
|
|
|
desc_interval);
|
2011-03-24 13:41:23 +08:00
|
|
|
|
|
|
|
|
|
return interval;
|
|
|
|
|
}
|
|
|
|
|
|
2012-02-14 06:42:11 +08:00
|
|
|
|
static unsigned int xhci_parse_microframe_interval(struct usb_device *udev,
|
|
|
|
|
struct usb_host_endpoint *ep)
|
|
|
|
|
{
|
2012-12-18 06:12:35 +08:00
|
|
|
|
if (ep->desc.bInterval == 0)
|
|
|
|
|
return 0;
|
2012-02-14 06:42:11 +08:00
|
|
|
|
return xhci_microframes_to_exponent(udev, ep,
|
|
|
|
|
ep->desc.bInterval, 0, 15);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static unsigned int xhci_parse_frame_interval(struct usb_device *udev,
|
|
|
|
|
struct usb_host_endpoint *ep)
|
|
|
|
|
{
|
|
|
|
|
return xhci_microframes_to_exponent(udev, ep,
|
|
|
|
|
ep->desc.bInterval * 8, 3, 10);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
/* Return the polling or NAK interval.
|
|
|
|
|
*
|
|
|
|
|
* The polling interval is expressed in "microframes". If xHCI's Interval field
|
|
|
|
|
* is set to N, it will service the endpoint every 2^(Interval)*125us.
|
|
|
|
|
*
|
|
|
|
|
* The NAK interval is one NAK per 1 to 255 microframes, or no NAKs if interval
|
|
|
|
|
* is set to 0.
|
|
|
|
|
*/
|
2011-03-20 17:15:16 +08:00
|
|
|
|
static unsigned int xhci_get_endpoint_interval(struct usb_device *udev,
|
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
|
|
|
|
struct usb_host_endpoint *ep)
|
|
|
|
|
{
|
|
|
|
|
unsigned int interval = 0;
|
|
|
|
|
|
|
|
|
|
switch (udev->speed) {
|
|
|
|
|
case USB_SPEED_HIGH:
|
|
|
|
|
/* Max NAK rate */
|
|
|
|
|
if (usb_endpoint_xfer_control(&ep->desc) ||
|
2011-03-24 13:41:23 +08:00
|
|
|
|
usb_endpoint_xfer_bulk(&ep->desc)) {
|
2012-02-14 06:42:11 +08:00
|
|
|
|
interval = xhci_parse_microframe_interval(udev, ep);
|
2011-03-24 13:41:23 +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
|
|
|
|
/* Fall through - SS and HS isoc/int have same decoding */
|
2011-03-24 13:41:23 +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
|
|
|
|
case USB_SPEED_SUPER:
|
|
|
|
|
if (usb_endpoint_xfer_int(&ep->desc) ||
|
2011-03-24 13:41:23 +08:00
|
|
|
|
usb_endpoint_xfer_isoc(&ep->desc)) {
|
|
|
|
|
interval = xhci_parse_exponent_interval(udev, ep);
|
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;
|
2011-03-24 13:41:23 +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
|
|
|
|
case USB_SPEED_FULL:
|
xhci: Fix full speed bInterval encoding.
Dmitry's patch
dfa49c4ad120a784ef1ff0717168aa79f55a483a USB: xhci - fix math in xhci_get_endpoint_interval()
introduced a bug. The USB 2.0 spec says that full speed isochronous endpoints'
bInterval must be decoded as an exponent to a power of two (e.g. interval =
2^(bInterval - 1)). Full speed interrupt endpoints, on the other hand, don't
use exponents, and the interval in frames is encoded straight into bInterval.
Dmitry's patch was supposed to fix up the full speed isochronous to parse
bInterval as an exponent, but instead it changed the *interrupt* endpoint
bInterval decoding. The isochronous endpoint encoding was the same.
This caused full speed devices with interrupt endpoints (including mice, hubs,
and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:
[ 100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
[ 100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000
...
[ 100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
[ 100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000
When the interrupt endpoint was added and a Configure Endpoint command was
issued to the host, the host controller would return a very odd error message
(0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
Probably the host controller was getting very confused with the bad encoding.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-14 04:10:01 +08:00
|
|
|
|
if (usb_endpoint_xfer_isoc(&ep->desc)) {
|
2011-03-24 13:41:23 +08:00
|
|
|
|
interval = xhci_parse_exponent_interval(udev, ep);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
/*
|
xhci: Fix full speed bInterval encoding.
Dmitry's patch
dfa49c4ad120a784ef1ff0717168aa79f55a483a USB: xhci - fix math in xhci_get_endpoint_interval()
introduced a bug. The USB 2.0 spec says that full speed isochronous endpoints'
bInterval must be decoded as an exponent to a power of two (e.g. interval =
2^(bInterval - 1)). Full speed interrupt endpoints, on the other hand, don't
use exponents, and the interval in frames is encoded straight into bInterval.
Dmitry's patch was supposed to fix up the full speed isochronous to parse
bInterval as an exponent, but instead it changed the *interrupt* endpoint
bInterval decoding. The isochronous endpoint encoding was the same.
This caused full speed devices with interrupt endpoints (including mice, hubs,
and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:
[ 100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
[ 100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000
...
[ 100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
[ 100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000
When the interrupt endpoint was added and a Configure Endpoint command was
issued to the host, the host controller would return a very odd error message
(0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
Probably the host controller was getting very confused with the bad encoding.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-14 04:10:01 +08:00
|
|
|
|
* Fall through for interrupt endpoint interval decoding
|
2011-03-24 13:41:23 +08:00
|
|
|
|
* since it uses the same rules as low speed interrupt
|
|
|
|
|
* endpoints.
|
|
|
|
|
*/
|
|
|
|
|
|
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 USB_SPEED_LOW:
|
|
|
|
|
if (usb_endpoint_xfer_int(&ep->desc) ||
|
2011-03-24 13:41:23 +08:00
|
|
|
|
usb_endpoint_xfer_isoc(&ep->desc)) {
|
|
|
|
|
|
|
|
|
|
interval = xhci_parse_frame_interval(udev, ep);
|
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;
|
2011-03-24 13:41:23 +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
|
|
|
|
default:
|
|
|
|
|
BUG();
|
|
|
|
|
}
|
|
|
|
|
return EP_INTERVAL(interval);
|
|
|
|
|
}
|
|
|
|
|
|
2010-07-10 21:48:01 +08:00
|
|
|
|
/* The "Mult" field in the endpoint context is only set for SuperSpeed isoc eps.
|
2010-04-16 23:07:04 +08:00
|
|
|
|
* High speed endpoint descriptors can define "the number of additional
|
|
|
|
|
* transaction opportunities per microframe", but that goes in the Max Burst
|
|
|
|
|
* endpoint context field.
|
|
|
|
|
*/
|
2011-03-20 17:15:16 +08:00
|
|
|
|
static u32 xhci_get_endpoint_mult(struct usb_device *udev,
|
2010-04-16 23:07:04 +08:00
|
|
|
|
struct usb_host_endpoint *ep)
|
|
|
|
|
{
|
2010-07-10 21:48:01 +08:00
|
|
|
|
if (udev->speed != USB_SPEED_SUPER ||
|
|
|
|
|
!usb_endpoint_xfer_isoc(&ep->desc))
|
2010-04-16 23:07:04 +08:00
|
|
|
|
return 0;
|
2010-05-01 00:44:46 +08:00
|
|
|
|
return ep->ss_ep_comp.bmAttributes;
|
2010-04-16 23:07:04 +08:00
|
|
|
|
}
|
|
|
|
|
|
2011-03-20 17:15:16 +08:00
|
|
|
|
static u32 xhci_get_endpoint_type(struct usb_device *udev,
|
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
|
|
|
|
struct usb_host_endpoint *ep)
|
|
|
|
|
{
|
|
|
|
|
int in;
|
|
|
|
|
u32 type;
|
|
|
|
|
|
|
|
|
|
in = usb_endpoint_dir_in(&ep->desc);
|
|
|
|
|
if (usb_endpoint_xfer_control(&ep->desc)) {
|
|
|
|
|
type = EP_TYPE(CTRL_EP);
|
|
|
|
|
} else if (usb_endpoint_xfer_bulk(&ep->desc)) {
|
|
|
|
|
if (in)
|
|
|
|
|
type = EP_TYPE(BULK_IN_EP);
|
|
|
|
|
else
|
|
|
|
|
type = EP_TYPE(BULK_OUT_EP);
|
|
|
|
|
} else if (usb_endpoint_xfer_isoc(&ep->desc)) {
|
|
|
|
|
if (in)
|
|
|
|
|
type = EP_TYPE(ISOC_IN_EP);
|
|
|
|
|
else
|
|
|
|
|
type = EP_TYPE(ISOC_OUT_EP);
|
|
|
|
|
} else if (usb_endpoint_xfer_int(&ep->desc)) {
|
|
|
|
|
if (in)
|
|
|
|
|
type = EP_TYPE(INT_IN_EP);
|
|
|
|
|
else
|
|
|
|
|
type = EP_TYPE(INT_OUT_EP);
|
|
|
|
|
} else {
|
2013-04-24 22:24:58 +08:00
|
|
|
|
type = 0;
|
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
|
|
|
|
}
|
|
|
|
|
return type;
|
|
|
|
|
}
|
|
|
|
|
|
USB: xhci: properly set endpoint context fields for periodic eps.
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval. The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload). This is used by the hardware for bandwidth
management and scheduling of packets.
For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor). Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.
For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).
For FS/LS devices, this is just the max packet size.
The other thing we must set in the endpoint context is the Average TRB
Length. This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD. This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.
It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together. Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD. The Linux
xHCI driver does not use Event Data TRBs.
In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately. For now,
we set it to the same number as the Max ESIT payload.
The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-16 23:07:27 +08:00
|
|
|
|
/* Return the maximum endpoint service interval time (ESIT) payload.
|
|
|
|
|
* Basically, this is the maxpacket size, multiplied by the burst size
|
|
|
|
|
* and mult size.
|
|
|
|
|
*/
|
2011-03-20 17:15:16 +08:00
|
|
|
|
static u32 xhci_get_max_esit_payload(struct xhci_hcd *xhci,
|
USB: xhci: properly set endpoint context fields for periodic eps.
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval. The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload). This is used by the hardware for bandwidth
management and scheduling of packets.
For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor). Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.
For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).
For FS/LS devices, this is just the max packet size.
The other thing we must set in the endpoint context is the Average TRB
Length. This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD. This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.
It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together. Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD. The Linux
xHCI driver does not use Event Data TRBs.
In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately. For now,
we set it to the same number as the Max ESIT payload.
The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-16 23:07:27 +08:00
|
|
|
|
struct usb_device *udev,
|
|
|
|
|
struct usb_host_endpoint *ep)
|
|
|
|
|
{
|
|
|
|
|
int max_burst;
|
|
|
|
|
int max_packet;
|
|
|
|
|
|
|
|
|
|
/* Only applies for interrupt or isochronous endpoints */
|
|
|
|
|
if (usb_endpoint_xfer_control(&ep->desc) ||
|
|
|
|
|
usb_endpoint_xfer_bulk(&ep->desc))
|
|
|
|
|
return 0;
|
|
|
|
|
|
2010-05-01 00:44:46 +08:00
|
|
|
|
if (udev->speed == USB_SPEED_SUPER)
|
2011-04-12 02:19:12 +08:00
|
|
|
|
return le16_to_cpu(ep->ss_ep_comp.wBytesPerInterval);
|
USB: xhci: properly set endpoint context fields for periodic eps.
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval. The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload). This is used by the hardware for bandwidth
management and scheduling of packets.
For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor). Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.
For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).
For FS/LS devices, this is just the max packet size.
The other thing we must set in the endpoint context is the Average TRB
Length. This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD. This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.
It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together. Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD. The Linux
xHCI driver does not use Event Data TRBs.
In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately. For now,
we set it to the same number as the Max ESIT payload.
The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-16 23:07:27 +08:00
|
|
|
|
|
2011-08-23 18:12:03 +08:00
|
|
|
|
max_packet = GET_MAX_PACKET(usb_endpoint_maxp(&ep->desc));
|
|
|
|
|
max_burst = (usb_endpoint_maxp(&ep->desc) & 0x1800) >> 11;
|
USB: xhci: properly set endpoint context fields for periodic eps.
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval. The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload). This is used by the hardware for bandwidth
management and scheduling of packets.
For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor). Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.
For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).
For FS/LS devices, this is just the max packet size.
The other thing we must set in the endpoint context is the Average TRB
Length. This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD. This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.
It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together. Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD. The Linux
xHCI driver does not use Event Data TRBs.
In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately. For now,
we set it to the same number as the Max ESIT payload.
The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-16 23:07:27 +08:00
|
|
|
|
/* A 0 in max burst means 1 transfer per ESIT */
|
|
|
|
|
return max_packet * (max_burst + 1);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
/* Set up an endpoint with one ring segment. Do not allocate stream rings.
|
|
|
|
|
* Drivers will have to call usb_alloc_streams() to do that.
|
|
|
|
|
*/
|
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
|
|
|
|
int xhci_endpoint_init(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
|
struct usb_device *udev,
|
2009-05-15 02:44:22 +08:00
|
|
|
|
struct usb_host_endpoint *ep,
|
|
|
|
|
gfp_t mem_flags)
|
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
|
|
|
|
{
|
|
|
|
|
unsigned int ep_index;
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
|
struct xhci_ring *ep_ring;
|
|
|
|
|
unsigned int max_packet;
|
|
|
|
|
unsigned int max_burst;
|
2012-03-05 17:49:32 +08:00
|
|
|
|
enum xhci_ring_type type;
|
USB: xhci: properly set endpoint context fields for periodic eps.
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval. The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload). This is used by the hardware for bandwidth
management and scheduling of packets.
For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor). Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.
For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).
For FS/LS devices, this is just the max packet size.
The other thing we must set in the endpoint context is the Average TRB
Length. This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD. This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.
It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together. Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD. The Linux
xHCI driver does not use Event Data TRBs.
In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately. For now,
we set it to the same number as the Max ESIT payload.
The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-16 23:07:27 +08:00
|
|
|
|
u32 max_esit_payload;
|
2013-04-24 22:24:58 +08:00
|
|
|
|
u32 endpoint_type;
|
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
|
|
|
|
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&ep->desc);
|
2009-07-28 03:05:15 +08:00
|
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index);
|
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
|
|
|
|
|
2013-04-24 22:24:58 +08:00
|
|
|
|
endpoint_type = xhci_get_endpoint_type(udev, ep);
|
|
|
|
|
if (!endpoint_type)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
ep_ctx->ep_info2 = cpu_to_le32(endpoint_type);
|
|
|
|
|
|
2012-03-05 17:49:32 +08:00
|
|
|
|
type = usb_endpoint_type(&ep->desc);
|
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
|
|
|
|
/* Set up the endpoint ring */
|
2012-03-05 17:49:37 +08:00
|
|
|
|
virt_dev->eps[ep_index].new_ring =
|
2012-03-05 17:49:39 +08:00
|
|
|
|
xhci_ring_alloc(xhci, 2, 1, type, mem_flags);
|
2009-12-04 01:44:29 +08:00
|
|
|
|
if (!virt_dev->eps[ep_index].new_ring) {
|
|
|
|
|
/* Attempt to use the ring cache */
|
|
|
|
|
if (virt_dev->num_rings_cached == 0)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
virt_dev->eps[ep_index].new_ring =
|
|
|
|
|
virt_dev->ring_cache[virt_dev->num_rings_cached];
|
|
|
|
|
virt_dev->ring_cache[virt_dev->num_rings_cached] = NULL;
|
|
|
|
|
virt_dev->num_rings_cached--;
|
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_reinit_cached_ring(xhci, virt_dev->eps[ep_index].new_ring,
|
2012-03-05 17:49:36 +08:00
|
|
|
|
1, type);
|
2009-12-04 01:44:29 +08:00
|
|
|
|
}
|
2010-07-23 06:23:25 +08:00
|
|
|
|
virt_dev->eps[ep_index].skip = false;
|
2009-09-05 01:53:09 +08:00
|
|
|
|
ep_ring = virt_dev->eps[ep_index].new_ring;
|
2011-03-29 10:40:46 +08:00
|
|
|
|
ep_ctx->deq = cpu_to_le64(ep_ring->first_seg->dma | ep_ring->cycle_state);
|
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
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
|
ep_ctx->ep_info = cpu_to_le32(xhci_get_endpoint_interval(udev, ep)
|
|
|
|
|
| EP_MULT(xhci_get_endpoint_mult(udev, ep)));
|
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
|
|
|
|
|
|
|
|
|
/* FIXME dig Mult and streams info out of ep companion desc */
|
|
|
|
|
|
2009-07-28 03:04:27 +08:00
|
|
|
|
/* Allow 3 retries for everything but isoc;
|
2011-05-05 18:14:00 +08:00
|
|
|
|
* CErr shall be set to 0 for Isoch endpoints.
|
2009-07-28 03:04:27 +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
|
|
|
|
if (!usb_endpoint_xfer_isoc(&ep->desc))
|
2013-04-24 22:24:58 +08:00
|
|
|
|
ep_ctx->ep_info2 |= cpu_to_le32(ERROR_COUNT(3));
|
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
|
|
|
|
else
|
2013-04-24 22:24:58 +08:00
|
|
|
|
ep_ctx->ep_info2 |= cpu_to_le32(ERROR_COUNT(0));
|
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
|
|
|
|
|
|
|
|
|
/* Set the max packet size and max burst */
|
2013-05-08 23:18:05 +08:00
|
|
|
|
max_packet = GET_MAX_PACKET(usb_endpoint_maxp(&ep->desc));
|
|
|
|
|
max_burst = 0;
|
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
|
|
|
|
switch (udev->speed) {
|
|
|
|
|
case USB_SPEED_SUPER:
|
2009-04-28 10:58:50 +08:00
|
|
|
|
/* dig out max burst from ep companion desc */
|
2013-05-08 23:18:05 +08:00
|
|
|
|
max_burst = ep->ss_ep_comp.bMaxBurst;
|
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;
|
|
|
|
|
case USB_SPEED_HIGH:
|
2013-05-08 23:18:05 +08:00
|
|
|
|
/* Some devices get this wrong */
|
|
|
|
|
if (usb_endpoint_xfer_bulk(&ep->desc))
|
|
|
|
|
max_packet = 512;
|
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
|
|
|
|
/* bits 11:12 specify the number of additional transaction
|
|
|
|
|
* opportunities per microframe (USB 2.0, section 9.6.6)
|
|
|
|
|
*/
|
|
|
|
|
if (usb_endpoint_xfer_isoc(&ep->desc) ||
|
|
|
|
|
usb_endpoint_xfer_int(&ep->desc)) {
|
2011-08-23 18:12:03 +08:00
|
|
|
|
max_burst = (usb_endpoint_maxp(&ep->desc)
|
2011-03-29 10:40:46 +08:00
|
|
|
|
& 0x1800) >> 11;
|
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
|
|
|
|
}
|
2013-05-08 23:18:05 +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 USB_SPEED_FULL:
|
|
|
|
|
case USB_SPEED_LOW:
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
BUG();
|
|
|
|
|
}
|
2013-05-08 23:18:05 +08:00
|
|
|
|
ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet) |
|
|
|
|
|
MAX_BURST(max_burst));
|
USB: xhci: properly set endpoint context fields for periodic eps.
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval. The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload). This is used by the hardware for bandwidth
management and scheduling of packets.
For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor). Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.
For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).
For FS/LS devices, this is just the max packet size.
The other thing we must set in the endpoint context is the Average TRB
Length. This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD. This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.
It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together. Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD. The Linux
xHCI driver does not use Event Data TRBs.
In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately. For now,
we set it to the same number as the Max ESIT payload.
The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-16 23:07:27 +08:00
|
|
|
|
max_esit_payload = xhci_get_max_esit_payload(xhci, udev, ep);
|
2011-03-29 10:40:46 +08:00
|
|
|
|
ep_ctx->tx_info = cpu_to_le32(MAX_ESIT_PAYLOAD_FOR_EP(max_esit_payload));
|
USB: xhci: properly set endpoint context fields for periodic eps.
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval. The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload). This is used by the hardware for bandwidth
management and scheduling of packets.
For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor). Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.
For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).
For FS/LS devices, this is just the max packet size.
The other thing we must set in the endpoint context is the Average TRB
Length. This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD. This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.
It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together. Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD. The Linux
xHCI driver does not use Event Data TRBs.
In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately. For now,
we set it to the same number as the Max ESIT payload.
The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-16 23:07:27 +08:00
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* XXX no idea how to calculate the average TRB buffer length for bulk
|
|
|
|
|
* endpoints, as the driver gives us no clue how big each scatter gather
|
|
|
|
|
* list entry (or buffer) is going to be.
|
|
|
|
|
*
|
|
|
|
|
* For isochronous and interrupt endpoints, we set it to the max
|
|
|
|
|
* available, until we have new API in the USB core to allow drivers to
|
|
|
|
|
* declare how much bandwidth they actually need.
|
|
|
|
|
*
|
|
|
|
|
* Normally, it would be calculated by taking the total of the buffer
|
|
|
|
|
* lengths in the TD and then dividing by the number of TRBs in a TD,
|
|
|
|
|
* including link TRBs, No-op TRBs, and Event data TRBs. Since we don't
|
|
|
|
|
* use Event Data TRBs, and we don't chain in a link TRB on short
|
|
|
|
|
* transfers, we're basically dividing by 1.
|
2011-05-05 18:13:58 +08:00
|
|
|
|
*
|
|
|
|
|
* xHCI 1.0 specification indicates that the Average TRB Length should
|
|
|
|
|
* be set to 8 for control endpoints.
|
USB: xhci: properly set endpoint context fields for periodic eps.
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval. The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload). This is used by the hardware for bandwidth
management and scheduling of packets.
For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor). Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.
For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).
For FS/LS devices, this is just the max packet size.
The other thing we must set in the endpoint context is the Average TRB
Length. This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD. This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.
It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together. Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD. The Linux
xHCI driver does not use Event Data TRBs.
In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately. For now,
we set it to the same number as the Max ESIT payload.
The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-16 23:07:27 +08:00
|
|
|
|
*/
|
2011-05-05 18:13:58 +08:00
|
|
|
|
if (usb_endpoint_xfer_control(&ep->desc) && xhci->hci_version == 0x100)
|
|
|
|
|
ep_ctx->tx_info |= cpu_to_le32(AVG_TRB_LENGTH_FOR_EP(8));
|
|
|
|
|
else
|
|
|
|
|
ep_ctx->tx_info |=
|
|
|
|
|
cpu_to_le32(AVG_TRB_LENGTH_FOR_EP(max_esit_payload));
|
USB: xhci: properly set endpoint context fields for periodic eps.
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval. The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload). This is used by the hardware for bandwidth
management and scheduling of packets.
For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor). Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.
For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).
For FS/LS devices, this is just the max packet size.
The other thing we must set in the endpoint context is the Average TRB
Length. This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD. This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.
It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together. Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD. The Linux
xHCI driver does not use Event Data TRBs.
In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately. For now,
we set it to the same number as the Max ESIT payload.
The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-16 23:07:27 +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
|
|
|
|
/* FIXME Debug endpoint context */
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void xhci_endpoint_zero(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
|
struct usb_host_endpoint *ep)
|
|
|
|
|
{
|
|
|
|
|
unsigned int ep_index;
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
|
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&ep->desc);
|
2009-07-28 03:05:15 +08:00
|
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index);
|
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
|
|
|
|
|
|
|
|
|
ep_ctx->ep_info = 0;
|
|
|
|
|
ep_ctx->ep_info2 = 0;
|
2009-07-28 03:03:31 +08:00
|
|
|
|
ep_ctx->deq = 0;
|
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
|
|
|
|
ep_ctx->tx_info = 0;
|
|
|
|
|
/* Don't free the endpoint ring until the set interface or configuration
|
|
|
|
|
* request succeeds.
|
|
|
|
|
*/
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-03 02:05:48 +08:00
|
|
|
|
void xhci_clear_endpoint_bw_info(struct xhci_bw_info *bw_info)
|
|
|
|
|
{
|
|
|
|
|
bw_info->ep_interval = 0;
|
|
|
|
|
bw_info->mult = 0;
|
|
|
|
|
bw_info->num_packets = 0;
|
|
|
|
|
bw_info->max_packet_size = 0;
|
|
|
|
|
bw_info->type = 0;
|
|
|
|
|
bw_info->max_esit_payload = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void xhci_update_bw_info(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_container_ctx *in_ctx,
|
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx,
|
|
|
|
|
struct xhci_virt_device *virt_dev)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_bw_info *bw_info;
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
|
unsigned int ep_type;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 1; i < 31; ++i) {
|
|
|
|
|
bw_info = &virt_dev->eps[i].bw_info;
|
|
|
|
|
|
|
|
|
|
/* We can't tell what endpoint type is being dropped, but
|
|
|
|
|
* unconditionally clearing the bandwidth info for non-periodic
|
|
|
|
|
* endpoints should be harmless because the info will never be
|
|
|
|
|
* set in the first place.
|
|
|
|
|
*/
|
|
|
|
|
if (!EP_IS_ADDED(ctrl_ctx, i) && EP_IS_DROPPED(ctrl_ctx, i)) {
|
|
|
|
|
/* Dropped endpoint */
|
|
|
|
|
xhci_clear_endpoint_bw_info(bw_info);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (EP_IS_ADDED(ctrl_ctx, i)) {
|
|
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, in_ctx, i);
|
|
|
|
|
ep_type = CTX_TO_EP_TYPE(le32_to_cpu(ep_ctx->ep_info2));
|
|
|
|
|
|
|
|
|
|
/* Ignore non-periodic endpoints */
|
|
|
|
|
if (ep_type != ISOC_OUT_EP && ep_type != INT_OUT_EP &&
|
|
|
|
|
ep_type != ISOC_IN_EP &&
|
|
|
|
|
ep_type != INT_IN_EP)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* Added or changed endpoint */
|
|
|
|
|
bw_info->ep_interval = CTX_TO_EP_INTERVAL(
|
|
|
|
|
le32_to_cpu(ep_ctx->ep_info));
|
2011-09-14 07:41:12 +08:00
|
|
|
|
/* Number of packets and mult are zero-based in the
|
|
|
|
|
* input context, but we want one-based for the
|
|
|
|
|
* interval table.
|
2011-09-03 02:05:48 +08:00
|
|
|
|
*/
|
2011-09-14 07:41:12 +08:00
|
|
|
|
bw_info->mult = CTX_TO_EP_MULT(
|
|
|
|
|
le32_to_cpu(ep_ctx->ep_info)) + 1;
|
2011-09-03 02:05:48 +08:00
|
|
|
|
bw_info->num_packets = CTX_TO_MAX_BURST(
|
|
|
|
|
le32_to_cpu(ep_ctx->ep_info2)) + 1;
|
|
|
|
|
bw_info->max_packet_size = MAX_PACKET_DECODED(
|
|
|
|
|
le32_to_cpu(ep_ctx->ep_info2));
|
|
|
|
|
bw_info->type = ep_type;
|
|
|
|
|
bw_info->max_esit_payload = CTX_TO_MAX_ESIT_PAYLOAD(
|
|
|
|
|
le32_to_cpu(ep_ctx->tx_info));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-08-08 05:04:43 +08:00
|
|
|
|
/* Copy output xhci_ep_ctx to the input xhci_ep_ctx copy.
|
|
|
|
|
* Useful when you want to change one particular aspect of the endpoint and then
|
|
|
|
|
* issue a configure endpoint command.
|
|
|
|
|
*/
|
|
|
|
|
void xhci_endpoint_copy(struct xhci_hcd *xhci,
|
2009-09-05 01:53:13 +08:00
|
|
|
|
struct xhci_container_ctx *in_ctx,
|
|
|
|
|
struct xhci_container_ctx *out_ctx,
|
|
|
|
|
unsigned int ep_index)
|
2009-08-08 05:04:43 +08:00
|
|
|
|
{
|
|
|
|
|
struct xhci_ep_ctx *out_ep_ctx;
|
|
|
|
|
struct xhci_ep_ctx *in_ep_ctx;
|
|
|
|
|
|
2009-09-05 01:53:13 +08:00
|
|
|
|
out_ep_ctx = xhci_get_ep_ctx(xhci, out_ctx, ep_index);
|
|
|
|
|
in_ep_ctx = xhci_get_ep_ctx(xhci, in_ctx, ep_index);
|
2009-08-08 05:04:43 +08:00
|
|
|
|
|
|
|
|
|
in_ep_ctx->ep_info = out_ep_ctx->ep_info;
|
|
|
|
|
in_ep_ctx->ep_info2 = out_ep_ctx->ep_info2;
|
|
|
|
|
in_ep_ctx->deq = out_ep_ctx->deq;
|
|
|
|
|
in_ep_ctx->tx_info = out_ep_ctx->tx_info;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Copy output xhci_slot_ctx to the input xhci_slot_ctx.
|
|
|
|
|
* Useful when you want to change one particular aspect of the endpoint and then
|
|
|
|
|
* issue a configure endpoint command. Only the context entries field matters,
|
|
|
|
|
* but we'll copy the whole thing anyway.
|
|
|
|
|
*/
|
2009-09-05 01:53:13 +08:00
|
|
|
|
void xhci_slot_copy(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_container_ctx *in_ctx,
|
|
|
|
|
struct xhci_container_ctx *out_ctx)
|
2009-08-08 05:04:43 +08:00
|
|
|
|
{
|
|
|
|
|
struct xhci_slot_ctx *in_slot_ctx;
|
|
|
|
|
struct xhci_slot_ctx *out_slot_ctx;
|
|
|
|
|
|
2009-09-05 01:53:13 +08:00
|
|
|
|
in_slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
|
|
|
|
|
out_slot_ctx = xhci_get_slot_ctx(xhci, out_ctx);
|
2009-08-08 05:04:43 +08:00
|
|
|
|
|
|
|
|
|
in_slot_ctx->dev_info = out_slot_ctx->dev_info;
|
|
|
|
|
in_slot_ctx->dev_info2 = out_slot_ctx->dev_info2;
|
|
|
|
|
in_slot_ctx->tt_info = out_slot_ctx->tt_info;
|
|
|
|
|
in_slot_ctx->dev_state = out_slot_ctx->dev_state;
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-28 03:05:03 +08:00
|
|
|
|
/* Set up the scratchpad buffer array and scratchpad buffers, if needed. */
|
|
|
|
|
static int scratchpad_alloc(struct xhci_hcd *xhci, gfp_t flags)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
struct device *dev = xhci_to_hcd(xhci)->self.controller;
|
|
|
|
|
int num_sp = HCS_MAX_SCRATCHPAD(xhci->hcs_params2);
|
|
|
|
|
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Allocating %d scratchpad buffers", num_sp);
|
2009-07-28 03:05:03 +08:00
|
|
|
|
|
|
|
|
|
if (!num_sp)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
xhci->scratchpad = kzalloc(sizeof(*xhci->scratchpad), flags);
|
|
|
|
|
if (!xhci->scratchpad)
|
|
|
|
|
goto fail_sp;
|
|
|
|
|
|
2011-09-24 05:19:59 +08:00
|
|
|
|
xhci->scratchpad->sp_array = dma_alloc_coherent(dev,
|
2009-07-28 03:05:03 +08:00
|
|
|
|
num_sp * sizeof(u64),
|
2011-09-24 05:19:59 +08:00
|
|
|
|
&xhci->scratchpad->sp_dma, flags);
|
2009-07-28 03:05:03 +08:00
|
|
|
|
if (!xhci->scratchpad->sp_array)
|
|
|
|
|
goto fail_sp2;
|
|
|
|
|
|
|
|
|
|
xhci->scratchpad->sp_buffers = kzalloc(sizeof(void *) * num_sp, flags);
|
|
|
|
|
if (!xhci->scratchpad->sp_buffers)
|
|
|
|
|
goto fail_sp3;
|
|
|
|
|
|
|
|
|
|
xhci->scratchpad->sp_dma_buffers =
|
|
|
|
|
kzalloc(sizeof(dma_addr_t) * num_sp, flags);
|
|
|
|
|
|
|
|
|
|
if (!xhci->scratchpad->sp_dma_buffers)
|
|
|
|
|
goto fail_sp4;
|
|
|
|
|
|
2011-03-29 10:40:46 +08:00
|
|
|
|
xhci->dcbaa->dev_context_ptrs[0] = cpu_to_le64(xhci->scratchpad->sp_dma);
|
2009-07-28 03:05:03 +08:00
|
|
|
|
for (i = 0; i < num_sp; i++) {
|
|
|
|
|
dma_addr_t dma;
|
2011-09-24 05:19:59 +08:00
|
|
|
|
void *buf = dma_alloc_coherent(dev, xhci->page_size, &dma,
|
|
|
|
|
flags);
|
2009-07-28 03:05:03 +08:00
|
|
|
|
if (!buf)
|
|
|
|
|
goto fail_sp5;
|
|
|
|
|
|
|
|
|
|
xhci->scratchpad->sp_array[i] = dma;
|
|
|
|
|
xhci->scratchpad->sp_buffers[i] = buf;
|
|
|
|
|
xhci->scratchpad->sp_dma_buffers[i] = dma;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
fail_sp5:
|
|
|
|
|
for (i = i - 1; i >= 0; i--) {
|
2011-09-24 05:19:59 +08:00
|
|
|
|
dma_free_coherent(dev, xhci->page_size,
|
2009-07-28 03:05:03 +08:00
|
|
|
|
xhci->scratchpad->sp_buffers[i],
|
|
|
|
|
xhci->scratchpad->sp_dma_buffers[i]);
|
|
|
|
|
}
|
|
|
|
|
kfree(xhci->scratchpad->sp_dma_buffers);
|
|
|
|
|
|
|
|
|
|
fail_sp4:
|
|
|
|
|
kfree(xhci->scratchpad->sp_buffers);
|
|
|
|
|
|
|
|
|
|
fail_sp3:
|
2011-09-24 05:19:59 +08:00
|
|
|
|
dma_free_coherent(dev, num_sp * sizeof(u64),
|
2009-07-28 03:05:03 +08:00
|
|
|
|
xhci->scratchpad->sp_array,
|
|
|
|
|
xhci->scratchpad->sp_dma);
|
|
|
|
|
|
|
|
|
|
fail_sp2:
|
|
|
|
|
kfree(xhci->scratchpad);
|
|
|
|
|
xhci->scratchpad = NULL;
|
|
|
|
|
|
|
|
|
|
fail_sp:
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void scratchpad_free(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
int num_sp;
|
|
|
|
|
int i;
|
2013-11-15 09:18:08 +08:00
|
|
|
|
struct device *dev = xhci_to_hcd(xhci)->self.controller;
|
2009-07-28 03:05:03 +08:00
|
|
|
|
|
|
|
|
|
if (!xhci->scratchpad)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
num_sp = HCS_MAX_SCRATCHPAD(xhci->hcs_params2);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < num_sp; i++) {
|
2013-11-15 09:18:08 +08:00
|
|
|
|
dma_free_coherent(dev, xhci->page_size,
|
2009-07-28 03:05:03 +08:00
|
|
|
|
xhci->scratchpad->sp_buffers[i],
|
|
|
|
|
xhci->scratchpad->sp_dma_buffers[i]);
|
|
|
|
|
}
|
|
|
|
|
kfree(xhci->scratchpad->sp_dma_buffers);
|
|
|
|
|
kfree(xhci->scratchpad->sp_buffers);
|
2013-11-15 09:18:08 +08:00
|
|
|
|
dma_free_coherent(dev, num_sp * sizeof(u64),
|
2009-07-28 03:05:03 +08:00
|
|
|
|
xhci->scratchpad->sp_array,
|
|
|
|
|
xhci->scratchpad->sp_dma);
|
|
|
|
|
kfree(xhci->scratchpad);
|
|
|
|
|
xhci->scratchpad = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-05 01:53:13 +08:00
|
|
|
|
struct xhci_command *xhci_alloc_command(struct xhci_hcd *xhci,
|
2009-12-10 07:59:03 +08:00
|
|
|
|
bool allocate_in_ctx, bool allocate_completion,
|
|
|
|
|
gfp_t mem_flags)
|
2009-09-05 01:53:13 +08:00
|
|
|
|
{
|
|
|
|
|
struct xhci_command *command;
|
|
|
|
|
|
|
|
|
|
command = kzalloc(sizeof(*command), mem_flags);
|
|
|
|
|
if (!command)
|
|
|
|
|
return NULL;
|
|
|
|
|
|
2009-12-10 07:59:03 +08:00
|
|
|
|
if (allocate_in_ctx) {
|
|
|
|
|
command->in_ctx =
|
|
|
|
|
xhci_alloc_container_ctx(xhci, XHCI_CTX_TYPE_INPUT,
|
|
|
|
|
mem_flags);
|
|
|
|
|
if (!command->in_ctx) {
|
|
|
|
|
kfree(command);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2009-11-21 19:51:47 +08:00
|
|
|
|
}
|
2009-09-05 01:53:13 +08:00
|
|
|
|
|
|
|
|
|
if (allocate_completion) {
|
|
|
|
|
command->completion =
|
|
|
|
|
kzalloc(sizeof(struct completion), mem_flags);
|
|
|
|
|
if (!command->completion) {
|
|
|
|
|
xhci_free_container_ctx(xhci, command->in_ctx);
|
2009-11-21 19:51:47 +08:00
|
|
|
|
kfree(command);
|
2009-09-05 01:53:13 +08:00
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
init_completion(command->completion);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
command->status = 0;
|
|
|
|
|
INIT_LIST_HEAD(&command->cmd_list);
|
|
|
|
|
return command;
|
|
|
|
|
}
|
|
|
|
|
|
2010-07-23 06:23:31 +08:00
|
|
|
|
void xhci_urb_free_priv(struct xhci_hcd *xhci, struct urb_priv *urb_priv)
|
|
|
|
|
{
|
2011-09-03 02:05:57 +08:00
|
|
|
|
if (urb_priv) {
|
|
|
|
|
kfree(urb_priv->td[0]);
|
|
|
|
|
kfree(urb_priv);
|
2010-07-23 06:23:31 +08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-05 01:53:13 +08:00
|
|
|
|
void xhci_free_command(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_command *command)
|
|
|
|
|
{
|
|
|
|
|
xhci_free_container_ctx(xhci,
|
|
|
|
|
command->in_ctx);
|
|
|
|
|
kfree(command->completion);
|
|
|
|
|
kfree(command);
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 10:52:28 +08:00
|
|
|
|
void xhci_mem_cleanup(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
2013-11-15 09:18:08 +08:00
|
|
|
|
struct device *dev = xhci_to_hcd(xhci)->self.controller;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
int size;
|
2012-06-01 16:06:24 +08:00
|
|
|
|
int i, j, num_ports;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-09 00:26:03 +08:00
|
|
|
|
del_timer_sync(&xhci->cmd_timer);
|
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
|
/* Free the Event Ring Segment Table and the actual Event Ring */
|
|
|
|
|
size = sizeof(struct xhci_erst_entry)*(xhci->erst.num_entries);
|
|
|
|
|
if (xhci->erst.entries)
|
2013-11-15 09:18:08 +08:00
|
|
|
|
dma_free_coherent(dev, size,
|
2009-04-28 10:52:34 +08:00
|
|
|
|
xhci->erst.entries, xhci->erst.erst_dma_addr);
|
|
|
|
|
xhci->erst.entries = NULL;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed ERST");
|
2009-04-28 10:52:34 +08:00
|
|
|
|
if (xhci->event_ring)
|
|
|
|
|
xhci_ring_free(xhci, xhci->event_ring);
|
|
|
|
|
xhci->event_ring = NULL;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed event ring");
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
2012-05-08 22:32:03 +08:00
|
|
|
|
if (xhci->lpm_command)
|
|
|
|
|
xhci_free_command(xhci, xhci->lpm_command);
|
2014-09-11 18:55:49 +08:00
|
|
|
|
xhci->lpm_command = NULL;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
if (xhci->cmd_ring)
|
|
|
|
|
xhci_ring_free(xhci, xhci->cmd_ring);
|
|
|
|
|
xhci->cmd_ring = NULL;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed command ring");
|
2014-05-09 00:26:01 +08:00
|
|
|
|
xhci_cleanup_command_queue(xhci);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
2014-05-29 04:51:13 +08:00
|
|
|
|
num_ports = HCS_MAX_PORTS(xhci->hcs_params1);
|
2014-09-11 18:55:48 +08:00
|
|
|
|
for (i = 0; i < num_ports && xhci->rh_bw; i++) {
|
2014-05-29 04:51:13 +08:00
|
|
|
|
struct xhci_interval_bw_table *bwt = &xhci->rh_bw[i].bw_table;
|
|
|
|
|
for (j = 0; j < XHCI_MAX_INTERVAL; j++) {
|
|
|
|
|
struct list_head *ep = &bwt->interval_bw[j].endpoints;
|
|
|
|
|
while (!list_empty(ep))
|
|
|
|
|
list_del_init(ep->next);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
|
for (i = 1; i < MAX_HC_SLOTS; ++i)
|
|
|
|
|
xhci_free_virt_device(xhci, i);
|
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
|
if (xhci->segment_pool)
|
|
|
|
|
dma_pool_destroy(xhci->segment_pool);
|
|
|
|
|
xhci->segment_pool = NULL;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed segment pool");
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
|
|
|
|
if (xhci->device_pool)
|
|
|
|
|
dma_pool_destroy(xhci->device_pool);
|
|
|
|
|
xhci->device_pool = NULL;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed device context pool");
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
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
|
|
|
|
if (xhci->small_streams_pool)
|
|
|
|
|
dma_pool_destroy(xhci->small_streams_pool);
|
|
|
|
|
xhci->small_streams_pool = NULL;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Freed small stream array pool");
|
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
|
|
|
|
|
|
|
|
|
if (xhci->medium_streams_pool)
|
|
|
|
|
dma_pool_destroy(xhci->medium_streams_pool);
|
|
|
|
|
xhci->medium_streams_pool = NULL;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Freed medium stream array pool");
|
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
|
|
|
|
|
2009-04-28 10:53:42 +08:00
|
|
|
|
if (xhci->dcbaa)
|
2013-11-15 09:18:08 +08:00
|
|
|
|
dma_free_coherent(dev, sizeof(*xhci->dcbaa),
|
2009-04-28 10:53:42 +08:00
|
|
|
|
xhci->dcbaa, xhci->dcbaa->dma);
|
|
|
|
|
xhci->dcbaa = NULL;
|
2009-04-28 10:57:38 +08:00
|
|
|
|
|
2009-11-05 03:22:19 +08:00
|
|
|
|
scratchpad_free(xhci);
|
2010-10-27 07:47:13 +08:00
|
|
|
|
|
2013-04-10 02:33:31 +08:00
|
|
|
|
if (!xhci->rh_bw)
|
|
|
|
|
goto no_bw;
|
|
|
|
|
|
2012-06-01 16:06:24 +08:00
|
|
|
|
for (i = 0; i < num_ports; i++) {
|
|
|
|
|
struct xhci_tt_bw_info *tt, *n;
|
|
|
|
|
list_for_each_entry_safe(tt, n, &xhci->rh_bw[i].tts, tt_list) {
|
|
|
|
|
list_del(&tt->tt_list);
|
|
|
|
|
kfree(tt);
|
|
|
|
|
}
|
2012-05-10 16:19:21 +08:00
|
|
|
|
}
|
|
|
|
|
|
2013-04-10 02:33:31 +08:00
|
|
|
|
no_bw:
|
2013-11-07 15:19:45 +08:00
|
|
|
|
xhci->cmd_ring_reserved_trbs = 0;
|
2010-10-27 07:47:13 +08:00
|
|
|
|
xhci->num_usb2_ports = 0;
|
|
|
|
|
xhci->num_usb3_ports = 0;
|
2012-05-10 16:19:21 +08:00
|
|
|
|
xhci->num_active_eps = 0;
|
2010-10-27 07:47:13 +08:00
|
|
|
|
kfree(xhci->usb2_ports);
|
|
|
|
|
kfree(xhci->usb3_ports);
|
|
|
|
|
kfree(xhci->port_array);
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
|
kfree(xhci->rh_bw);
|
2013-05-23 22:14:28 +08:00
|
|
|
|
kfree(xhci->ext_caps);
|
2010-10-27 07:47:13 +08:00
|
|
|
|
|
2009-04-28 10:52:28 +08:00
|
|
|
|
xhci->page_size = 0;
|
|
|
|
|
xhci->page_shift = 0;
|
2010-12-16 04:47:14 +08:00
|
|
|
|
xhci->bus_state[0].bus_suspended = 0;
|
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->bus_state[1].bus_suspended = 0;
|
2009-04-28 10:52:28 +08:00
|
|
|
|
}
|
|
|
|
|
|
2009-11-10 05:35:23 +08:00
|
|
|
|
static int xhci_test_trb_in_td(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_segment *input_seg,
|
|
|
|
|
union xhci_trb *start_trb,
|
|
|
|
|
union xhci_trb *end_trb,
|
|
|
|
|
dma_addr_t input_dma,
|
|
|
|
|
struct xhci_segment *result_seg,
|
|
|
|
|
char *test_name, int test_number)
|
|
|
|
|
{
|
|
|
|
|
unsigned long long start_dma;
|
|
|
|
|
unsigned long long end_dma;
|
|
|
|
|
struct xhci_segment *seg;
|
|
|
|
|
|
|
|
|
|
start_dma = xhci_trb_virt_to_dma(input_seg, start_trb);
|
|
|
|
|
end_dma = xhci_trb_virt_to_dma(input_seg, end_trb);
|
|
|
|
|
|
2014-08-20 21:41:51 +08:00
|
|
|
|
seg = trb_in_td(xhci, input_seg, start_trb, end_trb, input_dma, false);
|
2009-11-10 05:35:23 +08:00
|
|
|
|
if (seg != result_seg) {
|
|
|
|
|
xhci_warn(xhci, "WARN: %s TRB math test %d failed!\n",
|
|
|
|
|
test_name, test_number);
|
|
|
|
|
xhci_warn(xhci, "Tested TRB math w/ seg %p and "
|
|
|
|
|
"input DMA 0x%llx\n",
|
|
|
|
|
input_seg,
|
|
|
|
|
(unsigned long long) input_dma);
|
|
|
|
|
xhci_warn(xhci, "starting TRB %p (0x%llx DMA), "
|
|
|
|
|
"ending TRB %p (0x%llx DMA)\n",
|
|
|
|
|
start_trb, start_dma,
|
|
|
|
|
end_trb, end_dma);
|
|
|
|
|
xhci_warn(xhci, "Expected seg %p, got seg %p\n",
|
|
|
|
|
result_seg, seg);
|
2014-08-20 21:41:51 +08:00
|
|
|
|
trb_in_td(xhci, input_seg, start_trb, end_trb, input_dma,
|
|
|
|
|
true);
|
2009-11-10 05:35:23 +08:00
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* TRB math checks for xhci_trb_in_td(), using the command and event rings. */
|
|
|
|
|
static int xhci_check_trb_in_td_math(struct xhci_hcd *xhci, gfp_t mem_flags)
|
|
|
|
|
{
|
|
|
|
|
struct {
|
|
|
|
|
dma_addr_t input_dma;
|
|
|
|
|
struct xhci_segment *result_seg;
|
|
|
|
|
} simple_test_vector [] = {
|
|
|
|
|
/* A zeroed DMA field should fail */
|
|
|
|
|
{ 0, NULL },
|
|
|
|
|
/* One TRB before the ring start should fail */
|
|
|
|
|
{ xhci->event_ring->first_seg->dma - 16, NULL },
|
|
|
|
|
/* One byte before the ring start should fail */
|
|
|
|
|
{ xhci->event_ring->first_seg->dma - 1, NULL },
|
|
|
|
|
/* Starting TRB should succeed */
|
|
|
|
|
{ xhci->event_ring->first_seg->dma, xhci->event_ring->first_seg },
|
|
|
|
|
/* Ending TRB should succeed */
|
|
|
|
|
{ xhci->event_ring->first_seg->dma + (TRBS_PER_SEGMENT - 1)*16,
|
|
|
|
|
xhci->event_ring->first_seg },
|
|
|
|
|
/* One byte after the ring end should fail */
|
|
|
|
|
{ xhci->event_ring->first_seg->dma + (TRBS_PER_SEGMENT - 1)*16 + 1, NULL },
|
|
|
|
|
/* One TRB after the ring end should fail */
|
|
|
|
|
{ xhci->event_ring->first_seg->dma + (TRBS_PER_SEGMENT)*16, NULL },
|
|
|
|
|
/* An address of all ones should fail */
|
|
|
|
|
{ (dma_addr_t) (~0), NULL },
|
|
|
|
|
};
|
|
|
|
|
struct {
|
|
|
|
|
struct xhci_segment *input_seg;
|
|
|
|
|
union xhci_trb *start_trb;
|
|
|
|
|
union xhci_trb *end_trb;
|
|
|
|
|
dma_addr_t input_dma;
|
|
|
|
|
struct xhci_segment *result_seg;
|
|
|
|
|
} complex_test_vector [] = {
|
|
|
|
|
/* Test feeding a valid DMA address from a different ring */
|
|
|
|
|
{ .input_seg = xhci->event_ring->first_seg,
|
|
|
|
|
.start_trb = xhci->event_ring->first_seg->trbs,
|
|
|
|
|
.end_trb = &xhci->event_ring->first_seg->trbs[TRBS_PER_SEGMENT - 1],
|
|
|
|
|
.input_dma = xhci->cmd_ring->first_seg->dma,
|
|
|
|
|
.result_seg = NULL,
|
|
|
|
|
},
|
|
|
|
|
/* Test feeding a valid end TRB from a different ring */
|
|
|
|
|
{ .input_seg = xhci->event_ring->first_seg,
|
|
|
|
|
.start_trb = xhci->event_ring->first_seg->trbs,
|
|
|
|
|
.end_trb = &xhci->cmd_ring->first_seg->trbs[TRBS_PER_SEGMENT - 1],
|
|
|
|
|
.input_dma = xhci->cmd_ring->first_seg->dma,
|
|
|
|
|
.result_seg = NULL,
|
|
|
|
|
},
|
|
|
|
|
/* Test feeding a valid start and end TRB from a different ring */
|
|
|
|
|
{ .input_seg = xhci->event_ring->first_seg,
|
|
|
|
|
.start_trb = xhci->cmd_ring->first_seg->trbs,
|
|
|
|
|
.end_trb = &xhci->cmd_ring->first_seg->trbs[TRBS_PER_SEGMENT - 1],
|
|
|
|
|
.input_dma = xhci->cmd_ring->first_seg->dma,
|
|
|
|
|
.result_seg = NULL,
|
|
|
|
|
},
|
|
|
|
|
/* TRB in this ring, but after this TD */
|
|
|
|
|
{ .input_seg = xhci->event_ring->first_seg,
|
|
|
|
|
.start_trb = &xhci->event_ring->first_seg->trbs[0],
|
|
|
|
|
.end_trb = &xhci->event_ring->first_seg->trbs[3],
|
|
|
|
|
.input_dma = xhci->event_ring->first_seg->dma + 4*16,
|
|
|
|
|
.result_seg = NULL,
|
|
|
|
|
},
|
|
|
|
|
/* TRB in this ring, but before this TD */
|
|
|
|
|
{ .input_seg = xhci->event_ring->first_seg,
|
|
|
|
|
.start_trb = &xhci->event_ring->first_seg->trbs[3],
|
|
|
|
|
.end_trb = &xhci->event_ring->first_seg->trbs[6],
|
|
|
|
|
.input_dma = xhci->event_ring->first_seg->dma + 2*16,
|
|
|
|
|
.result_seg = NULL,
|
|
|
|
|
},
|
|
|
|
|
/* TRB in this ring, but after this wrapped TD */
|
|
|
|
|
{ .input_seg = xhci->event_ring->first_seg,
|
|
|
|
|
.start_trb = &xhci->event_ring->first_seg->trbs[TRBS_PER_SEGMENT - 3],
|
|
|
|
|
.end_trb = &xhci->event_ring->first_seg->trbs[1],
|
|
|
|
|
.input_dma = xhci->event_ring->first_seg->dma + 2*16,
|
|
|
|
|
.result_seg = NULL,
|
|
|
|
|
},
|
|
|
|
|
/* TRB in this ring, but before this wrapped TD */
|
|
|
|
|
{ .input_seg = xhci->event_ring->first_seg,
|
|
|
|
|
.start_trb = &xhci->event_ring->first_seg->trbs[TRBS_PER_SEGMENT - 3],
|
|
|
|
|
.end_trb = &xhci->event_ring->first_seg->trbs[1],
|
|
|
|
|
.input_dma = xhci->event_ring->first_seg->dma + (TRBS_PER_SEGMENT - 4)*16,
|
|
|
|
|
.result_seg = NULL,
|
|
|
|
|
},
|
|
|
|
|
/* TRB not in this ring, and we have a wrapped TD */
|
|
|
|
|
{ .input_seg = xhci->event_ring->first_seg,
|
|
|
|
|
.start_trb = &xhci->event_ring->first_seg->trbs[TRBS_PER_SEGMENT - 3],
|
|
|
|
|
.end_trb = &xhci->event_ring->first_seg->trbs[1],
|
|
|
|
|
.input_dma = xhci->cmd_ring->first_seg->dma + 2*16,
|
|
|
|
|
.result_seg = NULL,
|
|
|
|
|
},
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
unsigned int num_tests;
|
|
|
|
|
int i, ret;
|
|
|
|
|
|
2010-06-28 19:55:46 +08:00
|
|
|
|
num_tests = ARRAY_SIZE(simple_test_vector);
|
2009-11-10 05:35:23 +08:00
|
|
|
|
for (i = 0; i < num_tests; i++) {
|
|
|
|
|
ret = xhci_test_trb_in_td(xhci,
|
|
|
|
|
xhci->event_ring->first_seg,
|
|
|
|
|
xhci->event_ring->first_seg->trbs,
|
|
|
|
|
&xhci->event_ring->first_seg->trbs[TRBS_PER_SEGMENT - 1],
|
|
|
|
|
simple_test_vector[i].input_dma,
|
|
|
|
|
simple_test_vector[i].result_seg,
|
|
|
|
|
"Simple", i);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-28 19:55:46 +08:00
|
|
|
|
num_tests = ARRAY_SIZE(complex_test_vector);
|
2009-11-10 05:35:23 +08:00
|
|
|
|
for (i = 0; i < num_tests; i++) {
|
|
|
|
|
ret = xhci_test_trb_in_td(xhci,
|
|
|
|
|
complex_test_vector[i].input_seg,
|
|
|
|
|
complex_test_vector[i].start_trb,
|
|
|
|
|
complex_test_vector[i].end_trb,
|
|
|
|
|
complex_test_vector[i].input_dma,
|
|
|
|
|
complex_test_vector[i].result_seg,
|
|
|
|
|
"Complex", i);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
xhci_dbg(xhci, "TRB math tests passed.\n");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2010-07-30 13:12:56 +08:00
|
|
|
|
static void xhci_set_hc_event_deq(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
u64 temp;
|
|
|
|
|
dma_addr_t deq;
|
|
|
|
|
|
|
|
|
|
deq = xhci_trb_virt_to_dma(xhci->event_ring->deq_seg,
|
|
|
|
|
xhci->event_ring->dequeue);
|
|
|
|
|
if (deq == 0 && !in_interrupt())
|
|
|
|
|
xhci_warn(xhci, "WARN something wrong with SW event ring "
|
|
|
|
|
"dequeue ptr.\n");
|
|
|
|
|
/* Update HC event ring dequeue pointer */
|
2014-01-31 05:27:49 +08:00
|
|
|
|
temp = xhci_read_64(xhci, &xhci->ir_set->erst_dequeue);
|
2010-07-30 13:12:56 +08:00
|
|
|
|
temp &= ERST_PTR_MASK;
|
|
|
|
|
/* Don't clear the EHB bit (which is RW1C) because
|
|
|
|
|
* there might be more events to service.
|
|
|
|
|
*/
|
|
|
|
|
temp &= ~ERST_EHB;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Write event ring dequeue pointer, "
|
|
|
|
|
"preserving EHB bit");
|
2014-01-30 06:02:00 +08:00
|
|
|
|
xhci_write_64(xhci, ((u64) deq & (u64) ~ERST_PTR_MASK) | temp,
|
2010-07-30 13:12:56 +08:00
|
|
|
|
&xhci->ir_set->erst_dequeue);
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-27 07:47:13 +08:00
|
|
|
|
static void xhci_add_in_port(struct xhci_hcd *xhci, unsigned int num_ports,
|
2013-05-23 22:14:28 +08:00
|
|
|
|
__le32 __iomem *addr, u8 major_revision, int max_caps)
|
2010-10-27 07:47:13 +08:00
|
|
|
|
{
|
|
|
|
|
u32 temp, port_offset, port_count;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
if (major_revision > 0x03) {
|
|
|
|
|
xhci_warn(xhci, "Ignoring unknown port speed, "
|
|
|
|
|
"Ext Cap %p, revision = 0x%x\n",
|
|
|
|
|
addr, major_revision);
|
|
|
|
|
/* Ignoring port protocol we can't understand. FIXME */
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Port offset and count in the third dword, see section 7.2 */
|
2013-11-15 11:34:06 +08:00
|
|
|
|
temp = readl(addr + 2);
|
2010-10-27 07:47:13 +08:00
|
|
|
|
port_offset = XHCI_EXT_PORT_OFF(temp);
|
|
|
|
|
port_count = XHCI_EXT_PORT_COUNT(temp);
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Ext Cap %p, port offset = %u, "
|
|
|
|
|
"count = %u, revision = 0x%x",
|
2010-10-27 07:47:13 +08:00
|
|
|
|
addr, port_offset, port_count, major_revision);
|
|
|
|
|
/* Port count includes the current port offset */
|
|
|
|
|
if (port_offset == 0 || (port_offset + port_count - 1) > num_ports)
|
|
|
|
|
/* WTF? "Valid values are ‘1’ to MaxPorts" */
|
|
|
|
|
return;
|
2011-09-24 05:19:51 +08:00
|
|
|
|
|
2013-05-23 22:14:28 +08:00
|
|
|
|
/* cache usb2 port capabilities */
|
|
|
|
|
if (major_revision < 0x03 && xhci->num_ext_caps < max_caps)
|
|
|
|
|
xhci->ext_caps[xhci->num_ext_caps++] = temp;
|
|
|
|
|
|
2011-09-24 05:19:51 +08:00
|
|
|
|
/* Check the host's USB2 LPM capability */
|
|
|
|
|
if ((xhci->hci_version == 0x96) && (major_revision != 0x03) &&
|
|
|
|
|
(temp & XHCI_L1C)) {
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"xHCI 0.96: support USB2 software lpm");
|
2011-09-24 05:19:51 +08:00
|
|
|
|
xhci->sw_lpm_support = 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ((xhci->hci_version >= 0x100) && (major_revision != 0x03)) {
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"xHCI 1.0: support USB2 software lpm");
|
2011-09-24 05:19:51 +08:00
|
|
|
|
xhci->sw_lpm_support = 1;
|
|
|
|
|
if (temp & XHCI_HLC) {
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"xHCI 1.0: support USB2 hardware lpm");
|
2011-09-24 05:19:51 +08:00
|
|
|
|
xhci->hw_lpm_support = 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-27 07:47:13 +08:00
|
|
|
|
port_offset--;
|
|
|
|
|
for (i = port_offset; i < (port_offset + port_count); i++) {
|
|
|
|
|
/* Duplicate entry. Ignore the port if the revisions differ. */
|
|
|
|
|
if (xhci->port_array[i] != 0) {
|
|
|
|
|
xhci_warn(xhci, "Duplicate port entry, Ext Cap %p,"
|
|
|
|
|
" port %u\n", addr, i);
|
|
|
|
|
xhci_warn(xhci, "Port was marked as USB %u, "
|
|
|
|
|
"duplicated as USB %u\n",
|
|
|
|
|
xhci->port_array[i], major_revision);
|
|
|
|
|
/* Only adjust the roothub port counts if we haven't
|
|
|
|
|
* found a similar duplicate.
|
|
|
|
|
*/
|
|
|
|
|
if (xhci->port_array[i] != major_revision &&
|
2011-03-18 03:39:49 +08:00
|
|
|
|
xhci->port_array[i] != DUPLICATE_ENTRY) {
|
2010-10-27 07:47:13 +08:00
|
|
|
|
if (xhci->port_array[i] == 0x03)
|
|
|
|
|
xhci->num_usb3_ports--;
|
|
|
|
|
else
|
|
|
|
|
xhci->num_usb2_ports--;
|
2011-03-18 03:39:49 +08:00
|
|
|
|
xhci->port_array[i] = DUPLICATE_ENTRY;
|
2010-10-27 07:47:13 +08:00
|
|
|
|
}
|
|
|
|
|
/* FIXME: Should we disable the port? */
|
2010-12-10 02:29:00 +08:00
|
|
|
|
continue;
|
2010-10-27 07:47:13 +08:00
|
|
|
|
}
|
|
|
|
|
xhci->port_array[i] = major_revision;
|
|
|
|
|
if (major_revision == 0x03)
|
|
|
|
|
xhci->num_usb3_ports++;
|
|
|
|
|
else
|
|
|
|
|
xhci->num_usb2_ports++;
|
|
|
|
|
}
|
|
|
|
|
/* FIXME: Should we disable ports not in the Extended Capabilities? */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Scan the Extended Capabilities for the "Supported Protocol Capabilities" that
|
|
|
|
|
* specify what speeds each port is supposed to be. We can't count on the port
|
|
|
|
|
* speed bits in the PORTSC register being correct until a device is connected,
|
|
|
|
|
* but we need to set up the two fake roothubs with the correct number of USB
|
|
|
|
|
* 3.0 and USB 2.0 ports at host controller initialization time.
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_setup_port_arrays(struct xhci_hcd *xhci, gfp_t flags)
|
|
|
|
|
{
|
2013-05-23 22:14:28 +08:00
|
|
|
|
__le32 __iomem *addr, *tmp_addr;
|
|
|
|
|
u32 offset, tmp_offset;
|
2010-10-27 07:47:13 +08:00
|
|
|
|
unsigned int num_ports;
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
|
int i, j, port_index;
|
2013-05-23 22:14:28 +08:00
|
|
|
|
int cap_count = 0;
|
2010-10-27 07:47:13 +08:00
|
|
|
|
|
|
|
|
|
addr = &xhci->cap_regs->hcc_params;
|
2013-11-15 11:34:06 +08:00
|
|
|
|
offset = XHCI_HCC_EXT_CAPS(readl(addr));
|
2010-10-27 07:47:13 +08:00
|
|
|
|
if (offset == 0) {
|
|
|
|
|
xhci_err(xhci, "No Extended Capability registers, "
|
|
|
|
|
"unable to set up roothub.\n");
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
num_ports = HCS_MAX_PORTS(xhci->hcs_params1);
|
|
|
|
|
xhci->port_array = kzalloc(sizeof(*xhci->port_array)*num_ports, flags);
|
|
|
|
|
if (!xhci->port_array)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
|
xhci->rh_bw = kzalloc(sizeof(*xhci->rh_bw)*num_ports, flags);
|
|
|
|
|
if (!xhci->rh_bw)
|
|
|
|
|
return -ENOMEM;
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
|
for (i = 0; i < num_ports; i++) {
|
|
|
|
|
struct xhci_interval_bw_table *bw_table;
|
|
|
|
|
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
|
INIT_LIST_HEAD(&xhci->rh_bw[i].tts);
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
|
bw_table = &xhci->rh_bw[i].bw_table;
|
|
|
|
|
for (j = 0; j < XHCI_MAX_INTERVAL; j++)
|
|
|
|
|
INIT_LIST_HEAD(&bw_table->interval_bw[j].endpoints);
|
|
|
|
|
}
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
|
|
2010-10-27 07:47:13 +08:00
|
|
|
|
/*
|
|
|
|
|
* For whatever reason, the first capability offset is from the
|
|
|
|
|
* capability register base, not from the HCCPARAMS register.
|
|
|
|
|
* See section 5.3.6 for offset calculation.
|
|
|
|
|
*/
|
|
|
|
|
addr = &xhci->cap_regs->hc_capbase + offset;
|
2013-05-23 22:14:28 +08:00
|
|
|
|
|
|
|
|
|
tmp_addr = addr;
|
|
|
|
|
tmp_offset = offset;
|
|
|
|
|
|
|
|
|
|
/* count extended protocol capability entries for later caching */
|
|
|
|
|
do {
|
|
|
|
|
u32 cap_id;
|
2013-11-15 11:34:06 +08:00
|
|
|
|
cap_id = readl(tmp_addr);
|
2013-05-23 22:14:28 +08:00
|
|
|
|
if (XHCI_EXT_CAPS_ID(cap_id) == XHCI_EXT_CAPS_PROTOCOL)
|
|
|
|
|
cap_count++;
|
|
|
|
|
tmp_offset = XHCI_EXT_CAPS_NEXT(cap_id);
|
|
|
|
|
tmp_addr += tmp_offset;
|
|
|
|
|
} while (tmp_offset);
|
|
|
|
|
|
|
|
|
|
xhci->ext_caps = kzalloc(sizeof(*xhci->ext_caps) * cap_count, flags);
|
|
|
|
|
if (!xhci->ext_caps)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
2010-10-27 07:47:13 +08:00
|
|
|
|
while (1) {
|
|
|
|
|
u32 cap_id;
|
|
|
|
|
|
2013-11-15 11:34:06 +08:00
|
|
|
|
cap_id = readl(addr);
|
2010-10-27 07:47:13 +08:00
|
|
|
|
if (XHCI_EXT_CAPS_ID(cap_id) == XHCI_EXT_CAPS_PROTOCOL)
|
|
|
|
|
xhci_add_in_port(xhci, num_ports, addr,
|
2013-05-23 22:14:28 +08:00
|
|
|
|
(u8) XHCI_EXT_PORT_MAJOR(cap_id),
|
|
|
|
|
cap_count);
|
2010-10-27 07:47:13 +08:00
|
|
|
|
offset = XHCI_EXT_CAPS_NEXT(cap_id);
|
|
|
|
|
if (!offset || (xhci->num_usb2_ports + xhci->num_usb3_ports)
|
|
|
|
|
== num_ports)
|
|
|
|
|
break;
|
|
|
|
|
/*
|
|
|
|
|
* Once you're into the Extended Capabilities, the offset is
|
|
|
|
|
* always relative to the register holding the offset.
|
|
|
|
|
*/
|
|
|
|
|
addr += offset;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (xhci->num_usb2_ports == 0 && xhci->num_usb3_ports == 0) {
|
|
|
|
|
xhci_warn(xhci, "No ports on the roothubs?\n");
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Found %u USB 2.0 ports and %u USB 3.0 ports.",
|
2010-10-27 07:47:13 +08:00
|
|
|
|
xhci->num_usb2_ports, xhci->num_usb3_ports);
|
2010-11-24 02:42:22 +08:00
|
|
|
|
|
|
|
|
|
/* Place limits on the number of roothub ports so that the hub
|
|
|
|
|
* descriptors aren't longer than the USB core will allocate.
|
|
|
|
|
*/
|
|
|
|
|
if (xhci->num_usb3_ports > 15) {
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Limiting USB 3.0 roothub ports to 15.");
|
2010-11-24 02:42:22 +08:00
|
|
|
|
xhci->num_usb3_ports = 15;
|
|
|
|
|
}
|
|
|
|
|
if (xhci->num_usb2_ports > USB_MAXCHILDREN) {
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Limiting USB 2.0 roothub ports to %u.",
|
2010-11-24 02:42:22 +08:00
|
|
|
|
USB_MAXCHILDREN);
|
|
|
|
|
xhci->num_usb2_ports = USB_MAXCHILDREN;
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-27 07:47:13 +08:00
|
|
|
|
/*
|
|
|
|
|
* Note we could have all USB 3.0 ports, or all USB 2.0 ports.
|
|
|
|
|
* Not sure how the USB core will handle a hub with no ports...
|
|
|
|
|
*/
|
|
|
|
|
if (xhci->num_usb2_ports) {
|
|
|
|
|
xhci->usb2_ports = kmalloc(sizeof(*xhci->usb2_ports)*
|
|
|
|
|
xhci->num_usb2_ports, flags);
|
|
|
|
|
if (!xhci->usb2_ports)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
port_index = 0;
|
2010-12-10 02:29:00 +08:00
|
|
|
|
for (i = 0; i < num_ports; i++) {
|
|
|
|
|
if (xhci->port_array[i] == 0x03 ||
|
|
|
|
|
xhci->port_array[i] == 0 ||
|
2011-03-18 03:39:49 +08:00
|
|
|
|
xhci->port_array[i] == DUPLICATE_ENTRY)
|
2010-12-10 02:29:00 +08:00
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
xhci->usb2_ports[port_index] =
|
|
|
|
|
&xhci->op_regs->port_status_base +
|
|
|
|
|
NUM_PORT_REGS*i;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"USB 2.0 port at index %u, "
|
|
|
|
|
"addr = %p", i,
|
2010-12-10 02:29:00 +08:00
|
|
|
|
xhci->usb2_ports[port_index]);
|
|
|
|
|
port_index++;
|
2010-11-24 02:42:22 +08:00
|
|
|
|
if (port_index == xhci->num_usb2_ports)
|
|
|
|
|
break;
|
2010-12-10 02:29:00 +08:00
|
|
|
|
}
|
2010-10-27 07:47:13 +08:00
|
|
|
|
}
|
|
|
|
|
if (xhci->num_usb3_ports) {
|
|
|
|
|
xhci->usb3_ports = kmalloc(sizeof(*xhci->usb3_ports)*
|
|
|
|
|
xhci->num_usb3_ports, flags);
|
|
|
|
|
if (!xhci->usb3_ports)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
port_index = 0;
|
|
|
|
|
for (i = 0; i < num_ports; i++)
|
|
|
|
|
if (xhci->port_array[i] == 0x03) {
|
|
|
|
|
xhci->usb3_ports[port_index] =
|
|
|
|
|
&xhci->op_regs->port_status_base +
|
|
|
|
|
NUM_PORT_REGS*i;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"USB 3.0 port at index %u, "
|
|
|
|
|
"addr = %p", i,
|
2010-10-27 07:47:13 +08:00
|
|
|
|
xhci->usb3_ports[port_index]);
|
|
|
|
|
port_index++;
|
2010-11-24 02:42:22 +08:00
|
|
|
|
if (port_index == xhci->num_usb3_ports)
|
|
|
|
|
break;
|
2010-10-27 07:47:13 +08:00
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2009-11-10 05:35:23 +08:00
|
|
|
|
|
2009-04-28 10:52:28 +08:00
|
|
|
|
int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
|
|
|
|
|
{
|
2009-04-28 10:52:34 +08:00
|
|
|
|
dma_addr_t dma;
|
|
|
|
|
struct device *dev = xhci_to_hcd(xhci)->self.controller;
|
2009-04-28 10:52:28 +08:00
|
|
|
|
unsigned int val, val2;
|
2009-07-28 03:03:31 +08:00
|
|
|
|
u64 val_64;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
struct xhci_segment *seg;
|
2011-11-12 06:57:33 +08:00
|
|
|
|
u32 page_size, temp;
|
2009-04-28 10:52:28 +08:00
|
|
|
|
int i;
|
|
|
|
|
|
2014-05-09 00:26:01 +08:00
|
|
|
|
INIT_LIST_HEAD(&xhci->cmd_list);
|
2013-04-05 01:32:13 +08:00
|
|
|
|
|
2013-11-15 11:34:06 +08:00
|
|
|
|
page_size = readl(&xhci->op_regs->page_size);
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Supported page size register = 0x%x", page_size);
|
2009-04-28 10:52:28 +08:00
|
|
|
|
for (i = 0; i < 16; i++) {
|
|
|
|
|
if ((0x1 & page_size) != 0)
|
|
|
|
|
break;
|
|
|
|
|
page_size = page_size >> 1;
|
|
|
|
|
}
|
|
|
|
|
if (i < 16)
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Supported page size of %iK", (1 << (i+12)) / 1024);
|
2009-04-28 10:52:28 +08:00
|
|
|
|
else
|
|
|
|
|
xhci_warn(xhci, "WARN: no supported page size\n");
|
|
|
|
|
/* Use 4K pages, since that's common and the minimum the HC supports */
|
|
|
|
|
xhci->page_shift = 12;
|
|
|
|
|
xhci->page_size = 1 << xhci->page_shift;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"HCD page size set to %iK", xhci->page_size / 1024);
|
2009-04-28 10:52:28 +08:00
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Program the Number of Device Slots Enabled field in the CONFIG
|
|
|
|
|
* register with the max value of slots the HC can handle.
|
|
|
|
|
*/
|
2013-11-15 11:34:06 +08:00
|
|
|
|
val = HCS_MAX_SLOTS(readl(&xhci->cap_regs->hcs_params1));
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// xHC can handle at most %d device slots.", val);
|
2013-11-15 11:34:06 +08:00
|
|
|
|
val2 = readl(&xhci->op_regs->config_reg);
|
2009-04-28 10:52:28 +08:00
|
|
|
|
val |= (val2 & ~HCS_SLOTS_MASK);
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Setting Max device slots reg = 0x%x.", val);
|
2013-11-15 11:34:07 +08:00
|
|
|
|
writel(val, &xhci->op_regs->config_reg);
|
2009-04-28 10:52:28 +08:00
|
|
|
|
|
2009-04-28 10:53:42 +08:00
|
|
|
|
/*
|
|
|
|
|
* Section 5.4.8 - doorbell array must be
|
|
|
|
|
* "physically contiguous and 64-byte (cache line) aligned".
|
|
|
|
|
*/
|
2011-09-24 05:19:59 +08:00
|
|
|
|
xhci->dcbaa = dma_alloc_coherent(dev, sizeof(*xhci->dcbaa), &dma,
|
|
|
|
|
GFP_KERNEL);
|
2009-04-28 10:53:42 +08:00
|
|
|
|
if (!xhci->dcbaa)
|
|
|
|
|
goto fail;
|
|
|
|
|
memset(xhci->dcbaa, 0, sizeof *(xhci->dcbaa));
|
|
|
|
|
xhci->dcbaa->dma = dma;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Device context base array address = 0x%llx (DMA), %p (virt)",
|
2009-04-30 10:14:08 +08:00
|
|
|
|
(unsigned long long)xhci->dcbaa->dma, xhci->dcbaa);
|
2014-01-30 06:02:00 +08:00
|
|
|
|
xhci_write_64(xhci, dma, &xhci->op_regs->dcbaa_ptr);
|
2009-04-28 10:53:42 +08:00
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
|
/*
|
|
|
|
|
* Initialize the ring segment pool. The ring must be a contiguous
|
|
|
|
|
* structure comprised of TRBs. The TRBs must be 16 byte aligned,
|
2013-11-05 22:50:03 +08:00
|
|
|
|
* however, the command ring segment needs 64-byte aligned segments
|
|
|
|
|
* and our use of dma addresses in the trb_address_map radix tree needs
|
|
|
|
|
* TRB_SEGMENT_SIZE alignment, so we pick the greater alignment need.
|
2009-04-28 10:52:34 +08:00
|
|
|
|
*/
|
|
|
|
|
xhci->segment_pool = dma_pool_create("xHCI ring segments", dev,
|
2013-11-05 22:50:03 +08:00
|
|
|
|
TRB_SEGMENT_SIZE, TRB_SEGMENT_SIZE, xhci->page_size);
|
2009-07-28 03:05:15 +08:00
|
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
|
/* See Table 46 and Note on Figure 55 */
|
|
|
|
|
xhci->device_pool = dma_pool_create("xHCI input/output contexts", dev,
|
2009-07-28 03:05:15 +08:00
|
|
|
|
2112, 64, xhci->page_size);
|
2009-04-28 10:57:38 +08:00
|
|
|
|
if (!xhci->segment_pool || !xhci->device_pool)
|
2009-04-28 10:52:34 +08:00
|
|
|
|
goto fail;
|
|
|
|
|
|
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
|
|
|
|
/* Linear stream context arrays don't have any boundary restrictions,
|
|
|
|
|
* and only need to be 16-byte aligned.
|
|
|
|
|
*/
|
|
|
|
|
xhci->small_streams_pool =
|
|
|
|
|
dma_pool_create("xHCI 256 byte stream ctx arrays",
|
|
|
|
|
dev, SMALL_STREAM_ARRAY_SIZE, 16, 0);
|
|
|
|
|
xhci->medium_streams_pool =
|
|
|
|
|
dma_pool_create("xHCI 1KB stream ctx arrays",
|
|
|
|
|
dev, MEDIUM_STREAM_ARRAY_SIZE, 16, 0);
|
|
|
|
|
/* Any stream context array bigger than MEDIUM_STREAM_ARRAY_SIZE
|
2011-09-24 05:19:59 +08:00
|
|
|
|
* will be allocated with dma_alloc_coherent()
|
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
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
if (!xhci->small_streams_pool || !xhci->medium_streams_pool)
|
|
|
|
|
goto fail;
|
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
|
/* Set up the command ring to have one segments for now. */
|
2012-03-05 17:49:36 +08:00
|
|
|
|
xhci->cmd_ring = xhci_ring_alloc(xhci, 1, 1, TYPE_COMMAND, flags);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
if (!xhci->cmd_ring)
|
|
|
|
|
goto fail;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Allocated command ring at %p", xhci->cmd_ring);
|
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "First segment DMA is 0x%llx",
|
2009-04-30 10:14:08 +08:00
|
|
|
|
(unsigned long long)xhci->cmd_ring->first_seg->dma);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
|
|
/* Set the address in the Command Ring Control register */
|
2014-01-31 05:27:49 +08:00
|
|
|
|
val_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
|
2009-07-28 03:03:31 +08:00
|
|
|
|
val_64 = (val_64 & (u64) CMD_RING_RSVD_BITS) |
|
|
|
|
|
(xhci->cmd_ring->first_seg->dma & (u64) ~CMD_RING_RSVD_BITS) |
|
2009-04-28 10:52:34 +08:00
|
|
|
|
xhci->cmd_ring->cycle_state;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Setting command ring address to 0x%x", val);
|
2014-01-30 06:02:00 +08:00
|
|
|
|
xhci_write_64(xhci, val_64, &xhci->op_regs->cmd_ring);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
xhci_dbg_cmd_ptrs(xhci);
|
|
|
|
|
|
2012-05-08 22:32:03 +08:00
|
|
|
|
xhci->lpm_command = xhci_alloc_command(xhci, true, true, flags);
|
|
|
|
|
if (!xhci->lpm_command)
|
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
|
|
/* Reserve one command ring TRB for disabling LPM.
|
|
|
|
|
* Since the USB core grabs the shared usb_bus bandwidth mutex before
|
|
|
|
|
* disabling LPM, we only need to reserve one TRB for all devices.
|
|
|
|
|
*/
|
|
|
|
|
xhci->cmd_ring_reserved_trbs++;
|
|
|
|
|
|
2013-11-15 11:34:06 +08:00
|
|
|
|
val = readl(&xhci->cap_regs->db_off);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
val &= DBOFF_MASK;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Doorbell array is located at offset 0x%x"
|
|
|
|
|
" from cap regs base addr", val);
|
2011-02-09 08:29:34 +08:00
|
|
|
|
xhci->dba = (void __iomem *) xhci->cap_regs + val;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
xhci_dbg_regs(xhci);
|
|
|
|
|
xhci_print_run_regs(xhci);
|
|
|
|
|
/* Set ir_set to interrupt register set 0 */
|
2011-02-09 08:29:34 +08:00
|
|
|
|
xhci->ir_set = &xhci->run_regs->ir_set[0];
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Event ring setup: Allocate a normal ring, but also setup
|
|
|
|
|
* the event ring segment table (ERST). Section 4.9.3.
|
|
|
|
|
*/
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "// Allocating event ring");
|
2012-03-05 17:49:36 +08:00
|
|
|
|
xhci->event_ring = xhci_ring_alloc(xhci, ERST_NUM_SEGS, 1, TYPE_EVENT,
|
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
|
|
|
|
flags);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
if (!xhci->event_ring)
|
|
|
|
|
goto fail;
|
2009-11-10 05:35:23 +08:00
|
|
|
|
if (xhci_check_trb_in_td_math(xhci, flags) < 0)
|
|
|
|
|
goto fail;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
2011-09-24 05:19:59 +08:00
|
|
|
|
xhci->erst.entries = dma_alloc_coherent(dev,
|
|
|
|
|
sizeof(struct xhci_erst_entry) * ERST_NUM_SEGS, &dma,
|
|
|
|
|
GFP_KERNEL);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
if (!xhci->erst.entries)
|
|
|
|
|
goto fail;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Allocated event ring segment table at 0x%llx",
|
2009-04-30 10:14:08 +08:00
|
|
|
|
(unsigned long long)dma);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
|
|
memset(xhci->erst.entries, 0, sizeof(struct xhci_erst_entry)*ERST_NUM_SEGS);
|
|
|
|
|
xhci->erst.num_entries = ERST_NUM_SEGS;
|
|
|
|
|
xhci->erst.erst_dma_addr = dma;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Set ERST to 0; private num segs = %i, virt addr = %p, dma addr = 0x%llx",
|
2009-04-28 10:52:34 +08:00
|
|
|
|
xhci->erst.num_entries,
|
2009-04-30 10:14:08 +08:00
|
|
|
|
xhci->erst.entries,
|
|
|
|
|
(unsigned long long)xhci->erst.erst_dma_addr);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
|
|
/* set ring base address and size for each segment table entry */
|
|
|
|
|
for (val = 0, seg = xhci->event_ring->first_seg; val < ERST_NUM_SEGS; val++) {
|
|
|
|
|
struct xhci_erst_entry *entry = &xhci->erst.entries[val];
|
2011-03-29 10:40:46 +08:00
|
|
|
|
entry->seg_addr = cpu_to_le64(seg->dma);
|
|
|
|
|
entry->seg_size = cpu_to_le32(TRBS_PER_SEGMENT);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
entry->rsvd = 0;
|
|
|
|
|
seg = seg->next;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* set ERST count with the number of entries in the segment table */
|
2013-11-15 11:34:06 +08:00
|
|
|
|
val = readl(&xhci->ir_set->erst_size);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
val &= ERST_SIZE_MASK;
|
|
|
|
|
val |= ERST_NUM_SEGS;
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Write ERST size = %i to ir_set 0 (some bits preserved)",
|
2009-04-28 10:52:34 +08:00
|
|
|
|
val);
|
2013-11-15 11:34:07 +08:00
|
|
|
|
writel(val, &xhci->ir_set->erst_size);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Set ERST entries to point to event ring.");
|
2009-04-28 10:52:34 +08:00
|
|
|
|
/* set the segment table base address */
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Set ERST base address for ir_set 0 = 0x%llx",
|
2009-04-30 10:14:08 +08:00
|
|
|
|
(unsigned long long)xhci->erst.erst_dma_addr);
|
2014-01-31 05:27:49 +08:00
|
|
|
|
val_64 = xhci_read_64(xhci, &xhci->ir_set->erst_base);
|
2009-07-28 03:03:31 +08:00
|
|
|
|
val_64 &= ERST_PTR_MASK;
|
|
|
|
|
val_64 |= (xhci->erst.erst_dma_addr & (u64) ~ERST_PTR_MASK);
|
2014-01-30 06:02:00 +08:00
|
|
|
|
xhci_write_64(xhci, val_64, &xhci->ir_set->erst_base);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
|
|
/* Set the event ring dequeue address */
|
2009-04-30 10:05:20 +08:00
|
|
|
|
xhci_set_hc_event_deq(xhci);
|
2013-08-14 11:33:55 +08:00
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Wrote ERST address to ir_set 0.");
|
2011-02-09 08:29:33 +08:00
|
|
|
|
xhci_print_ir_set(xhci, 0);
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-09 00:26:03 +08:00
|
|
|
|
/* init command timeout timer */
|
2015-01-09 22:06:30 +08:00
|
|
|
|
setup_timer(&xhci->cmd_timer, xhci_handle_command_timeout,
|
|
|
|
|
(unsigned long)xhci);
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-09 00:26:03 +08:00
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
|
/*
|
|
|
|
|
* XXX: Might need to set the Interrupter Moderation Register to
|
|
|
|
|
* something other than the default (~1ms minimum between interrupts).
|
|
|
|
|
* See section 5.5.1.2.
|
|
|
|
|
*/
|
2009-04-28 10:57:38 +08:00
|
|
|
|
init_completion(&xhci->addr_dev);
|
|
|
|
|
for (i = 0; i < MAX_HC_SLOTS; ++i)
|
2010-04-19 23:53:50 +08:00
|
|
|
|
xhci->devs[i] = NULL;
|
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
|
|
|
|
for (i = 0; i < USB_MAXCHILDREN; ++i) {
|
2010-12-16 04:47:14 +08:00
|
|
|
|
xhci->bus_state[0].resume_done[i] = 0;
|
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->bus_state[1].resume_done[i] = 0;
|
usb: Fix xHCI host issues on remote wakeup.
When a device signals remote wakeup on a roothub, and the suspend change
bit is set, the host controller driver must not give control back to the
USB core until the port goes back into the active state.
EHCI accomplishes this by waiting in the get port status function until
the PORT_RESUME bit is cleared:
/* stop resume signaling */
temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME);
ehci_writel(ehci, temp, status_reg);
clear_bit(wIndex, &ehci->resuming_ports);
retval = ehci_handshake(ehci, status_reg,
PORT_RESUME, 0, 2000 /* 2msec */);
Similarly, the xHCI host should wait until the port goes into U0, before
passing control up to the USB core. When the port transitions from the
RExit state to U0, the xHCI driver will get a port status change event.
We need to wait for that event before passing control up to the USB
core.
After the port transitions to the active state, the USB core should time
a recovery interval before it talks to the device. The length of that
recovery interval is TRSMRCY, 10 ms, mentioned in the USB 2.0 spec,
section 7.1.7.7. The previous xHCI code (which did not wait for the
port to go into U0) would cause the USB core to violate that recovery
interval.
This bug caused numerous USB device disconnects on remote wakeup under
ChromeOS and a Lynx Point LP xHCI host that takes up to 20 ms to move
from RExit to U0. ChromeOS is very aggressive about power savings, and
sets the autosuspend_delay to 100 ms, and disables USB persist.
I attempted to replicate this bug with Ubuntu 12.04, but could not. I
used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
was triggered on ChromeOS with. I also changed the USB sysfs settings
as described above, but still could not reproduce the bug under Ubuntu.
It may be that ChromeOS userspace triggers this bug through additional
settings.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-20 23:12:12 +08:00
|
|
|
|
/* Only the USB 2.0 completions will ever be used. */
|
|
|
|
|
init_completion(&xhci->bus_state[1].rexit_done[i]);
|
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
|
|
|
|
}
|
2009-04-28 10:52:28 +08:00
|
|
|
|
|
2009-07-28 03:05:03 +08:00
|
|
|
|
if (scratchpad_alloc(xhci, flags))
|
|
|
|
|
goto fail;
|
2010-10-27 07:47:13 +08:00
|
|
|
|
if (xhci_setup_port_arrays(xhci, flags))
|
|
|
|
|
goto fail;
|
2009-07-28 03:05:03 +08:00
|
|
|
|
|
2011-11-12 06:57:33 +08:00
|
|
|
|
/* Enable USB 3.0 device notifications for function remote wake, which
|
|
|
|
|
* is necessary for allowing USB 3.0 devices to do remote wakeup from
|
|
|
|
|
* U3 (device suspend).
|
|
|
|
|
*/
|
2013-11-15 11:34:06 +08:00
|
|
|
|
temp = readl(&xhci->op_regs->dev_notification);
|
2011-11-12 06:57:33 +08:00
|
|
|
|
temp &= ~DEV_NOTE_MASK;
|
|
|
|
|
temp |= DEV_NOTE_FWAKE;
|
2013-11-15 11:34:07 +08:00
|
|
|
|
writel(temp, &xhci->op_regs->dev_notification);
|
2011-11-12 06:57:33 +08:00
|
|
|
|
|
2009-04-28 10:52:28 +08:00
|
|
|
|
return 0;
|
2009-07-28 03:05:03 +08:00
|
|
|
|
|
2009-04-28 10:52:28 +08:00
|
|
|
|
fail:
|
|
|
|
|
xhci_warn(xhci, "Couldn't initialize memory\n");
|
2012-03-17 04:09:39 +08:00
|
|
|
|
xhci_halt(xhci);
|
|
|
|
|
xhci_reset(xhci);
|
2009-04-28 10:52:28 +08:00
|
|
|
|
xhci_mem_cleanup(xhci);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|