2009-04-28 02:52:28 +00: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.
|
|
|
|
|
*/
|
|
|
|
|
|
2010-07-21 23:56:08 +00:00
|
|
|
#include <linux/pci.h>
|
2009-04-28 02:52:28 +00:00
|
|
|
#include <linux/irq.h>
|
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-02 22:34:16 +00:00
|
|
|
#include <linux/log2.h>
|
2009-04-28 02:52:28 +00:00
|
|
|
#include <linux/module.h>
|
2009-08-07 21:04:36 +00:00
|
|
|
#include <linux/moduleparam.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 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
#include "xhci.h"
|
|
|
|
|
|
|
|
|
|
#define DRIVER_AUTHOR "Sarah Sharp"
|
|
|
|
|
#define DRIVER_DESC "'eXtensible' Host Controller (xHC) Driver"
|
|
|
|
|
|
2009-08-07 21:04:36 +00:00
|
|
|
/* Some 0.95 hardware can't handle the chain bit on a Link TRB being cleared */
|
|
|
|
|
static int link_quirk;
|
|
|
|
|
module_param(link_quirk, int, S_IRUGO | S_IWUSR);
|
|
|
|
|
MODULE_PARM_DESC(link_quirk, "Don't clear the chain bit on a link TRB");
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
/* TODO: copied from ehci-hcd.c - can this be refactored? */
|
|
|
|
|
/*
|
|
|
|
|
* handshake - spin reading hc until handshake completes or fails
|
|
|
|
|
* @ptr: address of hc register to be read
|
|
|
|
|
* @mask: bits to look at in result of read
|
|
|
|
|
* @done: value of those bits when handshake succeeds
|
|
|
|
|
* @usec: timeout in microseconds
|
|
|
|
|
*
|
|
|
|
|
* Returns negative errno, or zero on success
|
|
|
|
|
*
|
|
|
|
|
* Success happens when the "mask" bits have the specified value (hardware
|
|
|
|
|
* handshake done). There are two failure modes: "usec" have passed (major
|
|
|
|
|
* hardware flakeout), or the register reads as all-ones (hardware removed).
|
|
|
|
|
*/
|
|
|
|
|
static int handshake(struct xhci_hcd *xhci, void __iomem *ptr,
|
|
|
|
|
u32 mask, u32 done, int usec)
|
|
|
|
|
{
|
|
|
|
|
u32 result;
|
|
|
|
|
|
|
|
|
|
do {
|
|
|
|
|
result = xhci_readl(xhci, ptr);
|
|
|
|
|
if (result == ~(u32)0) /* card removed */
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
result &= mask;
|
|
|
|
|
if (result == done)
|
|
|
|
|
return 0;
|
|
|
|
|
udelay(1);
|
|
|
|
|
usec--;
|
|
|
|
|
} while (usec > 0);
|
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2009-10-27 17:56:33 +00:00
|
|
|
* Disable interrupts and begin the xHCI halting process.
|
2009-04-28 02:52:28 +00:00
|
|
|
*/
|
2009-10-27 17:56:33 +00:00
|
|
|
void xhci_quiesce(struct xhci_hcd *xhci)
|
2009-04-28 02:52:28 +00:00
|
|
|
{
|
|
|
|
|
u32 halted;
|
|
|
|
|
u32 cmd;
|
|
|
|
|
u32 mask;
|
|
|
|
|
|
|
|
|
|
mask = ~(XHCI_IRQS);
|
|
|
|
|
halted = xhci_readl(xhci, &xhci->op_regs->status) & STS_HALT;
|
|
|
|
|
if (!halted)
|
|
|
|
|
mask &= ~CMD_RUN;
|
|
|
|
|
|
|
|
|
|
cmd = xhci_readl(xhci, &xhci->op_regs->command);
|
|
|
|
|
cmd &= mask;
|
|
|
|
|
xhci_writel(xhci, cmd, &xhci->op_regs->command);
|
2009-10-27 17:56:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Force HC into halt state.
|
|
|
|
|
*
|
|
|
|
|
* Disable any IRQs and clear the run/stop bit.
|
|
|
|
|
* HC will complete any current and actively pipelined transactions, and
|
|
|
|
|
* should halt within 16 microframes of the run/stop bit being cleared.
|
|
|
|
|
* Read HC Halted bit in the status register to see when the HC is finished.
|
|
|
|
|
* XXX: shouldn't we set HC_STATE_HALT here somewhere?
|
|
|
|
|
*/
|
|
|
|
|
int xhci_halt(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
xhci_dbg(xhci, "// Halt the HC\n");
|
|
|
|
|
xhci_quiesce(xhci);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
return handshake(xhci, &xhci->op_regs->status,
|
|
|
|
|
STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC);
|
|
|
|
|
}
|
|
|
|
|
|
2010-05-24 20:25:21 +00:00
|
|
|
/*
|
|
|
|
|
* Set the run bit and wait for the host to be running.
|
|
|
|
|
*/
|
|
|
|
|
int xhci_start(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
u32 temp;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
temp = xhci_readl(xhci, &xhci->op_regs->command);
|
|
|
|
|
temp |= (CMD_RUN);
|
|
|
|
|
xhci_dbg(xhci, "// Turn on HC, cmd = 0x%x.\n",
|
|
|
|
|
temp);
|
|
|
|
|
xhci_writel(xhci, temp, &xhci->op_regs->command);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Wait for the HCHalted Status bit to be 0 to indicate the host is
|
|
|
|
|
* running.
|
|
|
|
|
*/
|
|
|
|
|
ret = handshake(xhci, &xhci->op_regs->status,
|
|
|
|
|
STS_HALT, 0, XHCI_MAX_HALT_USEC);
|
|
|
|
|
if (ret == -ETIMEDOUT)
|
|
|
|
|
xhci_err(xhci, "Host took too long to start, "
|
|
|
|
|
"waited %u microseconds.\n",
|
|
|
|
|
XHCI_MAX_HALT_USEC);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
/*
|
|
|
|
|
* Reset a halted HC, and set the internal HC state to HC_STATE_HALT.
|
|
|
|
|
*
|
|
|
|
|
* This resets pipelines, timers, counters, state machines, etc.
|
|
|
|
|
* Transactions will be terminated immediately, and operational registers
|
|
|
|
|
* will be set to their defaults.
|
|
|
|
|
*/
|
|
|
|
|
int xhci_reset(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
u32 command;
|
|
|
|
|
u32 state;
|
2010-05-24 20:25:15 +00:00
|
|
|
int ret;
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
state = xhci_readl(xhci, &xhci->op_regs->status);
|
2009-07-27 19:03:50 +00:00
|
|
|
if ((state & STS_HALT) == 0) {
|
|
|
|
|
xhci_warn(xhci, "Host controller not halted, aborting reset.\n");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "// Reset the HC\n");
|
|
|
|
|
command = xhci_readl(xhci, &xhci->op_regs->command);
|
|
|
|
|
command |= CMD_RESET;
|
|
|
|
|
xhci_writel(xhci, command, &xhci->op_regs->command);
|
|
|
|
|
/* XXX: Why does EHCI set this here? Shouldn't other code do this? */
|
|
|
|
|
xhci_to_hcd(xhci)->state = HC_STATE_HALT;
|
|
|
|
|
|
2010-05-24 20:25:15 +00:00
|
|
|
ret = handshake(xhci, &xhci->op_regs->command,
|
|
|
|
|
CMD_RESET, 0, 250 * 1000);
|
|
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Wait for controller to be ready for doorbell rings\n");
|
|
|
|
|
/*
|
|
|
|
|
* xHCI cannot write to any doorbells or operational registers other
|
|
|
|
|
* than status until the "Controller Not Ready" flag is cleared.
|
|
|
|
|
*/
|
|
|
|
|
return handshake(xhci, &xhci->op_regs->status, STS_CNR, 0, 250 * 1000);
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
|
|
|
|
|
2010-07-21 23:56:08 +00:00
|
|
|
/*
|
|
|
|
|
* Free IRQs
|
|
|
|
|
* free all IRQs request
|
|
|
|
|
*/
|
|
|
|
|
static void xhci_free_irq(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
|
|
|
|
|
|
|
|
|
|
/* return if using legacy interrupt */
|
|
|
|
|
if (xhci_to_hcd(xhci)->irq >= 0)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
if (xhci->msix_entries) {
|
|
|
|
|
for (i = 0; i < xhci->msix_count; i++)
|
|
|
|
|
if (xhci->msix_entries[i].vector)
|
|
|
|
|
free_irq(xhci->msix_entries[i].vector,
|
|
|
|
|
xhci_to_hcd(xhci));
|
|
|
|
|
} else if (pdev->irq >= 0)
|
|
|
|
|
free_irq(pdev->irq, xhci_to_hcd(xhci));
|
|
|
|
|
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Set up MSI
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_setup_msi(struct xhci_hcd *xhci)
|
2009-04-28 02:52:28 +00:00
|
|
|
{
|
|
|
|
|
int ret;
|
2010-07-21 23:56:08 +00:00
|
|
|
struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
|
|
|
|
|
|
|
|
|
|
ret = pci_enable_msi(pdev);
|
|
|
|
|
if (ret) {
|
|
|
|
|
xhci_err(xhci, "failed to allocate MSI entry\n");
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret = request_irq(pdev->irq, (irq_handler_t)xhci_msi_irq,
|
|
|
|
|
0, "xhci_hcd", xhci_to_hcd(xhci));
|
|
|
|
|
if (ret) {
|
|
|
|
|
xhci_err(xhci, "disable MSI interrupt\n");
|
|
|
|
|
pci_disable_msi(pdev);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Set up MSI-X
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_setup_msix(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
int i, ret = 0;
|
2009-04-28 02:52:28 +00:00
|
|
|
struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
|
|
|
|
|
|
2010-07-21 23:56:08 +00:00
|
|
|
/*
|
|
|
|
|
* calculate number of msi-x vectors supported.
|
|
|
|
|
* - HCS_MAX_INTRS: the max number of interrupts the host can handle,
|
|
|
|
|
* with max number of interrupters based on the xhci HCSPARAMS1.
|
|
|
|
|
* - num_online_cpus: maximum msi-x vectors per CPUs core.
|
|
|
|
|
* Add additional 1 vector to ensure always available interrupt.
|
|
|
|
|
*/
|
|
|
|
|
xhci->msix_count = min(num_online_cpus() + 1,
|
|
|
|
|
HCS_MAX_INTRS(xhci->hcs_params1));
|
|
|
|
|
|
|
|
|
|
xhci->msix_entries =
|
|
|
|
|
kmalloc((sizeof(struct msix_entry))*xhci->msix_count,
|
|
|
|
|
GFP_KERNEL);
|
2009-04-28 02:52:28 +00:00
|
|
|
if (!xhci->msix_entries) {
|
|
|
|
|
xhci_err(xhci, "Failed to allocate MSI-X entries\n");
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
2010-07-21 23:56:08 +00:00
|
|
|
|
|
|
|
|
for (i = 0; i < xhci->msix_count; i++) {
|
|
|
|
|
xhci->msix_entries[i].entry = i;
|
|
|
|
|
xhci->msix_entries[i].vector = 0;
|
|
|
|
|
}
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
ret = pci_enable_msix(pdev, xhci->msix_entries, xhci->msix_count);
|
|
|
|
|
if (ret) {
|
|
|
|
|
xhci_err(xhci, "Failed to enable MSI-X\n");
|
|
|
|
|
goto free_entries;
|
|
|
|
|
}
|
|
|
|
|
|
2010-07-21 23:56:08 +00:00
|
|
|
for (i = 0; i < xhci->msix_count; i++) {
|
|
|
|
|
ret = request_irq(xhci->msix_entries[i].vector,
|
|
|
|
|
(irq_handler_t)xhci_msi_irq,
|
|
|
|
|
0, "xhci_hcd", xhci_to_hcd(xhci));
|
|
|
|
|
if (ret)
|
|
|
|
|
goto disable_msix;
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
2010-07-21 23:56:08 +00:00
|
|
|
|
|
|
|
|
return ret;
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
disable_msix:
|
2010-07-21 23:56:08 +00:00
|
|
|
xhci_err(xhci, "disable MSI-X interrupt\n");
|
|
|
|
|
xhci_free_irq(xhci);
|
2009-04-28 02:52:28 +00:00
|
|
|
pci_disable_msix(pdev);
|
|
|
|
|
free_entries:
|
|
|
|
|
kfree(xhci->msix_entries);
|
|
|
|
|
xhci->msix_entries = NULL;
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Free any IRQs and disable MSI-X */
|
|
|
|
|
static void xhci_cleanup_msix(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
|
|
|
|
|
|
2010-07-21 23:56:08 +00:00
|
|
|
xhci_free_irq(xhci);
|
|
|
|
|
|
|
|
|
|
if (xhci->msix_entries) {
|
|
|
|
|
pci_disable_msix(pdev);
|
|
|
|
|
kfree(xhci->msix_entries);
|
|
|
|
|
xhci->msix_entries = NULL;
|
|
|
|
|
} else {
|
|
|
|
|
pci_disable_msi(pdev);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return;
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Initialize memory for HCD and xHC (one-time init).
|
|
|
|
|
*
|
|
|
|
|
* Program the PAGESIZE register, initialize the device context array, create
|
|
|
|
|
* device contexts (?), set up a command ring segment (or two?), create event
|
|
|
|
|
* ring (one for now).
|
|
|
|
|
*/
|
|
|
|
|
int xhci_init(struct usb_hcd *hcd)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
int retval = 0;
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "xhci_init\n");
|
|
|
|
|
spin_lock_init(&xhci->lock);
|
2009-08-07 21:04:36 +00:00
|
|
|
if (link_quirk) {
|
|
|
|
|
xhci_dbg(xhci, "QUIRK: Not clearing Link TRB chain bits.\n");
|
|
|
|
|
xhci->quirks |= XHCI_LINK_TRB_QUIRK;
|
|
|
|
|
} else {
|
2009-08-07 21:04:55 +00:00
|
|
|
xhci_dbg(xhci, "xHCI doesn't need link TRB QUIRK\n");
|
2009-08-07 21:04:36 +00:00
|
|
|
}
|
2009-04-28 02:52:28 +00:00
|
|
|
retval = xhci_mem_init(xhci, GFP_KERNEL);
|
|
|
|
|
xhci_dbg(xhci, "Finished xhci_init\n");
|
|
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:53:56 +00:00
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_USB_XHCI_HCD_DEBUGGING
|
2009-04-30 02:05:20 +00:00
|
|
|
void xhci_event_ring_work(unsigned long arg)
|
2009-04-28 02:53:56 +00:00
|
|
|
{
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
int temp;
|
2009-07-27 19:03:31 +00:00
|
|
|
u64 temp_64;
|
2009-04-28 02:53:56 +00:00
|
|
|
struct xhci_hcd *xhci = (struct xhci_hcd *) arg;
|
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Poll event ring: %lu\n", jiffies);
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
temp = xhci_readl(xhci, &xhci->op_regs->status);
|
|
|
|
|
xhci_dbg(xhci, "op reg status = 0x%x\n", temp);
|
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-27 17:57:01 +00:00
|
|
|
if (temp == 0xffffffff || (xhci->xhc_state & XHCI_STATE_DYING)) {
|
2009-09-16 23:42:30 +00:00
|
|
|
xhci_dbg(xhci, "HW died, polling stopped.\n");
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:53:56 +00:00
|
|
|
temp = xhci_readl(xhci, &xhci->ir_set->irq_pending);
|
|
|
|
|
xhci_dbg(xhci, "ir_set 0 pending = 0x%x\n", temp);
|
|
|
|
|
xhci_dbg(xhci, "No-op commands handled = %d\n", xhci->noops_handled);
|
|
|
|
|
xhci_dbg(xhci, "HC error bitmask = 0x%x\n", xhci->error_bitmask);
|
|
|
|
|
xhci->error_bitmask = 0;
|
|
|
|
|
xhci_dbg(xhci, "Event ring:\n");
|
|
|
|
|
xhci_debug_segment(xhci, xhci->event_ring->deq_seg);
|
|
|
|
|
xhci_dbg_ring_ptrs(xhci, xhci->event_ring);
|
2009-07-27 19:03:31 +00:00
|
|
|
temp_64 = xhci_read_64(xhci, &xhci->ir_set->erst_dequeue);
|
|
|
|
|
temp_64 &= ~ERST_PTR_MASK;
|
|
|
|
|
xhci_dbg(xhci, "ERST deq = 64'h%0lx\n", (long unsigned int) temp_64);
|
2009-04-28 02:53:56 +00:00
|
|
|
xhci_dbg(xhci, "Command ring:\n");
|
|
|
|
|
xhci_debug_segment(xhci, xhci->cmd_ring->deq_seg);
|
|
|
|
|
xhci_dbg_ring_ptrs(xhci, xhci->cmd_ring);
|
|
|
|
|
xhci_dbg_cmd_ptrs(xhci);
|
2009-04-28 02:57:38 +00:00
|
|
|
for (i = 0; i < MAX_HC_SLOTS; ++i) {
|
2009-09-04 17:53:09 +00:00
|
|
|
if (!xhci->devs[i])
|
|
|
|
|
continue;
|
|
|
|
|
for (j = 0; j < 31; ++j) {
|
2010-04-02 22:34:43 +00:00
|
|
|
xhci_dbg_ep_rings(xhci, i, j, &xhci->devs[i]->eps[j]);
|
2009-04-28 02:57:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
2009-04-28 02:53:56 +00:00
|
|
|
|
|
|
|
|
if (xhci->noops_submitted != NUM_TEST_NOOPS)
|
2009-04-30 02:05:20 +00:00
|
|
|
if (xhci_setup_one_noop(xhci))
|
|
|
|
|
xhci_ring_cmd_db(xhci);
|
2009-04-28 02:53:56 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
if (!xhci->zombie)
|
|
|
|
|
mod_timer(&xhci->event_ring_timer, jiffies + POLL_TIMEOUT * HZ);
|
|
|
|
|
else
|
|
|
|
|
xhci_dbg(xhci, "Quit polling the event ring.\n");
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
/*
|
|
|
|
|
* Start the HC after it was halted.
|
|
|
|
|
*
|
|
|
|
|
* This function is called by the USB core when the HC driver is added.
|
|
|
|
|
* Its opposite is xhci_stop().
|
|
|
|
|
*
|
|
|
|
|
* xhci_init() must be called once before this function can be called.
|
|
|
|
|
* Reset the HC, enable device slot contexts, program DCBAAP, and
|
|
|
|
|
* set command ring pointer and event ring pointer.
|
|
|
|
|
*
|
|
|
|
|
* Setup MSI-X vectors and enable interrupts.
|
|
|
|
|
*/
|
|
|
|
|
int xhci_run(struct usb_hcd *hcd)
|
|
|
|
|
{
|
|
|
|
|
u32 temp;
|
2009-07-27 19:03:31 +00:00
|
|
|
u64 temp_64;
|
2010-07-21 23:56:08 +00:00
|
|
|
u32 ret;
|
2009-04-28 02:52:28 +00:00
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
2010-07-21 23:56:08 +00:00
|
|
|
struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
|
2009-04-28 02:53:56 +00:00
|
|
|
void (*doorbell)(struct xhci_hcd *) = NULL;
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2009-04-28 02:57:12 +00:00
|
|
|
hcd->uses_new_polling = 1;
|
|
|
|
|
|
2009-04-28 02:53:56 +00:00
|
|
|
xhci_dbg(xhci, "xhci_run\n");
|
2010-07-21 23:56:08 +00:00
|
|
|
/* unregister the legacy interrupt */
|
|
|
|
|
if (hcd->irq)
|
|
|
|
|
free_irq(hcd->irq, hcd);
|
|
|
|
|
hcd->irq = -1;
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
ret = xhci_setup_msix(xhci);
|
2010-07-21 23:56:08 +00:00
|
|
|
if (ret)
|
|
|
|
|
/* fall back to msi*/
|
|
|
|
|
ret = xhci_setup_msi(xhci);
|
|
|
|
|
|
|
|
|
|
if (ret) {
|
|
|
|
|
/* fall back to legacy interrupt*/
|
|
|
|
|
ret = request_irq(pdev->irq, &usb_hcd_irq, IRQF_SHARED,
|
|
|
|
|
hcd->irq_descr, hcd);
|
|
|
|
|
if (ret) {
|
|
|
|
|
xhci_err(xhci, "request interrupt %d failed\n",
|
|
|
|
|
pdev->irq);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
hcd->irq = pdev->irq;
|
|
|
|
|
}
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2009-04-28 02:53:56 +00:00
|
|
|
#ifdef CONFIG_USB_XHCI_HCD_DEBUGGING
|
|
|
|
|
init_timer(&xhci->event_ring_timer);
|
|
|
|
|
xhci->event_ring_timer.data = (unsigned long) xhci;
|
2009-04-30 02:05:20 +00:00
|
|
|
xhci->event_ring_timer.function = xhci_event_ring_work;
|
2009-04-28 02:53:56 +00:00
|
|
|
/* Poll the event ring */
|
|
|
|
|
xhci->event_ring_timer.expires = jiffies + POLL_TIMEOUT * HZ;
|
|
|
|
|
xhci->zombie = 0;
|
|
|
|
|
xhci_dbg(xhci, "Setting event ring polling timer\n");
|
|
|
|
|
add_timer(&xhci->event_ring_timer);
|
|
|
|
|
#endif
|
|
|
|
|
|
2009-07-27 19:03:46 +00:00
|
|
|
xhci_dbg(xhci, "Command ring memory map follows:\n");
|
|
|
|
|
xhci_debug_ring(xhci, xhci->cmd_ring);
|
|
|
|
|
xhci_dbg_ring_ptrs(xhci, xhci->cmd_ring);
|
|
|
|
|
xhci_dbg_cmd_ptrs(xhci);
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "ERST memory map follows:\n");
|
|
|
|
|
xhci_dbg_erst(xhci, &xhci->erst);
|
|
|
|
|
xhci_dbg(xhci, "Event ring:\n");
|
|
|
|
|
xhci_debug_ring(xhci, xhci->event_ring);
|
|
|
|
|
xhci_dbg_ring_ptrs(xhci, xhci->event_ring);
|
|
|
|
|
temp_64 = xhci_read_64(xhci, &xhci->ir_set->erst_dequeue);
|
|
|
|
|
temp_64 &= ~ERST_PTR_MASK;
|
|
|
|
|
xhci_dbg(xhci, "ERST deq = 64'h%0lx\n", (long unsigned int) temp_64);
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
xhci_dbg(xhci, "// Set the interrupt modulation register\n");
|
|
|
|
|
temp = xhci_readl(xhci, &xhci->ir_set->irq_control);
|
2009-05-14 18:44:26 +00:00
|
|
|
temp &= ~ER_IRQ_INTERVAL_MASK;
|
2009-04-28 02:52:28 +00:00
|
|
|
temp |= (u32) 160;
|
|
|
|
|
xhci_writel(xhci, temp, &xhci->ir_set->irq_control);
|
|
|
|
|
|
|
|
|
|
/* Set the HCD state before we enable the irqs */
|
|
|
|
|
hcd->state = HC_STATE_RUNNING;
|
|
|
|
|
temp = xhci_readl(xhci, &xhci->op_regs->command);
|
|
|
|
|
temp |= (CMD_EIE);
|
|
|
|
|
xhci_dbg(xhci, "// Enable interrupts, cmd = 0x%x.\n",
|
|
|
|
|
temp);
|
|
|
|
|
xhci_writel(xhci, temp, &xhci->op_regs->command);
|
|
|
|
|
|
|
|
|
|
temp = xhci_readl(xhci, &xhci->ir_set->irq_pending);
|
2009-04-30 02:14:08 +00:00
|
|
|
xhci_dbg(xhci, "// Enabling event ring interrupter %p by writing 0x%x to irq_pending\n",
|
|
|
|
|
xhci->ir_set, (unsigned int) ER_IRQ_ENABLE(temp));
|
2009-04-28 02:52:28 +00:00
|
|
|
xhci_writel(xhci, ER_IRQ_ENABLE(temp),
|
|
|
|
|
&xhci->ir_set->irq_pending);
|
|
|
|
|
xhci_print_ir_set(xhci, xhci->ir_set, 0);
|
|
|
|
|
|
2009-04-28 02:53:56 +00:00
|
|
|
if (NUM_TEST_NOOPS > 0)
|
2009-04-30 02:05:20 +00:00
|
|
|
doorbell = xhci_setup_one_noop(xhci);
|
2010-05-24 20:25:28 +00:00
|
|
|
if (xhci->quirks & XHCI_NEC_HOST)
|
|
|
|
|
xhci_queue_vendor_command(xhci, 0, 0, 0,
|
|
|
|
|
TRB_TYPE(TRB_NEC_GET_FW));
|
2009-04-28 02:53:56 +00:00
|
|
|
|
2010-05-24 20:25:21 +00:00
|
|
|
if (xhci_start(xhci)) {
|
|
|
|
|
xhci_halt(xhci);
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:53:56 +00:00
|
|
|
if (doorbell)
|
|
|
|
|
(*doorbell)(xhci);
|
2010-05-24 20:25:28 +00:00
|
|
|
if (xhci->quirks & XHCI_NEC_HOST)
|
|
|
|
|
xhci_ring_cmd_db(xhci);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Finished xhci_run\n");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Stop xHCI driver.
|
|
|
|
|
*
|
|
|
|
|
* This function is called by the USB core when the HC driver is removed.
|
|
|
|
|
* Its opposite is xhci_run().
|
|
|
|
|
*
|
|
|
|
|
* Disable device contexts, disable IRQs, and quiesce the HC.
|
|
|
|
|
* Reset the HC, finish any completed transactions, and cleanup memory.
|
|
|
|
|
*/
|
|
|
|
|
void xhci_stop(struct usb_hcd *hcd)
|
|
|
|
|
{
|
|
|
|
|
u32 temp;
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
|
|
|
|
|
spin_lock_irq(&xhci->lock);
|
|
|
|
|
xhci_halt(xhci);
|
|
|
|
|
xhci_reset(xhci);
|
2010-07-21 23:56:08 +00:00
|
|
|
xhci_cleanup_msix(xhci);
|
2009-04-28 02:52:28 +00:00
|
|
|
spin_unlock_irq(&xhci->lock);
|
|
|
|
|
|
2009-04-28 02:53:56 +00:00
|
|
|
#ifdef CONFIG_USB_XHCI_HCD_DEBUGGING
|
|
|
|
|
/* Tell the event ring poll function not to reschedule */
|
|
|
|
|
xhci->zombie = 1;
|
|
|
|
|
del_timer_sync(&xhci->event_ring_timer);
|
|
|
|
|
#endif
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
xhci_dbg(xhci, "// Disabling event ring interrupts\n");
|
|
|
|
|
temp = xhci_readl(xhci, &xhci->op_regs->status);
|
|
|
|
|
xhci_writel(xhci, temp & ~STS_EINT, &xhci->op_regs->status);
|
|
|
|
|
temp = xhci_readl(xhci, &xhci->ir_set->irq_pending);
|
|
|
|
|
xhci_writel(xhci, ER_IRQ_DISABLE(temp),
|
|
|
|
|
&xhci->ir_set->irq_pending);
|
|
|
|
|
xhci_print_ir_set(xhci, xhci->ir_set, 0);
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "cleaning up memory\n");
|
|
|
|
|
xhci_mem_cleanup(xhci);
|
|
|
|
|
xhci_dbg(xhci, "xhci_stop completed - status = %x\n",
|
|
|
|
|
xhci_readl(xhci, &xhci->op_regs->status));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Shutdown HC (not bus-specific)
|
|
|
|
|
*
|
|
|
|
|
* This is called when the machine is rebooting or halting. We assume that the
|
|
|
|
|
* machine will be powered off, and the HC's internal state will be reset.
|
|
|
|
|
* Don't bother to free memory.
|
|
|
|
|
*/
|
|
|
|
|
void xhci_shutdown(struct usb_hcd *hcd)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
|
|
|
|
|
spin_lock_irq(&xhci->lock);
|
|
|
|
|
xhci_halt(xhci);
|
|
|
|
|
xhci_cleanup_msix(xhci);
|
2010-07-21 23:56:08 +00:00
|
|
|
spin_unlock_irq(&xhci->lock);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "xhci_shutdown completed - status = %x\n",
|
|
|
|
|
xhci_readl(xhci, &xhci->op_regs->status));
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:53:56 +00:00
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
|
2009-04-28 02:58:01 +00:00
|
|
|
/**
|
|
|
|
|
* xhci_get_endpoint_index - Used for passing endpoint bitmasks between the core and
|
|
|
|
|
* HCDs. Find the index for an endpoint given its descriptor. Use the return
|
|
|
|
|
* value to right shift 1 for the bitmask.
|
|
|
|
|
*
|
|
|
|
|
* Index = (epnum * 2) + direction - 1,
|
|
|
|
|
* where direction = 0 for OUT, 1 for IN.
|
|
|
|
|
* For control endpoints, the IN index is used (OUT index is unused), so
|
|
|
|
|
* index = (epnum * 2) + direction - 1 = (epnum * 2) + 1 - 1 = (epnum * 2)
|
|
|
|
|
*/
|
|
|
|
|
unsigned int xhci_get_endpoint_index(struct usb_endpoint_descriptor *desc)
|
|
|
|
|
{
|
|
|
|
|
unsigned int index;
|
|
|
|
|
if (usb_endpoint_xfer_control(desc))
|
|
|
|
|
index = (unsigned int) (usb_endpoint_num(desc)*2);
|
|
|
|
|
else
|
|
|
|
|
index = (unsigned int) (usb_endpoint_num(desc)*2) +
|
|
|
|
|
(usb_endpoint_dir_in(desc) ? 1 : 0) - 1;
|
|
|
|
|
return 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 02:58:38 +00:00
|
|
|
/* Find the flag for this endpoint (for use in the control context). Use the
|
|
|
|
|
* endpoint index to create a bitmask. The slot context is bit 0, endpoint 0 is
|
|
|
|
|
* bit 1, etc.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int xhci_get_endpoint_flag(struct usb_endpoint_descriptor *desc)
|
|
|
|
|
{
|
|
|
|
|
return 1 << (xhci_get_endpoint_index(desc) + 1);
|
|
|
|
|
}
|
|
|
|
|
|
2009-08-07 21:04:55 +00:00
|
|
|
/* Find the flag for this endpoint (for use in the control context). Use the
|
|
|
|
|
* endpoint index to create a bitmask. The slot context is bit 0, endpoint 0 is
|
|
|
|
|
* bit 1, etc.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int xhci_get_endpoint_flag_from_index(unsigned int ep_index)
|
|
|
|
|
{
|
|
|
|
|
return 1 << (ep_index + 1);
|
|
|
|
|
}
|
|
|
|
|
|
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 02:58:38 +00:00
|
|
|
/* Compute the last valid endpoint context index. Basically, this is the
|
|
|
|
|
* endpoint index plus one. For slot contexts with more than valid endpoint,
|
|
|
|
|
* we find the most significant bit set in the added contexts flags.
|
|
|
|
|
* e.g. ep 1 IN (with epnum 0x81) => added_ctxs = 0b1000
|
|
|
|
|
* fls(0b1000) = 4, but the endpoint context index is 3, so subtract one.
|
|
|
|
|
*/
|
2009-08-07 21:04:55 +00:00
|
|
|
unsigned int xhci_last_valid_endpoint(u32 added_ctxs)
|
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 02:58:38 +00:00
|
|
|
{
|
|
|
|
|
return fls(added_ctxs) - 1;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:58:01 +00:00
|
|
|
/* Returns 1 if the arguments are OK;
|
|
|
|
|
* returns 0 this is a root hub; returns -EINVAL for NULL pointers.
|
|
|
|
|
*/
|
|
|
|
|
int xhci_check_args(struct usb_hcd *hcd, struct usb_device *udev,
|
2010-10-14 14:22:45 +00:00
|
|
|
struct usb_host_endpoint *ep, int check_ep, bool check_virt_dev,
|
|
|
|
|
const char *func) {
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
struct xhci_virt_device *virt_dev;
|
|
|
|
|
|
2009-04-28 02:58:01 +00:00
|
|
|
if (!hcd || (check_ep && !ep) || !udev) {
|
|
|
|
|
printk(KERN_DEBUG "xHCI %s called with invalid args\n",
|
|
|
|
|
func);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
if (!udev->parent) {
|
|
|
|
|
printk(KERN_DEBUG "xHCI %s called for root hub\n",
|
|
|
|
|
func);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2010-10-14 14:22:45 +00:00
|
|
|
|
|
|
|
|
if (check_virt_dev) {
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
if (!udev->slot_id || !xhci->devs
|
|
|
|
|
|| !xhci->devs[udev->slot_id]) {
|
|
|
|
|
printk(KERN_DEBUG "xHCI %s called with unaddressed "
|
|
|
|
|
"device\n", func);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
virt_dev = xhci->devs[udev->slot_id];
|
|
|
|
|
if (virt_dev->udev != udev) {
|
|
|
|
|
printk(KERN_DEBUG "xHCI %s called with udev and "
|
|
|
|
|
"virt_dev does not match\n", func);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2009-04-28 02:58:01 +00:00
|
|
|
}
|
2010-10-14 14:22:45 +00:00
|
|
|
|
2009-04-28 02:58:01 +00:00
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
2009-08-07 21:04:49 +00:00
|
|
|
static int xhci_configure_endpoint(struct xhci_hcd *xhci,
|
2009-09-04 17:53:13 +00:00
|
|
|
struct usb_device *udev, struct xhci_command *command,
|
|
|
|
|
bool ctx_change, bool must_succeed);
|
2009-08-07 21:04:49 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Full speed devices may have a max packet size greater than 8 bytes, but the
|
|
|
|
|
* USB core doesn't know that until it reads the first 8 bytes of the
|
|
|
|
|
* descriptor. If the usb_device's max packet size changes after that point,
|
|
|
|
|
* we need to issue an evaluate context command and wait on it.
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_check_maxpacket(struct xhci_hcd *xhci, unsigned int slot_id,
|
|
|
|
|
unsigned int ep_index, struct urb *urb)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_container_ctx *in_ctx;
|
|
|
|
|
struct xhci_container_ctx *out_ctx;
|
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
|
int max_packet_size;
|
|
|
|
|
int hw_max_packet_size;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
|
|
out_ctx = xhci->devs[slot_id]->out_ctx;
|
|
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, out_ctx, ep_index);
|
|
|
|
|
hw_max_packet_size = MAX_PACKET_DECODED(ep_ctx->ep_info2);
|
|
|
|
|
max_packet_size = urb->dev->ep0.desc.wMaxPacketSize;
|
|
|
|
|
if (hw_max_packet_size != max_packet_size) {
|
|
|
|
|
xhci_dbg(xhci, "Max Packet Size for ep 0 changed.\n");
|
|
|
|
|
xhci_dbg(xhci, "Max packet size in usb_device = %d\n",
|
|
|
|
|
max_packet_size);
|
|
|
|
|
xhci_dbg(xhci, "Max packet size in xHCI HW = %d\n",
|
|
|
|
|
hw_max_packet_size);
|
|
|
|
|
xhci_dbg(xhci, "Issuing evaluate context command.\n");
|
|
|
|
|
|
|
|
|
|
/* Set up the modified control endpoint 0 */
|
2009-09-04 17:53:13 +00:00
|
|
|
xhci_endpoint_copy(xhci, xhci->devs[slot_id]->in_ctx,
|
|
|
|
|
xhci->devs[slot_id]->out_ctx, ep_index);
|
2009-08-07 21:04:49 +00:00
|
|
|
in_ctx = xhci->devs[slot_id]->in_ctx;
|
|
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, in_ctx, ep_index);
|
|
|
|
|
ep_ctx->ep_info2 &= ~MAX_PACKET_MASK;
|
|
|
|
|
ep_ctx->ep_info2 |= MAX_PACKET(max_packet_size);
|
|
|
|
|
|
|
|
|
|
/* Set up the input context flags for the command */
|
|
|
|
|
/* FIXME: This won't work if a non-default control endpoint
|
|
|
|
|
* changes max packet sizes.
|
|
|
|
|
*/
|
|
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
|
|
|
|
|
ctrl_ctx->add_flags = EP0_FLAG;
|
|
|
|
|
ctrl_ctx->drop_flags = 0;
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Slot %d input context\n", slot_id);
|
|
|
|
|
xhci_dbg_ctx(xhci, in_ctx, ep_index);
|
|
|
|
|
xhci_dbg(xhci, "Slot %d output context\n", slot_id);
|
|
|
|
|
xhci_dbg_ctx(xhci, out_ctx, ep_index);
|
|
|
|
|
|
2009-09-04 17:53:13 +00:00
|
|
|
ret = xhci_configure_endpoint(xhci, urb->dev, NULL,
|
|
|
|
|
true, false);
|
2009-08-07 21:04:49 +00:00
|
|
|
|
|
|
|
|
/* Clean up the input context for later use by bandwidth
|
|
|
|
|
* functions.
|
|
|
|
|
*/
|
|
|
|
|
ctrl_ctx->add_flags = SLOT_FLAG;
|
|
|
|
|
}
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:58:01 +00:00
|
|
|
/*
|
|
|
|
|
* non-error returns are a promise to giveback() the urb later
|
|
|
|
|
* we drop ownership so next owner (or urb unlink) can get it
|
|
|
|
|
*/
|
|
|
|
|
int xhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flags)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
unsigned int slot_id, ep_index;
|
2010-07-22 22:23:31 +00:00
|
|
|
struct urb_priv *urb_priv;
|
|
|
|
|
int size, i;
|
2009-08-07 21:04:49 +00:00
|
|
|
|
2010-10-14 14:22:45 +00:00
|
|
|
if (!urb || xhci_check_args(hcd, urb->dev, urb->ep,
|
|
|
|
|
true, true, __func__) <= 0)
|
2009-04-28 02:58:01 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
slot_id = urb->dev->slot_id;
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&urb->ep->desc);
|
|
|
|
|
|
2010-06-22 20:39:10 +00:00
|
|
|
if (!HCD_HW_ACCESSIBLE(hcd)) {
|
2009-04-28 02:58:01 +00:00
|
|
|
if (!in_interrupt())
|
|
|
|
|
xhci_dbg(xhci, "urb submitted during PCI suspend\n");
|
|
|
|
|
ret = -ESHUTDOWN;
|
|
|
|
|
goto exit;
|
|
|
|
|
}
|
2010-07-22 22:23:31 +00:00
|
|
|
|
|
|
|
|
if (usb_endpoint_xfer_isoc(&urb->ep->desc))
|
|
|
|
|
size = urb->number_of_packets;
|
|
|
|
|
else
|
|
|
|
|
size = 1;
|
|
|
|
|
|
|
|
|
|
urb_priv = kzalloc(sizeof(struct urb_priv) +
|
|
|
|
|
size * sizeof(struct xhci_td *), mem_flags);
|
|
|
|
|
if (!urb_priv)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < size; i++) {
|
|
|
|
|
urb_priv->td[i] = kzalloc(sizeof(struct xhci_td), mem_flags);
|
|
|
|
|
if (!urb_priv->td[i]) {
|
|
|
|
|
urb_priv->length = i;
|
|
|
|
|
xhci_urb_free_priv(xhci, urb_priv);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
urb_priv->length = size;
|
|
|
|
|
urb_priv->td_cnt = 0;
|
|
|
|
|
urb->hcpriv = urb_priv;
|
|
|
|
|
|
2009-08-07 21:04:49 +00:00
|
|
|
if (usb_endpoint_xfer_control(&urb->ep->desc)) {
|
|
|
|
|
/* Check to see if the max packet size for the default control
|
|
|
|
|
* endpoint changed during FS device enumeration
|
|
|
|
|
*/
|
|
|
|
|
if (urb->dev->speed == USB_SPEED_FULL) {
|
|
|
|
|
ret = xhci_check_maxpacket(xhci, slot_id,
|
|
|
|
|
ep_index, urb);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-27 19:03:23 +00:00
|
|
|
/* We have a spinlock and interrupts disabled, so we must pass
|
|
|
|
|
* atomic context to this function, which may allocate memory.
|
|
|
|
|
*/
|
2009-08-07 21:04:49 +00:00
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 17:57:01 +00:00
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING)
|
|
|
|
|
goto dying;
|
2009-07-27 19:03:23 +00:00
|
|
|
ret = xhci_queue_ctrl_tx(xhci, GFP_ATOMIC, urb,
|
2009-04-30 02:05:20 +00:00
|
|
|
slot_id, ep_index);
|
2009-08-07 21:04:49 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
} else if (usb_endpoint_xfer_bulk(&urb->ep->desc)) {
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 17:57:01 +00:00
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING)
|
|
|
|
|
goto dying;
|
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-02 22:34:16 +00:00
|
|
|
if (xhci->devs[slot_id]->eps[ep_index].ep_state &
|
|
|
|
|
EP_GETTING_STREAMS) {
|
|
|
|
|
xhci_warn(xhci, "WARN: Can't enqueue URB while bulk ep "
|
|
|
|
|
"is transitioning to using streams.\n");
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
} else if (xhci->devs[slot_id]->eps[ep_index].ep_state &
|
|
|
|
|
EP_GETTING_NO_STREAMS) {
|
|
|
|
|
xhci_warn(xhci, "WARN: Can't enqueue URB while bulk ep "
|
|
|
|
|
"is transitioning to "
|
|
|
|
|
"not having streams.\n");
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
} else {
|
|
|
|
|
ret = xhci_queue_bulk_tx(xhci, GFP_ATOMIC, urb,
|
|
|
|
|
slot_id, ep_index);
|
|
|
|
|
}
|
2009-08-07 21:04:49 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
2009-09-02 19:14:28 +00:00
|
|
|
} else if (usb_endpoint_xfer_int(&urb->ep->desc)) {
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 17:57:01 +00:00
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING)
|
|
|
|
|
goto dying;
|
2009-09-02 19:14:28 +00:00
|
|
|
ret = xhci_queue_intr_tx(xhci, GFP_ATOMIC, urb,
|
|
|
|
|
slot_id, ep_index);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
2009-08-07 21:04:49 +00:00
|
|
|
} else {
|
2010-07-22 22:23:52 +00:00
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING)
|
|
|
|
|
goto dying;
|
|
|
|
|
ret = xhci_queue_isoc_tx_prepare(xhci, GFP_ATOMIC, urb,
|
|
|
|
|
slot_id, ep_index);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
2009-08-07 21:04:49 +00:00
|
|
|
}
|
2009-04-28 02:58:01 +00:00
|
|
|
exit:
|
|
|
|
|
return ret;
|
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-27 17:57:01 +00:00
|
|
|
dying:
|
2010-07-22 22:23:31 +00:00
|
|
|
xhci_urb_free_priv(xhci, urb_priv);
|
|
|
|
|
urb->hcpriv = NULL;
|
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-27 17:57:01 +00:00
|
|
|
xhci_dbg(xhci, "Ep 0x%x: URB %p submitted for "
|
|
|
|
|
"non-responsive xHCI host.\n",
|
|
|
|
|
urb->ep->desc.bEndpointAddress, urb);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return -ESHUTDOWN;
|
2009-04-28 02:58:01 +00:00
|
|
|
}
|
|
|
|
|
|
2010-07-30 05:12:20 +00:00
|
|
|
/* Get the right ring for the given URB.
|
|
|
|
|
* If the endpoint supports streams, boundary check the URB's stream ID.
|
|
|
|
|
* If the endpoint doesn't support streams, return the singular endpoint ring.
|
|
|
|
|
*/
|
|
|
|
|
static struct xhci_ring *xhci_urb_to_transfer_ring(struct xhci_hcd *xhci,
|
|
|
|
|
struct urb *urb)
|
|
|
|
|
{
|
|
|
|
|
unsigned int slot_id;
|
|
|
|
|
unsigned int ep_index;
|
|
|
|
|
unsigned int stream_id;
|
|
|
|
|
struct xhci_virt_ep *ep;
|
|
|
|
|
|
|
|
|
|
slot_id = urb->dev->slot_id;
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&urb->ep->desc);
|
|
|
|
|
stream_id = urb->stream_id;
|
|
|
|
|
ep = &xhci->devs[slot_id]->eps[ep_index];
|
|
|
|
|
/* Common case: no streams */
|
|
|
|
|
if (!(ep->ep_state & EP_HAS_STREAMS))
|
|
|
|
|
return ep->ring;
|
|
|
|
|
|
|
|
|
|
if (stream_id == 0) {
|
|
|
|
|
xhci_warn(xhci,
|
|
|
|
|
"WARN: Slot ID %u, ep index %u has streams, "
|
|
|
|
|
"but URB has no stream ID.\n",
|
|
|
|
|
slot_id, ep_index);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (stream_id < ep->stream_info->num_streams)
|
|
|
|
|
return ep->stream_info->stream_rings[stream_id];
|
|
|
|
|
|
|
|
|
|
xhci_warn(xhci,
|
|
|
|
|
"WARN: Slot ID %u, ep index %u has "
|
|
|
|
|
"stream IDs 1 to %u allocated, "
|
|
|
|
|
"but stream ID %u is requested.\n",
|
|
|
|
|
slot_id, ep_index,
|
|
|
|
|
ep->stream_info->num_streams - 1,
|
|
|
|
|
stream_id);
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 02:02:31 +00:00
|
|
|
/*
|
|
|
|
|
* Remove the URB's TD from the endpoint ring. This may cause the HC to stop
|
|
|
|
|
* USB transfers, potentially stopping in the middle of a TRB buffer. The HC
|
|
|
|
|
* should pick up where it left off in the TD, unless a Set Transfer Ring
|
|
|
|
|
* Dequeue Pointer is issued.
|
|
|
|
|
*
|
|
|
|
|
* The TRBs that make up the buffers for the canceled URB will be "removed" from
|
|
|
|
|
* the ring. Since the ring is a contiguous structure, they can't be physically
|
|
|
|
|
* removed. Instead, there are two options:
|
|
|
|
|
*
|
|
|
|
|
* 1) If the HC is in the middle of processing the URB to be canceled, we
|
|
|
|
|
* simply move the ring's dequeue pointer past those TRBs using the Set
|
|
|
|
|
* Transfer Ring Dequeue Pointer command. This will be the common case,
|
|
|
|
|
* when drivers timeout on the last submitted URB and attempt to cancel.
|
|
|
|
|
*
|
|
|
|
|
* 2) If the HC is in the middle of a different TD, we turn the TRBs into a
|
|
|
|
|
* series of 1-TRB transfer no-op TDs. (No-ops shouldn't be chained.) The
|
|
|
|
|
* HC will need to invalidate the any TRBs it has cached after the stop
|
|
|
|
|
* endpoint command, as noted in the xHCI 0.95 errata.
|
|
|
|
|
*
|
|
|
|
|
* 3) The TD may have completed by the time the Stop Endpoint Command
|
|
|
|
|
* completes, so software needs to handle that case too.
|
|
|
|
|
*
|
|
|
|
|
* This function should protect against the TD enqueueing code ringing the
|
|
|
|
|
* doorbell while this code is waiting for a Stop Endpoint command to complete.
|
|
|
|
|
* It also needs to account for multiple cancellations on happening at the same
|
|
|
|
|
* time for the same endpoint.
|
|
|
|
|
*
|
|
|
|
|
* Note that this function can be called in any context, or so says
|
|
|
|
|
* usb_hcd_unlink_urb()
|
2009-04-28 02:58:01 +00:00
|
|
|
*/
|
|
|
|
|
int xhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status)
|
|
|
|
|
{
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 02:02:31 +00:00
|
|
|
unsigned long flags;
|
2010-07-22 22:23:31 +00:00
|
|
|
int ret, i;
|
2009-09-29 00:21:37 +00:00
|
|
|
u32 temp;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 02:02:31 +00:00
|
|
|
struct xhci_hcd *xhci;
|
2010-07-22 22:23:31 +00:00
|
|
|
struct urb_priv *urb_priv;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 02:02:31 +00:00
|
|
|
struct xhci_td *td;
|
|
|
|
|
unsigned int ep_index;
|
|
|
|
|
struct xhci_ring *ep_ring;
|
2009-09-04 17:53:09 +00:00
|
|
|
struct xhci_virt_ep *ep;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 02:02:31 +00:00
|
|
|
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
/* Make sure the URB hasn't completed or been unlinked already */
|
|
|
|
|
ret = usb_hcd_check_unlink_urb(hcd, urb, status);
|
|
|
|
|
if (ret || !urb->hcpriv)
|
|
|
|
|
goto done;
|
2009-09-29 00:21:37 +00:00
|
|
|
temp = xhci_readl(xhci, &xhci->op_regs->status);
|
|
|
|
|
if (temp == 0xffffffff) {
|
|
|
|
|
xhci_dbg(xhci, "HW died, freeing TD.\n");
|
2010-07-22 22:23:31 +00:00
|
|
|
urb_priv = urb->hcpriv;
|
2009-09-29 00:21:37 +00:00
|
|
|
|
|
|
|
|
usb_hcd_unlink_urb_from_ep(hcd, urb);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
usb_hcd_giveback_urb(xhci_to_hcd(xhci), urb, -ESHUTDOWN);
|
2010-07-22 22:23:31 +00:00
|
|
|
xhci_urb_free_priv(xhci, urb_priv);
|
2009-09-29 00:21:37 +00:00
|
|
|
return ret;
|
|
|
|
|
}
|
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-27 17:57:01 +00:00
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING) {
|
|
|
|
|
xhci_dbg(xhci, "Ep 0x%x: URB %p to be canceled on "
|
|
|
|
|
"non-responsive xHCI host.\n",
|
|
|
|
|
urb->ep->desc.bEndpointAddress, urb);
|
|
|
|
|
/* Let the stop endpoint command watchdog timer (which set this
|
|
|
|
|
* state) finish cleaning up the endpoint TD lists. We must
|
|
|
|
|
* have caught it in the middle of dropping a lock and giving
|
|
|
|
|
* back an URB.
|
|
|
|
|
*/
|
|
|
|
|
goto done;
|
|
|
|
|
}
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 02:02:31 +00:00
|
|
|
|
2009-04-30 02:14:08 +00:00
|
|
|
xhci_dbg(xhci, "Cancel URB %p\n", urb);
|
2009-07-27 19:03:46 +00:00
|
|
|
xhci_dbg(xhci, "Event ring:\n");
|
|
|
|
|
xhci_debug_ring(xhci, xhci->event_ring);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 02:02:31 +00:00
|
|
|
ep_index = xhci_get_endpoint_index(&urb->ep->desc);
|
2009-09-04 17:53:09 +00:00
|
|
|
ep = &xhci->devs[urb->dev->slot_id]->eps[ep_index];
|
2010-04-02 22:34:43 +00:00
|
|
|
ep_ring = xhci_urb_to_transfer_ring(xhci, urb);
|
|
|
|
|
if (!ep_ring) {
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
goto done;
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-27 19:03:46 +00:00
|
|
|
xhci_dbg(xhci, "Endpoint ring:\n");
|
|
|
|
|
xhci_debug_ring(xhci, ep_ring);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 02:02:31 +00:00
|
|
|
|
2010-07-22 22:23:31 +00:00
|
|
|
urb_priv = urb->hcpriv;
|
|
|
|
|
|
|
|
|
|
for (i = urb_priv->td_cnt; i < urb_priv->length; i++) {
|
|
|
|
|
td = urb_priv->td[i];
|
|
|
|
|
list_add_tail(&td->cancelled_td_list, &ep->cancelled_td_list);
|
|
|
|
|
}
|
|
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 02:02:31 +00:00
|
|
|
/* Queue a stop endpoint command, but only if this is
|
|
|
|
|
* the first cancellation to be handled.
|
|
|
|
|
*/
|
USB: xhci: Handle URB cancel, complete and resubmit race.
In the old code, there was a race condition between the stop endpoint
command and the URB submission process. When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell. The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.
However, the following race condition could occur with the old code:
1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
(at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted. An
event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
canceled, decrements ep->cancels_pending to 0, and removes it from the to
be canceled list.
5. The event handler drops the lock and gives back the URB. The
completion handler requeues the URB (or a different driver enqueues a new
URB). This causes the endpoint's doorbell to be rung, since
ep->cancels_pending == 0. The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command. The
handler assumes the endpoint is stopped, but it isn't. It attempts to
move the dequeue pointer or change TDs to cancel the second URB, while the
hardware is actively accessing the endpoint ring.
To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING. When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet. The endpoint doorbell should not be rung when this
is set. Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell. ep->cancels_pending is eliminated, because it is no longer
used.
Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty. All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 17:55:52 +00:00
|
|
|
if (!(ep->ep_state & EP_HALT_PENDING)) {
|
|
|
|
|
ep->ep_state |= EP_HALT_PENDING;
|
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-27 17:57:01 +00:00
|
|
|
ep->stop_cmds_pending++;
|
|
|
|
|
ep->stop_cmd_timer.expires = jiffies +
|
|
|
|
|
XHCI_STOP_EP_CMD_TIMEOUT * HZ;
|
|
|
|
|
add_timer(&ep->stop_cmd_timer);
|
2010-10-14 14:22:57 +00:00
|
|
|
xhci_queue_stop_endpoint(xhci, urb->dev->slot_id, ep_index, 0);
|
2009-04-30 02:05:20 +00:00
|
|
|
xhci_ring_cmd_db(xhci);
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 02:02:31 +00:00
|
|
|
}
|
|
|
|
|
done:
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return ret;
|
2009-04-28 02:58:01 +00: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 02:58:38 +00:00
|
|
|
/* Drop an endpoint from a new bandwidth configuration for this device.
|
|
|
|
|
* Only one call to this function is allowed per endpoint before
|
|
|
|
|
* check_bandwidth() or reset_bandwidth() must be called.
|
|
|
|
|
* A call to xhci_drop_endpoint() followed by a call to xhci_add_endpoint() will
|
|
|
|
|
* add the endpoint to the schedule with possibly new parameters denoted by a
|
|
|
|
|
* different endpoint descriptor in usb_host_endpoint.
|
|
|
|
|
* A call to xhci_add_endpoint() followed by a call to xhci_drop_endpoint() is
|
|
|
|
|
* not allowed.
|
2009-05-14 18:44:22 +00:00
|
|
|
*
|
|
|
|
|
* The USB core will not allow URBs to be queued to an endpoint that is being
|
|
|
|
|
* disabled, so there's no need for mutual exclusion to protect
|
|
|
|
|
* the xhci->devs[slot_id] structure.
|
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 02:58:38 +00:00
|
|
|
*/
|
|
|
|
|
int xhci_drop_endpoint(struct usb_hcd *hcd, struct usb_device *udev,
|
|
|
|
|
struct usb_host_endpoint *ep)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci;
|
2009-07-27 19:05:15 +00:00
|
|
|
struct xhci_container_ctx *in_ctx, *out_ctx;
|
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
|
|
|
|
struct xhci_slot_ctx *slot_ctx;
|
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 02:58:38 +00:00
|
|
|
unsigned int last_ctx;
|
|
|
|
|
unsigned int ep_index;
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
|
u32 drop_flag;
|
|
|
|
|
u32 new_add_flags, new_drop_flags, new_slot_info;
|
|
|
|
|
int ret;
|
|
|
|
|
|
2010-10-14 14:22:45 +00:00
|
|
|
ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
|
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 02:58:38 +00:00
|
|
|
if (ret <= 0)
|
|
|
|
|
return ret;
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
2009-04-30 02:14:08 +00:00
|
|
|
xhci_dbg(xhci, "%s called for udev %p\n", __func__, 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 02:58:38 +00:00
|
|
|
|
|
|
|
|
drop_flag = xhci_get_endpoint_flag(&ep->desc);
|
|
|
|
|
if (drop_flag == SLOT_FLAG || drop_flag == EP0_FLAG) {
|
|
|
|
|
xhci_dbg(xhci, "xHCI %s - can't drop slot or ep 0 %#x\n",
|
|
|
|
|
__func__, drop_flag);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
in_ctx = xhci->devs[udev->slot_id]->in_ctx;
|
2009-07-27 19:05:15 +00:00
|
|
|
out_ctx = xhci->devs[udev->slot_id]->out_ctx;
|
|
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
|
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 02:58:38 +00:00
|
|
|
ep_index = xhci_get_endpoint_index(&ep->desc);
|
2009-07-27 19:05:15 +00:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, out_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 02:58:38 +00:00
|
|
|
/* If the HC already knows the endpoint is disabled,
|
|
|
|
|
* or the HCD has noted it is disabled, ignore this request
|
|
|
|
|
*/
|
|
|
|
|
if ((ep_ctx->ep_info & EP_STATE_MASK) == EP_STATE_DISABLED ||
|
2009-07-27 19:05:15 +00:00
|
|
|
ctrl_ctx->drop_flags & xhci_get_endpoint_flag(&ep->desc)) {
|
2009-04-30 02:14:08 +00:00
|
|
|
xhci_warn(xhci, "xHCI %s called with disabled ep %p\n",
|
|
|
|
|
__func__, 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 02:58:38 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-27 19:05:15 +00:00
|
|
|
ctrl_ctx->drop_flags |= drop_flag;
|
|
|
|
|
new_drop_flags = ctrl_ctx->drop_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 02:58:38 +00:00
|
|
|
|
2009-09-18 15:55:12 +00:00
|
|
|
ctrl_ctx->add_flags &= ~drop_flag;
|
2009-07-27 19:05:15 +00:00
|
|
|
new_add_flags = ctrl_ctx->add_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 02:58:38 +00:00
|
|
|
|
2009-07-27 19:05:15 +00:00
|
|
|
last_ctx = xhci_last_valid_endpoint(ctrl_ctx->add_flags);
|
|
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
|
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 02:58:38 +00:00
|
|
|
/* Update the last valid endpoint context, if we deleted the last one */
|
2009-07-27 19:05:15 +00:00
|
|
|
if ((slot_ctx->dev_info & LAST_CTX_MASK) > LAST_CTX(last_ctx)) {
|
|
|
|
|
slot_ctx->dev_info &= ~LAST_CTX_MASK;
|
|
|
|
|
slot_ctx->dev_info |= LAST_CTX(last_ctx);
|
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 02:58:38 +00:00
|
|
|
}
|
2009-07-27 19:05:15 +00:00
|
|
|
new_slot_info = slot_ctx->dev_info;
|
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 02:58:38 +00:00
|
|
|
|
|
|
|
|
xhci_endpoint_zero(xhci, xhci->devs[udev->slot_id], ep);
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "drop ep 0x%x, slot id %d, new drop flags = %#x, new add flags = %#x, new slot info = %#x\n",
|
|
|
|
|
(unsigned int) ep->desc.bEndpointAddress,
|
|
|
|
|
udev->slot_id,
|
|
|
|
|
(unsigned int) new_drop_flags,
|
|
|
|
|
(unsigned int) new_add_flags,
|
|
|
|
|
(unsigned int) new_slot_info);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add an endpoint to a new possible bandwidth configuration for this device.
|
|
|
|
|
* Only one call to this function is allowed per endpoint before
|
|
|
|
|
* check_bandwidth() or reset_bandwidth() must be called.
|
|
|
|
|
* A call to xhci_drop_endpoint() followed by a call to xhci_add_endpoint() will
|
|
|
|
|
* add the endpoint to the schedule with possibly new parameters denoted by a
|
|
|
|
|
* different endpoint descriptor in usb_host_endpoint.
|
|
|
|
|
* A call to xhci_add_endpoint() followed by a call to xhci_drop_endpoint() is
|
|
|
|
|
* not allowed.
|
2009-05-14 18:44:22 +00:00
|
|
|
*
|
|
|
|
|
* The USB core will not allow URBs to be queued to an endpoint until the
|
|
|
|
|
* configuration or alt setting is installed in the device, so there's no need
|
|
|
|
|
* for mutual exclusion to protect the xhci->devs[slot_id] structure.
|
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 02:58:38 +00:00
|
|
|
*/
|
|
|
|
|
int xhci_add_endpoint(struct usb_hcd *hcd, struct usb_device *udev,
|
|
|
|
|
struct usb_host_endpoint *ep)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci;
|
2009-07-27 19:05:15 +00:00
|
|
|
struct xhci_container_ctx *in_ctx, *out_ctx;
|
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 02:58:38 +00:00
|
|
|
unsigned int ep_index;
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
2009-07-27 19:05:15 +00:00
|
|
|
struct xhci_slot_ctx *slot_ctx;
|
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
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 02:58:38 +00:00
|
|
|
u32 added_ctxs;
|
|
|
|
|
unsigned int last_ctx;
|
|
|
|
|
u32 new_add_flags, new_drop_flags, new_slot_info;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
|
2010-10-14 14:22:45 +00:00
|
|
|
ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
|
2009-07-27 19:03:15 +00:00
|
|
|
if (ret <= 0) {
|
|
|
|
|
/* So we won't queue a reset ep command for a root hub */
|
|
|
|
|
ep->hcpriv = NULL;
|
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 02:58:38 +00:00
|
|
|
return ret;
|
2009-07-27 19:03:15 +00: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 02:58:38 +00:00
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
|
|
|
|
|
added_ctxs = xhci_get_endpoint_flag(&ep->desc);
|
|
|
|
|
last_ctx = xhci_last_valid_endpoint(added_ctxs);
|
|
|
|
|
if (added_ctxs == SLOT_FLAG || added_ctxs == EP0_FLAG) {
|
|
|
|
|
/* FIXME when we have to issue an evaluate endpoint command to
|
|
|
|
|
* deal with ep0 max packet size changing once we get the
|
|
|
|
|
* descriptors
|
|
|
|
|
*/
|
|
|
|
|
xhci_dbg(xhci, "xHCI %s - can't add slot or ep 0 %#x\n",
|
|
|
|
|
__func__, added_ctxs);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
in_ctx = xhci->devs[udev->slot_id]->in_ctx;
|
2009-07-27 19:05:15 +00:00
|
|
|
out_ctx = xhci->devs[udev->slot_id]->out_ctx;
|
|
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
|
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 02:58:38 +00:00
|
|
|
ep_index = xhci_get_endpoint_index(&ep->desc);
|
2009-07-27 19:05:15 +00:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, out_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 02:58:38 +00:00
|
|
|
/* If the HCD has already noted the endpoint is enabled,
|
|
|
|
|
* ignore this request.
|
|
|
|
|
*/
|
2009-07-27 19:05:15 +00:00
|
|
|
if (ctrl_ctx->add_flags & xhci_get_endpoint_flag(&ep->desc)) {
|
2009-04-30 02:14:08 +00:00
|
|
|
xhci_warn(xhci, "xHCI %s called with enabled ep %p\n",
|
|
|
|
|
__func__, 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 02:58:38 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-05-14 18:44:22 +00:00
|
|
|
/*
|
|
|
|
|
* Configuration and alternate setting changes must be done in
|
|
|
|
|
* process context, not interrupt context (or so documenation
|
|
|
|
|
* for usb_set_interface() and usb_set_configuration() claim).
|
|
|
|
|
*/
|
|
|
|
|
if (xhci_endpoint_init(xhci, xhci->devs[udev->slot_id],
|
2009-12-16 18:43:59 +00:00
|
|
|
udev, ep, GFP_NOIO) < 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 02:58:38 +00:00
|
|
|
dev_dbg(&udev->dev, "%s - could not initialize ep %#x\n",
|
|
|
|
|
__func__, ep->desc.bEndpointAddress);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-27 19:05:15 +00:00
|
|
|
ctrl_ctx->add_flags |= added_ctxs;
|
|
|
|
|
new_add_flags = ctrl_ctx->add_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 02:58:38 +00:00
|
|
|
|
|
|
|
|
/* If xhci_endpoint_disable() was called for this endpoint, but the
|
|
|
|
|
* xHC hasn't been notified yet through the check_bandwidth() call,
|
|
|
|
|
* this re-adds a new state for the endpoint from the new endpoint
|
|
|
|
|
* descriptors. We must drop and re-add this endpoint, so we leave the
|
|
|
|
|
* drop flags alone.
|
|
|
|
|
*/
|
2009-07-27 19:05:15 +00:00
|
|
|
new_drop_flags = ctrl_ctx->drop_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 02:58:38 +00:00
|
|
|
|
2009-07-27 19:05:15 +00:00
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
|
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 02:58:38 +00:00
|
|
|
/* Update the last valid endpoint context, if we just added one past */
|
2009-07-27 19:05:15 +00:00
|
|
|
if ((slot_ctx->dev_info & LAST_CTX_MASK) < LAST_CTX(last_ctx)) {
|
|
|
|
|
slot_ctx->dev_info &= ~LAST_CTX_MASK;
|
|
|
|
|
slot_ctx->dev_info |= LAST_CTX(last_ctx);
|
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 02:58:38 +00:00
|
|
|
}
|
2009-07-27 19:05:15 +00:00
|
|
|
new_slot_info = slot_ctx->dev_info;
|
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 02:58:38 +00:00
|
|
|
|
2009-07-27 19:03:15 +00:00
|
|
|
/* Store the usb_device pointer for later use */
|
|
|
|
|
ep->hcpriv = 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 02:58:38 +00:00
|
|
|
xhci_dbg(xhci, "add ep 0x%x, slot id %d, new drop flags = %#x, new add flags = %#x, new slot info = %#x\n",
|
|
|
|
|
(unsigned int) ep->desc.bEndpointAddress,
|
|
|
|
|
udev->slot_id,
|
|
|
|
|
(unsigned int) new_drop_flags,
|
|
|
|
|
(unsigned int) new_add_flags,
|
|
|
|
|
(unsigned int) new_slot_info);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-07-27 19:05:15 +00:00
|
|
|
static void xhci_zero_in_ctx(struct xhci_hcd *xhci, struct xhci_virt_device *virt_dev)
|
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 02:58:38 +00:00
|
|
|
{
|
2009-07-27 19:05:15 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
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 02:58:38 +00:00
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
2009-07-27 19:05:15 +00:00
|
|
|
struct xhci_slot_ctx *slot_ctx;
|
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 02:58:38 +00:00
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
/* When a device's add flag and drop flag are zero, any subsequent
|
|
|
|
|
* configure endpoint command will leave that endpoint's state
|
|
|
|
|
* untouched. Make sure we don't leave any old state in the input
|
|
|
|
|
* endpoint contexts.
|
|
|
|
|
*/
|
2009-07-27 19:05:15 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, virt_dev->in_ctx);
|
|
|
|
|
ctrl_ctx->drop_flags = 0;
|
|
|
|
|
ctrl_ctx->add_flags = 0;
|
|
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->in_ctx);
|
|
|
|
|
slot_ctx->dev_info &= ~LAST_CTX_MASK;
|
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 02:58:38 +00:00
|
|
|
/* Endpoint 0 is always valid */
|
2009-07-27 19:05:15 +00:00
|
|
|
slot_ctx->dev_info |= LAST_CTX(1);
|
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 02:58:38 +00:00
|
|
|
for (i = 1; i < 31; ++i) {
|
2009-07-27 19:05:15 +00:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, i);
|
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 02:58:38 +00:00
|
|
|
ep_ctx->ep_info = 0;
|
|
|
|
|
ep_ctx->ep_info2 = 0;
|
2009-07-27 19:03:31 +00: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 02:58:38 +00:00
|
|
|
ep_ctx->tx_info = 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-08-07 21:04:43 +00:00
|
|
|
static int xhci_configure_endpoint_result(struct xhci_hcd *xhci,
|
2009-09-04 17:53:13 +00:00
|
|
|
struct usb_device *udev, int *cmd_status)
|
2009-08-07 21:04:43 +00:00
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
|
2009-09-04 17:53:13 +00:00
|
|
|
switch (*cmd_status) {
|
2009-08-07 21:04:43 +00:00
|
|
|
case COMP_ENOMEM:
|
|
|
|
|
dev_warn(&udev->dev, "Not enough host controller resources "
|
|
|
|
|
"for new device state.\n");
|
|
|
|
|
ret = -ENOMEM;
|
|
|
|
|
/* FIXME: can we allocate more resources for the HC? */
|
|
|
|
|
break;
|
|
|
|
|
case COMP_BW_ERR:
|
|
|
|
|
dev_warn(&udev->dev, "Not enough bandwidth "
|
|
|
|
|
"for new device state.\n");
|
|
|
|
|
ret = -ENOSPC;
|
|
|
|
|
/* FIXME: can we go back to the old state? */
|
|
|
|
|
break;
|
|
|
|
|
case COMP_TRB_ERR:
|
|
|
|
|
/* the HCD set up something wrong */
|
|
|
|
|
dev_warn(&udev->dev, "ERROR: Endpoint drop flag = 0, "
|
|
|
|
|
"add flag = 1, "
|
|
|
|
|
"and endpoint is not disabled.\n");
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
case COMP_SUCCESS:
|
|
|
|
|
dev_dbg(&udev->dev, "Successful Endpoint Configure command\n");
|
|
|
|
|
ret = 0;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
xhci_err(xhci, "ERROR: unexpected command completion "
|
2009-09-04 17:53:13 +00:00
|
|
|
"code 0x%x.\n", *cmd_status);
|
2009-08-07 21:04:43 +00:00
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int xhci_evaluate_context_result(struct xhci_hcd *xhci,
|
2009-09-04 17:53:13 +00:00
|
|
|
struct usb_device *udev, int *cmd_status)
|
2009-08-07 21:04:43 +00:00
|
|
|
{
|
|
|
|
|
int ret;
|
2009-09-04 17:53:13 +00:00
|
|
|
struct xhci_virt_device *virt_dev = xhci->devs[udev->slot_id];
|
2009-08-07 21:04:43 +00:00
|
|
|
|
2009-09-04 17:53:13 +00:00
|
|
|
switch (*cmd_status) {
|
2009-08-07 21:04:43 +00:00
|
|
|
case COMP_EINVAL:
|
|
|
|
|
dev_warn(&udev->dev, "WARN: xHCI driver setup invalid evaluate "
|
|
|
|
|
"context command.\n");
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
case COMP_EBADSLT:
|
|
|
|
|
dev_warn(&udev->dev, "WARN: slot not enabled for"
|
|
|
|
|
"evaluate context command.\n");
|
|
|
|
|
case COMP_CTX_STATE:
|
|
|
|
|
dev_warn(&udev->dev, "WARN: invalid context state for "
|
|
|
|
|
"evaluate context command.\n");
|
|
|
|
|
xhci_dbg_ctx(xhci, virt_dev->out_ctx, 1);
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
case COMP_SUCCESS:
|
|
|
|
|
dev_dbg(&udev->dev, "Successful evaluate context command\n");
|
|
|
|
|
ret = 0;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
xhci_err(xhci, "ERROR: unexpected command completion "
|
2009-09-04 17:53:13 +00:00
|
|
|
"code 0x%x.\n", *cmd_status);
|
2009-08-07 21:04:43 +00:00
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Issue a configure endpoint command or evaluate context command
|
|
|
|
|
* and wait for it to finish.
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_configure_endpoint(struct xhci_hcd *xhci,
|
2009-09-04 17:53:13 +00:00
|
|
|
struct usb_device *udev,
|
|
|
|
|
struct xhci_command *command,
|
|
|
|
|
bool ctx_change, bool must_succeed)
|
2009-08-07 21:04:43 +00:00
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
int timeleft;
|
|
|
|
|
unsigned long flags;
|
2009-09-04 17:53:13 +00:00
|
|
|
struct xhci_container_ctx *in_ctx;
|
|
|
|
|
struct completion *cmd_completion;
|
|
|
|
|
int *cmd_status;
|
|
|
|
|
struct xhci_virt_device *virt_dev;
|
2009-08-07 21:04:43 +00:00
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
2009-09-04 17:53:13 +00:00
|
|
|
virt_dev = xhci->devs[udev->slot_id];
|
|
|
|
|
if (command) {
|
|
|
|
|
in_ctx = command->in_ctx;
|
|
|
|
|
cmd_completion = command->completion;
|
|
|
|
|
cmd_status = &command->status;
|
|
|
|
|
command->command_trb = xhci->cmd_ring->enqueue;
|
|
|
|
|
list_add_tail(&command->cmd_list, &virt_dev->cmd_list);
|
|
|
|
|
} else {
|
|
|
|
|
in_ctx = virt_dev->in_ctx;
|
|
|
|
|
cmd_completion = &virt_dev->cmd_completion;
|
|
|
|
|
cmd_status = &virt_dev->cmd_status;
|
|
|
|
|
}
|
2010-03-12 09:10:04 +00:00
|
|
|
init_completion(cmd_completion);
|
2009-09-04 17:53:13 +00:00
|
|
|
|
2009-08-07 21:04:43 +00:00
|
|
|
if (!ctx_change)
|
2009-09-04 17:53:13 +00:00
|
|
|
ret = xhci_queue_configure_endpoint(xhci, in_ctx->dma,
|
|
|
|
|
udev->slot_id, must_succeed);
|
2009-08-07 21:04:43 +00:00
|
|
|
else
|
2009-09-04 17:53:13 +00:00
|
|
|
ret = xhci_queue_evaluate_context(xhci, in_ctx->dma,
|
2009-08-07 21:04:43 +00:00
|
|
|
udev->slot_id);
|
|
|
|
|
if (ret < 0) {
|
2009-12-09 23:58:58 +00:00
|
|
|
if (command)
|
|
|
|
|
list_del(&command->cmd_list);
|
2009-08-07 21:04:43 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
xhci_dbg(xhci, "FIXME allocate a new ring segment\n");
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
/* Wait for the configure endpoint command to complete */
|
|
|
|
|
timeleft = wait_for_completion_interruptible_timeout(
|
2009-09-04 17:53:13 +00:00
|
|
|
cmd_completion,
|
2009-08-07 21:04:43 +00:00
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
|
if (timeleft <= 0) {
|
|
|
|
|
xhci_warn(xhci, "%s while waiting for %s command\n",
|
|
|
|
|
timeleft == 0 ? "Timeout" : "Signal",
|
|
|
|
|
ctx_change == 0 ?
|
|
|
|
|
"configure endpoint" :
|
|
|
|
|
"evaluate context");
|
|
|
|
|
/* FIXME cancel the configure endpoint command */
|
|
|
|
|
return -ETIME;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!ctx_change)
|
2009-09-04 17:53:13 +00:00
|
|
|
return xhci_configure_endpoint_result(xhci, udev, cmd_status);
|
|
|
|
|
return xhci_evaluate_context_result(xhci, udev, cmd_status);
|
2009-08-07 21:04:43 +00:00
|
|
|
}
|
|
|
|
|
|
2009-05-14 18:44:22 +00:00
|
|
|
/* Called after one or more calls to xhci_add_endpoint() or
|
|
|
|
|
* xhci_drop_endpoint(). If this call fails, the USB core is expected
|
|
|
|
|
* to call xhci_reset_bandwidth().
|
|
|
|
|
*
|
|
|
|
|
* Since we are in the middle of changing either configuration or
|
|
|
|
|
* installing a new alt setting, the USB core won't allow URBs to be
|
|
|
|
|
* enqueued for any endpoint on the old config or interface. Nothing
|
|
|
|
|
* else should be touching the xhci->devs[slot_id] structure, so we
|
|
|
|
|
* don't need to take the xhci->lock for manipulating 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 02:58:38 +00:00
|
|
|
int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
struct xhci_virt_device *virt_dev;
|
2009-07-27 19:05:15 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
|
|
|
|
struct xhci_slot_ctx *slot_ctx;
|
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 02:58:38 +00:00
|
|
|
|
2010-10-14 14:22:45 +00:00
|
|
|
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
|
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 02:58:38 +00:00
|
|
|
if (ret <= 0)
|
|
|
|
|
return ret;
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
|
2009-04-30 02:14:08 +00:00
|
|
|
xhci_dbg(xhci, "%s called for udev %p\n", __func__, 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 02:58:38 +00:00
|
|
|
virt_dev = xhci->devs[udev->slot_id];
|
|
|
|
|
|
|
|
|
|
/* See section 4.6.6 - A0 = 1; A1 = D0 = D1 = 0 */
|
2009-07-27 19:05:15 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, virt_dev->in_ctx);
|
|
|
|
|
ctrl_ctx->add_flags |= SLOT_FLAG;
|
|
|
|
|
ctrl_ctx->add_flags &= ~EP0_FLAG;
|
|
|
|
|
ctrl_ctx->drop_flags &= ~SLOT_FLAG;
|
|
|
|
|
ctrl_ctx->drop_flags &= ~EP0_FLAG;
|
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 02:58:38 +00:00
|
|
|
xhci_dbg(xhci, "New Input Control Context:\n");
|
2009-07-27 19:05:15 +00:00
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->in_ctx);
|
|
|
|
|
xhci_dbg_ctx(xhci, virt_dev->in_ctx,
|
|
|
|
|
LAST_CTX_TO_EP_NUM(slot_ctx->dev_info));
|
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 02:58:38 +00:00
|
|
|
|
2009-09-04 17:53:13 +00:00
|
|
|
ret = xhci_configure_endpoint(xhci, udev, NULL,
|
|
|
|
|
false, false);
|
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 02:58:38 +00:00
|
|
|
if (ret) {
|
|
|
|
|
/* Callee should call reset_bandwidth() */
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Output context after successful config ep cmd:\n");
|
2009-07-27 19:05:15 +00:00
|
|
|
xhci_dbg_ctx(xhci, virt_dev->out_ctx,
|
|
|
|
|
LAST_CTX_TO_EP_NUM(slot_ctx->dev_info));
|
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 02:58:38 +00:00
|
|
|
|
2009-07-27 19:05:15 +00:00
|
|
|
xhci_zero_in_ctx(xhci, virt_dev);
|
2009-12-03 17:44:29 +00:00
|
|
|
/* Install new rings and free or cache any old rings */
|
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 02:58:38 +00:00
|
|
|
for (i = 1; i < 31; ++i) {
|
2009-12-03 17:44:29 +00:00
|
|
|
if (!virt_dev->eps[i].new_ring)
|
|
|
|
|
continue;
|
|
|
|
|
/* Only cache or free the old ring if it exists.
|
|
|
|
|
* It may not if this is the first add of an endpoint.
|
|
|
|
|
*/
|
|
|
|
|
if (virt_dev->eps[i].ring) {
|
2009-12-09 23:59:01 +00:00
|
|
|
xhci_free_or_cache_endpoint_ring(xhci, virt_dev, i);
|
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 02:58:38 +00:00
|
|
|
}
|
2009-12-03 17:44:29 +00:00
|
|
|
virt_dev->eps[i].ring = virt_dev->eps[i].new_ring;
|
|
|
|
|
virt_dev->eps[i].new_ring = NULL;
|
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 02:58:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void xhci_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
struct xhci_virt_device *virt_dev;
|
|
|
|
|
int i, ret;
|
|
|
|
|
|
2010-10-14 14:22:45 +00:00
|
|
|
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
|
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 02:58:38 +00:00
|
|
|
if (ret <= 0)
|
|
|
|
|
return;
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
|
2009-04-30 02:14:08 +00:00
|
|
|
xhci_dbg(xhci, "%s called for udev %p\n", __func__, 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 02:58:38 +00:00
|
|
|
virt_dev = xhci->devs[udev->slot_id];
|
|
|
|
|
/* Free any rings allocated for added endpoints */
|
|
|
|
|
for (i = 0; i < 31; ++i) {
|
2009-09-04 17:53:09 +00:00
|
|
|
if (virt_dev->eps[i].new_ring) {
|
|
|
|
|
xhci_ring_free(xhci, virt_dev->eps[i].new_ring);
|
|
|
|
|
virt_dev->eps[i].new_ring = NULL;
|
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 02:58:38 +00:00
|
|
|
}
|
|
|
|
|
}
|
2009-07-27 19:05:15 +00:00
|
|
|
xhci_zero_in_ctx(xhci, virt_dev);
|
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 02:58:38 +00:00
|
|
|
}
|
|
|
|
|
|
2009-09-04 17:53:11 +00:00
|
|
|
static void xhci_setup_input_ctx_for_config_ep(struct xhci_hcd *xhci,
|
2009-09-04 17:53:13 +00:00
|
|
|
struct xhci_container_ctx *in_ctx,
|
|
|
|
|
struct xhci_container_ctx *out_ctx,
|
|
|
|
|
u32 add_flags, u32 drop_flags)
|
2009-09-04 17:53:11 +00:00
|
|
|
{
|
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
2009-09-04 17:53:13 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
|
2009-09-04 17:53:11 +00:00
|
|
|
ctrl_ctx->add_flags = add_flags;
|
|
|
|
|
ctrl_ctx->drop_flags = drop_flags;
|
2009-09-04 17:53:13 +00:00
|
|
|
xhci_slot_copy(xhci, in_ctx, out_ctx);
|
2009-09-04 17:53:11 +00:00
|
|
|
ctrl_ctx->add_flags |= SLOT_FLAG;
|
|
|
|
|
|
2009-09-04 17:53:13 +00:00
|
|
|
xhci_dbg(xhci, "Input Context:\n");
|
|
|
|
|
xhci_dbg_ctx(xhci, in_ctx, xhci_last_valid_endpoint(add_flags));
|
2009-09-04 17:53:11 +00:00
|
|
|
}
|
|
|
|
|
|
2009-08-07 21:04:55 +00:00
|
|
|
void xhci_setup_input_ctx_for_quirk(struct xhci_hcd *xhci,
|
|
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
|
|
|
|
struct xhci_dequeue_state *deq_state)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_container_ctx *in_ctx;
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
|
u32 added_ctxs;
|
|
|
|
|
dma_addr_t addr;
|
|
|
|
|
|
2009-09-04 17:53:13 +00:00
|
|
|
xhci_endpoint_copy(xhci, xhci->devs[slot_id]->in_ctx,
|
|
|
|
|
xhci->devs[slot_id]->out_ctx, ep_index);
|
2009-08-07 21:04:55 +00:00
|
|
|
in_ctx = xhci->devs[slot_id]->in_ctx;
|
|
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, in_ctx, ep_index);
|
|
|
|
|
addr = xhci_trb_virt_to_dma(deq_state->new_deq_seg,
|
|
|
|
|
deq_state->new_deq_ptr);
|
|
|
|
|
if (addr == 0) {
|
|
|
|
|
xhci_warn(xhci, "WARN Cannot submit config ep after "
|
|
|
|
|
"reset ep command\n");
|
|
|
|
|
xhci_warn(xhci, "WARN deq seg = %p, deq ptr = %p\n",
|
|
|
|
|
deq_state->new_deq_seg,
|
|
|
|
|
deq_state->new_deq_ptr);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
ep_ctx->deq = addr | deq_state->new_cycle_state;
|
|
|
|
|
|
|
|
|
|
added_ctxs = xhci_get_endpoint_flag_from_index(ep_index);
|
2009-09-04 17:53:13 +00:00
|
|
|
xhci_setup_input_ctx_for_config_ep(xhci, xhci->devs[slot_id]->in_ctx,
|
|
|
|
|
xhci->devs[slot_id]->out_ctx, added_ctxs, added_ctxs);
|
2009-08-07 21:04:55 +00:00
|
|
|
}
|
|
|
|
|
|
2009-08-07 21:04:52 +00:00
|
|
|
void xhci_cleanup_stalled_ring(struct xhci_hcd *xhci,
|
2009-09-04 17:53:09 +00:00
|
|
|
struct usb_device *udev, unsigned int ep_index)
|
2009-08-07 21:04:52 +00:00
|
|
|
{
|
|
|
|
|
struct xhci_dequeue_state deq_state;
|
2009-09-04 17:53:09 +00:00
|
|
|
struct xhci_virt_ep *ep;
|
2009-08-07 21:04:52 +00:00
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Cleaning up stalled endpoint ring\n");
|
2009-09-04 17:53:09 +00:00
|
|
|
ep = &xhci->devs[udev->slot_id]->eps[ep_index];
|
2009-08-07 21:04:52 +00:00
|
|
|
/* We need to move the HW's dequeue pointer past this TD,
|
|
|
|
|
* or it will attempt to resend it on the next doorbell ring.
|
|
|
|
|
*/
|
|
|
|
|
xhci_find_new_dequeue_state(xhci, udev->slot_id,
|
2010-04-02 22:34:43 +00:00
|
|
|
ep_index, ep->stopped_stream, ep->stopped_td,
|
2009-08-07 21:04:55 +00:00
|
|
|
&deq_state);
|
2009-08-07 21:04:52 +00:00
|
|
|
|
2009-08-07 21:04:55 +00:00
|
|
|
/* HW with the reset endpoint quirk will use the saved dequeue state to
|
|
|
|
|
* issue a configure endpoint command later.
|
|
|
|
|
*/
|
|
|
|
|
if (!(xhci->quirks & XHCI_RESET_EP_QUIRK)) {
|
|
|
|
|
xhci_dbg(xhci, "Queueing new dequeue state\n");
|
2009-09-04 17:53:09 +00:00
|
|
|
xhci_queue_new_dequeue_state(xhci, udev->slot_id,
|
2010-04-02 22:34:43 +00:00
|
|
|
ep_index, ep->stopped_stream, &deq_state);
|
2009-08-07 21:04:55 +00:00
|
|
|
} else {
|
|
|
|
|
/* Better hope no one uses the input context between now and the
|
|
|
|
|
* reset endpoint completion!
|
2010-04-02 22:34:43 +00:00
|
|
|
* XXX: No idea how this hardware will react when stream rings
|
|
|
|
|
* are enabled.
|
2009-08-07 21:04:55 +00:00
|
|
|
*/
|
|
|
|
|
xhci_dbg(xhci, "Setting up input context for "
|
|
|
|
|
"configure endpoint command\n");
|
|
|
|
|
xhci_setup_input_ctx_for_quirk(xhci, udev->slot_id,
|
|
|
|
|
ep_index, &deq_state);
|
|
|
|
|
}
|
2009-08-07 21:04:52 +00:00
|
|
|
}
|
|
|
|
|
|
2009-07-27 19:03:15 +00:00
|
|
|
/* Deal with stalled endpoints. The core should have sent the control message
|
|
|
|
|
* to clear the halt condition. However, we need to make the xHCI hardware
|
|
|
|
|
* reset its sequence number, since a device will expect a sequence number of
|
|
|
|
|
* zero after the halt condition is cleared.
|
|
|
|
|
* Context: in_interrupt
|
|
|
|
|
*/
|
|
|
|
|
void xhci_endpoint_reset(struct usb_hcd *hcd,
|
|
|
|
|
struct usb_host_endpoint *ep)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
struct usb_device *udev;
|
|
|
|
|
unsigned int ep_index;
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
int ret;
|
2009-09-04 17:53:09 +00:00
|
|
|
struct xhci_virt_ep *virt_ep;
|
2009-07-27 19:03:15 +00:00
|
|
|
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
udev = (struct usb_device *) ep->hcpriv;
|
|
|
|
|
/* Called with a root hub endpoint (or an endpoint that wasn't added
|
|
|
|
|
* with xhci_add_endpoint()
|
|
|
|
|
*/
|
|
|
|
|
if (!ep->hcpriv)
|
|
|
|
|
return;
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&ep->desc);
|
2009-09-04 17:53:09 +00:00
|
|
|
virt_ep = &xhci->devs[udev->slot_id]->eps[ep_index];
|
|
|
|
|
if (!virt_ep->stopped_td) {
|
2009-07-27 19:05:21 +00:00
|
|
|
xhci_dbg(xhci, "Endpoint 0x%x not halted, refusing to reset.\n",
|
|
|
|
|
ep->desc.bEndpointAddress);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2009-08-07 21:04:52 +00:00
|
|
|
if (usb_endpoint_xfer_control(&ep->desc)) {
|
|
|
|
|
xhci_dbg(xhci, "Control endpoint stall already handled.\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
2009-07-27 19:03:15 +00:00
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Queueing reset endpoint command\n");
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
ret = xhci_queue_reset_ep(xhci, udev->slot_id, ep_index);
|
2009-07-27 19:05:21 +00:00
|
|
|
/*
|
|
|
|
|
* Can't change the ring dequeue pointer until it's transitioned to the
|
|
|
|
|
* stopped state, which is only upon a successful reset endpoint
|
|
|
|
|
* command. Better hope that last command worked!
|
|
|
|
|
*/
|
2009-07-27 19:03:15 +00:00
|
|
|
if (!ret) {
|
2009-09-04 17:53:09 +00:00
|
|
|
xhci_cleanup_stalled_ring(xhci, udev, ep_index);
|
|
|
|
|
kfree(virt_ep->stopped_td);
|
2009-07-27 19:03:15 +00:00
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
|
}
|
2010-05-06 20:40:08 +00:00
|
|
|
virt_ep->stopped_td = NULL;
|
|
|
|
|
virt_ep->stopped_trb = NULL;
|
2010-05-06 20:40:18 +00:00
|
|
|
virt_ep->stopped_stream = 0;
|
2009-07-27 19:03:15 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
|
xhci_warn(xhci, "FIXME allocate a new ring segment\n");
|
|
|
|
|
}
|
|
|
|
|
|
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-02 22:34:16 +00:00
|
|
|
static int xhci_check_streams_endpoint(struct xhci_hcd *xhci,
|
|
|
|
|
struct usb_device *udev, struct usb_host_endpoint *ep,
|
|
|
|
|
unsigned int slot_id)
|
|
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
unsigned int ep_index;
|
|
|
|
|
unsigned int ep_state;
|
|
|
|
|
|
|
|
|
|
if (!ep)
|
|
|
|
|
return -EINVAL;
|
2010-10-14 14:22:45 +00:00
|
|
|
ret = xhci_check_args(xhci_to_hcd(xhci), udev, ep, 1, true, __func__);
|
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-02 22:34:16 +00:00
|
|
|
if (ret <= 0)
|
|
|
|
|
return -EINVAL;
|
2010-04-30 16:44:46 +00:00
|
|
|
if (ep->ss_ep_comp.bmAttributes == 0) {
|
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-02 22:34:16 +00:00
|
|
|
xhci_warn(xhci, "WARN: SuperSpeed Endpoint Companion"
|
|
|
|
|
" descriptor for ep 0x%x does not support streams\n",
|
|
|
|
|
ep->desc.bEndpointAddress);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&ep->desc);
|
|
|
|
|
ep_state = xhci->devs[slot_id]->eps[ep_index].ep_state;
|
|
|
|
|
if (ep_state & EP_HAS_STREAMS ||
|
|
|
|
|
ep_state & EP_GETTING_STREAMS) {
|
|
|
|
|
xhci_warn(xhci, "WARN: SuperSpeed bulk endpoint 0x%x "
|
|
|
|
|
"already has streams set up.\n",
|
|
|
|
|
ep->desc.bEndpointAddress);
|
|
|
|
|
xhci_warn(xhci, "Send email to xHCI maintainer and ask for "
|
|
|
|
|
"dynamic stream context array reallocation.\n");
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
if (!list_empty(&xhci->devs[slot_id]->eps[ep_index].ring->td_list)) {
|
|
|
|
|
xhci_warn(xhci, "Cannot setup streams for SuperSpeed bulk "
|
|
|
|
|
"endpoint 0x%x; URBs are pending.\n",
|
|
|
|
|
ep->desc.bEndpointAddress);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void xhci_calculate_streams_entries(struct xhci_hcd *xhci,
|
|
|
|
|
unsigned int *num_streams, unsigned int *num_stream_ctxs)
|
|
|
|
|
{
|
|
|
|
|
unsigned int max_streams;
|
|
|
|
|
|
|
|
|
|
/* The stream context array size must be a power of two */
|
|
|
|
|
*num_stream_ctxs = roundup_pow_of_two(*num_streams);
|
|
|
|
|
/*
|
|
|
|
|
* Find out how many primary stream array entries the host controller
|
|
|
|
|
* supports. Later we may use secondary stream arrays (similar to 2nd
|
|
|
|
|
* level page entries), but that's an optional feature for xHCI host
|
|
|
|
|
* controllers. xHCs must support at least 4 stream IDs.
|
|
|
|
|
*/
|
|
|
|
|
max_streams = HCC_MAX_PSA(xhci->hcc_params);
|
|
|
|
|
if (*num_stream_ctxs > max_streams) {
|
|
|
|
|
xhci_dbg(xhci, "xHCI HW only supports %u stream ctx entries.\n",
|
|
|
|
|
max_streams);
|
|
|
|
|
*num_stream_ctxs = max_streams;
|
|
|
|
|
*num_streams = max_streams;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns an error code if one of the endpoint already has streams.
|
|
|
|
|
* This does not change any data structures, it only checks and gathers
|
|
|
|
|
* information.
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_calculate_streams_and_bitmask(struct xhci_hcd *xhci,
|
|
|
|
|
struct usb_device *udev,
|
|
|
|
|
struct usb_host_endpoint **eps, unsigned int num_eps,
|
|
|
|
|
unsigned int *num_streams, u32 *changed_ep_bitmask)
|
|
|
|
|
{
|
|
|
|
|
unsigned int max_streams;
|
|
|
|
|
unsigned int endpoint_flag;
|
|
|
|
|
int i;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < num_eps; i++) {
|
|
|
|
|
ret = xhci_check_streams_endpoint(xhci, udev,
|
|
|
|
|
eps[i], udev->slot_id);
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
2010-04-30 16:44:46 +00:00
|
|
|
max_streams = USB_SS_MAX_STREAMS(
|
|
|
|
|
eps[i]->ss_ep_comp.bmAttributes);
|
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-02 22:34:16 +00:00
|
|
|
if (max_streams < (*num_streams - 1)) {
|
|
|
|
|
xhci_dbg(xhci, "Ep 0x%x only supports %u stream IDs.\n",
|
|
|
|
|
eps[i]->desc.bEndpointAddress,
|
|
|
|
|
max_streams);
|
|
|
|
|
*num_streams = max_streams+1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
endpoint_flag = xhci_get_endpoint_flag(&eps[i]->desc);
|
|
|
|
|
if (*changed_ep_bitmask & endpoint_flag)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
*changed_ep_bitmask |= endpoint_flag;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static u32 xhci_calculate_no_streams_bitmask(struct xhci_hcd *xhci,
|
|
|
|
|
struct usb_device *udev,
|
|
|
|
|
struct usb_host_endpoint **eps, unsigned int num_eps)
|
|
|
|
|
{
|
|
|
|
|
u32 changed_ep_bitmask = 0;
|
|
|
|
|
unsigned int slot_id;
|
|
|
|
|
unsigned int ep_index;
|
|
|
|
|
unsigned int ep_state;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
slot_id = udev->slot_id;
|
|
|
|
|
if (!xhci->devs[slot_id])
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < num_eps; i++) {
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&eps[i]->desc);
|
|
|
|
|
ep_state = xhci->devs[slot_id]->eps[ep_index].ep_state;
|
|
|
|
|
/* Are streams already being freed for the endpoint? */
|
|
|
|
|
if (ep_state & EP_GETTING_NO_STREAMS) {
|
|
|
|
|
xhci_warn(xhci, "WARN Can't disable streams for "
|
|
|
|
|
"endpoint 0x%x\n, "
|
|
|
|
|
"streams are being disabled already.",
|
|
|
|
|
eps[i]->desc.bEndpointAddress);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
/* Are there actually any streams to free? */
|
|
|
|
|
if (!(ep_state & EP_HAS_STREAMS) &&
|
|
|
|
|
!(ep_state & EP_GETTING_STREAMS)) {
|
|
|
|
|
xhci_warn(xhci, "WARN Can't disable streams for "
|
|
|
|
|
"endpoint 0x%x\n, "
|
|
|
|
|
"streams are already disabled!",
|
|
|
|
|
eps[i]->desc.bEndpointAddress);
|
|
|
|
|
xhci_warn(xhci, "WARN xhci_free_streams() called "
|
|
|
|
|
"with non-streams endpoint\n");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
changed_ep_bitmask |= xhci_get_endpoint_flag(&eps[i]->desc);
|
|
|
|
|
}
|
|
|
|
|
return changed_ep_bitmask;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The USB device drivers use this function (though the HCD interface in USB
|
|
|
|
|
* core) to prepare a set of bulk endpoints to use streams. Streams are used to
|
|
|
|
|
* coordinate mass storage command queueing across multiple endpoints (basically
|
|
|
|
|
* a stream ID == a task ID).
|
|
|
|
|
*
|
|
|
|
|
* Setting up streams involves allocating the same size stream context array
|
|
|
|
|
* for each endpoint and issuing a configure endpoint command for all endpoints.
|
|
|
|
|
*
|
|
|
|
|
* Don't allow the call to succeed if one endpoint only supports one stream
|
|
|
|
|
* (which means it doesn't support streams at all).
|
|
|
|
|
*
|
|
|
|
|
* Drivers may get less stream IDs than they asked for, if the host controller
|
|
|
|
|
* hardware or endpoints claim they can't support the number of requested
|
|
|
|
|
* stream IDs.
|
|
|
|
|
*/
|
|
|
|
|
int xhci_alloc_streams(struct usb_hcd *hcd, struct usb_device *udev,
|
|
|
|
|
struct usb_host_endpoint **eps, unsigned int num_eps,
|
|
|
|
|
unsigned int num_streams, gfp_t mem_flags)
|
|
|
|
|
{
|
|
|
|
|
int i, ret;
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
struct xhci_virt_device *vdev;
|
|
|
|
|
struct xhci_command *config_cmd;
|
|
|
|
|
unsigned int ep_index;
|
|
|
|
|
unsigned int num_stream_ctxs;
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
u32 changed_ep_bitmask = 0;
|
|
|
|
|
|
|
|
|
|
if (!eps)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
|
|
/* Add one to the number of streams requested to account for
|
|
|
|
|
* stream 0 that is reserved for xHCI usage.
|
|
|
|
|
*/
|
|
|
|
|
num_streams += 1;
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
xhci_dbg(xhci, "Driver wants %u stream IDs (including stream 0).\n",
|
|
|
|
|
num_streams);
|
|
|
|
|
|
|
|
|
|
config_cmd = xhci_alloc_command(xhci, true, true, mem_flags);
|
|
|
|
|
if (!config_cmd) {
|
|
|
|
|
xhci_dbg(xhci, "Could not allocate xHCI command structure.\n");
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Check to make sure all endpoints are not already configured for
|
|
|
|
|
* streams. While we're at it, find the maximum number of streams that
|
|
|
|
|
* all the endpoints will support and check for duplicate endpoints.
|
|
|
|
|
*/
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
ret = xhci_calculate_streams_and_bitmask(xhci, udev, eps,
|
|
|
|
|
num_eps, &num_streams, &changed_ep_bitmask);
|
|
|
|
|
if (ret < 0) {
|
|
|
|
|
xhci_free_command(xhci, config_cmd);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
if (num_streams <= 1) {
|
|
|
|
|
xhci_warn(xhci, "WARN: endpoints can't handle "
|
|
|
|
|
"more than one stream.\n");
|
|
|
|
|
xhci_free_command(xhci, config_cmd);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
vdev = xhci->devs[udev->slot_id];
|
|
|
|
|
/* Mark each endpoint as being in transistion, so
|
|
|
|
|
* xhci_urb_enqueue() will reject all URBs.
|
|
|
|
|
*/
|
|
|
|
|
for (i = 0; i < num_eps; i++) {
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&eps[i]->desc);
|
|
|
|
|
vdev->eps[ep_index].ep_state |= EP_GETTING_STREAMS;
|
|
|
|
|
}
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
/* Setup internal data structures and allocate HW data structures for
|
|
|
|
|
* streams (but don't install the HW structures in the input context
|
|
|
|
|
* until we're sure all memory allocation succeeded).
|
|
|
|
|
*/
|
|
|
|
|
xhci_calculate_streams_entries(xhci, &num_streams, &num_stream_ctxs);
|
|
|
|
|
xhci_dbg(xhci, "Need %u stream ctx entries for %u stream IDs.\n",
|
|
|
|
|
num_stream_ctxs, num_streams);
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < num_eps; i++) {
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&eps[i]->desc);
|
|
|
|
|
vdev->eps[ep_index].stream_info = xhci_alloc_stream_info(xhci,
|
|
|
|
|
num_stream_ctxs,
|
|
|
|
|
num_streams, mem_flags);
|
|
|
|
|
if (!vdev->eps[ep_index].stream_info)
|
|
|
|
|
goto cleanup;
|
|
|
|
|
/* Set maxPstreams in endpoint context and update deq ptr to
|
|
|
|
|
* point to stream context array. FIXME
|
|
|
|
|
*/
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Set up the input context for a configure endpoint command. */
|
|
|
|
|
for (i = 0; i < num_eps; i++) {
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
|
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&eps[i]->desc);
|
|
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, config_cmd->in_ctx, ep_index);
|
|
|
|
|
|
|
|
|
|
xhci_endpoint_copy(xhci, config_cmd->in_ctx,
|
|
|
|
|
vdev->out_ctx, ep_index);
|
|
|
|
|
xhci_setup_streams_ep_input_ctx(xhci, ep_ctx,
|
|
|
|
|
vdev->eps[ep_index].stream_info);
|
|
|
|
|
}
|
|
|
|
|
/* Tell the HW to drop its old copy of the endpoint context info
|
|
|
|
|
* and add the updated copy from the input context.
|
|
|
|
|
*/
|
|
|
|
|
xhci_setup_input_ctx_for_config_ep(xhci, config_cmd->in_ctx,
|
|
|
|
|
vdev->out_ctx, changed_ep_bitmask, changed_ep_bitmask);
|
|
|
|
|
|
|
|
|
|
/* Issue and wait for the configure endpoint command */
|
|
|
|
|
ret = xhci_configure_endpoint(xhci, udev, config_cmd,
|
|
|
|
|
false, false);
|
|
|
|
|
|
|
|
|
|
/* xHC rejected the configure endpoint command for some reason, so we
|
|
|
|
|
* leave the old ring intact and free our internal streams data
|
|
|
|
|
* structure.
|
|
|
|
|
*/
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
for (i = 0; i < num_eps; i++) {
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&eps[i]->desc);
|
|
|
|
|
vdev->eps[ep_index].ep_state &= ~EP_GETTING_STREAMS;
|
|
|
|
|
xhci_dbg(xhci, "Slot %u ep ctx %u now has streams.\n",
|
|
|
|
|
udev->slot_id, ep_index);
|
|
|
|
|
vdev->eps[ep_index].ep_state |= EP_HAS_STREAMS;
|
|
|
|
|
}
|
|
|
|
|
xhci_free_command(xhci, config_cmd);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
/* Subtract 1 for stream 0, which drivers can't use */
|
|
|
|
|
return num_streams - 1;
|
|
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
|
/* If it didn't work, free the streams! */
|
|
|
|
|
for (i = 0; i < num_eps; i++) {
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&eps[i]->desc);
|
|
|
|
|
xhci_free_stream_info(xhci, vdev->eps[ep_index].stream_info);
|
2010-04-30 22:37:56 +00:00
|
|
|
vdev->eps[ep_index].stream_info = NULL;
|
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-02 22:34:16 +00:00
|
|
|
/* FIXME Unset maxPstreams in endpoint context and
|
|
|
|
|
* update deq ptr to point to normal string ring.
|
|
|
|
|
*/
|
|
|
|
|
vdev->eps[ep_index].ep_state &= ~EP_GETTING_STREAMS;
|
|
|
|
|
vdev->eps[ep_index].ep_state &= ~EP_HAS_STREAMS;
|
|
|
|
|
xhci_endpoint_zero(xhci, vdev, eps[i]);
|
|
|
|
|
}
|
|
|
|
|
xhci_free_command(xhci, config_cmd);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Transition the endpoint from using streams to being a "normal" endpoint
|
|
|
|
|
* without streams.
|
|
|
|
|
*
|
|
|
|
|
* Modify the endpoint context state, submit a configure endpoint command,
|
|
|
|
|
* and free all endpoint rings for streams if that completes successfully.
|
|
|
|
|
*/
|
|
|
|
|
int xhci_free_streams(struct usb_hcd *hcd, struct usb_device *udev,
|
|
|
|
|
struct usb_host_endpoint **eps, unsigned int num_eps,
|
|
|
|
|
gfp_t mem_flags)
|
|
|
|
|
{
|
|
|
|
|
int i, ret;
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
struct xhci_virt_device *vdev;
|
|
|
|
|
struct xhci_command *command;
|
|
|
|
|
unsigned int ep_index;
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
u32 changed_ep_bitmask;
|
|
|
|
|
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
vdev = xhci->devs[udev->slot_id];
|
|
|
|
|
|
|
|
|
|
/* Set up a configure endpoint command to remove the streams rings */
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
changed_ep_bitmask = xhci_calculate_no_streams_bitmask(xhci,
|
|
|
|
|
udev, eps, num_eps);
|
|
|
|
|
if (changed_ep_bitmask == 0) {
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Use the xhci_command structure from the first endpoint. We may have
|
|
|
|
|
* allocated too many, but the driver may call xhci_free_streams() for
|
|
|
|
|
* each endpoint it grouped into one call to xhci_alloc_streams().
|
|
|
|
|
*/
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&eps[0]->desc);
|
|
|
|
|
command = vdev->eps[ep_index].stream_info->free_streams_command;
|
|
|
|
|
for (i = 0; i < num_eps; i++) {
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
|
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&eps[i]->desc);
|
|
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, command->in_ctx, ep_index);
|
|
|
|
|
xhci->devs[udev->slot_id]->eps[ep_index].ep_state |=
|
|
|
|
|
EP_GETTING_NO_STREAMS;
|
|
|
|
|
|
|
|
|
|
xhci_endpoint_copy(xhci, command->in_ctx,
|
|
|
|
|
vdev->out_ctx, ep_index);
|
|
|
|
|
xhci_setup_no_streams_ep_input_ctx(xhci, ep_ctx,
|
|
|
|
|
&vdev->eps[ep_index]);
|
|
|
|
|
}
|
|
|
|
|
xhci_setup_input_ctx_for_config_ep(xhci, command->in_ctx,
|
|
|
|
|
vdev->out_ctx, changed_ep_bitmask, changed_ep_bitmask);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
/* Issue and wait for the configure endpoint command,
|
|
|
|
|
* which must succeed.
|
|
|
|
|
*/
|
|
|
|
|
ret = xhci_configure_endpoint(xhci, udev, command,
|
|
|
|
|
false, true);
|
|
|
|
|
|
|
|
|
|
/* xHC rejected the configure endpoint command for some reason, so we
|
|
|
|
|
* leave the streams rings intact.
|
|
|
|
|
*/
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
for (i = 0; i < num_eps; i++) {
|
|
|
|
|
ep_index = xhci_get_endpoint_index(&eps[i]->desc);
|
|
|
|
|
xhci_free_stream_info(xhci, vdev->eps[ep_index].stream_info);
|
2010-04-30 22:37:56 +00:00
|
|
|
vdev->eps[ep_index].stream_info = NULL;
|
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-02 22:34:16 +00:00
|
|
|
/* FIXME Unset maxPstreams in endpoint context and
|
|
|
|
|
* update deq ptr to point to normal string ring.
|
|
|
|
|
*/
|
|
|
|
|
vdev->eps[ep_index].ep_state &= ~EP_GETTING_NO_STREAMS;
|
|
|
|
|
vdev->eps[ep_index].ep_state &= ~EP_HAS_STREAMS;
|
|
|
|
|
}
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-09 23:59:13 +00:00
|
|
|
/*
|
|
|
|
|
* This submits a Reset Device Command, which will set the device state to 0,
|
|
|
|
|
* set the device address to 0, and disable all the endpoints except the default
|
|
|
|
|
* control endpoint. The USB core should come back and call
|
|
|
|
|
* xhci_address_device(), and then re-set up the configuration. If this is
|
|
|
|
|
* called because of a usb_reset_and_verify_device(), then the old alternate
|
|
|
|
|
* settings will be re-installed through the normal bandwidth allocation
|
|
|
|
|
* functions.
|
|
|
|
|
*
|
|
|
|
|
* Wait for the Reset Device command to finish. Remove all structures
|
|
|
|
|
* associated with the endpoints that were disabled. Clear the input device
|
|
|
|
|
* structure? Cache the rings? Reset the control endpoint 0 max packet size?
|
2010-10-14 14:22:48 +00:00
|
|
|
*
|
|
|
|
|
* If the virt_dev to be reset does not exist or does not match the udev,
|
|
|
|
|
* it means the device is lost, possibly due to the xHC restore error and
|
|
|
|
|
* re-initialization during S3/S4. In this case, call xhci_alloc_dev() to
|
|
|
|
|
* re-allocate the device.
|
2009-12-09 23:59:13 +00:00
|
|
|
*/
|
2010-10-14 14:22:48 +00:00
|
|
|
int xhci_discover_or_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
|
2009-12-09 23:59:13 +00:00
|
|
|
{
|
|
|
|
|
int ret, i;
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
unsigned int slot_id;
|
|
|
|
|
struct xhci_virt_device *virt_dev;
|
|
|
|
|
struct xhci_command *reset_device_cmd;
|
|
|
|
|
int timeleft;
|
|
|
|
|
int last_freed_endpoint;
|
|
|
|
|
|
2010-10-14 14:22:48 +00:00
|
|
|
ret = xhci_check_args(hcd, udev, NULL, 0, false, __func__);
|
2009-12-09 23:59:13 +00:00
|
|
|
if (ret <= 0)
|
|
|
|
|
return ret;
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
slot_id = udev->slot_id;
|
|
|
|
|
virt_dev = xhci->devs[slot_id];
|
2010-10-14 14:22:48 +00:00
|
|
|
if (!virt_dev) {
|
|
|
|
|
xhci_dbg(xhci, "The device to be reset with slot ID %u does "
|
|
|
|
|
"not exist. Re-allocate the device\n", slot_id);
|
|
|
|
|
ret = xhci_alloc_dev(hcd, udev);
|
|
|
|
|
if (ret == 1)
|
|
|
|
|
return 0;
|
|
|
|
|
else
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (virt_dev->udev != udev) {
|
|
|
|
|
/* If the virt_dev and the udev does not match, this virt_dev
|
|
|
|
|
* may belong to another udev.
|
|
|
|
|
* Re-allocate the device.
|
|
|
|
|
*/
|
|
|
|
|
xhci_dbg(xhci, "The device to be reset with slot ID %u does "
|
|
|
|
|
"not match the udev. Re-allocate the device\n",
|
|
|
|
|
slot_id);
|
|
|
|
|
ret = xhci_alloc_dev(hcd, udev);
|
|
|
|
|
if (ret == 1)
|
|
|
|
|
return 0;
|
|
|
|
|
else
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2009-12-09 23:59:13 +00:00
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Resetting device with slot ID %u\n", slot_id);
|
|
|
|
|
/* Allocate the command structure that holds the struct completion.
|
|
|
|
|
* Assume we're in process context, since the normal device reset
|
|
|
|
|
* process has to wait for the device anyway. Storage devices are
|
|
|
|
|
* reset as part of error handling, so use GFP_NOIO instead of
|
|
|
|
|
* GFP_KERNEL.
|
|
|
|
|
*/
|
|
|
|
|
reset_device_cmd = xhci_alloc_command(xhci, false, true, GFP_NOIO);
|
|
|
|
|
if (!reset_device_cmd) {
|
|
|
|
|
xhci_dbg(xhci, "Couldn't allocate command structure.\n");
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Attempt to submit the Reset Device command to the command ring */
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
reset_device_cmd->command_trb = xhci->cmd_ring->enqueue;
|
|
|
|
|
list_add_tail(&reset_device_cmd->cmd_list, &virt_dev->cmd_list);
|
|
|
|
|
ret = xhci_queue_reset_device(xhci, slot_id);
|
|
|
|
|
if (ret) {
|
|
|
|
|
xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
|
|
|
|
|
list_del(&reset_device_cmd->cmd_list);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
goto command_cleanup;
|
|
|
|
|
}
|
|
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
/* Wait for the Reset Device command to finish */
|
|
|
|
|
timeleft = wait_for_completion_interruptible_timeout(
|
|
|
|
|
reset_device_cmd->completion,
|
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
|
if (timeleft <= 0) {
|
|
|
|
|
xhci_warn(xhci, "%s while waiting for reset device command\n",
|
|
|
|
|
timeleft == 0 ? "Timeout" : "Signal");
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
/* The timeout might have raced with the event ring handler, so
|
|
|
|
|
* only delete from the list if the item isn't poisoned.
|
|
|
|
|
*/
|
|
|
|
|
if (reset_device_cmd->cmd_list.next != LIST_POISON1)
|
|
|
|
|
list_del(&reset_device_cmd->cmd_list);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
ret = -ETIME;
|
|
|
|
|
goto command_cleanup;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The Reset Device command can't fail, according to the 0.95/0.96 spec,
|
|
|
|
|
* unless we tried to reset a slot ID that wasn't enabled,
|
|
|
|
|
* or the device wasn't in the addressed or configured state.
|
|
|
|
|
*/
|
|
|
|
|
ret = reset_device_cmd->status;
|
|
|
|
|
switch (ret) {
|
|
|
|
|
case COMP_EBADSLT: /* 0.95 completion code for bad slot ID */
|
|
|
|
|
case COMP_CTX_STATE: /* 0.96 completion code for same thing */
|
|
|
|
|
xhci_info(xhci, "Can't reset device (slot ID %u) in %s state\n",
|
|
|
|
|
slot_id,
|
|
|
|
|
xhci_get_slot_state(xhci, virt_dev->out_ctx));
|
|
|
|
|
xhci_info(xhci, "Not freeing device rings.\n");
|
|
|
|
|
/* Don't treat this as an error. May change my mind later. */
|
|
|
|
|
ret = 0;
|
|
|
|
|
goto command_cleanup;
|
|
|
|
|
case COMP_SUCCESS:
|
|
|
|
|
xhci_dbg(xhci, "Successful reset device command.\n");
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
if (xhci_is_vendor_info_code(xhci, ret))
|
|
|
|
|
break;
|
|
|
|
|
xhci_warn(xhci, "Unknown completion code %u for "
|
|
|
|
|
"reset device command.\n", ret);
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
goto command_cleanup;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Everything but endpoint 0 is disabled, so free or cache the rings. */
|
|
|
|
|
last_freed_endpoint = 1;
|
|
|
|
|
for (i = 1; i < 31; ++i) {
|
|
|
|
|
if (!virt_dev->eps[i].ring)
|
|
|
|
|
continue;
|
|
|
|
|
xhci_free_or_cache_endpoint_ring(xhci, virt_dev, i);
|
|
|
|
|
last_freed_endpoint = i;
|
|
|
|
|
}
|
|
|
|
|
xhci_dbg(xhci, "Output context after successful reset device cmd:\n");
|
|
|
|
|
xhci_dbg_ctx(xhci, virt_dev->out_ctx, last_freed_endpoint);
|
|
|
|
|
ret = 0;
|
|
|
|
|
|
|
|
|
|
command_cleanup:
|
|
|
|
|
xhci_free_command(xhci, reset_device_cmd);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:57:38 +00:00
|
|
|
/*
|
|
|
|
|
* At this point, the struct usb_device is about to go away, the device has
|
|
|
|
|
* disconnected, and all traffic has been stopped and the endpoints have been
|
|
|
|
|
* disabled. Free any HC data structures associated with that device.
|
|
|
|
|
*/
|
|
|
|
|
void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-27 17:57:01 +00:00
|
|
|
struct xhci_virt_device *virt_dev;
|
2009-04-28 02:57:38 +00:00
|
|
|
unsigned long flags;
|
2009-09-16 23:42:39 +00:00
|
|
|
u32 state;
|
2010-10-14 14:22:45 +00:00
|
|
|
int i, ret;
|
2009-04-28 02:57:38 +00:00
|
|
|
|
2010-10-14 14:22:45 +00:00
|
|
|
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
|
|
|
|
|
if (ret <= 0)
|
2009-04-28 02:57:38 +00:00
|
|
|
return;
|
2010-10-14 14:22:45 +00: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-27 17:57:01 +00:00
|
|
|
virt_dev = xhci->devs[udev->slot_id];
|
|
|
|
|
|
|
|
|
|
/* Stop any wayward timer functions (which may grab the lock) */
|
|
|
|
|
for (i = 0; i < 31; ++i) {
|
|
|
|
|
virt_dev->eps[i].ep_state &= ~EP_HALT_PENDING;
|
|
|
|
|
del_timer_sync(&virt_dev->eps[i].stop_cmd_timer);
|
|
|
|
|
}
|
2009-04-28 02:57:38 +00:00
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
2009-09-16 23:42:39 +00:00
|
|
|
/* Don't disable the slot if the host controller is dead. */
|
|
|
|
|
state = xhci_readl(xhci, &xhci->op_regs->status);
|
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-27 17:57:01 +00:00
|
|
|
if (state == 0xffffffff || (xhci->xhc_state & XHCI_STATE_DYING)) {
|
2009-09-16 23:42:39 +00:00
|
|
|
xhci_free_virt_device(xhci, udev->slot_id);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-30 02:05:20 +00:00
|
|
|
if (xhci_queue_slot_control(xhci, TRB_DISABLE_SLOT, udev->slot_id)) {
|
2009-04-28 02:57:38 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
2009-04-30 02:05:20 +00:00
|
|
|
xhci_ring_cmd_db(xhci);
|
2009-04-28 02:57:38 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
/*
|
|
|
|
|
* Event command completion handler will free any data structures
|
2009-05-14 18:44:22 +00:00
|
|
|
* associated with the slot. XXX Can free sleep?
|
2009-04-28 02:57:38 +00:00
|
|
|
*/
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Returns 0 if the xHC ran out of device slots, the Enable Slot command
|
|
|
|
|
* timed out, or allocating memory failed. Returns 1 on success.
|
|
|
|
|
*/
|
|
|
|
|
int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
int timeleft;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
2009-04-30 02:05:20 +00:00
|
|
|
ret = xhci_queue_slot_control(xhci, TRB_ENABLE_SLOT, 0);
|
2009-04-28 02:57:38 +00:00
|
|
|
if (ret) {
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2009-04-30 02:05:20 +00:00
|
|
|
xhci_ring_cmd_db(xhci);
|
2009-04-28 02:57:38 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
/* XXX: how much time for xHC slot assignment? */
|
|
|
|
|
timeleft = wait_for_completion_interruptible_timeout(&xhci->addr_dev,
|
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
|
if (timeleft <= 0) {
|
|
|
|
|
xhci_warn(xhci, "%s while waiting for a slot\n",
|
|
|
|
|
timeleft == 0 ? "Timeout" : "Signal");
|
|
|
|
|
/* FIXME cancel the enable slot request */
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!xhci->slot_id) {
|
|
|
|
|
xhci_err(xhci, "Error while assigning device slot ID\n");
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2009-05-14 18:44:22 +00:00
|
|
|
/* xhci_alloc_virt_device() does not touch rings; no need to lock */
|
2009-04-28 02:57:38 +00:00
|
|
|
if (!xhci_alloc_virt_device(xhci, xhci->slot_id, udev, GFP_KERNEL)) {
|
|
|
|
|
/* Disable slot, if we can do it without mem alloc */
|
|
|
|
|
xhci_warn(xhci, "Could not allocate xHCI USB device data structures\n");
|
2009-05-14 18:44:22 +00:00
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
2009-04-30 02:05:20 +00:00
|
|
|
if (!xhci_queue_slot_control(xhci, TRB_DISABLE_SLOT, udev->slot_id))
|
|
|
|
|
xhci_ring_cmd_db(xhci);
|
2009-04-28 02:57:38 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
udev->slot_id = xhci->slot_id;
|
|
|
|
|
/* Is this a LS or FS device under a HS hub? */
|
|
|
|
|
/* Hub or peripherial? */
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Issue an Address Device command (which will issue a SetAddress request to
|
|
|
|
|
* the device).
|
|
|
|
|
* We should be protected by the usb_address0_mutex in khubd's hub_port_init, so
|
|
|
|
|
* we should only issue and wait on one address command at the same time.
|
|
|
|
|
*
|
|
|
|
|
* We add one to the device address issued by the hardware because the USB core
|
|
|
|
|
* uses address 1 for the root hubs (even though they're not really devices).
|
|
|
|
|
*/
|
|
|
|
|
int xhci_address_device(struct usb_hcd *hcd, struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
int timeleft;
|
|
|
|
|
struct xhci_virt_device *virt_dev;
|
|
|
|
|
int ret = 0;
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
2009-07-27 19:05:15 +00:00
|
|
|
struct xhci_slot_ctx *slot_ctx;
|
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
2009-07-27 19:03:31 +00:00
|
|
|
u64 temp_64;
|
2009-04-28 02:57:38 +00:00
|
|
|
|
|
|
|
|
if (!udev->slot_id) {
|
|
|
|
|
xhci_dbg(xhci, "Bad Slot ID %d\n", udev->slot_id);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
virt_dev = xhci->devs[udev->slot_id];
|
|
|
|
|
|
2010-10-14 14:22:48 +00:00
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->in_ctx);
|
|
|
|
|
/*
|
|
|
|
|
* If this is the first Set Address since device plug-in or
|
|
|
|
|
* virt_device realloaction after a resume with an xHCI power loss,
|
|
|
|
|
* then set up the slot context.
|
|
|
|
|
*/
|
|
|
|
|
if (!slot_ctx->dev_info)
|
2009-04-28 02:57:38 +00:00
|
|
|
xhci_setup_addressable_virt_dev(xhci, udev);
|
2010-10-14 14:22:48 +00:00
|
|
|
/* Otherwise, update the control endpoint ring enqueue pointer. */
|
2010-07-09 15:08:54 +00:00
|
|
|
else
|
|
|
|
|
xhci_copy_ep0_dequeue_into_input_ctx(xhci, udev);
|
2009-07-27 19:03:46 +00:00
|
|
|
xhci_dbg(xhci, "Slot ID %d Input Context:\n", udev->slot_id);
|
2009-07-27 19:05:15 +00:00
|
|
|
xhci_dbg_ctx(xhci, virt_dev->in_ctx, 2);
|
2009-04-28 02:57:38 +00:00
|
|
|
|
2009-05-14 18:44:22 +00:00
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
2009-07-27 19:05:15 +00:00
|
|
|
ret = xhci_queue_address_device(xhci, virt_dev->in_ctx->dma,
|
|
|
|
|
udev->slot_id);
|
2009-04-28 02:57:38 +00:00
|
|
|
if (ret) {
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
2009-04-30 02:05:20 +00:00
|
|
|
xhci_ring_cmd_db(xhci);
|
2009-04-28 02:57:38 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
/* ctrl tx can take up to 5 sec; XXX: need more time for xHC? */
|
|
|
|
|
timeleft = wait_for_completion_interruptible_timeout(&xhci->addr_dev,
|
|
|
|
|
USB_CTRL_SET_TIMEOUT);
|
|
|
|
|
/* FIXME: From section 4.3.4: "Software shall be responsible for timing
|
|
|
|
|
* the SetAddress() "recovery interval" required by USB and aborting the
|
|
|
|
|
* command on a timeout.
|
|
|
|
|
*/
|
|
|
|
|
if (timeleft <= 0) {
|
|
|
|
|
xhci_warn(xhci, "%s while waiting for a slot\n",
|
|
|
|
|
timeleft == 0 ? "Timeout" : "Signal");
|
|
|
|
|
/* FIXME cancel the address device command */
|
|
|
|
|
return -ETIME;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (virt_dev->cmd_status) {
|
|
|
|
|
case COMP_CTX_STATE:
|
|
|
|
|
case COMP_EBADSLT:
|
|
|
|
|
xhci_err(xhci, "Setup ERROR: address device command for slot %d.\n",
|
|
|
|
|
udev->slot_id);
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
case COMP_TX_ERR:
|
|
|
|
|
dev_warn(&udev->dev, "Device not responding to set address.\n");
|
|
|
|
|
ret = -EPROTO;
|
|
|
|
|
break;
|
|
|
|
|
case COMP_SUCCESS:
|
|
|
|
|
xhci_dbg(xhci, "Successful Address Device command\n");
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
xhci_err(xhci, "ERROR: unexpected command completion "
|
|
|
|
|
"code 0x%x.\n", virt_dev->cmd_status);
|
2009-07-27 19:03:46 +00:00
|
|
|
xhci_dbg(xhci, "Slot ID %d Output Context:\n", udev->slot_id);
|
2009-07-27 19:05:15 +00:00
|
|
|
xhci_dbg_ctx(xhci, virt_dev->out_ctx, 2);
|
2009-04-28 02:57:38 +00:00
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
if (ret) {
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
2009-07-27 19:03:31 +00:00
|
|
|
temp_64 = xhci_read_64(xhci, &xhci->op_regs->dcbaa_ptr);
|
|
|
|
|
xhci_dbg(xhci, "Op regs DCBAA ptr = %#016llx\n", temp_64);
|
|
|
|
|
xhci_dbg(xhci, "Slot ID %d dcbaa entry @%p = %#016llx\n",
|
2009-04-28 02:57:38 +00:00
|
|
|
udev->slot_id,
|
2009-07-27 19:03:31 +00:00
|
|
|
&xhci->dcbaa->dev_context_ptrs[udev->slot_id],
|
|
|
|
|
(unsigned long long)
|
|
|
|
|
xhci->dcbaa->dev_context_ptrs[udev->slot_id]);
|
2009-04-30 02:14:08 +00:00
|
|
|
xhci_dbg(xhci, "Output Context DMA address = %#08llx\n",
|
2009-07-27 19:05:15 +00:00
|
|
|
(unsigned long long)virt_dev->out_ctx->dma);
|
2009-04-28 02:57:38 +00:00
|
|
|
xhci_dbg(xhci, "Slot ID %d Input Context:\n", udev->slot_id);
|
2009-07-27 19:05:15 +00:00
|
|
|
xhci_dbg_ctx(xhci, virt_dev->in_ctx, 2);
|
2009-04-28 02:57:38 +00:00
|
|
|
xhci_dbg(xhci, "Slot ID %d Output Context:\n", udev->slot_id);
|
2009-07-27 19:05:15 +00:00
|
|
|
xhci_dbg_ctx(xhci, virt_dev->out_ctx, 2);
|
2009-04-28 02:57:38 +00:00
|
|
|
/*
|
|
|
|
|
* USB core uses address 1 for the roothubs, so we add one to the
|
|
|
|
|
* address given back to us by the HC.
|
|
|
|
|
*/
|
2009-07-27 19:05:15 +00:00
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->out_ctx);
|
2010-10-14 14:22:51 +00:00
|
|
|
/* Use kernel assigned address for devices; store xHC assigned
|
|
|
|
|
* address locally. */
|
|
|
|
|
virt_dev->address = (slot_ctx->dev_state & DEV_ADDR_MASK) + 1;
|
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 02:58:38 +00:00
|
|
|
/* Zero the input context control for later use */
|
2009-07-27 19:05:15 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, virt_dev->in_ctx);
|
|
|
|
|
ctrl_ctx->add_flags = 0;
|
|
|
|
|
ctrl_ctx->drop_flags = 0;
|
2009-04-28 02:57:38 +00:00
|
|
|
|
2010-10-14 14:22:51 +00:00
|
|
|
xhci_dbg(xhci, "Internal device address = %d\n", virt_dev->address);
|
2009-04-28 02:57:38 +00:00
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-04 17:53:20 +00:00
|
|
|
/* Once a hub descriptor is fetched for a device, we need to update the xHC's
|
|
|
|
|
* internal data structures for the device.
|
|
|
|
|
*/
|
|
|
|
|
int xhci_update_hub_device(struct usb_hcd *hcd, struct usb_device *hdev,
|
|
|
|
|
struct usb_tt *tt, gfp_t mem_flags)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
struct xhci_virt_device *vdev;
|
|
|
|
|
struct xhci_command *config_cmd;
|
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
|
|
|
|
struct xhci_slot_ctx *slot_ctx;
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
unsigned think_time;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
/* Ignore root hubs */
|
|
|
|
|
if (!hdev->parent)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
vdev = xhci->devs[hdev->slot_id];
|
|
|
|
|
if (!vdev) {
|
|
|
|
|
xhci_warn(xhci, "Cannot update hub desc for unknown device.\n");
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2009-12-09 23:59:03 +00:00
|
|
|
config_cmd = xhci_alloc_command(xhci, true, true, mem_flags);
|
2009-09-04 17:53:20 +00:00
|
|
|
if (!config_cmd) {
|
|
|
|
|
xhci_dbg(xhci, "Could not allocate xHCI command structure.\n");
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
xhci_slot_copy(xhci, config_cmd->in_ctx, vdev->out_ctx);
|
|
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, config_cmd->in_ctx);
|
|
|
|
|
ctrl_ctx->add_flags |= SLOT_FLAG;
|
|
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, config_cmd->in_ctx);
|
|
|
|
|
slot_ctx->dev_info |= DEV_HUB;
|
|
|
|
|
if (tt->multi)
|
|
|
|
|
slot_ctx->dev_info |= DEV_MTT;
|
|
|
|
|
if (xhci->hci_version > 0x95) {
|
|
|
|
|
xhci_dbg(xhci, "xHCI version %x needs hub "
|
|
|
|
|
"TT think time and number of ports\n",
|
|
|
|
|
(unsigned int) xhci->hci_version);
|
|
|
|
|
slot_ctx->dev_info2 |= XHCI_MAX_PORTS(hdev->maxchild);
|
|
|
|
|
/* Set TT think time - convert from ns to FS bit times.
|
|
|
|
|
* 0 = 8 FS bit times, 1 = 16 FS bit times,
|
|
|
|
|
* 2 = 24 FS bit times, 3 = 32 FS bit times.
|
|
|
|
|
*/
|
|
|
|
|
think_time = tt->think_time;
|
|
|
|
|
if (think_time != 0)
|
|
|
|
|
think_time = (think_time / 666) - 1;
|
|
|
|
|
slot_ctx->tt_info |= TT_THINK_TIME(think_time);
|
|
|
|
|
} else {
|
|
|
|
|
xhci_dbg(xhci, "xHCI version %x doesn't need hub "
|
|
|
|
|
"TT think time or number of ports\n",
|
|
|
|
|
(unsigned int) xhci->hci_version);
|
|
|
|
|
}
|
|
|
|
|
slot_ctx->dev_state = 0;
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Set up %s for hub device.\n",
|
|
|
|
|
(xhci->hci_version > 0x95) ?
|
|
|
|
|
"configure endpoint" : "evaluate context");
|
|
|
|
|
xhci_dbg(xhci, "Slot %u Input Context:\n", hdev->slot_id);
|
|
|
|
|
xhci_dbg_ctx(xhci, config_cmd->in_ctx, 0);
|
|
|
|
|
|
|
|
|
|
/* Issue and wait for the configure endpoint or
|
|
|
|
|
* evaluate context command.
|
|
|
|
|
*/
|
|
|
|
|
if (xhci->hci_version > 0x95)
|
|
|
|
|
ret = xhci_configure_endpoint(xhci, hdev, config_cmd,
|
|
|
|
|
false, false);
|
|
|
|
|
else
|
|
|
|
|
ret = xhci_configure_endpoint(xhci, hdev, config_cmd,
|
|
|
|
|
true, false);
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Slot %u Output Context:\n", hdev->slot_id);
|
|
|
|
|
xhci_dbg_ctx(xhci, vdev->out_ctx, 0);
|
|
|
|
|
|
|
|
|
|
xhci_free_command(xhci, config_cmd);
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
int xhci_get_frame(struct usb_hcd *hcd)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
/* EHCI mods by the periodic size. Why? */
|
|
|
|
|
return xhci_readl(xhci, &xhci->run_regs->microframe_index) >> 3;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MODULE_DESCRIPTION(DRIVER_DESC);
|
|
|
|
|
MODULE_AUTHOR(DRIVER_AUTHOR);
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
|
|
|
|
|
|
static int __init xhci_hcd_init(void)
|
|
|
|
|
{
|
|
|
|
|
#ifdef CONFIG_PCI
|
|
|
|
|
int retval = 0;
|
|
|
|
|
|
|
|
|
|
retval = xhci_register_pci();
|
|
|
|
|
|
|
|
|
|
if (retval < 0) {
|
|
|
|
|
printk(KERN_DEBUG "Problem registering PCI driver.");
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2009-05-14 18:44:18 +00:00
|
|
|
/*
|
|
|
|
|
* Check the compiler generated sizes of structures that must be laid
|
|
|
|
|
* out in specific ways for hardware access.
|
|
|
|
|
*/
|
|
|
|
|
BUILD_BUG_ON(sizeof(struct xhci_doorbell_array) != 256*32/8);
|
|
|
|
|
BUILD_BUG_ON(sizeof(struct xhci_slot_ctx) != 8*32/8);
|
|
|
|
|
BUILD_BUG_ON(sizeof(struct xhci_ep_ctx) != 8*32/8);
|
|
|
|
|
/* xhci_device_control has eight fields, and also
|
|
|
|
|
* embeds one xhci_slot_ctx and 31 xhci_ep_ctx
|
|
|
|
|
*/
|
|
|
|
|
BUILD_BUG_ON(sizeof(struct xhci_stream_ctx) != 4*32/8);
|
|
|
|
|
BUILD_BUG_ON(sizeof(union xhci_trb) != 4*32/8);
|
|
|
|
|
BUILD_BUG_ON(sizeof(struct xhci_erst_entry) != 4*32/8);
|
|
|
|
|
BUILD_BUG_ON(sizeof(struct xhci_cap_regs) != 7*32/8);
|
|
|
|
|
BUILD_BUG_ON(sizeof(struct xhci_intr_reg) != 8*32/8);
|
|
|
|
|
/* xhci_run_regs has eight fields and embeds 128 xhci_intr_regs */
|
|
|
|
|
BUILD_BUG_ON(sizeof(struct xhci_run_regs) != (8+8*128)*32/8);
|
|
|
|
|
BUILD_BUG_ON(sizeof(struct xhci_doorbell_array) != 256*32/8);
|
2009-04-28 02:52:28 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
module_init(xhci_hcd_init);
|
|
|
|
|
|
|
|
|
|
static void __exit xhci_hcd_cleanup(void)
|
|
|
|
|
{
|
|
|
|
|
#ifdef CONFIG_PCI
|
|
|
|
|
xhci_unregister_pci();
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
module_exit(xhci_hcd_cleanup);
|
