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>
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
#include <linux/dmi.h>
|
2013-07-26 12:34:43 +00:00
|
|
|
#include <linux/dma-mapping.h>
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
#include "xhci.h"
|
2013-08-05 21:22:15 +00:00
|
|
|
#include "xhci-trace.h"
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
#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");
|
|
|
|
|
|
2013-12-09 11:42:48 +00:00
|
|
|
static unsigned int quirks;
|
|
|
|
|
module_param(quirks, uint, S_IRUGO);
|
|
|
|
|
MODULE_PARM_DESC(quirks, "Bit flags for quirks to be enabled as default");
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
/* TODO: copied from ehci-hcd.c - can this be refactored? */
|
|
|
|
|
/*
|
2012-10-25 20:27:51 +00:00
|
|
|
* xhci_handshake - spin reading hc until handshake completes or fails
|
2009-04-28 02:52:28 +00:00
|
|
|
* @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).
|
|
|
|
|
*/
|
2012-10-25 20:27:51 +00:00
|
|
|
int xhci_handshake(struct xhci_hcd *xhci, void __iomem *ptr,
|
2009-04-28 02:52:28 +00:00
|
|
|
u32 mask, u32 done, int usec)
|
|
|
|
|
{
|
|
|
|
|
u32 result;
|
|
|
|
|
|
|
|
|
|
do {
|
2013-11-15 03:34:06 +00:00
|
|
|
result = readl(ptr);
|
2009-04-28 02:52:28 +00:00
|
|
|
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);
|
2013-11-15 03:34:06 +00:00
|
|
|
halted = readl(&xhci->op_regs->status) & STS_HALT;
|
2009-04-28 02:52:28 +00:00
|
|
|
if (!halted)
|
|
|
|
|
mask &= ~CMD_RUN;
|
|
|
|
|
|
2013-11-15 03:34:06 +00:00
|
|
|
cmd = readl(&xhci->op_regs->command);
|
2009-04-28 02:52:28 +00:00
|
|
|
cmd &= mask;
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(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
|
2011-01-06 07:43:39 +00:00
|
|
|
* should halt within 16 ms of the run/stop bit being cleared.
|
2009-10-27 17:56:33 +00:00
|
|
|
* Read HC Halted bit in the status register to see when the HC is finished.
|
|
|
|
|
*/
|
|
|
|
|
int xhci_halt(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
2011-03-11 18:20:58 +00:00
|
|
|
int ret;
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "// Halt the HC");
|
2009-10-27 17:56:33 +00:00
|
|
|
xhci_quiesce(xhci);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2012-10-25 20:27:51 +00:00
|
|
|
ret = xhci_handshake(xhci, &xhci->op_regs->status,
|
2009-04-28 02:52:28 +00:00
|
|
|
STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC);
|
2012-06-27 08:30:57 +00:00
|
|
|
if (!ret) {
|
2011-03-11 18:20:58 +00:00
|
|
|
xhci->xhc_state |= XHCI_STATE_HALTED;
|
2012-06-27 08:30:57 +00:00
|
|
|
xhci->cmd_ring_state = CMD_RING_STATE_STOPPED;
|
|
|
|
|
} else
|
2012-03-16 19:58:20 +00:00
|
|
|
xhci_warn(xhci, "Host not halted after %u microseconds.\n",
|
|
|
|
|
XHCI_MAX_HALT_USEC);
|
2011-03-11 18:20:58 +00:00
|
|
|
return ret;
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
|
|
|
|
|
2010-05-24 20:25:21 +00:00
|
|
|
/*
|
|
|
|
|
* Set the run bit and wait for the host to be running.
|
|
|
|
|
*/
|
2011-02-08 21:55:59 +00:00
|
|
|
static int xhci_start(struct xhci_hcd *xhci)
|
2010-05-24 20:25:21 +00:00
|
|
|
{
|
|
|
|
|
u32 temp;
|
|
|
|
|
int ret;
|
|
|
|
|
|
2013-11-15 03:34:06 +00:00
|
|
|
temp = readl(&xhci->op_regs->command);
|
2010-05-24 20:25:21 +00:00
|
|
|
temp |= (CMD_RUN);
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "// Turn on HC, cmd = 0x%x.",
|
2010-05-24 20:25:21 +00:00
|
|
|
temp);
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(temp, &xhci->op_regs->command);
|
2010-05-24 20:25:21 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Wait for the HCHalted Status bit to be 0 to indicate the host is
|
|
|
|
|
* running.
|
|
|
|
|
*/
|
2012-10-25 20:27:51 +00:00
|
|
|
ret = xhci_handshake(xhci, &xhci->op_regs->status,
|
2010-05-24 20:25:21 +00:00
|
|
|
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);
|
2011-03-11 18:20:58 +00:00
|
|
|
if (!ret)
|
|
|
|
|
xhci->xhc_state &= ~XHCI_STATE_HALTED;
|
2010-05-24 20:25:21 +00:00
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
/*
|
2011-03-11 16:47:33 +00:00
|
|
|
* Reset a halted HC.
|
2009-04-28 02:52:28 +00:00
|
|
|
*
|
|
|
|
|
* 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;
|
2012-04-13 18:54:30 +00:00
|
|
|
int ret, i;
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2013-11-15 03:34:06 +00:00
|
|
|
state = readl(&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
|
|
|
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "// Reset the HC");
|
2013-11-15 03:34:06 +00:00
|
|
|
command = readl(&xhci->op_regs->command);
|
2009-04-28 02:52:28 +00:00
|
|
|
command |= CMD_RESET;
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(command, &xhci->op_regs->command);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2012-10-25 20:27:51 +00:00
|
|
|
ret = xhci_handshake(xhci, &xhci->op_regs->command,
|
2012-07-23 23:06:08 +00:00
|
|
|
CMD_RESET, 0, 10 * 1000 * 1000);
|
2010-05-24 20:25:15 +00:00
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
|
|
|
|
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Wait for controller to be ready for doorbell rings");
|
2010-05-24 20:25:15 +00:00
|
|
|
/*
|
|
|
|
|
* xHCI cannot write to any doorbells or operational registers other
|
|
|
|
|
* than status until the "Controller Not Ready" flag is cleared.
|
|
|
|
|
*/
|
2012-10-25 20:27:51 +00:00
|
|
|
ret = xhci_handshake(xhci, &xhci->op_regs->status,
|
2012-07-23 23:06:08 +00:00
|
|
|
STS_CNR, 0, 10 * 1000 * 1000);
|
2012-04-13 18:54:30 +00:00
|
|
|
|
|
|
|
|
for (i = 0; i < 2; ++i) {
|
|
|
|
|
xhci->bus_state[i].port_c_suspend = 0;
|
|
|
|
|
xhci->bus_state[i].suspended_ports = 0;
|
|
|
|
|
xhci->bus_state[i].resuming_ports = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
|
|
|
|
|
2011-09-23 21:19:58 +00:00
|
|
|
#ifdef CONFIG_PCI
|
|
|
|
|
static int xhci_free_msi(struct xhci_hcd *xhci)
|
2010-07-21 23:56:08 +00:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
2011-09-23 21:19:58 +00:00
|
|
|
if (!xhci->msix_entries)
|
|
|
|
|
return -EINVAL;
|
2010-07-21 23:56:08 +00:00
|
|
|
|
2011-09-23 21:19:58 +00:00
|
|
|
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));
|
|
|
|
|
return 0;
|
2010-07-21 23:56:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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) {
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"failed to allocate MSI entry");
|
2010-07-21 23:56:08 +00:00
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2013-05-24 02:54:19 +00:00
|
|
|
ret = request_irq(pdev->irq, xhci_msi_irq,
|
2010-07-21 23:56:08 +00:00
|
|
|
0, "xhci_hcd", xhci_to_hcd(xhci));
|
|
|
|
|
if (ret) {
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"disable MSI interrupt");
|
2010-07-21 23:56:08 +00:00
|
|
|
pci_disable_msi(pdev);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-23 21:19:58 +00:00
|
|
|
/*
|
|
|
|
|
* Free IRQs
|
|
|
|
|
* free all IRQs request
|
|
|
|
|
*/
|
|
|
|
|
static void xhci_free_irq(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
/* return if using legacy interrupt */
|
2012-02-29 14:46:23 +00:00
|
|
|
if (xhci_to_hcd(xhci)->irq > 0)
|
2011-09-23 21:19:58 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
ret = xhci_free_msi(xhci);
|
|
|
|
|
if (!ret)
|
|
|
|
|
return;
|
2012-02-29 14:46:23 +00:00
|
|
|
if (pdev->irq > 0)
|
2011-09-23 21:19:58 +00:00
|
|
|
free_irq(pdev->irq, xhci_to_hcd(xhci));
|
|
|
|
|
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2010-07-21 23:56:08 +00:00
|
|
|
/*
|
|
|
|
|
* Set up MSI-X
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_setup_msix(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
int i, ret = 0;
|
2010-12-27 09:39:02 +00:00
|
|
|
struct usb_hcd *hcd = xhci_to_hcd(xhci);
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
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,
|
2010-11-11 17:41:02 +00:00
|
|
|
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
|
|
|
|
2014-05-08 16:25:58 +00:00
|
|
|
ret = pci_enable_msix_exact(pdev, xhci->msix_entries, xhci->msix_count);
|
2009-04-28 02:52:28 +00:00
|
|
|
if (ret) {
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Failed to enable MSI-X");
|
2009-04-28 02:52:28 +00:00
|
|
|
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,
|
2013-05-24 02:54:19 +00:00
|
|
|
xhci_msi_irq,
|
2010-07-21 23:56:08 +00:00
|
|
|
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
|
|
|
|
2010-12-27 09:39:02 +00:00
|
|
|
hcd->msix_enabled = 1;
|
2010-07-21 23:56:08 +00:00
|
|
|
return ret;
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
disable_msix:
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "disable MSI-X interrupt");
|
2010-07-21 23:56:08 +00:00
|
|
|
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)
|
|
|
|
|
{
|
2010-12-27 09:39:02 +00:00
|
|
|
struct usb_hcd *hcd = xhci_to_hcd(xhci);
|
|
|
|
|
struct pci_dev *pdev = to_pci_dev(hcd->self.controller);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2013-11-15 22:53:14 +00:00
|
|
|
if (xhci->quirks & XHCI_PLAT)
|
|
|
|
|
return;
|
|
|
|
|
|
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);
|
|
|
|
|
}
|
|
|
|
|
|
2010-12-27 09:39:02 +00:00
|
|
|
hcd->msix_enabled = 0;
|
2010-07-21 23:56:08 +00:00
|
|
|
return;
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
|
|
|
|
|
2013-07-23 18:58:20 +00:00
|
|
|
static void __maybe_unused xhci_msix_sync_irqs(struct xhci_hcd *xhci)
|
2011-09-23 21:19:58 +00:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
if (xhci->msix_entries) {
|
|
|
|
|
for (i = 0; i < xhci->msix_count; i++)
|
|
|
|
|
synchronize_irq(xhci->msix_entries[i].vector);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int xhci_try_enable_msi(struct usb_hcd *hcd)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
xhci-plat: Don't enable legacy PCI interrupts.
The xHCI platform driver calls into usb_add_hcd to register the irq for
its platform device. It does not want the xHCI generic driver to
register an interrupt for it at all. The original code did that by
setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not
enable MSI or MSI-X for a PCI host.
Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled,
the xHCI generic driver will attempt to register a legacy PCI interrupt
for the xHCI platform device in xhci_try_enable_msi(). This will result
in a bogus irq being registered, since the underlying device is a
platform_device, not a pci_device, and thus the pci_device->irq pointer
will be bogus.
Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can
distinguish between a PCI device that can't handle MSI or MSI-X, and a
platform device that should not have its interrupts touched at all.
This quirk may be useful in the future, in case other corner cases like
this arise.
This patch should be backported to kernels as old as 3.9, that
contain the commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb "USB: xhci:
correctly enable interrupts".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Yu Y Wang <yu.y.wang@intel.com>
Tested-by: Yu Y Wang <yu.y.wang@intel.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Cc: stable@vger.kernel.org
2013-08-08 17:08:34 +00:00
|
|
|
struct pci_dev *pdev;
|
2011-09-23 21:19:58 +00:00
|
|
|
int ret;
|
|
|
|
|
|
xhci-plat: Don't enable legacy PCI interrupts.
The xHCI platform driver calls into usb_add_hcd to register the irq for
its platform device. It does not want the xHCI generic driver to
register an interrupt for it at all. The original code did that by
setting the XHCI_BROKEN_MSI quirk, which tells the xHCI driver to not
enable MSI or MSI-X for a PCI host.
Unfortunately, if CONFIG_PCI is enabled, and CONFIG_USB_DW3 is enabled,
the xHCI generic driver will attempt to register a legacy PCI interrupt
for the xHCI platform device in xhci_try_enable_msi(). This will result
in a bogus irq being registered, since the underlying device is a
platform_device, not a pci_device, and thus the pci_device->irq pointer
will be bogus.
Add a new quirk, XHCI_PLAT, so that the xHCI generic driver can
distinguish between a PCI device that can't handle MSI or MSI-X, and a
platform device that should not have its interrupts touched at all.
This quirk may be useful in the future, in case other corner cases like
this arise.
This patch should be backported to kernels as old as 3.9, that
contain the commit 00eed9c814cb8f281be6f0f5d8f45025dc0a97eb "USB: xhci:
correctly enable interrupts".
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Yu Y Wang <yu.y.wang@intel.com>
Tested-by: Yu Y Wang <yu.y.wang@intel.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Cc: stable@vger.kernel.org
2013-08-08 17:08:34 +00:00
|
|
|
/* The xhci platform device has set up IRQs through usb_add_hcd. */
|
|
|
|
|
if (xhci->quirks & XHCI_PLAT)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
pdev = to_pci_dev(xhci_to_hcd(xhci)->self.controller);
|
2011-09-23 21:19:58 +00:00
|
|
|
/*
|
|
|
|
|
* Some Fresco Logic host controllers advertise MSI, but fail to
|
|
|
|
|
* generate interrupts. Don't even try to enable MSI.
|
|
|
|
|
*/
|
|
|
|
|
if (xhci->quirks & XHCI_BROKEN_MSI)
|
2013-03-04 16:14:43 +00:00
|
|
|
goto legacy_irq;
|
2011-09-23 21:19:58 +00:00
|
|
|
|
|
|
|
|
/* unregister the legacy interrupt */
|
|
|
|
|
if (hcd->irq)
|
|
|
|
|
free_irq(hcd->irq, hcd);
|
2012-02-29 14:46:23 +00:00
|
|
|
hcd->irq = 0;
|
2011-09-23 21:19:58 +00:00
|
|
|
|
|
|
|
|
ret = xhci_setup_msix(xhci);
|
|
|
|
|
if (ret)
|
|
|
|
|
/* fall back to msi*/
|
|
|
|
|
ret = xhci_setup_msi(xhci);
|
|
|
|
|
|
|
|
|
|
if (!ret)
|
2012-02-29 14:46:23 +00:00
|
|
|
/* hcd->irq is 0, we have MSI */
|
2011-09-23 21:19:58 +00:00
|
|
|
return 0;
|
|
|
|
|
|
2012-02-14 00:25:57 +00:00
|
|
|
if (!pdev->irq) {
|
|
|
|
|
xhci_err(xhci, "No msi-x/msi found and no IRQ in BIOS\n");
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-04 16:14:43 +00:00
|
|
|
legacy_irq:
|
2014-02-27 11:26:03 +00:00
|
|
|
if (!strlen(hcd->irq_descr))
|
|
|
|
|
snprintf(hcd->irq_descr, sizeof(hcd->irq_descr), "%s:usb%d",
|
|
|
|
|
hcd->driver->description, hcd->self.busnum);
|
|
|
|
|
|
2011-09-23 21:19:58 +00:00
|
|
|
/* 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;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
2014-04-25 16:20:16 +00:00
|
|
|
static inline int xhci_try_enable_msi(struct usb_hcd *hcd)
|
2011-09-23 21:19:58 +00:00
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2014-04-25 16:20:16 +00:00
|
|
|
static inline void xhci_cleanup_msix(struct xhci_hcd *xhci)
|
2011-09-23 21:19:58 +00:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
2014-04-25 16:20:16 +00:00
|
|
|
static inline void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
|
2011-09-23 21:19:58 +00:00
|
|
|
{
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
static void compliance_mode_recovery(unsigned long arg)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
struct usb_hcd *hcd;
|
|
|
|
|
u32 temp;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
xhci = (struct xhci_hcd *)arg;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < xhci->num_usb3_ports; i++) {
|
2013-11-15 03:34:06 +00:00
|
|
|
temp = readl(xhci->usb3_ports[i]);
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
if ((temp & PORT_PLS_MASK) == USB_SS_PORT_LS_COMP_MOD) {
|
|
|
|
|
/*
|
|
|
|
|
* Compliance Mode Detected. Letting USB Core
|
|
|
|
|
* handle the Warm Reset
|
|
|
|
|
*/
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Compliance mode detected->port %d",
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
i + 1);
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Attempting compliance mode recovery");
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
hcd = xhci->shared_hcd;
|
|
|
|
|
|
|
|
|
|
if (hcd->state == HC_STATE_SUSPENDED)
|
|
|
|
|
usb_hcd_resume_root_hub(hcd);
|
|
|
|
|
|
|
|
|
|
usb_hcd_poll_rh_status(hcd);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (xhci->port_status_u0 != ((1 << xhci->num_usb3_ports)-1))
|
|
|
|
|
mod_timer(&xhci->comp_mode_recovery_timer,
|
|
|
|
|
jiffies + msecs_to_jiffies(COMP_MODE_RCVRY_MSECS));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Quirk to work around issue generated by the SN65LVPE502CP USB3.0 re-driver
|
|
|
|
|
* that causes ports behind that hardware to enter compliance mode sometimes.
|
|
|
|
|
* The quirk creates a timer that polls every 2 seconds the link state of
|
|
|
|
|
* each host controller's port and recovers it by issuing a Warm reset
|
|
|
|
|
* if Compliance mode is detected, otherwise the port will become "dead" (no
|
|
|
|
|
* device connections or disconnections will be detected anymore). Becasue no
|
|
|
|
|
* status event is generated when entering compliance mode (per xhci spec),
|
|
|
|
|
* this quirk is needed on systems that have the failing hardware installed.
|
|
|
|
|
*/
|
|
|
|
|
static void compliance_mode_recovery_timer_init(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
xhci->port_status_u0 = 0;
|
|
|
|
|
init_timer(&xhci->comp_mode_recovery_timer);
|
|
|
|
|
|
|
|
|
|
xhci->comp_mode_recovery_timer.data = (unsigned long) xhci;
|
|
|
|
|
xhci->comp_mode_recovery_timer.function = compliance_mode_recovery;
|
|
|
|
|
xhci->comp_mode_recovery_timer.expires = jiffies +
|
|
|
|
|
msecs_to_jiffies(COMP_MODE_RCVRY_MSECS);
|
|
|
|
|
|
|
|
|
|
set_timer_slack(&xhci->comp_mode_recovery_timer,
|
|
|
|
|
msecs_to_jiffies(COMP_MODE_RCVRY_MSECS));
|
|
|
|
|
add_timer(&xhci->comp_mode_recovery_timer);
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Compliance mode recovery timer initialized");
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This function identifies the systems that have installed the SN65LVPE502CP
|
|
|
|
|
* USB3.0 re-driver and that need the Compliance Mode Quirk.
|
|
|
|
|
* Systems:
|
|
|
|
|
* Vendor: Hewlett-Packard -> System Models: Z420, Z620 and Z820
|
|
|
|
|
*/
|
xhci: Disable D3cold for buggy TI redrivers.
Some xHCI hosts contain a "redriver" from TI that silently drops port
status connect changes if the port slips into Compliance Mode. If the
port slips into compliance mode while the host is in D0, there will not
be a port status change event. If the port slips into compliance mode
while the host is in D3, the host will not send a PME. This includes
when the system is suspended (S3) or hibernated (S4).
If this happens when the system is in S3/S4, there is nothing software
can do. Other port status change events that would normally cause the
host to wake the system from S3/S4 may also be lost. This includes
remote wakeup, disconnects and connects on other ports, and overrcurrent
events. A decision was made to _NOT_ disable system suspend/hibernate
on these systems, since users are unlikely to enable wakeup from S3/S4
for the xHCI host.
Software can deal with this issue when the system is in S0. A work
around was put in to poll the port status registers for Compliance Mode.
The xHCI driver will continue to poll the registers while the host is
runtime suspended. Unfortunately, that means we can't allow the PCI
device to go into D3cold, because power will be removed from the host,
and the config space will read as all Fs.
Disable D3cold in the xHCI PCI runtime suspend function.
This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: stable@vger.kernel.org
2013-04-18 17:02:03 +00:00
|
|
|
bool xhci_compliance_mode_recovery_timer_quirk_check(void)
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
{
|
|
|
|
|
const char *dmi_product_name, *dmi_sys_vendor;
|
|
|
|
|
|
|
|
|
|
dmi_product_name = dmi_get_system_info(DMI_PRODUCT_NAME);
|
|
|
|
|
dmi_sys_vendor = dmi_get_system_info(DMI_SYS_VENDOR);
|
2012-09-22 12:41:19 +00:00
|
|
|
if (!dmi_product_name || !dmi_sys_vendor)
|
|
|
|
|
return false;
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
|
|
|
|
|
if (!(strstr(dmi_sys_vendor, "Hewlett-Packard")))
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
if (strstr(dmi_product_name, "Z420") ||
|
|
|
|
|
strstr(dmi_product_name, "Z620") ||
|
2012-10-17 19:09:12 +00:00
|
|
|
strstr(dmi_product_name, "Z820") ||
|
2012-11-08 22:59:27 +00:00
|
|
|
strstr(dmi_product_name, "Z1 Workstation"))
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int xhci_all_ports_seen_u0(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
return (xhci->port_status_u0 == ((1 << xhci->num_usb3_ports)-1));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "xhci_init");
|
2009-04-28 02:52:28 +00:00
|
|
|
spin_lock_init(&xhci->lock);
|
2011-09-13 23:41:10 +00:00
|
|
|
if (xhci->hci_version == 0x95 && link_quirk) {
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"QUIRK: Not clearing Link TRB chain bits.");
|
2009-08-07 21:04:36 +00:00
|
|
|
xhci->quirks |= XHCI_LINK_TRB_QUIRK;
|
|
|
|
|
} else {
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"xHCI doesn't need link TRB QUIRK");
|
2009-08-07 21:04:36 +00:00
|
|
|
}
|
2009-04-28 02:52:28 +00:00
|
|
|
retval = xhci_mem_init(xhci, GFP_KERNEL);
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Finished xhci_init");
|
2009-04-28 02:52:28 +00:00
|
|
|
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
/* Initializing Compliance Mode Recovery Data If Needed */
|
xhci: Disable D3cold for buggy TI redrivers.
Some xHCI hosts contain a "redriver" from TI that silently drops port
status connect changes if the port slips into Compliance Mode. If the
port slips into compliance mode while the host is in D0, there will not
be a port status change event. If the port slips into compliance mode
while the host is in D3, the host will not send a PME. This includes
when the system is suspended (S3) or hibernated (S4).
If this happens when the system is in S3/S4, there is nothing software
can do. Other port status change events that would normally cause the
host to wake the system from S3/S4 may also be lost. This includes
remote wakeup, disconnects and connects on other ports, and overrcurrent
events. A decision was made to _NOT_ disable system suspend/hibernate
on these systems, since users are unlikely to enable wakeup from S3/S4
for the xHCI host.
Software can deal with this issue when the system is in S0. A work
around was put in to poll the port status registers for Compliance Mode.
The xHCI driver will continue to poll the registers while the host is
runtime suspended. Unfortunately, that means we can't allow the PCI
device to go into D3cold, because power will be removed from the host,
and the config space will read as all Fs.
Disable D3cold in the xHCI PCI runtime suspend function.
This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: stable@vger.kernel.org
2013-04-18 17:02:03 +00:00
|
|
|
if (xhci_compliance_mode_recovery_timer_quirk_check()) {
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
xhci->quirks |= XHCI_COMP_MODE_QUIRK;
|
|
|
|
|
compliance_mode_recovery_timer_init(xhci);
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:53:56 +00:00
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
static int xhci_run_finished(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
if (xhci_start(xhci)) {
|
|
|
|
|
xhci_halt(xhci);
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
xhci->shared_hcd->state = HC_STATE_RUNNING;
|
2012-06-27 08:30:57 +00:00
|
|
|
xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
|
|
|
|
|
if (xhci->quirks & XHCI_NEC_HOST)
|
|
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
|
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Finished xhci_run for USB3 roothub");
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
2011-09-23 21:19:57 +00:00
|
|
|
int ret;
|
2009-04-28 02:52:28 +00:00
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
/* Start the xHCI host controller running only after the USB 2.0 roothub
|
|
|
|
|
* is setup.
|
|
|
|
|
*/
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2009-04-28 02:57:12 +00:00
|
|
|
hcd->uses_new_polling = 1;
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
if (!usb_hcd_is_primary_hcd(hcd))
|
|
|
|
|
return xhci_run_finished(xhci);
|
2009-04-28 02:57:12 +00:00
|
|
|
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "xhci_run");
|
2010-07-21 23:56:08 +00:00
|
|
|
|
2011-09-23 21:19:57 +00:00
|
|
|
ret = xhci_try_enable_msi(hcd);
|
2010-07-21 23:56:08 +00:00
|
|
|
if (ret)
|
2011-09-23 21:19:57 +00:00
|
|
|
return ret;
|
2009-04-28 02:52:28 +00:00
|
|
|
|
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);
|
2014-01-30 21:27:49 +00:00
|
|
|
temp_64 = xhci_read_64(xhci, &xhci->ir_set->erst_dequeue);
|
2009-07-27 19:03:46 +00:00
|
|
|
temp_64 &= ~ERST_PTR_MASK;
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"ERST deq = 64'h%0lx", (long unsigned int) temp_64);
|
2009-07-27 19:03:46 +00:00
|
|
|
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Set the interrupt modulation register");
|
2013-11-15 03:34:06 +00:00
|
|
|
temp = readl(&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;
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(temp, &xhci->ir_set->irq_control);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
/* Set the HCD state before we enable the irqs */
|
2013-11-15 03:34:06 +00:00
|
|
|
temp = readl(&xhci->op_regs->command);
|
2009-04-28 02:52:28 +00:00
|
|
|
temp |= (CMD_EIE);
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Enable interrupts, cmd = 0x%x.", temp);
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(temp, &xhci->op_regs->command);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2013-11-15 03:34:06 +00:00
|
|
|
temp = readl(&xhci->ir_set->irq_pending);
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Enabling event ring interrupter %p by writing 0x%x to irq_pending",
|
2009-04-30 02:14:08 +00:00
|
|
|
xhci->ir_set, (unsigned int) ER_IRQ_ENABLE(temp));
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(ER_IRQ_ENABLE(temp), &xhci->ir_set->irq_pending);
|
2011-02-09 00:29:33 +00:00
|
|
|
xhci_print_ir_set(xhci, 0);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2014-05-08 16:26:00 +00:00
|
|
|
if (xhci->quirks & XHCI_NEC_HOST) {
|
|
|
|
|
struct xhci_command *command;
|
|
|
|
|
command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
|
|
|
|
|
if (!command)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
xhci_queue_vendor_command(xhci, command, 0, 0, 0,
|
2010-05-24 20:25:28 +00:00
|
|
|
TRB_TYPE(TRB_NEC_GET_FW));
|
2014-05-08 16:26:00 +00:00
|
|
|
}
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"Finished xhci_run for USB2 roothub");
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
2010-05-24 20:25:21 +00:00
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
static void xhci_only_stop_hcd(struct usb_hcd *hcd)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
spin_lock_irq(&xhci->lock);
|
|
|
|
|
xhci_halt(xhci);
|
|
|
|
|
|
|
|
|
|
/* The shared_hcd is going to be deallocated shortly (the USB core only
|
|
|
|
|
* calls this function when allocation fails in usb_add_hcd(), or
|
|
|
|
|
* usb_remove_hcd() is called). So we need to unset xHCI's pointer.
|
|
|
|
|
*/
|
|
|
|
|
xhci->shared_hcd = NULL;
|
|
|
|
|
spin_unlock_irq(&xhci->lock);
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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);
|
|
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
if (!usb_hcd_is_primary_hcd(hcd)) {
|
|
|
|
|
xhci_only_stop_hcd(xhci->shared_hcd);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
spin_lock_irq(&xhci->lock);
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
/* Make sure the xHC is halted for a USB3 roothub
|
|
|
|
|
* (xhci_stop() could be called as part of failed init).
|
|
|
|
|
*/
|
2009-04-28 02:52:28 +00:00
|
|
|
xhci_halt(xhci);
|
|
|
|
|
xhci_reset(xhci);
|
|
|
|
|
spin_unlock_irq(&xhci->lock);
|
|
|
|
|
|
2010-12-17 21:17:04 +00:00
|
|
|
xhci_cleanup_msix(xhci);
|
|
|
|
|
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
/* Deleting Compliance Mode Recovery Timer */
|
|
|
|
|
if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) &&
|
2013-04-05 18:27:07 +00:00
|
|
|
(!(xhci_all_ports_seen_u0(xhci)))) {
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
del_timer_sync(&xhci->comp_mode_recovery_timer);
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"%s: compliance mode recovery timer deleted",
|
2013-04-05 18:27:07 +00:00
|
|
|
__func__);
|
|
|
|
|
}
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
|
2011-03-22 09:08:14 +00:00
|
|
|
if (xhci->quirks & XHCI_AMD_PLL_FIX)
|
|
|
|
|
usb_amd_dev_put();
|
|
|
|
|
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Disabling event ring interrupts");
|
2013-11-15 03:34:06 +00:00
|
|
|
temp = readl(&xhci->op_regs->status);
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(temp & ~STS_EINT, &xhci->op_regs->status);
|
2013-11-15 03:34:06 +00:00
|
|
|
temp = readl(&xhci->ir_set->irq_pending);
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(ER_IRQ_DISABLE(temp), &xhci->ir_set->irq_pending);
|
2011-02-09 00:29:33 +00:00
|
|
|
xhci_print_ir_set(xhci, 0);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "cleaning up memory");
|
2009-04-28 02:52:28 +00:00
|
|
|
xhci_mem_cleanup(xhci);
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"xhci_stop completed - status = %x",
|
2013-11-15 03:34:06 +00:00
|
|
|
readl(&xhci->op_regs->status));
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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.
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
*
|
|
|
|
|
* This will only ever be called with the main usb_hcd (the USB3 roothub).
|
2009-04-28 02:52:28 +00:00
|
|
|
*/
|
|
|
|
|
void xhci_shutdown(struct usb_hcd *hcd)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
|
2012-08-13 16:57:03 +00:00
|
|
|
if (xhci->quirks & XHCI_SPURIOUS_REBOOT)
|
xhci: Switch PPT ports to EHCI on shutdown.
The Intel desktop boards DH77EB and DH77DF have a hardware issue that
can be worked around by BIOS. If the USB ports are switched to xHCI on
shutdown, the xHCI host will send a spurious interrupt, which will wake
the system. Some BIOS will work around this, but not all.
The bug can be avoided if the USB ports are switched back to EHCI on
shutdown. The Intel Windows driver switches the ports back to EHCI, so
change the Linux xHCI driver to do the same.
Unfortunately, we can't tell the two effected boards apart from other
working motherboards, because the vendors will change the DMI strings
for the DH77EB and DH77DF boards to their own custom names. One example
is Compulab's mini-desktop, the Intense-PC. Instead, key off the
Panther Point xHCI host PCI vendor and device ID, and switch the ports
over for all PPT xHCI hosts.
The only impact this will have on non-effected boards is to add a couple
hundred milliseconds delay on boot when the BIOS has to switch the ports
over from EHCI to xHCI.
This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Denis Turischev <denis@compulab.co.il>
Tested-by: Denis Turischev <denis@compulab.co.il>
Cc: stable@vger.kernel.org
2012-07-23 15:59:30 +00:00
|
|
|
usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
spin_lock_irq(&xhci->lock);
|
|
|
|
|
xhci_halt(xhci);
|
2013-09-12 06:11:06 +00:00
|
|
|
/* Workaround for spurious wakeups at shutdown with HSW */
|
|
|
|
|
if (xhci->quirks & XHCI_SPURIOUS_WAKEUP)
|
|
|
|
|
xhci_reset(xhci);
|
2010-07-21 23:56:08 +00:00
|
|
|
spin_unlock_irq(&xhci->lock);
|
2009-04-28 02:52:28 +00:00
|
|
|
|
2010-12-17 21:17:04 +00:00
|
|
|
xhci_cleanup_msix(xhci);
|
|
|
|
|
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"xhci_shutdown completed - status = %x",
|
2013-11-15 03:34:06 +00:00
|
|
|
readl(&xhci->op_regs->status));
|
2013-09-12 06:11:06 +00:00
|
|
|
|
|
|
|
|
/* Yet another workaround for spurious wakeups at shutdown with HSW */
|
|
|
|
|
if (xhci->quirks & XHCI_SPURIOUS_WAKEUP)
|
|
|
|
|
pci_set_power_state(to_pci_dev(hcd->self.controller), PCI_D3hot);
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
|
|
|
|
|
2010-10-15 18:24:14 +00:00
|
|
|
#ifdef CONFIG_PM
|
2010-10-14 14:23:06 +00:00
|
|
|
static void xhci_save_registers(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
2013-11-15 03:34:06 +00:00
|
|
|
xhci->s3.command = readl(&xhci->op_regs->command);
|
|
|
|
|
xhci->s3.dev_nt = readl(&xhci->op_regs->dev_notification);
|
2014-01-30 21:27:49 +00:00
|
|
|
xhci->s3.dcbaa_ptr = xhci_read_64(xhci, &xhci->op_regs->dcbaa_ptr);
|
2013-11-15 03:34:06 +00:00
|
|
|
xhci->s3.config_reg = readl(&xhci->op_regs->config_reg);
|
|
|
|
|
xhci->s3.erst_size = readl(&xhci->ir_set->erst_size);
|
2014-01-30 21:27:49 +00:00
|
|
|
xhci->s3.erst_base = xhci_read_64(xhci, &xhci->ir_set->erst_base);
|
|
|
|
|
xhci->s3.erst_dequeue = xhci_read_64(xhci, &xhci->ir_set->erst_dequeue);
|
2013-11-15 03:34:06 +00:00
|
|
|
xhci->s3.irq_pending = readl(&xhci->ir_set->irq_pending);
|
|
|
|
|
xhci->s3.irq_control = readl(&xhci->ir_set->irq_control);
|
2010-10-14 14:23:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void xhci_restore_registers(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(xhci->s3.command, &xhci->op_regs->command);
|
|
|
|
|
writel(xhci->s3.dev_nt, &xhci->op_regs->dev_notification);
|
2014-01-29 22:02:00 +00:00
|
|
|
xhci_write_64(xhci, xhci->s3.dcbaa_ptr, &xhci->op_regs->dcbaa_ptr);
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(xhci->s3.config_reg, &xhci->op_regs->config_reg);
|
|
|
|
|
writel(xhci->s3.erst_size, &xhci->ir_set->erst_size);
|
2014-01-29 22:02:00 +00:00
|
|
|
xhci_write_64(xhci, xhci->s3.erst_base, &xhci->ir_set->erst_base);
|
|
|
|
|
xhci_write_64(xhci, xhci->s3.erst_dequeue, &xhci->ir_set->erst_dequeue);
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(xhci->s3.irq_pending, &xhci->ir_set->irq_pending);
|
|
|
|
|
writel(xhci->s3.irq_control, &xhci->ir_set->irq_control);
|
2010-10-14 14:23:06 +00:00
|
|
|
}
|
|
|
|
|
|
xhci: Fix command ring replay after resume.
Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.
After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer. I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.
Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned. The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.
Here's a log excerpt. On init, the xHCI driver places a vendor-specific
command on the command ring:
[ 215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[ 215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[ 215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)
When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010. Instead, it's 0x3781e000:
[ 235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[ 235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[ 235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[ 235.557866] usb usb9: root hub lost power or was reset
(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)
The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring. We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory. (The pointer isn't required to
be in the suspend power well, but it could be.) The command ring pointer
is set again after the host resumes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Andiry Xu <andiry.xu@amd.com>
2010-11-12 19:59:31 +00:00
|
|
|
static void xhci_set_cmd_ring_deq(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
u64 val_64;
|
|
|
|
|
|
|
|
|
|
/* step 2: initialize command ring buffer */
|
2014-01-30 21:27:49 +00:00
|
|
|
val_64 = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
|
xhci: Fix command ring replay after resume.
Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.
After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer. I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.
Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned. The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.
Here's a log excerpt. On init, the xHCI driver places a vendor-specific
command on the command ring:
[ 215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[ 215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[ 215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)
When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010. Instead, it's 0x3781e000:
[ 235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[ 235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[ 235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[ 235.557866] usb usb9: root hub lost power or was reset
(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)
The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring. We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory. (The pointer isn't required to
be in the suspend power well, but it could be.) The command ring pointer
is set again after the host resumes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Andiry Xu <andiry.xu@amd.com>
2010-11-12 19:59:31 +00:00
|
|
|
val_64 = (val_64 & (u64) CMD_RING_RSVD_BITS) |
|
|
|
|
|
(xhci_trb_virt_to_dma(xhci->cmd_ring->deq_seg,
|
|
|
|
|
xhci->cmd_ring->dequeue) &
|
|
|
|
|
(u64) ~CMD_RING_RSVD_BITS) |
|
|
|
|
|
xhci->cmd_ring->cycle_state;
|
2013-08-14 03:33:55 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
|
|
|
|
|
"// Setting command ring address to 0x%llx",
|
xhci: Fix command ring replay after resume.
Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.
After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer. I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.
Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned. The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.
Here's a log excerpt. On init, the xHCI driver places a vendor-specific
command on the command ring:
[ 215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[ 215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[ 215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)
When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010. Instead, it's 0x3781e000:
[ 235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[ 235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[ 235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[ 235.557866] usb usb9: root hub lost power or was reset
(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)
The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring. We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory. (The pointer isn't required to
be in the suspend power well, but it could be.) The command ring pointer
is set again after the host resumes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Andiry Xu <andiry.xu@amd.com>
2010-11-12 19:59:31 +00:00
|
|
|
(long unsigned long) val_64);
|
2014-01-29 22:02:00 +00:00
|
|
|
xhci_write_64(xhci, val_64, &xhci->op_regs->cmd_ring);
|
xhci: Fix command ring replay after resume.
Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.
After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer. I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.
Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned. The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.
Here's a log excerpt. On init, the xHCI driver places a vendor-specific
command on the command ring:
[ 215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[ 215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[ 215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)
When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010. Instead, it's 0x3781e000:
[ 235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[ 235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[ 235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[ 235.557866] usb usb9: root hub lost power or was reset
(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)
The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring. We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory. (The pointer isn't required to
be in the suspend power well, but it could be.) The command ring pointer
is set again after the host resumes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Andiry Xu <andiry.xu@amd.com>
2010-11-12 19:59:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The whole command ring must be cleared to zero when we suspend the host.
|
|
|
|
|
*
|
|
|
|
|
* The host doesn't save the command ring pointer in the suspend well, so we
|
|
|
|
|
* need to re-program it on resume. Unfortunately, the pointer must be 64-byte
|
|
|
|
|
* aligned, because of the reserved bits in the command ring dequeue pointer
|
|
|
|
|
* register. Therefore, we can't just set the dequeue pointer back in the
|
|
|
|
|
* middle of the ring (TRBs are 16-byte aligned).
|
|
|
|
|
*/
|
|
|
|
|
static void xhci_clear_command_ring(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_ring *ring;
|
|
|
|
|
struct xhci_segment *seg;
|
|
|
|
|
|
|
|
|
|
ring = xhci->cmd_ring;
|
|
|
|
|
seg = ring->deq_seg;
|
|
|
|
|
do {
|
2011-11-30 08:37:41 +00:00
|
|
|
memset(seg->trbs, 0,
|
|
|
|
|
sizeof(union xhci_trb) * (TRBS_PER_SEGMENT - 1));
|
|
|
|
|
seg->trbs[TRBS_PER_SEGMENT - 1].link.control &=
|
|
|
|
|
cpu_to_le32(~TRB_CYCLE);
|
xhci: Fix command ring replay after resume.
Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.
After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer. I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.
Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned. The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.
Here's a log excerpt. On init, the xHCI driver places a vendor-specific
command on the command ring:
[ 215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[ 215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[ 215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)
When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010. Instead, it's 0x3781e000:
[ 235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[ 235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[ 235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[ 235.557866] usb usb9: root hub lost power or was reset
(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)
The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring. We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory. (The pointer isn't required to
be in the suspend power well, but it could be.) The command ring pointer
is set again after the host resumes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Andiry Xu <andiry.xu@amd.com>
2010-11-12 19:59:31 +00:00
|
|
|
seg = seg->next;
|
|
|
|
|
} while (seg != ring->deq_seg);
|
|
|
|
|
|
|
|
|
|
/* Reset the software enqueue and dequeue pointers */
|
|
|
|
|
ring->deq_seg = ring->first_seg;
|
|
|
|
|
ring->dequeue = ring->first_seg->trbs;
|
|
|
|
|
ring->enq_seg = ring->deq_seg;
|
|
|
|
|
ring->enqueue = ring->dequeue;
|
|
|
|
|
|
2012-03-05 09:49:34 +00:00
|
|
|
ring->num_trbs_free = ring->num_segs * (TRBS_PER_SEGMENT - 1) - 1;
|
xhci: Fix command ring replay after resume.
Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.
After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer. I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.
Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned. The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.
Here's a log excerpt. On init, the xHCI driver places a vendor-specific
command on the command ring:
[ 215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[ 215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[ 215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)
When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010. Instead, it's 0x3781e000:
[ 235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[ 235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[ 235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[ 235.557866] usb usb9: root hub lost power or was reset
(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)
The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring. We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory. (The pointer isn't required to
be in the suspend power well, but it could be.) The command ring pointer
is set again after the host resumes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Andiry Xu <andiry.xu@amd.com>
2010-11-12 19:59:31 +00:00
|
|
|
/*
|
|
|
|
|
* Ring is now zeroed, so the HW should look for change of ownership
|
|
|
|
|
* when the cycle bit is set to 1.
|
|
|
|
|
*/
|
|
|
|
|
ring->cycle_state = 1;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Reset the hardware dequeue pointer.
|
|
|
|
|
* Yes, this will need to be re-written after resume, but we're paranoid
|
|
|
|
|
* and want to make sure the hardware doesn't access bogus memory
|
|
|
|
|
* because, say, the BIOS or an SMI started the host without changing
|
|
|
|
|
* the command ring pointers.
|
|
|
|
|
*/
|
|
|
|
|
xhci_set_cmd_ring_deq(xhci);
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-14 14:23:06 +00:00
|
|
|
/*
|
|
|
|
|
* Stop HC (not bus-specific)
|
|
|
|
|
*
|
|
|
|
|
* This is called when the machine transition into S3/S4 mode.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
int xhci_suspend(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
int rc = 0;
|
2013-09-30 13:50:54 +00:00
|
|
|
unsigned int delay = XHCI_MAX_HALT_USEC;
|
2010-10-14 14:23:06 +00:00
|
|
|
struct usb_hcd *hcd = xhci_to_hcd(xhci);
|
|
|
|
|
u32 command;
|
|
|
|
|
|
2012-10-19 07:55:16 +00:00
|
|
|
if (hcd->state != HC_STATE_SUSPENDED ||
|
|
|
|
|
xhci->shared_hcd->state != HC_STATE_SUSPENDED)
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
xhci: Avoid "dead ports", add roothub port polling.
The USB core hub thread (khubd) is designed with external USB hubs in
mind. It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.
The xHCI host controller is designed to be edge-triggered on the logical
'OR' of all the port status change bits. When all port status change
bits are clear, and a new change bit is set, the xHC will generate a
Port Status Change Event. If another change bit is set in the same port
status register before the first bit is cleared, it will not send
another event.
This means that the hub code may lose port status changes because of
race conditions between clearing change bits. The user sees this as a
"dead port" that doesn't react to device connects.
The fix is to turn on port polling whenever a new change bit is set.
Once the USB core issues a hub status request that shows that no change
bits are set in any USB ports, turn off port polling.
We can't allow the USB core to poll the roothub for port events during
host suspend because if the PCI host is in D3cold, the port registers
will be all f's. Instead, stop the port polling timer, and
unconditionally restart it when the host resumes. If there are no port
change bits set after the resume, the first call to hub_status_data will
disable polling.
This patch should be backported to stable kernels with the first xHCI
support, 2.6.31 and newer, that include the commit
0f2a79300a1471cf92ab43af165ea13555c8b0a5 "USB: xhci: Root hub support."
There will be merge conflicts because the check for HC_STATE_SUSPENDED
was moved into xhci_suspend in 3.8.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
2012-11-27 20:30:23 +00:00
|
|
|
/* Don't poll the roothubs on bus suspend. */
|
|
|
|
|
xhci_dbg(xhci, "%s: stopping port polling.\n", __func__);
|
|
|
|
|
clear_bit(HCD_FLAG_POLL_RH, &hcd->flags);
|
|
|
|
|
del_timer_sync(&hcd->rh_timer);
|
|
|
|
|
|
2010-10-14 14:23:06 +00:00
|
|
|
spin_lock_irq(&xhci->lock);
|
|
|
|
|
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
|
2011-03-07 19:24:07 +00:00
|
|
|
clear_bit(HCD_FLAG_HW_ACCESSIBLE, &xhci->shared_hcd->flags);
|
2010-10-14 14:23:06 +00:00
|
|
|
/* step 1: stop endpoint */
|
|
|
|
|
/* skipped assuming that port suspend has done */
|
|
|
|
|
|
|
|
|
|
/* step 2: clear Run/Stop bit */
|
2013-11-15 03:34:06 +00:00
|
|
|
command = readl(&xhci->op_regs->command);
|
2010-10-14 14:23:06 +00:00
|
|
|
command &= ~CMD_RUN;
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(command, &xhci->op_regs->command);
|
2013-09-30 13:50:54 +00:00
|
|
|
|
|
|
|
|
/* Some chips from Fresco Logic need an extraordinary delay */
|
|
|
|
|
delay *= (xhci->quirks & XHCI_SLOW_SUSPEND) ? 10 : 1;
|
|
|
|
|
|
2012-10-25 20:27:51 +00:00
|
|
|
if (xhci_handshake(xhci, &xhci->op_regs->status,
|
2013-09-30 13:50:54 +00:00
|
|
|
STS_HALT, STS_HALT, delay)) {
|
2010-10-14 14:23:06 +00:00
|
|
|
xhci_warn(xhci, "WARN: xHC CMD_RUN timeout\n");
|
|
|
|
|
spin_unlock_irq(&xhci->lock);
|
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
|
}
|
xhci: Fix command ring replay after resume.
Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.
After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer. I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.
Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned. The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.
Here's a log excerpt. On init, the xHCI driver places a vendor-specific
command on the command ring:
[ 215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[ 215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[ 215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)
When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010. Instead, it's 0x3781e000:
[ 235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[ 235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[ 235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[ 235.557866] usb usb9: root hub lost power or was reset
(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)
The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring. We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory. (The pointer isn't required to
be in the suspend power well, but it could be.) The command ring pointer
is set again after the host resumes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Andiry Xu <andiry.xu@amd.com>
2010-11-12 19:59:31 +00:00
|
|
|
xhci_clear_command_ring(xhci);
|
2010-10-14 14:23:06 +00:00
|
|
|
|
|
|
|
|
/* step 3: save registers */
|
|
|
|
|
xhci_save_registers(xhci);
|
|
|
|
|
|
|
|
|
|
/* step 4: set CSS flag */
|
2013-11-15 03:34:06 +00:00
|
|
|
command = readl(&xhci->op_regs->command);
|
2010-10-14 14:23:06 +00:00
|
|
|
command |= CMD_CSS;
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(command, &xhci->op_regs->command);
|
2012-10-25 20:27:51 +00:00
|
|
|
if (xhci_handshake(xhci, &xhci->op_regs->status,
|
|
|
|
|
STS_SAVE, 0, 10 * 1000)) {
|
2012-06-13 02:51:57 +00:00
|
|
|
xhci_warn(xhci, "WARN: xHC save state timeout\n");
|
2010-10-14 14:23:06 +00:00
|
|
|
spin_unlock_irq(&xhci->lock);
|
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
|
}
|
|
|
|
|
spin_unlock_irq(&xhci->lock);
|
|
|
|
|
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
/*
|
|
|
|
|
* Deleting Compliance Mode Recovery Timer because the xHCI Host
|
|
|
|
|
* is about to be suspended.
|
|
|
|
|
*/
|
|
|
|
|
if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) &&
|
|
|
|
|
(!(xhci_all_ports_seen_u0(xhci)))) {
|
|
|
|
|
del_timer_sync(&xhci->comp_mode_recovery_timer);
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"%s: compliance mode recovery timer deleted",
|
2013-04-05 18:27:07 +00:00
|
|
|
__func__);
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
}
|
|
|
|
|
|
2010-12-27 09:39:02 +00:00
|
|
|
/* step 5: remove core well power */
|
|
|
|
|
/* synchronize irq when using MSI-X */
|
2011-09-23 21:19:58 +00:00
|
|
|
xhci_msix_sync_irqs(xhci);
|
2010-12-27 09:39:02 +00:00
|
|
|
|
2010-10-14 14:23:06 +00:00
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* start xHC (not bus-specific)
|
|
|
|
|
*
|
|
|
|
|
* This is called when the machine transition from S3/S4 mode.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
|
|
|
|
|
{
|
xhci: Fix runtime suspended xhci from blocking system suspend.
The system suspend flow as following:
1, Freeze all user processes and kenrel threads.
2, Try to suspend all devices.
2.1, If pci device is in RPM suspended state, then pci driver will try
to resume it to RPM active state in the prepare stage.
2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
workqueue items to resume usb2&usb3 roothub devices.
2.3, Call suspend callbacks of devices.
2.3.1, All suspend callbacks of all hcd's children, including
roothub devices are called.
2.3.2, Finally, hcd_pci_suspend callback is called.
Due to workqueue threads were already frozen in step 1, the workqueue
items can't be scheduled, and the roothub devices can't be resumed in
this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
usb_hcd_resume_root_hub won't be cleared. Finally,
hcd_pci_suspend will return -EBUSY, and system suspend fails.
The reason why this issue doesn't show up very often is due to that
choose_wakeup will be called in step 2.3.1. In step 2.3.1, if
udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then
udev will resume to RPM active for changing the wakeup settings. This
has been a lucky hit which hides this issue.
For some special xHCI controllers which have no USB2 port, then roothub
will not match hub driver due to probe failed. Then its
do_remote_wakeup will be set to zero, and we won't be as lucky.
xhci driver doesn't need to resume roothub devices everytime like in
the above case. It's only needed when there are pending event TRBs.
This patch should be back-ported to kernels as old as 3.2, that
contains the commit f69e3120df82391a0ee8118e0a156239a06b2afb
"USB: XHCI: resume root hubs when the controller resumes"
Cc: stable@vger.kernel.org # 3.2
Signed-off-by: Wang, Yu <yu.y.wang@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
[use readl() instead of removed xhci_readl(), reword commit message -Mathias]
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-24 14:14:44 +00:00
|
|
|
u32 command, temp = 0, status;
|
2010-10-14 14:23:06 +00:00
|
|
|
struct usb_hcd *hcd = xhci_to_hcd(xhci);
|
2010-12-17 20:35:05 +00:00
|
|
|
struct usb_hcd *secondary_hcd;
|
2011-11-03 15:37:10 +00:00
|
|
|
int retval = 0;
|
xhci - correct comp_mode_recovery_timer on return from hibernate
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP,
controller, but it introduced a bug in resume from hibernate.
The fix created a timer, comp_mode_recovery_timer, which is deleted from
a timer list when xhci_suspend() is called. However, the hibernate image,
including the timer list containing the comp_mode_recovery_timer, had
already been saved before the timer was deleted.
Upon resume from hibernate, the list containing the comp_mode_recovery_timer
is restored from the image saved to disk, and xhci_resume(), assuming that
the timer had been deleted by xhci_suspend(), makes a call to
compliance_mode_recoery_timer_init(), which creates a new instance of the
comp_mode_recovery_timer and attempts to place it into the same list in which
it is already active, thus corrupting the list during the list_add() call.
At this point, a call trace is emitted indicating the list corruption.
Soon afterward, the system locks up, the watchdog times out, and the
ensuing NMI crashes the system.
The problem did not occur when resuming from suspend. In suspend, the
image in RAM remains exactly as it was when xhci_suspend() deleted the
comp_mode_recovery_timer, so there is no problem when xhci_resume()
creates a new instance of this timer and places it in the still empty
list.
This patch avoids the problem by deleting the timer in xhci_resume()
when resuming from hibernate. Now xhci_resume() can safely make the
call to create a new instance of this timer, whether returning from
suspend or hibernate.
Thanks to Alan Stern for his help with understanding the problem.
[Sarah reworked this patch to cover the case where the xHCI restore
register operation fails, and (temp & STS_SRE) is true (and we re-init
the host, including re-init for the compliance mode), but hibernate is
false. The original patch would have caused list corruption in this
case.]
This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: Tony Camuso <tcamuso@redhat.com>
Tested-by: Tony Camuso <tcamuso@redhat.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-02-21 21:11:27 +00:00
|
|
|
bool comp_timer_running = false;
|
2010-10-14 14:23:06 +00:00
|
|
|
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
/* Wait a bit if either of the roothubs need to settle from the
|
2011-03-31 01:57:33 +00:00
|
|
|
* transition into bus suspend.
|
2010-12-15 20:47:14 +00:00
|
|
|
*/
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-16 19:21:10 +00:00
|
|
|
if (time_before(jiffies, xhci->bus_state[0].next_statechange) ||
|
|
|
|
|
time_before(jiffies,
|
|
|
|
|
xhci->bus_state[1].next_statechange))
|
2010-10-14 14:23:06 +00:00
|
|
|
msleep(100);
|
|
|
|
|
|
2011-11-03 15:37:10 +00:00
|
|
|
set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
|
|
|
|
|
set_bit(HCD_FLAG_HW_ACCESSIBLE, &xhci->shared_hcd->flags);
|
|
|
|
|
|
2010-10-14 14:23:06 +00:00
|
|
|
spin_lock_irq(&xhci->lock);
|
2011-06-15 21:47:21 +00:00
|
|
|
if (xhci->quirks & XHCI_RESET_ON_RESUME)
|
|
|
|
|
hibernated = true;
|
2010-10-14 14:23:06 +00:00
|
|
|
|
|
|
|
|
if (!hibernated) {
|
|
|
|
|
/* step 1: restore register */
|
|
|
|
|
xhci_restore_registers(xhci);
|
|
|
|
|
/* step 2: initialize command ring buffer */
|
xhci: Fix command ring replay after resume.
Andiry's xHCI bus suspend patch introduced the possibly of a host
controller replaying old commands on the command ring, if the host
successfully restores the registers after a resume.
After a resume from suspend, the xHCI driver must restore the registers,
including the command ring pointer. I had suggested that Andiry set the
command ring pointer to the current command ring dequeue pointer, so that
the driver wouldn't have to zero the command ring.
Unfortunately, setting the command ring pointer to the current dequeue
pointer won't work because the register assumes the pointer is 64-byte
aligned, and TRBs on the command ring are 16-byte aligned. The lower
seven bits will always be masked off, leading to the written pointer being
up to 3 TRBs behind the intended pointer.
Here's a log excerpt. On init, the xHCI driver places a vendor-specific
command on the command ring:
[ 215.750958] xhci_hcd 0000:01:00.0: Vendor specific event TRB type = 48
[ 215.750960] xhci_hcd 0000:01:00.0: NEC firmware version 30.25
[ 215.750962] xhci_hcd 0000:01:00.0: Command ring deq = 0x3781e010 (DMA)
When we resume, the command ring dequeue pointer to be written should have
been 0x3781e010. Instead, it's 0x3781e000:
[ 235.557846] xhci_hcd 0000:01:00.0: // Setting command ring address to 0x3781e001
[ 235.557848] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 64'hffffc900100bc038, 64'h3781e001, 4'hf);
[ 235.557850] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc900100bc020, 32'h204, 4'hf);
[ 235.557866] usb usb9: root hub lost power or was reset
(I can't see the results of this bug because the xHCI restore always fails
on this box, and the xHCI driver re-allocates everything.)
The fix is to zero the command ring and put the software and hardware
enqueue and dequeue pointer back to the beginning of the ring. We do this
before the system suspends, to be paranoid and prevent the BIOS from
starting the host without clearing the command ring pointer, which might
cause the host to muck with stale memory. (The pointer isn't required to
be in the suspend power well, but it could be.) The command ring pointer
is set again after the host resumes.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Andiry Xu <andiry.xu@amd.com>
2010-11-12 19:59:31 +00:00
|
|
|
xhci_set_cmd_ring_deq(xhci);
|
2010-10-14 14:23:06 +00:00
|
|
|
/* step 3: restore state and start state*/
|
|
|
|
|
/* step 3: set CRS flag */
|
2013-11-15 03:34:06 +00:00
|
|
|
command = readl(&xhci->op_regs->command);
|
2010-10-14 14:23:06 +00:00
|
|
|
command |= CMD_CRS;
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(command, &xhci->op_regs->command);
|
2012-10-25 20:27:51 +00:00
|
|
|
if (xhci_handshake(xhci, &xhci->op_regs->status,
|
2012-06-13 02:51:57 +00:00
|
|
|
STS_RESTORE, 0, 10 * 1000)) {
|
|
|
|
|
xhci_warn(xhci, "WARN: xHC restore state timeout\n");
|
2010-10-14 14:23:06 +00:00
|
|
|
spin_unlock_irq(&xhci->lock);
|
|
|
|
|
return -ETIMEDOUT;
|
|
|
|
|
}
|
2013-11-15 03:34:06 +00:00
|
|
|
temp = readl(&xhci->op_regs->status);
|
2010-10-14 14:23:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If restore operation fails, re-initialize the HC during resume */
|
|
|
|
|
if ((temp & STS_SRE) || hibernated) {
|
xhci - correct comp_mode_recovery_timer on return from hibernate
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP,
controller, but it introduced a bug in resume from hibernate.
The fix created a timer, comp_mode_recovery_timer, which is deleted from
a timer list when xhci_suspend() is called. However, the hibernate image,
including the timer list containing the comp_mode_recovery_timer, had
already been saved before the timer was deleted.
Upon resume from hibernate, the list containing the comp_mode_recovery_timer
is restored from the image saved to disk, and xhci_resume(), assuming that
the timer had been deleted by xhci_suspend(), makes a call to
compliance_mode_recoery_timer_init(), which creates a new instance of the
comp_mode_recovery_timer and attempts to place it into the same list in which
it is already active, thus corrupting the list during the list_add() call.
At this point, a call trace is emitted indicating the list corruption.
Soon afterward, the system locks up, the watchdog times out, and the
ensuing NMI crashes the system.
The problem did not occur when resuming from suspend. In suspend, the
image in RAM remains exactly as it was when xhci_suspend() deleted the
comp_mode_recovery_timer, so there is no problem when xhci_resume()
creates a new instance of this timer and places it in the still empty
list.
This patch avoids the problem by deleting the timer in xhci_resume()
when resuming from hibernate. Now xhci_resume() can safely make the
call to create a new instance of this timer, whether returning from
suspend or hibernate.
Thanks to Alan Stern for his help with understanding the problem.
[Sarah reworked this patch to cover the case where the xHCI restore
register operation fails, and (temp & STS_SRE) is true (and we re-init
the host, including re-init for the compliance mode), but hibernate is
false. The original patch would have caused list corruption in this
case.]
This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: Tony Camuso <tcamuso@redhat.com>
Tested-by: Tony Camuso <tcamuso@redhat.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-02-21 21:11:27 +00:00
|
|
|
|
|
|
|
|
if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) &&
|
|
|
|
|
!(xhci_all_ports_seen_u0(xhci))) {
|
|
|
|
|
del_timer_sync(&xhci->comp_mode_recovery_timer);
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Compliance Mode Recovery Timer deleted!");
|
xhci - correct comp_mode_recovery_timer on return from hibernate
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP,
controller, but it introduced a bug in resume from hibernate.
The fix created a timer, comp_mode_recovery_timer, which is deleted from
a timer list when xhci_suspend() is called. However, the hibernate image,
including the timer list containing the comp_mode_recovery_timer, had
already been saved before the timer was deleted.
Upon resume from hibernate, the list containing the comp_mode_recovery_timer
is restored from the image saved to disk, and xhci_resume(), assuming that
the timer had been deleted by xhci_suspend(), makes a call to
compliance_mode_recoery_timer_init(), which creates a new instance of the
comp_mode_recovery_timer and attempts to place it into the same list in which
it is already active, thus corrupting the list during the list_add() call.
At this point, a call trace is emitted indicating the list corruption.
Soon afterward, the system locks up, the watchdog times out, and the
ensuing NMI crashes the system.
The problem did not occur when resuming from suspend. In suspend, the
image in RAM remains exactly as it was when xhci_suspend() deleted the
comp_mode_recovery_timer, so there is no problem when xhci_resume()
creates a new instance of this timer and places it in the still empty
list.
This patch avoids the problem by deleting the timer in xhci_resume()
when resuming from hibernate. Now xhci_resume() can safely make the
call to create a new instance of this timer, whether returning from
suspend or hibernate.
Thanks to Alan Stern for his help with understanding the problem.
[Sarah reworked this patch to cover the case where the xHCI restore
register operation fails, and (temp & STS_SRE) is true (and we re-init
the host, including re-init for the compliance mode), but hibernate is
false. The original patch would have caused list corruption in this
case.]
This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: Tony Camuso <tcamuso@redhat.com>
Tested-by: Tony Camuso <tcamuso@redhat.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-02-21 21:11:27 +00:00
|
|
|
}
|
|
|
|
|
|
xhci: Tell USB core both roothubs lost power.
On a resume, when the power is lost during hibernate, the USB core will
call hub_reset_resume for the xHCI USB 2.0 roothub, but not for the USB
3.0 roothub:
[ 164.748310] usb usb1: root hub lost power or was reset
[ 164.748353] usb usb2: root hub lost power or was reset
[ 164.748487] usb usb3: root hub lost power or was reset
[ 164.748488] xhci_hcd 0000:01:00.0: Stop HCD
...
[ 164.870039] hub 4-0:1.0: hub_resume
...
[ 164.870054] hub 3-0:1.0: hub_reset_resume
This causes issues later, because the USB core assumes the USB 3.0 hub
attached to the USB 3.0 roothub is still active. It attempts to queue a
control URB for the external hub, which fails because all the device
slot contexts were released when the USB 3.0 roothub lost power:
[ 164.980044] hub 4-1:1.0: hub_resume
[ 164.980047] xhci_hcd 0000:01:00.0: Get port status returned 0x10101
[ 164.980049] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980053] hub 3-0:1.0: port 1: status 0101 change 0001
[ 164.980056] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980060] xhci_hcd 0000:01:00.0: `MEM_WRITE_DWORD(3'b000, 32'hffffc90008948440, 32'h202e1, 4'hf);
[ 164.980062] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980066] xhci_hcd 0000:01:00.0: clear port connect change, actual port 0 status = 0x2e1
[ 164.980069] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980072] xhci_hcd 0000:01:00.0: get port status, actual port 1 status = 0x2a0
[ 164.980074] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980077] xhci_hcd 0000:01:00.0: Get port status returned 0x100
[ 164.980079] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980082] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980085] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980088] hub 4-1:1.0: port 4: status 0000 change 0000
[ 164.980091] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980094] hub 4-1:1.0: activate --> -22
[ 164.980113] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980117] hub 4-1:1.0: hub_port_status failed (err = -22)
[ 164.980119] xHCI xhci_urb_enqueue called with unaddressed device
[ 164.980123] hub 4-1:1.0: can't resume port 4, status -22
[ 164.980126] hub 4-1:1.0: port 4 status ffff.ffff after resume, -22
[ 164.980129] usb 4-1.4: can't resume, status -22
[ 164.980131] hub 4-1:1.0: logical disconnect on port 4
This causes issues when a USB 3.0 hard drive is attached to the external
USB 3.0 hub when the system is hibernated:
[ 6249.849653] sd 8:0:0:0: [sdb] Unhandled error code
[ 6249.849659] sd 8:0:0:0: [sdb] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 6249.849663] sd 8:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 2a 08 00 00 02 00
[ 6249.849671] end_request: I/O error, dev sdb, sector 10760
Make sure to inform the USB core that *both* xHCI roothubs lost power.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-04-13 00:43:19 +00:00
|
|
|
/* Let the USB core know _both_ roothubs lost power. */
|
|
|
|
|
usb_root_hub_lost_power(xhci->main_hcd->self.root_hub);
|
|
|
|
|
usb_root_hub_lost_power(xhci->shared_hcd->self.root_hub);
|
2010-10-14 14:23:06 +00:00
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Stop HCD\n");
|
|
|
|
|
xhci_halt(xhci);
|
|
|
|
|
xhci_reset(xhci);
|
|
|
|
|
spin_unlock_irq(&xhci->lock);
|
2010-12-27 09:39:02 +00:00
|
|
|
xhci_cleanup_msix(xhci);
|
2010-10-14 14:23:06 +00:00
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "// Disabling event ring interrupts\n");
|
2013-11-15 03:34:06 +00:00
|
|
|
temp = readl(&xhci->op_regs->status);
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(temp & ~STS_EINT, &xhci->op_regs->status);
|
2013-11-15 03:34:06 +00:00
|
|
|
temp = readl(&xhci->ir_set->irq_pending);
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(ER_IRQ_DISABLE(temp), &xhci->ir_set->irq_pending);
|
2011-02-09 00:29:33 +00:00
|
|
|
xhci_print_ir_set(xhci, 0);
|
2010-10-14 14:23:06 +00:00
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "cleaning up memory\n");
|
|
|
|
|
xhci_mem_cleanup(xhci);
|
|
|
|
|
xhci_dbg(xhci, "xhci_stop completed - status = %x\n",
|
2013-11-15 03:34:06 +00:00
|
|
|
readl(&xhci->op_regs->status));
|
2010-10-14 14:23:06 +00:00
|
|
|
|
2010-12-17 20:35:05 +00:00
|
|
|
/* USB core calls the PCI reinit and start functions twice:
|
|
|
|
|
* first with the primary HCD, and then with the secondary HCD.
|
|
|
|
|
* If we don't do the same, the host will never be started.
|
|
|
|
|
*/
|
|
|
|
|
if (!usb_hcd_is_primary_hcd(hcd))
|
|
|
|
|
secondary_hcd = hcd;
|
|
|
|
|
else
|
|
|
|
|
secondary_hcd = xhci->shared_hcd;
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Initialize the xhci_hcd\n");
|
|
|
|
|
retval = xhci_init(hcd->primary_hcd);
|
2010-10-14 14:23:06 +00:00
|
|
|
if (retval)
|
|
|
|
|
return retval;
|
xhci - correct comp_mode_recovery_timer on return from hibernate
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP,
controller, but it introduced a bug in resume from hibernate.
The fix created a timer, comp_mode_recovery_timer, which is deleted from
a timer list when xhci_suspend() is called. However, the hibernate image,
including the timer list containing the comp_mode_recovery_timer, had
already been saved before the timer was deleted.
Upon resume from hibernate, the list containing the comp_mode_recovery_timer
is restored from the image saved to disk, and xhci_resume(), assuming that
the timer had been deleted by xhci_suspend(), makes a call to
compliance_mode_recoery_timer_init(), which creates a new instance of the
comp_mode_recovery_timer and attempts to place it into the same list in which
it is already active, thus corrupting the list during the list_add() call.
At this point, a call trace is emitted indicating the list corruption.
Soon afterward, the system locks up, the watchdog times out, and the
ensuing NMI crashes the system.
The problem did not occur when resuming from suspend. In suspend, the
image in RAM remains exactly as it was when xhci_suspend() deleted the
comp_mode_recovery_timer, so there is no problem when xhci_resume()
creates a new instance of this timer and places it in the still empty
list.
This patch avoids the problem by deleting the timer in xhci_resume()
when resuming from hibernate. Now xhci_resume() can safely make the
call to create a new instance of this timer, whether returning from
suspend or hibernate.
Thanks to Alan Stern for his help with understanding the problem.
[Sarah reworked this patch to cover the case where the xHCI restore
register operation fails, and (temp & STS_SRE) is true (and we re-init
the host, including re-init for the compliance mode), but hibernate is
false. The original patch would have caused list corruption in this
case.]
This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: Tony Camuso <tcamuso@redhat.com>
Tested-by: Tony Camuso <tcamuso@redhat.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-02-21 21:11:27 +00:00
|
|
|
comp_timer_running = true;
|
|
|
|
|
|
2010-12-17 20:35:05 +00:00
|
|
|
xhci_dbg(xhci, "Start the primary HCD\n");
|
|
|
|
|
retval = xhci_run(hcd->primary_hcd);
|
2011-03-07 19:24:07 +00:00
|
|
|
if (!retval) {
|
2011-11-03 15:37:10 +00:00
|
|
|
xhci_dbg(xhci, "Start the secondary HCD\n");
|
|
|
|
|
retval = xhci_run(secondary_hcd);
|
2011-03-07 19:24:07 +00:00
|
|
|
}
|
2010-10-14 14:23:06 +00:00
|
|
|
hcd->state = HC_STATE_SUSPENDED;
|
2011-03-07 19:24:07 +00:00
|
|
|
xhci->shared_hcd->state = HC_STATE_SUSPENDED;
|
2011-11-03 15:37:10 +00:00
|
|
|
goto done;
|
2010-10-14 14:23:06 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* step 4: set Run/Stop bit */
|
2013-11-15 03:34:06 +00:00
|
|
|
command = readl(&xhci->op_regs->command);
|
2010-10-14 14:23:06 +00:00
|
|
|
command |= CMD_RUN;
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(command, &xhci->op_regs->command);
|
2012-10-25 20:27:51 +00:00
|
|
|
xhci_handshake(xhci, &xhci->op_regs->status, STS_HALT,
|
2010-10-14 14:23:06 +00:00
|
|
|
0, 250 * 1000);
|
|
|
|
|
|
|
|
|
|
/* step 5: walk topology and initialize portsc,
|
|
|
|
|
* portpmsc and portli
|
|
|
|
|
*/
|
|
|
|
|
/* this is done in bus_resume */
|
|
|
|
|
|
|
|
|
|
/* step 6: restart each of the previously
|
|
|
|
|
* Running endpoints by ringing their doorbells
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
spin_unlock_irq(&xhci->lock);
|
2011-11-03 15:37:10 +00:00
|
|
|
|
|
|
|
|
done:
|
|
|
|
|
if (retval == 0) {
|
xhci: Fix runtime suspended xhci from blocking system suspend.
The system suspend flow as following:
1, Freeze all user processes and kenrel threads.
2, Try to suspend all devices.
2.1, If pci device is in RPM suspended state, then pci driver will try
to resume it to RPM active state in the prepare stage.
2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two
workqueue items to resume usb2&usb3 roothub devices.
2.3, Call suspend callbacks of devices.
2.3.1, All suspend callbacks of all hcd's children, including
roothub devices are called.
2.3.2, Finally, hcd_pci_suspend callback is called.
Due to workqueue threads were already frozen in step 1, the workqueue
items can't be scheduled, and the roothub devices can't be resumed in
this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in
usb_hcd_resume_root_hub won't be cleared. Finally,
hcd_pci_suspend will return -EBUSY, and system suspend fails.
The reason why this issue doesn't show up very often is due to that
choose_wakeup will be called in step 2.3.1. In step 2.3.1, if
udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then
udev will resume to RPM active for changing the wakeup settings. This
has been a lucky hit which hides this issue.
For some special xHCI controllers which have no USB2 port, then roothub
will not match hub driver due to probe failed. Then its
do_remote_wakeup will be set to zero, and we won't be as lucky.
xhci driver doesn't need to resume roothub devices everytime like in
the above case. It's only needed when there are pending event TRBs.
This patch should be back-ported to kernels as old as 3.2, that
contains the commit f69e3120df82391a0ee8118e0a156239a06b2afb
"USB: XHCI: resume root hubs when the controller resumes"
Cc: stable@vger.kernel.org # 3.2
Signed-off-by: Wang, Yu <yu.y.wang@intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
[use readl() instead of removed xhci_readl(), reword commit message -Mathias]
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-24 14:14:44 +00:00
|
|
|
/* Resume root hubs only when have pending events. */
|
|
|
|
|
status = readl(&xhci->op_regs->status);
|
|
|
|
|
if (status & STS_EINT) {
|
|
|
|
|
usb_hcd_resume_root_hub(hcd);
|
|
|
|
|
usb_hcd_resume_root_hub(xhci->shared_hcd);
|
|
|
|
|
}
|
2011-11-03 15:37:10 +00:00
|
|
|
}
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* If system is subject to the Quirk, Compliance Mode Timer needs to
|
|
|
|
|
* be re-initialized Always after a system resume. Ports are subject
|
|
|
|
|
* to suffer the Compliance Mode issue again. It doesn't matter if
|
|
|
|
|
* ports have entered previously to U0 before system's suspension.
|
|
|
|
|
*/
|
xhci - correct comp_mode_recovery_timer on return from hibernate
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP,
controller, but it introduced a bug in resume from hibernate.
The fix created a timer, comp_mode_recovery_timer, which is deleted from
a timer list when xhci_suspend() is called. However, the hibernate image,
including the timer list containing the comp_mode_recovery_timer, had
already been saved before the timer was deleted.
Upon resume from hibernate, the list containing the comp_mode_recovery_timer
is restored from the image saved to disk, and xhci_resume(), assuming that
the timer had been deleted by xhci_suspend(), makes a call to
compliance_mode_recoery_timer_init(), which creates a new instance of the
comp_mode_recovery_timer and attempts to place it into the same list in which
it is already active, thus corrupting the list during the list_add() call.
At this point, a call trace is emitted indicating the list corruption.
Soon afterward, the system locks up, the watchdog times out, and the
ensuing NMI crashes the system.
The problem did not occur when resuming from suspend. In suspend, the
image in RAM remains exactly as it was when xhci_suspend() deleted the
comp_mode_recovery_timer, so there is no problem when xhci_resume()
creates a new instance of this timer and places it in the still empty
list.
This patch avoids the problem by deleting the timer in xhci_resume()
when resuming from hibernate. Now xhci_resume() can safely make the
call to create a new instance of this timer, whether returning from
suspend or hibernate.
Thanks to Alan Stern for his help with understanding the problem.
[Sarah reworked this patch to cover the case where the xHCI restore
register operation fails, and (temp & STS_SRE) is true (and we re-init
the host, including re-init for the compliance mode), but hibernate is
false. The original patch would have caused list corruption in this
case.]
This patch should be backported to kernels as old as 3.2, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"
Signed-off-by: Tony Camuso <tcamuso@redhat.com>
Tested-by: Tony Camuso <tcamuso@redhat.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-02-21 21:11:27 +00:00
|
|
|
if ((xhci->quirks & XHCI_COMP_MODE_QUIRK) && !comp_timer_running)
|
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-08-03 19:00:27 +00:00
|
|
|
compliance_mode_recovery_timer_init(xhci);
|
|
|
|
|
|
xhci: Avoid "dead ports", add roothub port polling.
The USB core hub thread (khubd) is designed with external USB hubs in
mind. It expects that if a port status change bit is set, the hub will
continue to send a notification through the hub status data transfer.
Basically, it expects hub notifications to be level-triggered.
The xHCI host controller is designed to be edge-triggered on the logical
'OR' of all the port status change bits. When all port status change
bits are clear, and a new change bit is set, the xHC will generate a
Port Status Change Event. If another change bit is set in the same port
status register before the first bit is cleared, it will not send
another event.
This means that the hub code may lose port status changes because of
race conditions between clearing change bits. The user sees this as a
"dead port" that doesn't react to device connects.
The fix is to turn on port polling whenever a new change bit is set.
Once the USB core issues a hub status request that shows that no change
bits are set in any USB ports, turn off port polling.
We can't allow the USB core to poll the roothub for port events during
host suspend because if the PCI host is in D3cold, the port registers
will be all f's. Instead, stop the port polling timer, and
unconditionally restart it when the host resumes. If there are no port
change bits set after the resume, the first call to hub_status_data will
disable polling.
This patch should be backported to stable kernels with the first xHCI
support, 2.6.31 and newer, that include the commit
0f2a79300a1471cf92ab43af165ea13555c8b0a5 "USB: xhci: Root hub support."
There will be merge conflicts because the check for HC_STATE_SUSPENDED
was moved into xhci_suspend in 3.8.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
2012-11-27 20:30:23 +00:00
|
|
|
/* Re-enable port polling. */
|
|
|
|
|
xhci_dbg(xhci, "%s: starting port polling.\n", __func__);
|
|
|
|
|
set_bit(HCD_FLAG_POLL_RH, &hcd->flags);
|
|
|
|
|
usb_hcd_poll_rh_status(hcd);
|
|
|
|
|
|
2011-11-03 15:37:10 +00:00
|
|
|
return retval;
|
2010-10-14 14:23:06 +00:00
|
|
|
}
|
2010-10-15 18:24:14 +00:00
|
|
|
#endif /* CONFIG_PM */
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2013-04-15 22:55:04 +00:00
|
|
|
/* The reverse operation to xhci_get_endpoint_index. Calculate the USB endpoint
|
|
|
|
|
* address from the XHCI endpoint index.
|
|
|
|
|
*/
|
|
|
|
|
unsigned int xhci_get_endpoint_address(unsigned int ep_index)
|
|
|
|
|
{
|
|
|
|
|
unsigned int number = DIV_ROUND_UP(ep_index, 2);
|
|
|
|
|
unsigned int direction = ep_index % 2 ? USB_DIR_OUT : USB_DIR_IN;
|
|
|
|
|
return direction | number;
|
|
|
|
|
}
|
|
|
|
|
|
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.
|
|
|
|
|
*/
|
2011-02-08 21:55:59 +00:00
|
|
|
static 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) {
|
2013-07-02 14:49:26 +00:00
|
|
|
pr_debug("xHCI %s called with invalid args\n", func);
|
2009-04-28 02:58:01 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
if (!udev->parent) {
|
2013-07-02 14:49:26 +00:00
|
|
|
pr_debug("xHCI %s called for root hub\n", func);
|
2009-04-28 02:58:01 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
2010-10-14 14:22:45 +00:00
|
|
|
|
2011-07-01 20:35:40 +00:00
|
|
|
xhci = hcd_to_xhci(hcd);
|
2010-10-14 14:22:45 +00:00
|
|
|
if (check_virt_dev) {
|
2011-09-02 18:06:00 +00:00
|
|
|
if (!udev->slot_id || !xhci->devs[udev->slot_id]) {
|
2013-07-02 14:49:26 +00:00
|
|
|
xhci_dbg(xhci, "xHCI %s called with unaddressed device\n",
|
|
|
|
|
func);
|
2010-10-14 14:22:45 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
virt_dev = xhci->devs[udev->slot_id];
|
|
|
|
|
if (virt_dev->udev != udev) {
|
2013-07-02 14:49:26 +00:00
|
|
|
xhci_dbg(xhci, "xHCI %s called with udev and "
|
2010-10-14 14:22:45 +00:00
|
|
|
"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
|
|
|
|
xhci: Avoid NULL pointer deref when host dies.
When the host controller fails to respond to an Enable Slot command, and
the host fails to respond to the register write to abort the command
ring, the xHCI driver will assume the host is dead, and call
usb_hc_died().
The USB device's slot_id is still set to zero, and the pointer stored at
xhci->devs[0] will always be NULL. The call to xhci_check_args in
xhci_free_dev should have caught the NULL virt_dev pointer.
However, xhci_free_dev is designed to free the xhci_virt_device
structures, even if the host is dead, so that we don't leak kernel
memory. xhci_free_dev checks the return value from the generic
xhci_check_args function. If the return value is -ENODEV, it carries on
trying to free the virtual device.
The issue is that xhci_check_args looks at the host controller state
before it looks at the xhci_virt_device pointer. It will return -ENIVAL
because the host is dead, and xhci_free_dev will ignore the return
value, and happily dereference the NULL xhci_virt_device pointer.
The fix is to make sure that xhci_check_args checks the xhci_virt_device
pointer before it checks the host state.
See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for
further details. This patch doesn't solve the underlying issue, but
will ensure we don't see any more NULL pointer dereferences because of
the issue.
This patch should be backported to kernels as old as 3.1, that
contain the commit 7bd89b4017f46a9b92853940fd9771319acb578a "xhci: Don't
submit commands or URBs to halted hosts."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Vincent Thiele <vincentthiele@gmail.com>
Cc: stable@vger.kernel.org
2013-07-24 17:27:13 +00:00
|
|
|
if (xhci->xhc_state & XHCI_STATE_HALTED)
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
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 *out_ctx;
|
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
2014-05-08 16:26:00 +00:00
|
|
|
struct xhci_command *command;
|
2009-08-07 21:04:49 +00:00
|
|
|
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);
|
2011-03-29 02:40:46 +00:00
|
|
|
hw_max_packet_size = MAX_PACKET_DECODED(le32_to_cpu(ep_ctx->ep_info2));
|
2011-08-23 10:12:03 +00:00
|
|
|
max_packet_size = usb_endpoint_maxp(&urb->dev->ep0.desc);
|
2009-08-07 21:04:49 +00:00
|
|
|
if (hw_max_packet_size != max_packet_size) {
|
2013-07-31 04:35:27 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
|
|
|
|
|
"Max Packet Size for ep 0 changed.");
|
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
|
|
|
|
|
"Max packet size in usb_device = %d",
|
2009-08-07 21:04:49 +00:00
|
|
|
max_packet_size);
|
2013-07-31 04:35:27 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
|
|
|
|
|
"Max packet size in xHCI HW = %d",
|
2009-08-07 21:04:49 +00:00
|
|
|
hw_max_packet_size);
|
2013-07-31 04:35:27 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
|
|
|
|
|
"Issuing evaluate context command.");
|
2009-08-07 21:04:49 +00:00
|
|
|
|
2013-04-24 00:11:14 +00:00
|
|
|
/* Set up the input context flags for the command */
|
|
|
|
|
/* FIXME: This won't work if a non-default control endpoint
|
|
|
|
|
* changes max packet sizes.
|
|
|
|
|
*/
|
2014-05-08 16:26:00 +00:00
|
|
|
|
|
|
|
|
command = xhci_alloc_command(xhci, false, true, GFP_KERNEL);
|
|
|
|
|
if (!command)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
command->in_ctx = xhci->devs[slot_id]->in_ctx;
|
|
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, command->in_ctx);
|
2013-04-24 00:11:14 +00:00
|
|
|
if (!ctrl_ctx) {
|
|
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
2014-05-08 16:26:00 +00:00
|
|
|
ret = -ENOMEM;
|
|
|
|
|
goto command_cleanup;
|
2013-04-24 00:11:14 +00:00
|
|
|
}
|
2009-08-07 21:04:49 +00:00
|
|
|
/* 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);
|
2013-04-24 00:11:14 +00:00
|
|
|
|
2014-05-08 16:26:00 +00:00
|
|
|
ep_ctx = xhci_get_ep_ctx(xhci, command->in_ctx, ep_index);
|
2011-03-29 02:40:46 +00:00
|
|
|
ep_ctx->ep_info2 &= cpu_to_le32(~MAX_PACKET_MASK);
|
|
|
|
|
ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet_size));
|
2009-08-07 21:04:49 +00:00
|
|
|
|
2011-03-29 02:40:46 +00:00
|
|
|
ctrl_ctx->add_flags = cpu_to_le32(EP0_FLAG);
|
2009-08-07 21:04:49 +00:00
|
|
|
ctrl_ctx->drop_flags = 0;
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Slot %d input context\n", slot_id);
|
2014-05-08 16:26:00 +00:00
|
|
|
xhci_dbg_ctx(xhci, command->in_ctx, ep_index);
|
2009-08-07 21:04:49 +00:00
|
|
|
xhci_dbg(xhci, "Slot %d output context\n", slot_id);
|
|
|
|
|
xhci_dbg_ctx(xhci, out_ctx, ep_index);
|
|
|
|
|
|
2014-05-08 16:26:00 +00:00
|
|
|
ret = xhci_configure_endpoint(xhci, urb->dev, command,
|
2009-09-04 17:53:13 +00:00
|
|
|
true, false);
|
2009-08-07 21:04:49 +00:00
|
|
|
|
|
|
|
|
/* Clean up the input context for later use by bandwidth
|
|
|
|
|
* functions.
|
|
|
|
|
*/
|
2011-03-29 02:40:46 +00:00
|
|
|
ctrl_ctx->add_flags = cpu_to_le32(SLOT_FLAG);
|
2014-05-08 16:26:00 +00:00
|
|
|
command_cleanup:
|
|
|
|
|
kfree(command->completion);
|
|
|
|
|
kfree(command);
|
2009-08-07 21:04:49 +00:00
|
|
|
}
|
|
|
|
|
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);
|
2011-09-02 18:05:57 +00:00
|
|
|
struct xhci_td *buffer;
|
2009-04-28 02:58:01 +00:00
|
|
|
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;
|
|
|
|
|
|
2011-09-02 18:05:57 +00:00
|
|
|
buffer = kzalloc(size * sizeof(struct xhci_td), mem_flags);
|
|
|
|
|
if (!buffer) {
|
|
|
|
|
kfree(urb_priv);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
2010-07-22 22:23:31 +00:00
|
|
|
for (i = 0; i < size; i++) {
|
2011-09-02 18:05:57 +00:00
|
|
|
urb_priv->td[i] = buffer;
|
|
|
|
|
buffer++;
|
2010-07-22 22:23:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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);
|
xhci: Fix memory leak during failed enqueue.
When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.
xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.
xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail. Instead, it expects those functions to
free urb_priv if an error occurs. However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL. It will, however, get freed if prepare_transfer() fails in those
enqueue functions.
Several of the error paths in the isochronous endpoint enqueue function
also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB. If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.
This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.
This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-22 21:34:34 +00:00
|
|
|
if (ret < 0) {
|
|
|
|
|
xhci_urb_free_priv(xhci, urb_priv);
|
|
|
|
|
urb->hcpriv = NULL;
|
2009-08-07 21:04:49 +00:00
|
|
|
return ret;
|
xhci: Fix memory leak during failed enqueue.
When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.
xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.
xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail. Instead, it expects those functions to
free urb_priv if an error occurs. However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL. It will, however, get freed if prepare_transfer() fails in those
enqueue functions.
Several of the error paths in the isochronous endpoint enqueue function
also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB. If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.
This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.
This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-22 21:34:34 +00:00
|
|
|
}
|
2009-08-07 21:04:49 +00:00
|
|
|
}
|
|
|
|
|
|
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);
|
xhci: Fix memory leak during failed enqueue.
When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.
xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.
xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail. Instead, it expects those functions to
free urb_priv if an error occurs. However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL. It will, however, get freed if prepare_transfer() fails in those
enqueue functions.
Several of the error paths in the isochronous endpoint enqueue function
also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB. If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.
This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.
This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-22 21:34:34 +00:00
|
|
|
if (ret)
|
|
|
|
|
goto free_priv;
|
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);
|
|
|
|
|
}
|
xhci: Fix memory leak during failed enqueue.
When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.
xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.
xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail. Instead, it expects those functions to
free urb_priv if an error occurs. However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL. It will, however, get freed if prepare_transfer() fails in those
enqueue functions.
Several of the error paths in the isochronous endpoint enqueue function
also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB. If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.
This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.
This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-22 21:34:34 +00:00
|
|
|
if (ret)
|
|
|
|
|
goto free_priv;
|
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);
|
xhci: Fix memory leak during failed enqueue.
When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.
xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.
xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail. Instead, it expects those functions to
free urb_priv if an error occurs. However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL. It will, however, get freed if prepare_transfer() fails in those
enqueue functions.
Several of the error paths in the isochronous endpoint enqueue function
also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB. If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.
This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.
This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-22 21:34:34 +00:00
|
|
|
if (ret)
|
|
|
|
|
goto free_priv;
|
2009-09-02 19:14:28 +00:00
|
|
|
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);
|
xhci: Fix memory leak during failed enqueue.
When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.
xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.
xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail. Instead, it expects those functions to
free urb_priv if an error occurs. However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL. It will, however, get freed if prepare_transfer() fails in those
enqueue functions.
Several of the error paths in the isochronous endpoint enqueue function
also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB. If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.
This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.
This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-22 21:34:34 +00:00
|
|
|
if (ret)
|
|
|
|
|
goto free_priv;
|
2010-07-22 22:23:52 +00:00
|
|
|
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:
|
|
|
|
|
xhci_dbg(xhci, "Ep 0x%x: URB %p submitted for "
|
|
|
|
|
"non-responsive xHCI host.\n",
|
|
|
|
|
urb->ep->desc.bEndpointAddress, urb);
|
xhci: Fix memory leak during failed enqueue.
When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.
xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.
xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail. Instead, it expects those functions to
free urb_priv if an error occurs. However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL. It will, however, get freed if prepare_transfer() fails in those
enqueue functions.
Several of the error paths in the isochronous endpoint enqueue function
also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB. If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.
This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.
This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-22 21:34:34 +00:00
|
|
|
ret = -ESHUTDOWN;
|
|
|
|
|
free_priv:
|
|
|
|
|
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
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
xhci: Fix memory leak during failed enqueue.
When the isochronous transfer support was introduced, and the xHCI driver
switched to using urb->hcpriv to store an "urb_priv" pointer, a couple of
memory leaks were introduced into the URB enqueue function in its error
handling paths.
xhci_urb_enqueue allocates urb_priv, but it doesn't free it if changing
the control endpoint's max packet size fails or the bulk endpoint is in
the middle of allocating or deallocating streams.
xhci_urb_enqueue also doesn't free urb_priv if any of the four endpoint
types' enqueue functions fail. Instead, it expects those functions to
free urb_priv if an error occurs. However, the bulk, control, and
interrupt enqueue functions do not free urb_priv if the endpoint ring is
NULL. It will, however, get freed if prepare_transfer() fails in those
enqueue functions.
Several of the error paths in the isochronous endpoint enqueue function
also fail to free it. xhci_queue_isoc_tx_prepare() doesn't free urb_priv
if prepare_ring() indicates there is not enough room for all the
isochronous TDs in this URB. If individual isochronous TDs fail to be
queued (perhaps due to an endpoint state change), urb_priv is also leaked.
This argues that the freeing of urb_priv should be done in the function
that allocated it, xhci_urb_enqueue.
This patch looks rather ugly, but refactoring the code will have to wait
because this patch needs to be backported to stable kernels.
This patch should be backported to kernels as old as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Andiry Xu <andiry.xu@amd.com>
Cc: stable@kernel.org
2011-07-22 21:34:34 +00:00
|
|
|
return ret;
|
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;
|
2014-05-08 16:26:00 +00:00
|
|
|
struct xhci_command *command;
|
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;
|
2013-11-15 03:34:06 +00:00
|
|
|
temp = readl(&xhci->op_regs->status);
|
2011-03-11 18:20:58 +00:00
|
|
|
if (temp == 0xffffffff || (xhci->xhc_state & XHCI_STATE_HALTED)) {
|
2013-08-14 03:33:54 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
|
"HW died, freeing TD.");
|
2010-07-22 22:23:31 +00:00
|
|
|
urb_priv = urb->hcpriv;
|
2011-08-02 22:43:40 +00:00
|
|
|
for (i = urb_priv->td_cnt; i < urb_priv->length; i++) {
|
|
|
|
|
td = urb_priv->td[i];
|
|
|
|
|
if (!list_empty(&td->td_list))
|
|
|
|
|
list_del_init(&td->td_list);
|
|
|
|
|
if (!list_empty(&td->cancelled_td_list))
|
|
|
|
|
list_del_init(&td->cancelled_td_list);
|
|
|
|
|
}
|
2009-09-29 00:21:37 +00:00
|
|
|
|
|
|
|
|
usb_hcd_unlink_urb_from_ep(hcd, urb);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
2010-10-26 18:22:02 +00:00
|
|
|
usb_hcd_giveback_urb(hcd, 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;
|
|
|
|
|
}
|
2011-07-01 20:35:40 +00:00
|
|
|
if ((xhci->xhc_state & XHCI_STATE_DYING) ||
|
|
|
|
|
(xhci->xhc_state & XHCI_STATE_HALTED)) {
|
2013-08-14 03:33:54 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
|
"Ep 0x%x: URB %p to be canceled on "
|
|
|
|
|
"non-responsive xHCI host.",
|
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
|
|
|
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
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2010-07-22 22:23:31 +00:00
|
|
|
urb_priv = urb->hcpriv;
|
2011-12-20 00:56:04 +00:00
|
|
|
i = urb_priv->td_cnt;
|
|
|
|
|
if (i < urb_priv->length)
|
2013-08-14 03:33:54 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
|
|
|
|
|
"Cancel URB %p, dev %s, ep 0x%x, "
|
|
|
|
|
"starting at offset 0x%llx",
|
2011-12-20 00:56:04 +00:00
|
|
|
urb, urb->dev->devpath,
|
|
|
|
|
urb->ep->desc.bEndpointAddress,
|
|
|
|
|
(unsigned long long) xhci_trb_virt_to_dma(
|
|
|
|
|
urb_priv->td[i]->start_seg,
|
|
|
|
|
urb_priv->td[i]->first_trb));
|
|
|
|
|
|
|
|
|
|
for (; i < urb_priv->length; i++) {
|
2010-07-22 22:23:31 +00:00
|
|
|
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)) {
|
2014-05-08 16:26:00 +00:00
|
|
|
command = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
|
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
|
|
|
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);
|
2014-05-08 16:26:00 +00:00
|
|
|
xhci_queue_stop_endpoint(xhci, command, 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;
|
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;
|
|
|
|
|
u32 drop_flag;
|
2014-06-24 14:14:42 +00:00
|
|
|
u32 new_add_flags, new_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
|
|
|
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);
|
2011-05-23 23:41:17 +00:00
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING)
|
|
|
|
|
return -ENODEV;
|
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
|
|
|
|
2011-05-23 23:41:17 +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);
|
2013-04-24 00:11:14 +00:00
|
|
|
if (!ctrl_ctx) {
|
|
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
|
|
|
|
return 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_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
|
|
|
|
|
*/
|
2011-06-01 00:22:55 +00:00
|
|
|
if (((ep_ctx->ep_info & cpu_to_le32(EP_STATE_MASK)) ==
|
|
|
|
|
cpu_to_le32(EP_STATE_DISABLED)) ||
|
2011-03-29 02:40:46 +00:00
|
|
|
le32_to_cpu(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;
|
|
|
|
|
}
|
|
|
|
|
|
2011-03-29 02:40:46 +00:00
|
|
|
ctrl_ctx->drop_flags |= cpu_to_le32(drop_flag);
|
|
|
|
|
new_drop_flags = le32_to_cpu(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
|
|
|
|
2011-03-29 02:40:46 +00:00
|
|
|
ctrl_ctx->add_flags &= cpu_to_le32(~drop_flag);
|
|
|
|
|
new_add_flags = le32_to_cpu(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
|
|
|
|
|
|
|
|
xhci_endpoint_zero(xhci, xhci->devs[udev->slot_id], ep);
|
|
|
|
|
|
2014-06-24 14:14:42 +00:00
|
|
|
xhci_dbg(xhci, "drop ep 0x%x, slot id %d, new drop flags = %#x, new add flags = %#x\n",
|
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->desc.bEndpointAddress,
|
|
|
|
|
udev->slot_id,
|
|
|
|
|
(unsigned int) new_drop_flags,
|
2014-06-24 14:14:42 +00:00
|
|
|
(unsigned int) new_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
|
|
|
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;
|
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
|
|
|
u32 added_ctxs;
|
2014-06-24 14:14:42 +00:00
|
|
|
u32 new_add_flags, new_drop_flags;
|
2011-06-06 06:10:04 +00:00
|
|
|
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
|
|
|
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);
|
2011-05-23 23:41:17 +00:00
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING)
|
|
|
|
|
return -ENODEV;
|
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
|
|
|
|
|
|
|
|
added_ctxs = xhci_get_endpoint_flag(&ep->desc);
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
2011-06-06 06:10:04 +00:00
|
|
|
virt_dev = xhci->devs[udev->slot_id];
|
|
|
|
|
in_ctx = virt_dev->in_ctx;
|
|
|
|
|
out_ctx = virt_dev->out_ctx;
|
2009-07-27 19:05:15 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
|
2013-04-24 00:11:14 +00:00
|
|
|
if (!ctrl_ctx) {
|
|
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2011-06-06 06:10:04 +00:00
|
|
|
|
2013-04-24 00:11:14 +00:00
|
|
|
ep_index = xhci_get_endpoint_index(&ep->desc);
|
2011-06-06 06:10:04 +00:00
|
|
|
/* If this endpoint is already in use, and the upper layers are trying
|
|
|
|
|
* to add it again without dropping it, reject the addition.
|
|
|
|
|
*/
|
|
|
|
|
if (virt_dev->eps[ep_index].ring &&
|
|
|
|
|
!(le32_to_cpu(ctrl_ctx->drop_flags) &
|
|
|
|
|
xhci_get_endpoint_flag(&ep->desc))) {
|
|
|
|
|
xhci_warn(xhci, "Trying to add endpoint 0x%x "
|
|
|
|
|
"without dropping it.\n",
|
|
|
|
|
(unsigned int) ep->desc.bEndpointAddress);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
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.
|
|
|
|
|
*/
|
2011-03-29 02:40:46 +00:00
|
|
|
if (le32_to_cpu(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).
|
|
|
|
|
*/
|
2011-06-06 06:10:04 +00:00
|
|
|
if (xhci_endpoint_init(xhci, virt_dev, 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;
|
|
|
|
|
}
|
|
|
|
|
|
2011-03-29 02:40:46 +00:00
|
|
|
ctrl_ctx->add_flags |= cpu_to_le32(added_ctxs);
|
|
|
|
|
new_add_flags = le32_to_cpu(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.
|
|
|
|
|
*/
|
2011-03-29 02:40:46 +00:00
|
|
|
new_drop_flags = le32_to_cpu(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:03:15 +00:00
|
|
|
/* Store the usb_device pointer for later use */
|
|
|
|
|
ep->hcpriv = udev;
|
|
|
|
|
|
2014-06-24 14:14:42 +00:00
|
|
|
xhci_dbg(xhci, "add ep 0x%x, slot id %d, new drop flags = %#x, new add flags = %#x\n",
|
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->desc.bEndpointAddress,
|
|
|
|
|
udev->slot_id,
|
|
|
|
|
(unsigned int) new_drop_flags,
|
2014-06-24 14:14:42 +00:00
|
|
|
(unsigned int) new_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
|
|
|
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;
|
|
|
|
|
|
2013-04-24 00:11:14 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, virt_dev->in_ctx);
|
|
|
|
|
if (!ctrl_ctx) {
|
|
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/* 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->drop_flags = 0;
|
|
|
|
|
ctrl_ctx->add_flags = 0;
|
|
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->in_ctx);
|
2011-03-29 02:40:46 +00:00
|
|
|
slot_ctx->dev_info &= cpu_to_le32(~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 */
|
2011-03-29 02:40:46 +00:00
|
|
|
slot_ctx->dev_info |= cpu_to_le32(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,
|
2011-04-28 19:23:23 +00:00
|
|
|
struct usb_device *udev, u32 *cmd_status)
|
2009-08-07 21:04:43 +00:00
|
|
|
{
|
|
|
|
|
int ret;
|
|
|
|
|
|
2009-09-04 17:53:13 +00:00
|
|
|
switch (*cmd_status) {
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 16:26:03 +00:00
|
|
|
case COMP_CMD_ABORT:
|
|
|
|
|
case COMP_CMD_STOP:
|
|
|
|
|
xhci_warn(xhci, "Timeout while waiting for configure endpoint command\n");
|
|
|
|
|
ret = -ETIME;
|
|
|
|
|
break;
|
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:
|
2012-01-04 22:29:18 +00:00
|
|
|
case COMP_2ND_BW_ERR:
|
2009-08-07 21:04:43 +00:00
|
|
|
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;
|
2011-06-08 10:34:06 +00:00
|
|
|
case COMP_DEV_ERR:
|
|
|
|
|
dev_warn(&udev->dev, "ERROR: Incompatible device for endpoint "
|
|
|
|
|
"configure command.\n");
|
|
|
|
|
ret = -ENODEV;
|
|
|
|
|
break;
|
2009-08-07 21:04:43 +00:00
|
|
|
case COMP_SUCCESS:
|
2013-07-31 04:35:27 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
|
|
|
|
|
"Successful Endpoint Configure command");
|
2009-08-07 21:04:43 +00:00
|
|
|
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,
|
2011-04-28 19:23:23 +00:00
|
|
|
struct usb_device *udev, u32 *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) {
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 16:26:03 +00:00
|
|
|
case COMP_CMD_ABORT:
|
|
|
|
|
case COMP_CMD_STOP:
|
|
|
|
|
xhci_warn(xhci, "Timeout while waiting for evaluate context command\n");
|
|
|
|
|
ret = -ETIME;
|
|
|
|
|
break;
|
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");
|
2012-10-16 20:26:22 +00:00
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
2009-08-07 21:04:43 +00:00
|
|
|
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;
|
2011-06-08 10:34:06 +00:00
|
|
|
case COMP_DEV_ERR:
|
|
|
|
|
dev_warn(&udev->dev, "ERROR: Incompatible device for evaluate "
|
|
|
|
|
"context command.\n");
|
|
|
|
|
ret = -ENODEV;
|
|
|
|
|
break;
|
2011-05-05 10:14:12 +00:00
|
|
|
case COMP_MEL_ERR:
|
|
|
|
|
/* Max Exit Latency too large error */
|
|
|
|
|
dev_warn(&udev->dev, "WARN: Max Exit Latency too large\n");
|
|
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
2009-08-07 21:04:43 +00:00
|
|
|
case COMP_SUCCESS:
|
2013-07-31 04:35:27 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
|
|
|
|
|
"Successful evaluate context command");
|
2009-08-07 21:04:43 +00:00
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
static u32 xhci_count_num_new_endpoints(struct xhci_hcd *xhci,
|
2013-04-24 00:11:14 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx)
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
{
|
|
|
|
|
u32 valid_add_flags;
|
|
|
|
|
u32 valid_drop_flags;
|
|
|
|
|
|
|
|
|
|
/* Ignore the slot flag (bit 0), and the default control endpoint flag
|
|
|
|
|
* (bit 1). The default control endpoint is added during the Address
|
|
|
|
|
* Device command and is never removed until the slot is disabled.
|
|
|
|
|
*/
|
2013-09-09 18:03:06 +00:00
|
|
|
valid_add_flags = le32_to_cpu(ctrl_ctx->add_flags) >> 2;
|
|
|
|
|
valid_drop_flags = le32_to_cpu(ctrl_ctx->drop_flags) >> 2;
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
|
|
|
|
|
/* Use hweight32 to count the number of ones in the add flags, or
|
|
|
|
|
* number of endpoints added. Don't count endpoints that are changed
|
|
|
|
|
* (both added and dropped).
|
|
|
|
|
*/
|
|
|
|
|
return hweight32(valid_add_flags) -
|
|
|
|
|
hweight32(valid_add_flags & valid_drop_flags);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static unsigned int xhci_count_num_dropped_endpoints(struct xhci_hcd *xhci,
|
2013-04-24 00:11:14 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx)
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
{
|
|
|
|
|
u32 valid_add_flags;
|
|
|
|
|
u32 valid_drop_flags;
|
|
|
|
|
|
2013-09-09 18:03:07 +00:00
|
|
|
valid_add_flags = le32_to_cpu(ctrl_ctx->add_flags) >> 2;
|
|
|
|
|
valid_drop_flags = le32_to_cpu(ctrl_ctx->drop_flags) >> 2;
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
|
|
|
|
|
return hweight32(valid_drop_flags) -
|
|
|
|
|
hweight32(valid_add_flags & valid_drop_flags);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We need to reserve the new number of endpoints before the configure endpoint
|
|
|
|
|
* command completes. We can't subtract the dropped endpoints from the number
|
|
|
|
|
* of active endpoints until the command completes because we can oversubscribe
|
|
|
|
|
* the host in this case:
|
|
|
|
|
*
|
|
|
|
|
* - the first configure endpoint command drops more endpoints than it adds
|
|
|
|
|
* - a second configure endpoint command that adds more endpoints is queued
|
|
|
|
|
* - the first configure endpoint command fails, so the config is unchanged
|
|
|
|
|
* - the second command may succeed, even though there isn't enough resources
|
|
|
|
|
*
|
|
|
|
|
* Must be called with xhci->lock held.
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_reserve_host_resources(struct xhci_hcd *xhci,
|
2013-04-24 00:11:14 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx)
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
{
|
|
|
|
|
u32 added_eps;
|
|
|
|
|
|
2013-04-24 00:11:14 +00:00
|
|
|
added_eps = xhci_count_num_new_endpoints(xhci, ctrl_ctx);
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
if (xhci->num_active_eps + added_eps > xhci->limit_active_eps) {
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Not enough ep ctxs: "
|
|
|
|
|
"%u active, need to add %u, limit is %u.",
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
xhci->num_active_eps, added_eps,
|
|
|
|
|
xhci->limit_active_eps);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
xhci->num_active_eps += added_eps;
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Adding %u ep ctxs, %u now active.", added_eps,
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
xhci->num_active_eps);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The configure endpoint was failed by the xHC for some other reason, so we
|
|
|
|
|
* need to revert the resources that failed configuration would have used.
|
|
|
|
|
*
|
|
|
|
|
* Must be called with xhci->lock held.
|
|
|
|
|
*/
|
|
|
|
|
static void xhci_free_host_resources(struct xhci_hcd *xhci,
|
2013-04-24 00:11:14 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx)
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
{
|
|
|
|
|
u32 num_failed_eps;
|
|
|
|
|
|
2013-04-24 00:11:14 +00:00
|
|
|
num_failed_eps = xhci_count_num_new_endpoints(xhci, ctrl_ctx);
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
xhci->num_active_eps -= num_failed_eps;
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Removing %u failed ep ctxs, %u now active.",
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
num_failed_eps,
|
|
|
|
|
xhci->num_active_eps);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Now that the command has completed, clean up the active endpoint count by
|
|
|
|
|
* subtracting out the endpoints that were dropped (but not changed).
|
|
|
|
|
*
|
|
|
|
|
* Must be called with xhci->lock held.
|
|
|
|
|
*/
|
|
|
|
|
static void xhci_finish_resource_reservation(struct xhci_hcd *xhci,
|
2013-04-24 00:11:14 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx)
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
{
|
|
|
|
|
u32 num_dropped_eps;
|
|
|
|
|
|
2013-04-24 00:11:14 +00:00
|
|
|
num_dropped_eps = xhci_count_num_dropped_endpoints(xhci, ctrl_ctx);
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
xhci->num_active_eps -= num_dropped_eps;
|
|
|
|
|
if (num_dropped_eps)
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Removing %u dropped ep ctxs, %u now active.",
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
num_dropped_eps,
|
|
|
|
|
xhci->num_active_eps);
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-07 11:10:03 +00:00
|
|
|
static unsigned int xhci_get_block_size(struct usb_device *udev)
|
2011-09-02 18:05:52 +00:00
|
|
|
{
|
|
|
|
|
switch (udev->speed) {
|
|
|
|
|
case USB_SPEED_LOW:
|
|
|
|
|
case USB_SPEED_FULL:
|
|
|
|
|
return FS_BLOCK;
|
|
|
|
|
case USB_SPEED_HIGH:
|
|
|
|
|
return HS_BLOCK;
|
|
|
|
|
case USB_SPEED_SUPER:
|
|
|
|
|
return SS_BLOCK;
|
|
|
|
|
case USB_SPEED_UNKNOWN:
|
|
|
|
|
case USB_SPEED_WIRELESS:
|
|
|
|
|
default:
|
|
|
|
|
/* Should never happen */
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-08-07 11:10:03 +00:00
|
|
|
static unsigned int
|
|
|
|
|
xhci_get_largest_overhead(struct xhci_interval_bw *interval_bw)
|
2011-09-02 18:05:52 +00:00
|
|
|
{
|
|
|
|
|
if (interval_bw->overhead[LS_OVERHEAD_TYPE])
|
|
|
|
|
return LS_OVERHEAD;
|
|
|
|
|
if (interval_bw->overhead[FS_OVERHEAD_TYPE])
|
|
|
|
|
return FS_OVERHEAD;
|
|
|
|
|
return HS_OVERHEAD;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* If we are changing a LS/FS device under a HS hub,
|
|
|
|
|
* make sure (if we are activating a new TT) that the HS bus has enough
|
|
|
|
|
* bandwidth for this new TT.
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_check_tt_bw_table(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
|
int old_active_eps)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_interval_bw_table *bw_table;
|
|
|
|
|
struct xhci_tt_bw_info *tt_info;
|
|
|
|
|
|
|
|
|
|
/* Find the bandwidth table for the root port this TT is attached to. */
|
|
|
|
|
bw_table = &xhci->rh_bw[virt_dev->real_port - 1].bw_table;
|
|
|
|
|
tt_info = virt_dev->tt_info;
|
|
|
|
|
/* If this TT already had active endpoints, the bandwidth for this TT
|
|
|
|
|
* has already been added. Removing all periodic endpoints (and thus
|
|
|
|
|
* making the TT enactive) will only decrease the bandwidth used.
|
|
|
|
|
*/
|
|
|
|
|
if (old_active_eps)
|
|
|
|
|
return 0;
|
|
|
|
|
if (old_active_eps == 0 && tt_info->active_eps != 0) {
|
|
|
|
|
if (bw_table->bw_used + TT_HS_OVERHEAD > HS_BW_LIMIT)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
/* Not sure why we would have no new active endpoints...
|
|
|
|
|
*
|
|
|
|
|
* Maybe because of an Evaluate Context change for a hub update or a
|
|
|
|
|
* control endpoint 0 max packet size change?
|
|
|
|
|
* FIXME: skip the bandwidth calculation in that case.
|
|
|
|
|
*/
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-13 23:41:13 +00:00
|
|
|
static int xhci_check_ss_bw(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *virt_dev)
|
|
|
|
|
{
|
|
|
|
|
unsigned int bw_reserved;
|
|
|
|
|
|
|
|
|
|
bw_reserved = DIV_ROUND_UP(SS_BW_RESERVED*SS_BW_LIMIT_IN, 100);
|
|
|
|
|
if (virt_dev->bw_table->ss_bw_in > (SS_BW_LIMIT_IN - bw_reserved))
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
bw_reserved = DIV_ROUND_UP(SS_BW_RESERVED*SS_BW_LIMIT_OUT, 100);
|
|
|
|
|
if (virt_dev->bw_table->ss_bw_out > (SS_BW_LIMIT_OUT - bw_reserved))
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-02 18:05:52 +00:00
|
|
|
/*
|
|
|
|
|
* This algorithm is a very conservative estimate of the worst-case scheduling
|
|
|
|
|
* scenario for any one interval. The hardware dynamically schedules the
|
|
|
|
|
* packets, so we can't tell which microframe could be the limiting factor in
|
|
|
|
|
* the bandwidth scheduling. This only takes into account periodic endpoints.
|
|
|
|
|
*
|
|
|
|
|
* Obviously, we can't solve an NP complete problem to find the minimum worst
|
|
|
|
|
* case scenario. Instead, we come up with an estimate that is no less than
|
|
|
|
|
* the worst case bandwidth used for any one microframe, but may be an
|
|
|
|
|
* over-estimate.
|
|
|
|
|
*
|
|
|
|
|
* We walk the requirements for each endpoint by interval, starting with the
|
|
|
|
|
* smallest interval, and place packets in the schedule where there is only one
|
|
|
|
|
* possible way to schedule packets for that interval. In order to simplify
|
|
|
|
|
* this algorithm, we record the largest max packet size for each interval, and
|
|
|
|
|
* assume all packets will be that size.
|
|
|
|
|
*
|
|
|
|
|
* For interval 0, we obviously must schedule all packets for each interval.
|
|
|
|
|
* The bandwidth for interval 0 is just the amount of data to be transmitted
|
|
|
|
|
* (the sum of all max ESIT payload sizes, plus any overhead per packet times
|
|
|
|
|
* the number of packets).
|
|
|
|
|
*
|
|
|
|
|
* For interval 1, we have two possible microframes to schedule those packets
|
|
|
|
|
* in. For this algorithm, if we can schedule the same number of packets for
|
|
|
|
|
* each possible scheduling opportunity (each microframe), we will do so. The
|
|
|
|
|
* remaining number of packets will be saved to be transmitted in the gaps in
|
|
|
|
|
* the next interval's scheduling sequence.
|
|
|
|
|
*
|
|
|
|
|
* As we move those remaining packets to be scheduled with interval 2 packets,
|
|
|
|
|
* we have to double the number of remaining packets to transmit. This is
|
|
|
|
|
* because the intervals are actually powers of 2, and we would be transmitting
|
|
|
|
|
* the previous interval's packets twice in this interval. We also have to be
|
|
|
|
|
* sure that when we look at the largest max packet size for this interval, we
|
|
|
|
|
* also look at the largest max packet size for the remaining packets and take
|
|
|
|
|
* the greater of the two.
|
|
|
|
|
*
|
|
|
|
|
* The algorithm continues to evenly distribute packets in each scheduling
|
|
|
|
|
* opportunity, and push the remaining packets out, until we get to the last
|
|
|
|
|
* interval. Then those packets and their associated overhead are just added
|
|
|
|
|
* to the bandwidth used.
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
*/
|
|
|
|
|
static int xhci_check_bw_table(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
|
int old_active_eps)
|
|
|
|
|
{
|
2011-09-02 18:05:52 +00:00
|
|
|
unsigned int bw_reserved;
|
|
|
|
|
unsigned int max_bandwidth;
|
|
|
|
|
unsigned int bw_used;
|
|
|
|
|
unsigned int block_size;
|
|
|
|
|
struct xhci_interval_bw_table *bw_table;
|
|
|
|
|
unsigned int packet_size = 0;
|
|
|
|
|
unsigned int overhead = 0;
|
|
|
|
|
unsigned int packets_transmitted = 0;
|
|
|
|
|
unsigned int packets_remaining = 0;
|
|
|
|
|
unsigned int i;
|
|
|
|
|
|
2011-09-13 23:41:13 +00:00
|
|
|
if (virt_dev->udev->speed == USB_SPEED_SUPER)
|
|
|
|
|
return xhci_check_ss_bw(xhci, virt_dev);
|
|
|
|
|
|
2011-09-02 18:05:52 +00:00
|
|
|
if (virt_dev->udev->speed == USB_SPEED_HIGH) {
|
|
|
|
|
max_bandwidth = HS_BW_LIMIT;
|
|
|
|
|
/* Convert percent of bus BW reserved to blocks reserved */
|
|
|
|
|
bw_reserved = DIV_ROUND_UP(HS_BW_RESERVED * max_bandwidth, 100);
|
|
|
|
|
} else {
|
|
|
|
|
max_bandwidth = FS_BW_LIMIT;
|
|
|
|
|
bw_reserved = DIV_ROUND_UP(FS_BW_RESERVED * max_bandwidth, 100);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bw_table = virt_dev->bw_table;
|
|
|
|
|
/* We need to translate the max packet size and max ESIT payloads into
|
|
|
|
|
* the units the hardware uses.
|
|
|
|
|
*/
|
|
|
|
|
block_size = xhci_get_block_size(virt_dev->udev);
|
|
|
|
|
|
|
|
|
|
/* If we are manipulating a LS/FS device under a HS hub, double check
|
|
|
|
|
* that the HS bus has enough bandwidth if we are activing a new TT.
|
|
|
|
|
*/
|
|
|
|
|
if (virt_dev->tt_info) {
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Recalculating BW for rootport %u",
|
2011-09-02 18:05:52 +00:00
|
|
|
virt_dev->real_port);
|
|
|
|
|
if (xhci_check_tt_bw_table(xhci, virt_dev, old_active_eps)) {
|
|
|
|
|
xhci_warn(xhci, "Not enough bandwidth on HS bus for "
|
|
|
|
|
"newly activated TT.\n");
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Recalculating BW for TT slot %u port %u",
|
2011-09-02 18:05:52 +00:00
|
|
|
virt_dev->tt_info->slot_id,
|
|
|
|
|
virt_dev->tt_info->ttport);
|
|
|
|
|
} else {
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Recalculating BW for rootport %u",
|
2011-09-02 18:05:52 +00:00
|
|
|
virt_dev->real_port);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Add in how much bandwidth will be used for interval zero, or the
|
|
|
|
|
* rounded max ESIT payload + number of packets * largest overhead.
|
|
|
|
|
*/
|
|
|
|
|
bw_used = DIV_ROUND_UP(bw_table->interval0_esit_payload, block_size) +
|
|
|
|
|
bw_table->interval_bw[0].num_packets *
|
|
|
|
|
xhci_get_largest_overhead(&bw_table->interval_bw[0]);
|
|
|
|
|
|
|
|
|
|
for (i = 1; i < XHCI_MAX_INTERVAL; i++) {
|
|
|
|
|
unsigned int bw_added;
|
|
|
|
|
unsigned int largest_mps;
|
|
|
|
|
unsigned int interval_overhead;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* How many packets could we transmit in this interval?
|
|
|
|
|
* If packets didn't fit in the previous interval, we will need
|
|
|
|
|
* to transmit that many packets twice within this interval.
|
|
|
|
|
*/
|
|
|
|
|
packets_remaining = 2 * packets_remaining +
|
|
|
|
|
bw_table->interval_bw[i].num_packets;
|
|
|
|
|
|
|
|
|
|
/* Find the largest max packet size of this or the previous
|
|
|
|
|
* interval.
|
|
|
|
|
*/
|
|
|
|
|
if (list_empty(&bw_table->interval_bw[i].endpoints))
|
|
|
|
|
largest_mps = 0;
|
|
|
|
|
else {
|
|
|
|
|
struct xhci_virt_ep *virt_ep;
|
|
|
|
|
struct list_head *ep_entry;
|
|
|
|
|
|
|
|
|
|
ep_entry = bw_table->interval_bw[i].endpoints.next;
|
|
|
|
|
virt_ep = list_entry(ep_entry,
|
|
|
|
|
struct xhci_virt_ep, bw_endpoint_list);
|
|
|
|
|
/* Convert to blocks, rounding up */
|
|
|
|
|
largest_mps = DIV_ROUND_UP(
|
|
|
|
|
virt_ep->bw_info.max_packet_size,
|
|
|
|
|
block_size);
|
|
|
|
|
}
|
|
|
|
|
if (largest_mps > packet_size)
|
|
|
|
|
packet_size = largest_mps;
|
|
|
|
|
|
|
|
|
|
/* Use the larger overhead of this or the previous interval. */
|
|
|
|
|
interval_overhead = xhci_get_largest_overhead(
|
|
|
|
|
&bw_table->interval_bw[i]);
|
|
|
|
|
if (interval_overhead > overhead)
|
|
|
|
|
overhead = interval_overhead;
|
|
|
|
|
|
|
|
|
|
/* How many packets can we evenly distribute across
|
|
|
|
|
* (1 << (i + 1)) possible scheduling opportunities?
|
|
|
|
|
*/
|
|
|
|
|
packets_transmitted = packets_remaining >> (i + 1);
|
|
|
|
|
|
|
|
|
|
/* Add in the bandwidth used for those scheduled packets */
|
|
|
|
|
bw_added = packets_transmitted * (overhead + packet_size);
|
|
|
|
|
|
|
|
|
|
/* How many packets do we have remaining to transmit? */
|
|
|
|
|
packets_remaining = packets_remaining % (1 << (i + 1));
|
|
|
|
|
|
|
|
|
|
/* What largest max packet size should those packets have? */
|
|
|
|
|
/* If we've transmitted all packets, don't carry over the
|
|
|
|
|
* largest packet size.
|
|
|
|
|
*/
|
|
|
|
|
if (packets_remaining == 0) {
|
|
|
|
|
packet_size = 0;
|
|
|
|
|
overhead = 0;
|
|
|
|
|
} else if (packets_transmitted > 0) {
|
|
|
|
|
/* Otherwise if we do have remaining packets, and we've
|
|
|
|
|
* scheduled some packets in this interval, take the
|
|
|
|
|
* largest max packet size from endpoints with this
|
|
|
|
|
* interval.
|
|
|
|
|
*/
|
|
|
|
|
packet_size = largest_mps;
|
|
|
|
|
overhead = interval_overhead;
|
|
|
|
|
}
|
|
|
|
|
/* Otherwise carry over packet_size and overhead from the last
|
|
|
|
|
* time we had a remainder.
|
|
|
|
|
*/
|
|
|
|
|
bw_used += bw_added;
|
|
|
|
|
if (bw_used > max_bandwidth) {
|
|
|
|
|
xhci_warn(xhci, "Not enough bandwidth. "
|
|
|
|
|
"Proposed: %u, Max: %u\n",
|
|
|
|
|
bw_used, max_bandwidth);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
/*
|
|
|
|
|
* Ok, we know we have some packets left over after even-handedly
|
|
|
|
|
* scheduling interval 15. We don't know which microframes they will
|
|
|
|
|
* fit into, so we over-schedule and say they will be scheduled every
|
|
|
|
|
* microframe.
|
|
|
|
|
*/
|
|
|
|
|
if (packets_remaining > 0)
|
|
|
|
|
bw_used += overhead + packet_size;
|
|
|
|
|
|
|
|
|
|
if (!virt_dev->tt_info && virt_dev->udev->speed == USB_SPEED_HIGH) {
|
|
|
|
|
unsigned int port_index = virt_dev->real_port - 1;
|
|
|
|
|
|
|
|
|
|
/* OK, we're manipulating a HS device attached to a
|
|
|
|
|
* root port bandwidth domain. Include the number of active TTs
|
|
|
|
|
* in the bandwidth used.
|
|
|
|
|
*/
|
|
|
|
|
bw_used += TT_HS_OVERHEAD *
|
|
|
|
|
xhci->rh_bw[port_index].num_active_tts;
|
|
|
|
|
}
|
|
|
|
|
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Final bandwidth: %u, Limit: %u, Reserved: %u, "
|
|
|
|
|
"Available: %u " "percent",
|
2011-09-02 18:05:52 +00:00
|
|
|
bw_used, max_bandwidth, bw_reserved,
|
|
|
|
|
(max_bandwidth - bw_used - bw_reserved) * 100 /
|
|
|
|
|
max_bandwidth);
|
|
|
|
|
|
|
|
|
|
bw_used += bw_reserved;
|
|
|
|
|
if (bw_used > max_bandwidth) {
|
|
|
|
|
xhci_warn(xhci, "Not enough bandwidth. Proposed: %u, Max: %u\n",
|
|
|
|
|
bw_used, max_bandwidth);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bw_table->bw_used = bw_used;
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool xhci_is_async_ep(unsigned int ep_type)
|
|
|
|
|
{
|
|
|
|
|
return (ep_type != ISOC_OUT_EP && ep_type != INT_OUT_EP &&
|
|
|
|
|
ep_type != ISOC_IN_EP &&
|
|
|
|
|
ep_type != INT_IN_EP);
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-13 23:41:13 +00:00
|
|
|
static bool xhci_is_sync_in_ep(unsigned int ep_type)
|
|
|
|
|
{
|
2012-10-25 20:44:12 +00:00
|
|
|
return (ep_type == ISOC_IN_EP || ep_type == INT_IN_EP);
|
2011-09-13 23:41:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static unsigned int xhci_get_ss_bw_consumed(struct xhci_bw_info *ep_bw)
|
|
|
|
|
{
|
|
|
|
|
unsigned int mps = DIV_ROUND_UP(ep_bw->max_packet_size, SS_BLOCK);
|
|
|
|
|
|
|
|
|
|
if (ep_bw->ep_interval == 0)
|
|
|
|
|
return SS_OVERHEAD_BURST +
|
|
|
|
|
(ep_bw->mult * ep_bw->num_packets *
|
|
|
|
|
(SS_OVERHEAD + mps));
|
|
|
|
|
return DIV_ROUND_UP(ep_bw->mult * ep_bw->num_packets *
|
|
|
|
|
(SS_OVERHEAD + mps + SS_OVERHEAD_BURST),
|
|
|
|
|
1 << ep_bw->ep_interval);
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
void xhci_drop_ep_from_interval_table(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_bw_info *ep_bw,
|
|
|
|
|
struct xhci_interval_bw_table *bw_table,
|
|
|
|
|
struct usb_device *udev,
|
|
|
|
|
struct xhci_virt_ep *virt_ep,
|
|
|
|
|
struct xhci_tt_bw_info *tt_info)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_interval_bw *interval_bw;
|
|
|
|
|
int normalized_interval;
|
|
|
|
|
|
2011-09-13 23:41:13 +00:00
|
|
|
if (xhci_is_async_ep(ep_bw->type))
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
return;
|
|
|
|
|
|
2011-09-13 23:41:13 +00:00
|
|
|
if (udev->speed == USB_SPEED_SUPER) {
|
|
|
|
|
if (xhci_is_sync_in_ep(ep_bw->type))
|
|
|
|
|
xhci->devs[udev->slot_id]->bw_table->ss_bw_in -=
|
|
|
|
|
xhci_get_ss_bw_consumed(ep_bw);
|
|
|
|
|
else
|
|
|
|
|
xhci->devs[udev->slot_id]->bw_table->ss_bw_out -=
|
|
|
|
|
xhci_get_ss_bw_consumed(ep_bw);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* SuperSpeed endpoints never get added to intervals in the table, so
|
|
|
|
|
* this check is only valid for HS/FS/LS devices.
|
|
|
|
|
*/
|
|
|
|
|
if (list_empty(&virt_ep->bw_endpoint_list))
|
|
|
|
|
return;
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
/* For LS/FS devices, we need to translate the interval expressed in
|
|
|
|
|
* microframes to frames.
|
|
|
|
|
*/
|
|
|
|
|
if (udev->speed == USB_SPEED_HIGH)
|
|
|
|
|
normalized_interval = ep_bw->ep_interval;
|
|
|
|
|
else
|
|
|
|
|
normalized_interval = ep_bw->ep_interval - 3;
|
|
|
|
|
|
|
|
|
|
if (normalized_interval == 0)
|
|
|
|
|
bw_table->interval0_esit_payload -= ep_bw->max_esit_payload;
|
|
|
|
|
interval_bw = &bw_table->interval_bw[normalized_interval];
|
|
|
|
|
interval_bw->num_packets -= ep_bw->num_packets;
|
|
|
|
|
switch (udev->speed) {
|
|
|
|
|
case USB_SPEED_LOW:
|
|
|
|
|
interval_bw->overhead[LS_OVERHEAD_TYPE] -= 1;
|
|
|
|
|
break;
|
|
|
|
|
case USB_SPEED_FULL:
|
|
|
|
|
interval_bw->overhead[FS_OVERHEAD_TYPE] -= 1;
|
|
|
|
|
break;
|
|
|
|
|
case USB_SPEED_HIGH:
|
|
|
|
|
interval_bw->overhead[HS_OVERHEAD_TYPE] -= 1;
|
|
|
|
|
break;
|
|
|
|
|
case USB_SPEED_SUPER:
|
|
|
|
|
case USB_SPEED_UNKNOWN:
|
|
|
|
|
case USB_SPEED_WIRELESS:
|
|
|
|
|
/* Should never happen because only LS/FS/HS endpoints will get
|
|
|
|
|
* added to the endpoint list.
|
|
|
|
|
*/
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (tt_info)
|
|
|
|
|
tt_info->active_eps -= 1;
|
|
|
|
|
list_del_init(&virt_ep->bw_endpoint_list);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void xhci_add_ep_to_interval_table(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_bw_info *ep_bw,
|
|
|
|
|
struct xhci_interval_bw_table *bw_table,
|
|
|
|
|
struct usb_device *udev,
|
|
|
|
|
struct xhci_virt_ep *virt_ep,
|
|
|
|
|
struct xhci_tt_bw_info *tt_info)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_interval_bw *interval_bw;
|
|
|
|
|
struct xhci_virt_ep *smaller_ep;
|
|
|
|
|
int normalized_interval;
|
|
|
|
|
|
|
|
|
|
if (xhci_is_async_ep(ep_bw->type))
|
|
|
|
|
return;
|
|
|
|
|
|
2011-09-13 23:41:13 +00:00
|
|
|
if (udev->speed == USB_SPEED_SUPER) {
|
|
|
|
|
if (xhci_is_sync_in_ep(ep_bw->type))
|
|
|
|
|
xhci->devs[udev->slot_id]->bw_table->ss_bw_in +=
|
|
|
|
|
xhci_get_ss_bw_consumed(ep_bw);
|
|
|
|
|
else
|
|
|
|
|
xhci->devs[udev->slot_id]->bw_table->ss_bw_out +=
|
|
|
|
|
xhci_get_ss_bw_consumed(ep_bw);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
/* For LS/FS devices, we need to translate the interval expressed in
|
|
|
|
|
* microframes to frames.
|
|
|
|
|
*/
|
|
|
|
|
if (udev->speed == USB_SPEED_HIGH)
|
|
|
|
|
normalized_interval = ep_bw->ep_interval;
|
|
|
|
|
else
|
|
|
|
|
normalized_interval = ep_bw->ep_interval - 3;
|
|
|
|
|
|
|
|
|
|
if (normalized_interval == 0)
|
|
|
|
|
bw_table->interval0_esit_payload += ep_bw->max_esit_payload;
|
|
|
|
|
interval_bw = &bw_table->interval_bw[normalized_interval];
|
|
|
|
|
interval_bw->num_packets += ep_bw->num_packets;
|
|
|
|
|
switch (udev->speed) {
|
|
|
|
|
case USB_SPEED_LOW:
|
|
|
|
|
interval_bw->overhead[LS_OVERHEAD_TYPE] += 1;
|
|
|
|
|
break;
|
|
|
|
|
case USB_SPEED_FULL:
|
|
|
|
|
interval_bw->overhead[FS_OVERHEAD_TYPE] += 1;
|
|
|
|
|
break;
|
|
|
|
|
case USB_SPEED_HIGH:
|
|
|
|
|
interval_bw->overhead[HS_OVERHEAD_TYPE] += 1;
|
|
|
|
|
break;
|
|
|
|
|
case USB_SPEED_SUPER:
|
|
|
|
|
case USB_SPEED_UNKNOWN:
|
|
|
|
|
case USB_SPEED_WIRELESS:
|
|
|
|
|
/* Should never happen because only LS/FS/HS endpoints will get
|
|
|
|
|
* added to the endpoint list.
|
|
|
|
|
*/
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (tt_info)
|
|
|
|
|
tt_info->active_eps += 1;
|
|
|
|
|
/* Insert the endpoint into the list, largest max packet size first. */
|
|
|
|
|
list_for_each_entry(smaller_ep, &interval_bw->endpoints,
|
|
|
|
|
bw_endpoint_list) {
|
|
|
|
|
if (ep_bw->max_packet_size >=
|
|
|
|
|
smaller_ep->bw_info.max_packet_size) {
|
|
|
|
|
/* Add the new ep before the smaller endpoint */
|
|
|
|
|
list_add_tail(&virt_ep->bw_endpoint_list,
|
|
|
|
|
&smaller_ep->bw_endpoint_list);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
/* Add the new endpoint at the end of the list. */
|
|
|
|
|
list_add_tail(&virt_ep->bw_endpoint_list,
|
|
|
|
|
&interval_bw->endpoints);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void xhci_update_tt_active_eps(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
|
int old_active_eps)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_root_port_bw_info *rh_bw_info;
|
|
|
|
|
if (!virt_dev->tt_info)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
rh_bw_info = &xhci->rh_bw[virt_dev->real_port - 1];
|
|
|
|
|
if (old_active_eps == 0 &&
|
|
|
|
|
virt_dev->tt_info->active_eps != 0) {
|
|
|
|
|
rh_bw_info->num_active_tts += 1;
|
2011-09-02 18:05:52 +00:00
|
|
|
rh_bw_info->bw_table.bw_used += TT_HS_OVERHEAD;
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
} else if (old_active_eps != 0 &&
|
|
|
|
|
virt_dev->tt_info->active_eps == 0) {
|
|
|
|
|
rh_bw_info->num_active_tts -= 1;
|
2011-09-02 18:05:52 +00:00
|
|
|
rh_bw_info->bw_table.bw_used -= TT_HS_OVERHEAD;
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int xhci_reserve_bandwidth(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
|
struct xhci_container_ctx *in_ctx)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_bw_info ep_bw_info[31];
|
|
|
|
|
int i;
|
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
|
|
|
|
int old_active_eps = 0;
|
|
|
|
|
|
|
|
|
|
if (virt_dev->tt_info)
|
|
|
|
|
old_active_eps = virt_dev->tt_info->active_eps;
|
|
|
|
|
|
|
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
|
2013-04-24 00:11:14 +00:00
|
|
|
if (!ctrl_ctx) {
|
|
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
|
|
|
|
|
for (i = 0; i < 31; i++) {
|
|
|
|
|
if (!EP_IS_ADDED(ctrl_ctx, i) && !EP_IS_DROPPED(ctrl_ctx, i))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* Make a copy of the BW info in case we need to revert this */
|
|
|
|
|
memcpy(&ep_bw_info[i], &virt_dev->eps[i].bw_info,
|
|
|
|
|
sizeof(ep_bw_info[i]));
|
|
|
|
|
/* Drop the endpoint from the interval table if the endpoint is
|
|
|
|
|
* being dropped or changed.
|
|
|
|
|
*/
|
|
|
|
|
if (EP_IS_DROPPED(ctrl_ctx, i))
|
|
|
|
|
xhci_drop_ep_from_interval_table(xhci,
|
|
|
|
|
&virt_dev->eps[i].bw_info,
|
|
|
|
|
virt_dev->bw_table,
|
|
|
|
|
virt_dev->udev,
|
|
|
|
|
&virt_dev->eps[i],
|
|
|
|
|
virt_dev->tt_info);
|
|
|
|
|
}
|
|
|
|
|
/* Overwrite the information stored in the endpoints' bw_info */
|
|
|
|
|
xhci_update_bw_info(xhci, virt_dev->in_ctx, ctrl_ctx, virt_dev);
|
|
|
|
|
for (i = 0; i < 31; i++) {
|
|
|
|
|
/* Add any changed or added endpoints to the interval table */
|
|
|
|
|
if (EP_IS_ADDED(ctrl_ctx, i))
|
|
|
|
|
xhci_add_ep_to_interval_table(xhci,
|
|
|
|
|
&virt_dev->eps[i].bw_info,
|
|
|
|
|
virt_dev->bw_table,
|
|
|
|
|
virt_dev->udev,
|
|
|
|
|
&virt_dev->eps[i],
|
|
|
|
|
virt_dev->tt_info);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!xhci_check_bw_table(xhci, virt_dev, old_active_eps)) {
|
|
|
|
|
/* Ok, this fits in the bandwidth we have.
|
|
|
|
|
* Update the number of active TTs.
|
|
|
|
|
*/
|
|
|
|
|
xhci_update_tt_active_eps(xhci, virt_dev, old_active_eps);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* We don't have enough bandwidth for this, revert the stored info. */
|
|
|
|
|
for (i = 0; i < 31; i++) {
|
|
|
|
|
if (!EP_IS_ADDED(ctrl_ctx, i) && !EP_IS_DROPPED(ctrl_ctx, i))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* Drop the new copies of any added or changed endpoints from
|
|
|
|
|
* the interval table.
|
|
|
|
|
*/
|
|
|
|
|
if (EP_IS_ADDED(ctrl_ctx, i)) {
|
|
|
|
|
xhci_drop_ep_from_interval_table(xhci,
|
|
|
|
|
&virt_dev->eps[i].bw_info,
|
|
|
|
|
virt_dev->bw_table,
|
|
|
|
|
virt_dev->udev,
|
|
|
|
|
&virt_dev->eps[i],
|
|
|
|
|
virt_dev->tt_info);
|
|
|
|
|
}
|
|
|
|
|
/* Revert the endpoint back to its old information */
|
|
|
|
|
memcpy(&virt_dev->eps[i].bw_info, &ep_bw_info[i],
|
|
|
|
|
sizeof(ep_bw_info[i]));
|
|
|
|
|
/* Add any changed or dropped endpoints back into the table */
|
|
|
|
|
if (EP_IS_DROPPED(ctrl_ctx, i))
|
|
|
|
|
xhci_add_ep_to_interval_table(xhci,
|
|
|
|
|
&virt_dev->eps[i].bw_info,
|
|
|
|
|
virt_dev->bw_table,
|
|
|
|
|
virt_dev->udev,
|
|
|
|
|
&virt_dev->eps[i],
|
|
|
|
|
virt_dev->tt_info);
|
|
|
|
|
}
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2009-08-07 21:04:43 +00:00
|
|
|
/* 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;
|
|
|
|
|
unsigned long flags;
|
2013-04-24 00:11:14 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
2009-09-04 17:53:13 +00:00
|
|
|
struct xhci_virt_device *virt_dev;
|
2014-05-08 16:26:00 +00:00
|
|
|
|
|
|
|
|
if (!command)
|
|
|
|
|
return -EINVAL;
|
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];
|
2011-09-02 18:05:43 +00:00
|
|
|
|
2014-05-08 16:26:00 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, command->in_ctx);
|
2013-04-24 00:11:14 +00:00
|
|
|
if (!ctrl_ctx) {
|
2013-06-25 22:49:36 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
2013-04-24 00:11:14 +00:00
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
|
2011-09-02 18:05:43 +00:00
|
|
|
if ((xhci->quirks & XHCI_EP_LIMIT_QUIRK) &&
|
2013-04-24 00:11:14 +00:00
|
|
|
xhci_reserve_host_resources(xhci, ctrl_ctx)) {
|
2011-09-02 18:05:43 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
xhci_warn(xhci, "Not enough host resources, "
|
|
|
|
|
"active endpoint contexts = %u\n",
|
|
|
|
|
xhci->num_active_eps);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
if ((xhci->quirks & XHCI_SW_BW_CHECKING) &&
|
2014-05-08 16:26:00 +00:00
|
|
|
xhci_reserve_bandwidth(xhci, virt_dev, command->in_ctx)) {
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
if ((xhci->quirks & XHCI_EP_LIMIT_QUIRK))
|
2013-04-24 00:11:14 +00:00
|
|
|
xhci_free_host_resources(xhci, ctrl_ctx);
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
xhci_warn(xhci, "Not enough bandwidth\n");
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
2011-09-02 18:05:43 +00:00
|
|
|
|
2009-08-07 21:04:43 +00:00
|
|
|
if (!ctx_change)
|
2014-05-08 16:26:00 +00:00
|
|
|
ret = xhci_queue_configure_endpoint(xhci, command,
|
|
|
|
|
command->in_ctx->dma,
|
2009-09-04 17:53:13 +00:00
|
|
|
udev->slot_id, must_succeed);
|
2009-08-07 21:04:43 +00:00
|
|
|
else
|
2014-05-08 16:26:00 +00:00
|
|
|
ret = xhci_queue_evaluate_context(xhci, command,
|
|
|
|
|
command->in_ctx->dma,
|
2012-05-07 22:34:26 +00:00
|
|
|
udev->slot_id, must_succeed);
|
2009-08-07 21:04:43 +00:00
|
|
|
if (ret < 0) {
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
if ((xhci->quirks & XHCI_EP_LIMIT_QUIRK))
|
2013-04-24 00:11:14 +00:00
|
|
|
xhci_free_host_resources(xhci, ctrl_ctx);
|
2009-08-07 21:04:43 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
2013-07-31 04:35:27 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
|
|
|
|
|
"FIXME allocate a new ring segment");
|
2009-08-07 21:04:43 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
/* Wait for the configure endpoint command to complete */
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 16:26:03 +00:00
|
|
|
wait_for_completion(command->completion);
|
2009-08-07 21:04:43 +00:00
|
|
|
|
|
|
|
|
if (!ctx_change)
|
2014-05-08 16:26:00 +00:00
|
|
|
ret = xhci_configure_endpoint_result(xhci, udev,
|
|
|
|
|
&command->status);
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
else
|
2014-05-08 16:26:00 +00:00
|
|
|
ret = xhci_evaluate_context_result(xhci, udev,
|
|
|
|
|
&command->status);
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
|
|
|
|
|
if ((xhci->quirks & XHCI_EP_LIMIT_QUIRK)) {
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
/* If the command failed, remove the reserved resources.
|
|
|
|
|
* Otherwise, clean up the estimate to include dropped eps.
|
|
|
|
|
*/
|
|
|
|
|
if (ret)
|
2013-04-24 00:11:14 +00:00
|
|
|
xhci_free_host_resources(xhci, ctrl_ctx);
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
else
|
2013-04-24 00:11:14 +00:00
|
|
|
xhci_finish_resource_reservation(xhci, ctrl_ctx);
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
}
|
|
|
|
|
return ret;
|
2009-08-07 21:04:43 +00:00
|
|
|
}
|
|
|
|
|
|
2013-10-03 22:29:45 +00:00
|
|
|
static void xhci_check_bw_drop_ep_streams(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *vdev, int i)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_virt_ep *ep = &vdev->eps[i];
|
|
|
|
|
|
|
|
|
|
if (ep->ep_state & EP_HAS_STREAMS) {
|
|
|
|
|
xhci_warn(xhci, "WARN: endpoint 0x%02x has streams on set_interface, freeing streams.\n",
|
|
|
|
|
xhci_get_endpoint_address(i));
|
|
|
|
|
xhci_free_stream_info(xhci, ep->stream_info);
|
|
|
|
|
ep->stream_info = NULL;
|
|
|
|
|
ep->ep_state &= ~EP_HAS_STREAMS;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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;
|
2014-05-08 16:26:00 +00:00
|
|
|
struct xhci_command *command;
|
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);
|
2011-05-23 23:41:17 +00:00
|
|
|
if (xhci->xhc_state & XHCI_STATE_DYING)
|
|
|
|
|
return -ENODEV;
|
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-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];
|
|
|
|
|
|
2014-05-08 16:26:00 +00:00
|
|
|
command = xhci_alloc_command(xhci, false, true, GFP_KERNEL);
|
|
|
|
|
if (!command)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
command->in_ctx = virt_dev->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
|
|
|
/* See section 4.6.6 - A0 = 1; A1 = D0 = D1 = 0 */
|
2014-05-08 16:26:00 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, command->in_ctx);
|
2013-04-24 00:11:14 +00:00
|
|
|
if (!ctrl_ctx) {
|
|
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
2014-05-08 16:26:00 +00:00
|
|
|
ret = -ENOMEM;
|
|
|
|
|
goto command_cleanup;
|
2013-04-24 00:11:14 +00:00
|
|
|
}
|
2011-03-29 02:40:46 +00:00
|
|
|
ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG);
|
|
|
|
|
ctrl_ctx->add_flags &= cpu_to_le32(~EP0_FLAG);
|
|
|
|
|
ctrl_ctx->drop_flags &= cpu_to_le32(~(SLOT_FLAG | EP0_FLAG));
|
2011-09-02 18:05:40 +00:00
|
|
|
|
|
|
|
|
/* Don't issue the command if there's no endpoints to update. */
|
|
|
|
|
if (ctrl_ctx->add_flags == cpu_to_le32(SLOT_FLAG) &&
|
2014-05-08 16:26:00 +00:00
|
|
|
ctrl_ctx->drop_flags == 0) {
|
|
|
|
|
ret = 0;
|
|
|
|
|
goto command_cleanup;
|
|
|
|
|
}
|
2014-06-24 14:14:42 +00:00
|
|
|
/* Fix up Context Entries field. Minimum value is EP0 == BIT(1). */
|
2009-07-27 19:05:15 +00:00
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->in_ctx);
|
2014-06-24 14:14:42 +00:00
|
|
|
for (i = 31; i >= 1; i--) {
|
|
|
|
|
__le32 le32 = cpu_to_le32(BIT(i));
|
|
|
|
|
|
|
|
|
|
if ((virt_dev->eps[i-1].ring && !(ctrl_ctx->drop_flags & le32))
|
|
|
|
|
|| (ctrl_ctx->add_flags & le32) || i == 1) {
|
|
|
|
|
slot_ctx->dev_info &= cpu_to_le32(~LAST_CTX_MASK);
|
|
|
|
|
slot_ctx->dev_info |= cpu_to_le32(LAST_CTX(i));
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
xhci_dbg(xhci, "New Input Control Context:\n");
|
2009-07-27 19:05:15 +00:00
|
|
|
xhci_dbg_ctx(xhci, virt_dev->in_ctx,
|
2011-03-29 02:40:46 +00:00
|
|
|
LAST_CTX_TO_EP_NUM(le32_to_cpu(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
|
|
|
|
2014-05-08 16:26:00 +00:00
|
|
|
ret = xhci_configure_endpoint(xhci, udev, command,
|
2009-09-04 17:53:13 +00:00
|
|
|
false, false);
|
2014-05-08 16:26:00 +00:00
|
|
|
if (ret)
|
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
|
|
|
/* Callee should call reset_bandwidth() */
|
2014-05-08 16:26:00 +00:00
|
|
|
goto command_cleanup;
|
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, "Output context after successful config ep cmd:\n");
|
2009-07-27 19:05:15 +00:00
|
|
|
xhci_dbg_ctx(xhci, virt_dev->out_ctx,
|
2011-03-29 02:40:46 +00:00
|
|
|
LAST_CTX_TO_EP_NUM(le32_to_cpu(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
|
|
|
|
2011-05-13 01:06:37 +00:00
|
|
|
/* Free any rings that were dropped, but not changed. */
|
|
|
|
|
for (i = 1; i < 31; ++i) {
|
2011-06-01 03:01:07 +00:00
|
|
|
if ((le32_to_cpu(ctrl_ctx->drop_flags) & (1 << (i + 1))) &&
|
2013-10-03 22:29:45 +00:00
|
|
|
!(le32_to_cpu(ctrl_ctx->add_flags) & (1 << (i + 1)))) {
|
2011-05-13 01:06:37 +00:00
|
|
|
xhci_free_or_cache_endpoint_ring(xhci, virt_dev, i);
|
2013-10-03 22:29:45 +00:00
|
|
|
xhci_check_bw_drop_ep_streams(xhci, virt_dev, i);
|
|
|
|
|
}
|
2011-05-13 01:06:37 +00:00
|
|
|
}
|
2009-07-27 19:05:15 +00:00
|
|
|
xhci_zero_in_ctx(xhci, virt_dev);
|
2011-05-13 01:06:37 +00:00
|
|
|
/*
|
|
|
|
|
* Install any rings for completely new endpoints or changed endpoints,
|
|
|
|
|
* and free or cache any old rings from changed endpoints.
|
|
|
|
|
*/
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 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
|
|
|
}
|
2013-10-03 22:29:45 +00:00
|
|
|
xhci_check_bw_drop_ep_streams(xhci, virt_dev, i);
|
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
|
|
|
}
|
2014-05-08 16:26:00 +00:00
|
|
|
command_cleanup:
|
|
|
|
|
kfree(command->completion);
|
|
|
|
|
kfree(command);
|
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,
|
2013-04-24 00:11:14 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx,
|
2009-09-04 17:53:13 +00:00
|
|
|
u32 add_flags, u32 drop_flags)
|
2009-09-04 17:53:11 +00:00
|
|
|
{
|
2011-03-29 02:40:46 +00:00
|
|
|
ctrl_ctx->add_flags = cpu_to_le32(add_flags);
|
|
|
|
|
ctrl_ctx->drop_flags = cpu_to_le32(drop_flags);
|
2009-09-04 17:53:13 +00:00
|
|
|
xhci_slot_copy(xhci, in_ctx, out_ctx);
|
2011-03-29 02:40:46 +00:00
|
|
|
ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG);
|
2009-09-04 17:53:11 +00:00
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
2011-02-08 21:55:59 +00:00
|
|
|
static void xhci_setup_input_ctx_for_quirk(struct xhci_hcd *xhci,
|
2009-08-07 21:04:55 +00:00
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
|
|
|
|
struct xhci_dequeue_state *deq_state)
|
|
|
|
|
{
|
2013-04-24 00:11:14 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
2009-08-07 21:04:55 +00:00
|
|
|
struct xhci_container_ctx *in_ctx;
|
|
|
|
|
struct xhci_ep_ctx *ep_ctx;
|
|
|
|
|
u32 added_ctxs;
|
|
|
|
|
dma_addr_t addr;
|
|
|
|
|
|
2013-04-24 00:11:14 +00:00
|
|
|
in_ctx = xhci->devs[slot_id]->in_ctx;
|
|
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
|
|
|
|
|
if (!ctrl_ctx) {
|
|
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
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;
|
|
|
|
|
}
|
2011-03-29 02:40:46 +00:00
|
|
|
ep_ctx->deq = cpu_to_le64(addr | deq_state->new_cycle_state);
|
2009-08-07 21:04:55 +00:00
|
|
|
|
|
|
|
|
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,
|
2013-04-24 00:11:14 +00:00
|
|
|
xhci->devs[slot_id]->out_ctx, ctrl_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
|
|
|
|
2013-08-06 04:52:46 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep,
|
|
|
|
|
"Cleaning up stalled endpoint ring");
|
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)) {
|
2014-05-08 16:26:00 +00:00
|
|
|
struct xhci_command *command;
|
|
|
|
|
/* Can't sleep if we're called from cleanup_halted_endpoint() */
|
|
|
|
|
command = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
|
|
|
|
|
if (!command)
|
|
|
|
|
return;
|
2013-08-06 04:52:46 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep,
|
|
|
|
|
"Queueing new dequeue state");
|
2014-05-08 16:26:00 +00:00
|
|
|
xhci_queue_new_dequeue_state(xhci, command, 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
|
|
|
*/
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Setting up input context for "
|
|
|
|
|
"configure endpoint command");
|
2009-08-07 21:04:55 +00:00
|
|
|
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;
|
2014-05-08 16:26:00 +00:00
|
|
|
struct xhci_command *command;
|
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) {
|
2013-08-06 04:52:46 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep,
|
|
|
|
|
"Endpoint 0x%x not halted, refusing to reset.",
|
|
|
|
|
ep->desc.bEndpointAddress);
|
2009-07-27 19:05:21 +00:00
|
|
|
return;
|
|
|
|
|
}
|
2009-08-07 21:04:52 +00:00
|
|
|
if (usb_endpoint_xfer_control(&ep->desc)) {
|
2013-08-06 04:52:46 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep,
|
|
|
|
|
"Control endpoint stall already handled.");
|
2009-08-07 21:04:52 +00:00
|
|
|
return;
|
|
|
|
|
}
|
2009-07-27 19:03:15 +00:00
|
|
|
|
2014-05-08 16:26:00 +00:00
|
|
|
command = xhci_alloc_command(xhci, false, false, GFP_ATOMIC);
|
|
|
|
|
if (!command)
|
|
|
|
|
return;
|
|
|
|
|
|
2013-08-06 04:52:46 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep,
|
|
|
|
|
"Queueing reset endpoint command");
|
2009-07-27 19:03:15 +00:00
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
2014-05-08 16:26:00 +00:00
|
|
|
ret = xhci_queue_reset_ep(xhci, command, 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;
|
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;
|
2013-10-04 15:05:55 +00:00
|
|
|
if (usb_ss_max_streams(&ep->ss_ep_comp) == 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;
|
|
|
|
|
|
2012-01-02 11:35:41 +00:00
|
|
|
max_streams = usb_ss_max_streams(&eps[i]->ss_ep_comp);
|
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 "
|
2013-07-17 02:25:59 +00:00
|
|
|
"endpoint 0x%x, "
|
|
|
|
|
"streams are being disabled already\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
|
|
|
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 "
|
2013-07-17 02:25:59 +00:00
|
|
|
"endpoint 0x%x, "
|
|
|
|
|
"streams are already disabled!\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
|
|
|
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;
|
2013-04-24 00:11:14 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
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
|
|
|
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);
|
|
|
|
|
|
2013-11-15 11:14:38 +00:00
|
|
|
/* MaxPSASize value 0 (2 streams) means streams are not supported */
|
|
|
|
|
if (HCC_MAX_PSA(xhci->hcc_params) < 4) {
|
|
|
|
|
xhci_dbg(xhci, "xHCI controller does not support streams.\n");
|
|
|
|
|
return -ENOSYS;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
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;
|
|
|
|
|
}
|
2013-04-24 00:11:14 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, config_cmd->in_ctx);
|
|
|
|
|
if (!ctrl_ctx) {
|
|
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
|
|
|
|
xhci_free_command(xhci, config_cmd);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
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
|
|
|
|
|
|
|
|
/* 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];
|
2011-03-31 01:57:33 +00:00
|
|
|
/* Mark each endpoint as being in transition, so
|
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_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,
|
2013-04-24 00:11:14 +00:00
|
|
|
vdev->out_ctx, ctrl_ctx,
|
|
|
|
|
changed_ep_bitmask, changed_ep_bitmask);
|
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
|
|
|
|
|
|
|
|
/* 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;
|
2013-04-24 00:11:14 +00:00
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
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
|
|
|
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;
|
2013-04-24 00:11:14 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, command->in_ctx);
|
|
|
|
|
if (!ctrl_ctx) {
|
2013-06-25 22:49:36 +00:00
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
2013-04-24 00:11:14 +00:00
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
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,
|
2013-04-24 00:11:14 +00:00
|
|
|
vdev->out_ctx, ctrl_ctx,
|
|
|
|
|
changed_ep_bitmask, changed_ep_bitmask);
|
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
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
/*
|
|
|
|
|
* Deletes endpoint resources for endpoints that were active before a Reset
|
|
|
|
|
* Device command, or a Disable Slot command. The Reset Device command leaves
|
|
|
|
|
* the control endpoint intact, whereas the Disable Slot command deletes it.
|
|
|
|
|
*
|
|
|
|
|
* Must be called with xhci->lock held.
|
|
|
|
|
*/
|
|
|
|
|
void xhci_free_device_endpoint_resources(struct xhci_hcd *xhci,
|
|
|
|
|
struct xhci_virt_device *virt_dev, bool drop_control_ep)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
unsigned int num_dropped_eps = 0;
|
|
|
|
|
unsigned int drop_flags = 0;
|
|
|
|
|
|
|
|
|
|
for (i = (drop_control_ep ? 0 : 1); i < 31; i++) {
|
|
|
|
|
if (virt_dev->eps[i].ring) {
|
|
|
|
|
drop_flags |= 1 << i;
|
|
|
|
|
num_dropped_eps++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
xhci->num_active_eps -= num_dropped_eps;
|
|
|
|
|
if (num_dropped_eps)
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Dropped %u ep ctxs, flags = 0x%x, "
|
|
|
|
|
"%u now active.",
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
num_dropped_eps, drop_flags,
|
|
|
|
|
xhci->num_active_eps);
|
|
|
|
|
}
|
|
|
|
|
|
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 last_freed_endpoint;
|
2011-06-01 21:27:50 +00:00
|
|
|
struct xhci_slot_ctx *slot_ctx;
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
int old_active_eps = 0;
|
2009-12-09 23:59:13 +00:00
|
|
|
|
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
|
|
|
|
2011-06-01 21:27:50 +00:00
|
|
|
/* If device is not setup, there is no point in resetting it */
|
|
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->out_ctx);
|
|
|
|
|
if (GET_SLOT_STATE(le32_to_cpu(slot_ctx->dev_state)) ==
|
|
|
|
|
SLOT_STATE_DISABLED)
|
|
|
|
|
return 0;
|
|
|
|
|
|
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);
|
2010-11-18 00:26:50 +00:00
|
|
|
|
2014-05-08 16:26:00 +00:00
|
|
|
ret = xhci_queue_reset_device(xhci, reset_device_cmd, slot_id);
|
2009-12-09 23:59:13 +00:00
|
|
|
if (ret) {
|
|
|
|
|
xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
|
|
|
|
|
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 */
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 16:26:03 +00:00
|
|
|
wait_for_completion(reset_device_cmd->completion);
|
2009-12-09 23:59:13 +00:00
|
|
|
|
|
|
|
|
/* 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) {
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 16:26:03 +00:00
|
|
|
case COMP_CMD_ABORT:
|
|
|
|
|
case COMP_CMD_STOP:
|
|
|
|
|
xhci_warn(xhci, "Timeout waiting for reset device command\n");
|
|
|
|
|
ret = -ETIME;
|
|
|
|
|
goto command_cleanup;
|
2009-12-09 23:59:13 +00:00
|
|
|
case COMP_EBADSLT: /* 0.95 completion code for bad slot ID */
|
|
|
|
|
case COMP_CTX_STATE: /* 0.96 completion code for same thing */
|
2013-07-02 14:49:25 +00:00
|
|
|
xhci_dbg(xhci, "Can't reset device (slot ID %u) in %s state\n",
|
2009-12-09 23:59:13 +00:00
|
|
|
slot_id,
|
|
|
|
|
xhci_get_slot_state(xhci, virt_dev->out_ctx));
|
2013-07-02 14:49:25 +00:00
|
|
|
xhci_dbg(xhci, "Not freeing device rings.\n");
|
2009-12-09 23:59:13 +00:00
|
|
|
/* 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;
|
|
|
|
|
}
|
|
|
|
|
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
/* Free up host controller endpoint resources */
|
|
|
|
|
if ((xhci->quirks & XHCI_EP_LIMIT_QUIRK)) {
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
/* Don't delete the default control endpoint resources */
|
|
|
|
|
xhci_free_device_endpoint_resources(xhci, virt_dev, false);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-09 23:59:13 +00:00
|
|
|
/* Everything but endpoint 0 is disabled, so free or cache the rings. */
|
|
|
|
|
last_freed_endpoint = 1;
|
|
|
|
|
for (i = 1; i < 31; ++i) {
|
2011-04-13 06:06:28 +00:00
|
|
|
struct xhci_virt_ep *ep = &virt_dev->eps[i];
|
|
|
|
|
|
|
|
|
|
if (ep->ep_state & EP_HAS_STREAMS) {
|
2013-10-03 22:29:45 +00:00
|
|
|
xhci_warn(xhci, "WARN: endpoint 0x%02x has streams on device reset, freeing streams.\n",
|
|
|
|
|
xhci_get_endpoint_address(i));
|
2011-04-13 06:06:28 +00:00
|
|
|
xhci_free_stream_info(xhci, ep->stream_info);
|
|
|
|
|
ep->stream_info = NULL;
|
|
|
|
|
ep->ep_state &= ~EP_HAS_STREAMS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ep->ring) {
|
|
|
|
|
xhci_free_or_cache_endpoint_ring(xhci, virt_dev, i);
|
|
|
|
|
last_freed_endpoint = i;
|
|
|
|
|
}
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
if (!list_empty(&virt_dev->eps[i].bw_endpoint_list))
|
|
|
|
|
xhci_drop_ep_from_interval_table(xhci,
|
|
|
|
|
&virt_dev->eps[i].bw_info,
|
|
|
|
|
virt_dev->bw_table,
|
|
|
|
|
udev,
|
|
|
|
|
&virt_dev->eps[i],
|
|
|
|
|
virt_dev->tt_info);
|
2011-09-02 18:05:48 +00:00
|
|
|
xhci_clear_endpoint_bw_info(&virt_dev->eps[i].bw_info);
|
2009-12-09 23:59:13 +00:00
|
|
|
}
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:50 +00:00
|
|
|
/* If necessary, update the number of active TTs on this root port */
|
|
|
|
|
xhci_update_tt_active_eps(xhci, virt_dev, old_active_eps);
|
|
|
|
|
|
2009-12-09 23:59:13 +00:00
|
|
|
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;
|
2014-05-08 16:26:00 +00:00
|
|
|
struct xhci_command *command;
|
|
|
|
|
|
|
|
|
|
command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
|
|
|
|
|
if (!command)
|
|
|
|
|
return;
|
2009-04-28 02:57:38 +00:00
|
|
|
|
2013-08-19 17:36:13 +00:00
|
|
|
#ifndef CONFIG_USB_DEFAULT_PERSIST
|
|
|
|
|
/*
|
|
|
|
|
* We called pm_runtime_get_noresume when the device was attached.
|
|
|
|
|
* Decrement the counter here to allow controller to runtime suspend
|
|
|
|
|
* if no devices remain.
|
|
|
|
|
*/
|
|
|
|
|
if (xhci->quirks & XHCI_RESET_ON_RESUME)
|
2013-08-28 16:31:04 +00:00
|
|
|
pm_runtime_put_noidle(hcd->self.controller);
|
2013-08-19 17:36:13 +00:00
|
|
|
#endif
|
|
|
|
|
|
2010-10-14 14:22:45 +00:00
|
|
|
ret = xhci_check_args(hcd, udev, NULL, 0, true, __func__);
|
2011-07-01 20:35:40 +00:00
|
|
|
/* If the host is halted due to driver unload, we still need to free the
|
|
|
|
|
* device.
|
|
|
|
|
*/
|
2014-05-08 16:26:00 +00:00
|
|
|
if (ret <= 0 && ret != -ENODEV) {
|
|
|
|
|
kfree(command);
|
2009-04-28 02:57:38 +00:00
|
|
|
return;
|
2014-05-08 16:26:00 +00:00
|
|
|
}
|
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. */
|
2013-11-15 03:34:06 +00:00
|
|
|
state = readl(&xhci->op_regs->status);
|
2011-07-01 20:35:40 +00:00
|
|
|
if (state == 0xffffffff || (xhci->xhc_state & XHCI_STATE_DYING) ||
|
|
|
|
|
(xhci->xhc_state & XHCI_STATE_HALTED)) {
|
2009-09-16 23:42:39 +00:00
|
|
|
xhci_free_virt_device(xhci, udev->slot_id);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
2014-05-08 16:26:00 +00:00
|
|
|
kfree(command);
|
2009-09-16 23:42:39 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-08 16:26:00 +00:00
|
|
|
if (xhci_queue_slot_control(xhci, command, 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);
|
2014-05-08 16:26:00 +00:00
|
|
|
|
2009-04-28 02:57:38 +00:00
|
|
|
/*
|
|
|
|
|
* 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
|
|
|
*/
|
|
|
|
|
}
|
|
|
|
|
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
/*
|
|
|
|
|
* Checks if we have enough host controller resources for the default control
|
|
|
|
|
* endpoint.
|
|
|
|
|
*
|
|
|
|
|
* Must be called with xhci->lock held.
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_reserve_host_control_ep_resources(struct xhci_hcd *xhci)
|
|
|
|
|
{
|
|
|
|
|
if (xhci->num_active_eps + 1 > xhci->limit_active_eps) {
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Not enough ep ctxs: "
|
|
|
|
|
"%u active, need to add 1, limit is %u.",
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
xhci->num_active_eps, xhci->limit_active_eps);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
xhci->num_active_eps += 1;
|
2013-08-06 04:52:45 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
|
|
|
|
|
"Adding 1 ep ctx, %u now active.",
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
xhci->num_active_eps);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
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 ret;
|
2014-05-08 16:26:00 +00:00
|
|
|
struct xhci_command *command;
|
|
|
|
|
|
|
|
|
|
command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
|
|
|
|
|
if (!command)
|
|
|
|
|
return 0;
|
2009-04-28 02:57:38 +00:00
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
2014-05-08 16:26:00 +00:00
|
|
|
command->completion = &xhci->addr_dev;
|
|
|
|
|
ret = xhci_queue_slot_control(xhci, command, 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");
|
2014-05-08 16:26:00 +00:00
|
|
|
kfree(command);
|
2009-04-28 02:57:38 +00:00
|
|
|
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);
|
|
|
|
|
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 16:26:03 +00:00
|
|
|
wait_for_completion(command->completion);
|
2009-04-28 02:57:38 +00:00
|
|
|
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 16:26:03 +00:00
|
|
|
if (!xhci->slot_id || command->status != COMP_SUCCESS) {
|
2009-04-28 02:57:38 +00:00
|
|
|
xhci_err(xhci, "Error while assigning device slot ID\n");
|
2014-05-08 16:25:59 +00:00
|
|
|
xhci_err(xhci, "Max number of devices this xHCI host supports is %u.\n",
|
|
|
|
|
HCS_MAX_SLOTS(
|
|
|
|
|
readl(&xhci->cap_regs->hcs_params1)));
|
2014-05-08 16:26:00 +00:00
|
|
|
kfree(command);
|
2009-04-28 02:57:38 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
|
|
|
|
|
if ((xhci->quirks & XHCI_EP_LIMIT_QUIRK)) {
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
ret = xhci_reserve_host_control_ep_resources(xhci);
|
|
|
|
|
if (ret) {
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
xhci_warn(xhci, "Not enough host resources, "
|
|
|
|
|
"active endpoint contexts = %u\n",
|
|
|
|
|
xhci->num_active_eps);
|
|
|
|
|
goto disable_slot;
|
|
|
|
|
}
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
}
|
|
|
|
|
/* Use GFP_NOIO, since this function can be called from
|
2010-12-28 21:08:42 +00:00
|
|
|
* xhci_discover_or_reset_device(), which may be called as part of
|
|
|
|
|
* mass storage driver error handling.
|
|
|
|
|
*/
|
|
|
|
|
if (!xhci_alloc_virt_device(xhci, xhci->slot_id, udev, GFP_NOIO)) {
|
2009-04-28 02:57:38 +00:00
|
|
|
xhci_warn(xhci, "Could not allocate xHCI USB device data structures\n");
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
goto disable_slot;
|
2009-04-28 02:57:38 +00:00
|
|
|
}
|
|
|
|
|
udev->slot_id = xhci->slot_id;
|
2013-08-19 17:36:13 +00:00
|
|
|
|
|
|
|
|
#ifndef CONFIG_USB_DEFAULT_PERSIST
|
|
|
|
|
/*
|
|
|
|
|
* If resetting upon resume, we can't put the controller into runtime
|
|
|
|
|
* suspend if there is a device attached.
|
|
|
|
|
*/
|
|
|
|
|
if (xhci->quirks & XHCI_RESET_ON_RESUME)
|
2013-08-28 16:31:04 +00:00
|
|
|
pm_runtime_get_noresume(hcd->self.controller);
|
2013-08-19 17:36:13 +00:00
|
|
|
#endif
|
|
|
|
|
|
2014-05-08 16:26:00 +00:00
|
|
|
|
|
|
|
|
kfree(command);
|
2009-04-28 02:57:38 +00:00
|
|
|
/* Is this a LS or FS device under a HS hub? */
|
|
|
|
|
/* Hub or peripherial? */
|
|
|
|
|
return 1;
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
|
|
|
|
|
disable_slot:
|
|
|
|
|
/* Disable slot, if we can do it without mem alloc */
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
2014-05-08 16:26:00 +00:00
|
|
|
command->completion = NULL;
|
|
|
|
|
command->status = 0;
|
|
|
|
|
if (!xhci_queue_slot_control(xhci, command, TRB_DISABLE_SLOT,
|
|
|
|
|
udev->slot_id))
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-11 23:14:58 +00:00
|
|
|
xhci_ring_cmd_db(xhci);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return 0;
|
2009-04-28 02:57:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2013-12-06 01:07:27 +00:00
|
|
|
* Issue an Address Device command and optionally send a corresponding
|
|
|
|
|
* SetAddress request to the device.
|
2009-04-28 02:57:38 +00:00
|
|
|
* 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.
|
|
|
|
|
*/
|
2013-12-06 01:07:27 +00:00
|
|
|
static int xhci_setup_device(struct usb_hcd *hcd, struct usb_device *udev,
|
|
|
|
|
enum xhci_setup_dev setup)
|
2009-04-28 02:57:38 +00:00
|
|
|
{
|
2013-11-22 09:20:01 +00:00
|
|
|
const char *act = setup == SETUP_CONTEXT_ONLY ? "context" : "address";
|
2009-04-28 02:57:38 +00:00
|
|
|
unsigned long flags;
|
|
|
|
|
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;
|
2014-05-08 16:26:00 +00:00
|
|
|
struct xhci_command *command;
|
2009-04-28 02:57:38 +00:00
|
|
|
|
|
|
|
|
if (!udev->slot_id) {
|
2013-08-05 21:22:15 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_address,
|
|
|
|
|
"Bad Slot ID %d", udev->slot_id);
|
2009-04-28 02:57:38 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
virt_dev = xhci->devs[udev->slot_id];
|
|
|
|
|
|
2011-03-29 02:40:56 +00:00
|
|
|
if (WARN_ON(!virt_dev)) {
|
|
|
|
|
/*
|
|
|
|
|
* In plug/unplug torture test with an NEC controller,
|
|
|
|
|
* a zero-dereference was observed once due to virt_dev = 0.
|
|
|
|
|
* Print useful debug rather than crash if it is observed again!
|
|
|
|
|
*/
|
|
|
|
|
xhci_warn(xhci, "Virt dev invalid for slot_id 0x%x!\n",
|
|
|
|
|
udev->slot_id);
|
|
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-08 16:26:00 +00:00
|
|
|
command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
|
|
|
|
|
if (!command)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
|
|
command->in_ctx = virt_dev->in_ctx;
|
|
|
|
|
command->completion = &xhci->addr_dev;
|
|
|
|
|
|
2010-10-14 14:22:48 +00:00
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->in_ctx);
|
2013-04-24 00:11:14 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, virt_dev->in_ctx);
|
|
|
|
|
if (!ctrl_ctx) {
|
|
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
2014-05-08 16:26:00 +00:00
|
|
|
kfree(command);
|
2013-04-24 00:11:14 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
2010-10-14 14:22:48 +00:00
|
|
|
/*
|
|
|
|
|
* 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);
|
2011-11-03 20:06:08 +00:00
|
|
|
ctrl_ctx->add_flags = cpu_to_le32(SLOT_FLAG | EP0_FLAG);
|
|
|
|
|
ctrl_ctx->drop_flags = 0;
|
|
|
|
|
|
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);
|
xhci: add xhci_address_ctx trace event
This patch defines a new event class, called xhci_log_ctx,
that records in the ring buffer the context data, the
context type (input or output), the context dma and virtual
addresses, the context endpoint entries, the slot ID and
whether the xHC uses 64 byte context data structures.
This information can be used, later, to parse and display
the context data fields with the appropriate plugin using
the trace-cmd tool.
Also, this patch defines a trace event, called xhci_address_ctx,
to trace the contexts related to the Address Device command and
adds the associated tracepoints in xhci_address_device().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-06 04:52:47 +00:00
|
|
|
trace_xhci_address_ctx(xhci, virt_dev->in_ctx,
|
2013-11-15 01:18:07 +00:00
|
|
|
le32_to_cpu(slot_ctx->dev_info) >> 27);
|
2009-04-28 02:57:38 +00:00
|
|
|
|
2009-05-14 18:44:22 +00:00
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
2014-05-08 16:26:00 +00:00
|
|
|
ret = xhci_queue_address_device(xhci, command, virt_dev->in_ctx->dma,
|
2013-12-06 01:07:27 +00:00
|
|
|
udev->slot_id, setup);
|
2009-04-28 02:57:38 +00:00
|
|
|
if (ret) {
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
2013-08-05 21:22:15 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_address,
|
|
|
|
|
"FIXME: allocate a command ring segment");
|
2014-05-08 16:26:00 +00:00
|
|
|
kfree(command);
|
2009-04-28 02:57:38 +00:00
|
|
|
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? */
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 16:26:03 +00:00
|
|
|
wait_for_completion(command->completion);
|
|
|
|
|
|
2009-04-28 02:57:38 +00:00
|
|
|
/* 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.
|
|
|
|
|
*/
|
2014-05-08 16:26:02 +00:00
|
|
|
switch (command->status) {
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-08 16:26:03 +00:00
|
|
|
case COMP_CMD_ABORT:
|
|
|
|
|
case COMP_CMD_STOP:
|
|
|
|
|
xhci_warn(xhci, "Timeout while waiting for setup device command\n");
|
|
|
|
|
ret = -ETIME;
|
|
|
|
|
break;
|
2009-04-28 02:57:38 +00:00
|
|
|
case COMP_CTX_STATE:
|
|
|
|
|
case COMP_EBADSLT:
|
2013-11-22 09:20:01 +00:00
|
|
|
xhci_err(xhci, "Setup ERROR: setup %s command for slot %d.\n",
|
|
|
|
|
act, udev->slot_id);
|
2009-04-28 02:57:38 +00:00
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
case COMP_TX_ERR:
|
2013-11-22 09:20:01 +00:00
|
|
|
dev_warn(&udev->dev, "Device not responding to setup %s.\n", act);
|
2009-04-28 02:57:38 +00:00
|
|
|
ret = -EPROTO;
|
|
|
|
|
break;
|
2011-06-08 10:34:06 +00:00
|
|
|
case COMP_DEV_ERR:
|
2013-11-22 09:20:01 +00:00
|
|
|
dev_warn(&udev->dev,
|
|
|
|
|
"ERROR: Incompatible device for setup %s command\n", act);
|
2011-06-08 10:34:06 +00:00
|
|
|
ret = -ENODEV;
|
|
|
|
|
break;
|
2009-04-28 02:57:38 +00:00
|
|
|
case COMP_SUCCESS:
|
2013-08-05 21:22:15 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_address,
|
2013-11-22 09:20:01 +00:00
|
|
|
"Successful setup %s command", act);
|
2009-04-28 02:57:38 +00:00
|
|
|
break;
|
|
|
|
|
default:
|
2013-11-22 09:20:01 +00:00
|
|
|
xhci_err(xhci,
|
|
|
|
|
"ERROR: unexpected setup %s command completion code 0x%x.\n",
|
2014-05-08 16:26:02 +00:00
|
|
|
act, command->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);
|
xhci: add xhci_address_ctx trace event
This patch defines a new event class, called xhci_log_ctx,
that records in the ring buffer the context data, the
context type (input or output), the context dma and virtual
addresses, the context endpoint entries, the slot ID and
whether the xHC uses 64 byte context data structures.
This information can be used, later, to parse and display
the context data fields with the appropriate plugin using
the trace-cmd tool.
Also, this patch defines a trace event, called xhci_address_ctx,
to trace the contexts related to the Address Device command and
adds the associated tracepoints in xhci_address_device().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-06 04:52:47 +00:00
|
|
|
trace_xhci_address_ctx(xhci, virt_dev->out_ctx, 1);
|
2009-04-28 02:57:38 +00:00
|
|
|
ret = -EINVAL;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
if (ret) {
|
2014-05-08 16:26:00 +00:00
|
|
|
kfree(command);
|
2009-04-28 02:57:38 +00:00
|
|
|
return ret;
|
|
|
|
|
}
|
2014-01-30 21:27:49 +00:00
|
|
|
temp_64 = xhci_read_64(xhci, &xhci->op_regs->dcbaa_ptr);
|
2013-08-05 21:22:15 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_address,
|
|
|
|
|
"Op regs DCBAA ptr = %#016llx", temp_64);
|
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_address,
|
|
|
|
|
"Slot ID %d dcbaa entry @%p = %#016llx",
|
|
|
|
|
udev->slot_id,
|
|
|
|
|
&xhci->dcbaa->dev_context_ptrs[udev->slot_id],
|
|
|
|
|
(unsigned long long)
|
|
|
|
|
le64_to_cpu(xhci->dcbaa->dev_context_ptrs[udev->slot_id]));
|
|
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_address,
|
|
|
|
|
"Output Context DMA address = %#08llx",
|
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);
|
xhci: add xhci_address_ctx trace event
This patch defines a new event class, called xhci_log_ctx,
that records in the ring buffer the context data, the
context type (input or output), the context dma and virtual
addresses, the context endpoint entries, the slot ID and
whether the xHC uses 64 byte context data structures.
This information can be used, later, to parse and display
the context data fields with the appropriate plugin using
the trace-cmd tool.
Also, this patch defines a trace event, called xhci_address_ctx,
to trace the contexts related to the Address Device command and
adds the associated tracepoints in xhci_address_device().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-06 04:52:47 +00:00
|
|
|
trace_xhci_address_ctx(xhci, virt_dev->in_ctx,
|
2013-11-15 01:18:07 +00:00
|
|
|
le32_to_cpu(slot_ctx->dev_info) >> 27);
|
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);
|
xhci: add xhci_address_ctx trace event
This patch defines a new event class, called xhci_log_ctx,
that records in the ring buffer the context data, the
context type (input or output), the context dma and virtual
addresses, the context endpoint entries, the slot ID and
whether the xHC uses 64 byte context data structures.
This information can be used, later, to parse and display
the context data fields with the appropriate plugin using
the trace-cmd tool.
Also, this patch defines a trace event, called xhci_address_ctx,
to trace the contexts related to the Address Device command and
adds the associated tracepoints in xhci_address_device().
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-06 04:52:47 +00:00
|
|
|
trace_xhci_address_ctx(xhci, virt_dev->out_ctx,
|
2013-11-15 01:18:07 +00:00
|
|
|
le32_to_cpu(slot_ctx->dev_info) >> 27);
|
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->add_flags = 0;
|
|
|
|
|
ctrl_ctx->drop_flags = 0;
|
2009-04-28 02:57:38 +00:00
|
|
|
|
2013-08-05 21:22:15 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_address,
|
2013-10-16 19:25:44 +00:00
|
|
|
"Internal device address = %d",
|
|
|
|
|
le32_to_cpu(slot_ctx->dev_state) & DEV_ADDR_MASK);
|
2014-05-08 16:26:00 +00:00
|
|
|
kfree(command);
|
2009-04-28 02:57:38 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-06 01:07:27 +00:00
|
|
|
int xhci_address_device(struct usb_hcd *hcd, struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
return xhci_setup_device(hcd, udev, SETUP_CONTEXT_ADDRESS);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int xhci_enable_device(struct usb_hcd *hcd, struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
return xhci_setup_device(hcd, udev, SETUP_CONTEXT_ONLY);
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-19 08:48:12 +00:00
|
|
|
/*
|
|
|
|
|
* Transfer the port index into real index in the HW port status
|
|
|
|
|
* registers. Caculate offset between the port's PORTSC register
|
|
|
|
|
* and port status base. Divide the number of per port register
|
|
|
|
|
* to get the real index. The raw port number bases 1.
|
|
|
|
|
*/
|
|
|
|
|
int xhci_find_raw_port_number(struct usb_hcd *hcd, int port1)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
__le32 __iomem *base_addr = &xhci->op_regs->port_status_base;
|
|
|
|
|
__le32 __iomem *addr;
|
|
|
|
|
int raw_port;
|
|
|
|
|
|
|
|
|
|
if (hcd->speed != HCD_USB3)
|
|
|
|
|
addr = xhci->usb2_ports[port1 - 1];
|
|
|
|
|
else
|
|
|
|
|
addr = xhci->usb3_ports[port1 - 1];
|
|
|
|
|
|
|
|
|
|
raw_port = (addr - base_addr)/NUM_PORT_REGS + 1;
|
|
|
|
|
return raw_port;
|
|
|
|
|
}
|
|
|
|
|
|
2013-05-23 14:14:30 +00:00
|
|
|
/*
|
|
|
|
|
* Issue an Evaluate Context command to change the Maximum Exit Latency in the
|
|
|
|
|
* slot context. If that succeeds, store the new MEL in the xhci_virt_device.
|
|
|
|
|
*/
|
2013-07-23 18:58:20 +00:00
|
|
|
static int __maybe_unused xhci_change_max_exit_latency(struct xhci_hcd *xhci,
|
2013-05-23 14:14:30 +00:00
|
|
|
struct usb_device *udev, u16 max_exit_latency)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_virt_device *virt_dev;
|
|
|
|
|
struct xhci_command *command;
|
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx;
|
|
|
|
|
struct xhci_slot_ctx *slot_ctx;
|
|
|
|
|
unsigned long flags;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
if (max_exit_latency == xhci->devs[udev->slot_id]->current_mel) {
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Attempt to issue an Evaluate Context command to change the MEL. */
|
|
|
|
|
virt_dev = xhci->devs[udev->slot_id];
|
|
|
|
|
command = xhci->lpm_command;
|
2013-04-24 00:11:14 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, command->in_ctx);
|
|
|
|
|
if (!ctrl_ctx) {
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
2013-05-23 14:14:30 +00:00
|
|
|
xhci_slot_copy(xhci, command->in_ctx, virt_dev->out_ctx);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG);
|
|
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx);
|
|
|
|
|
slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT));
|
|
|
|
|
slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency);
|
|
|
|
|
|
2013-07-31 04:35:27 +00:00
|
|
|
xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
|
|
|
|
|
"Set up evaluate context for LPM MEL change.");
|
2013-05-23 14:14:30 +00:00
|
|
|
xhci_dbg(xhci, "Slot %u Input Context:\n", udev->slot_id);
|
|
|
|
|
xhci_dbg_ctx(xhci, command->in_ctx, 0);
|
|
|
|
|
|
|
|
|
|
/* Issue and wait for the evaluate context command. */
|
|
|
|
|
ret = xhci_configure_endpoint(xhci, udev, command,
|
|
|
|
|
true, true);
|
|
|
|
|
xhci_dbg(xhci, "Slot %u Output Context:\n", udev->slot_id);
|
|
|
|
|
xhci_dbg_ctx(xhci, virt_dev->out_ctx, 0);
|
|
|
|
|
|
|
|
|
|
if (!ret) {
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
virt_dev->current_mel = max_exit_latency;
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
}
|
|
|
|
|
return ret;
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-27 20:14:46 +00:00
|
|
|
#ifdef CONFIG_PM_RUNTIME
|
2011-09-23 21:19:51 +00:00
|
|
|
|
|
|
|
|
/* BESL to HIRD Encoding array for USB2 LPM */
|
|
|
|
|
static int xhci_besl_encoding[16] = {125, 150, 200, 300, 400, 500, 1000, 2000,
|
|
|
|
|
3000, 4000, 5000, 6000, 7000, 8000, 9000, 10000};
|
|
|
|
|
|
|
|
|
|
/* Calculate HIRD/BESL for USB2 PORTPMSC*/
|
2011-12-12 08:45:28 +00:00
|
|
|
static int xhci_calculate_hird_besl(struct xhci_hcd *xhci,
|
|
|
|
|
struct usb_device *udev)
|
2011-09-23 21:19:51 +00:00
|
|
|
{
|
2011-12-12 08:45:28 +00:00
|
|
|
int u2del, besl, besl_host;
|
|
|
|
|
int besl_device = 0;
|
|
|
|
|
u32 field;
|
|
|
|
|
|
|
|
|
|
u2del = HCS_U2_LATENCY(xhci->hcs_params3);
|
|
|
|
|
field = le32_to_cpu(udev->bos->ext_cap->bmAttributes);
|
2011-09-23 21:19:51 +00:00
|
|
|
|
2011-12-12 08:45:28 +00:00
|
|
|
if (field & USB_BESL_SUPPORT) {
|
|
|
|
|
for (besl_host = 0; besl_host < 16; besl_host++) {
|
|
|
|
|
if (xhci_besl_encoding[besl_host] >= u2del)
|
2011-09-23 21:19:51 +00:00
|
|
|
break;
|
|
|
|
|
}
|
2011-12-12 08:45:28 +00:00
|
|
|
/* Use baseline BESL value as default */
|
|
|
|
|
if (field & USB_BESL_BASELINE_VALID)
|
|
|
|
|
besl_device = USB_GET_BESL_BASELINE(field);
|
|
|
|
|
else if (field & USB_BESL_DEEP_VALID)
|
|
|
|
|
besl_device = USB_GET_BESL_DEEP(field);
|
2011-09-23 21:19:51 +00:00
|
|
|
} else {
|
|
|
|
|
if (u2del <= 50)
|
2011-12-12 08:45:28 +00:00
|
|
|
besl_host = 0;
|
2011-09-23 21:19:51 +00:00
|
|
|
else
|
2011-12-12 08:45:28 +00:00
|
|
|
besl_host = (u2del - 51) / 75 + 1;
|
2011-09-23 21:19:51 +00:00
|
|
|
}
|
|
|
|
|
|
2011-12-12 08:45:28 +00:00
|
|
|
besl = besl_host + besl_device;
|
|
|
|
|
if (besl > 15)
|
|
|
|
|
besl = 15;
|
|
|
|
|
|
|
|
|
|
return besl;
|
2011-09-23 21:19:51 +00:00
|
|
|
}
|
|
|
|
|
|
2013-05-23 14:14:30 +00:00
|
|
|
/* Calculate BESLD, L1 timeout and HIRDM for USB2 PORTHLPMC */
|
|
|
|
|
static int xhci_calculate_usb2_hw_lpm_params(struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
u32 field;
|
|
|
|
|
int l1;
|
|
|
|
|
int besld = 0;
|
|
|
|
|
int hirdm = 0;
|
|
|
|
|
|
|
|
|
|
field = le32_to_cpu(udev->bos->ext_cap->bmAttributes);
|
|
|
|
|
|
|
|
|
|
/* xHCI l1 is set in steps of 256us, xHCI 1.0 section 5.4.11.2 */
|
2013-05-23 14:14:31 +00:00
|
|
|
l1 = udev->l1_params.timeout / 256;
|
2013-05-23 14:14:30 +00:00
|
|
|
|
|
|
|
|
/* device has preferred BESLD */
|
|
|
|
|
if (field & USB_BESL_DEEP_VALID) {
|
|
|
|
|
besld = USB_GET_BESL_DEEP(field);
|
|
|
|
|
hirdm = 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return PORT_BESLD(besld) | PORT_L1_TIMEOUT(l1) | PORT_HIRDM(hirdm);
|
|
|
|
|
}
|
|
|
|
|
|
2011-09-23 21:19:52 +00:00
|
|
|
int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
|
|
|
|
|
struct usb_device *udev, int enable)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
__le32 __iomem **port_array;
|
2013-05-23 14:14:30 +00:00
|
|
|
__le32 __iomem *pm_addr, *hlpm_addr;
|
|
|
|
|
u32 pm_val, hlpm_val, field;
|
2011-09-23 21:19:52 +00:00
|
|
|
unsigned int port_num;
|
|
|
|
|
unsigned long flags;
|
2013-05-23 14:14:30 +00:00
|
|
|
int hird, exit_latency;
|
|
|
|
|
int ret;
|
2011-09-23 21:19:52 +00:00
|
|
|
|
|
|
|
|
if (hcd->speed == HCD_USB3 || !xhci->hw_lpm_support ||
|
|
|
|
|
!udev->lpm_capable)
|
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
|
|
if (!udev->parent || udev->parent->parent ||
|
|
|
|
|
udev->descriptor.bDeviceClass == USB_CLASS_HUB)
|
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
|
|
if (udev->usb2_hw_lpm_capable != 1)
|
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
port_array = xhci->usb2_ports;
|
|
|
|
|
port_num = udev->portnum - 1;
|
2013-05-23 14:14:29 +00:00
|
|
|
pm_addr = port_array[port_num] + PORTPMSC;
|
2013-11-15 03:34:06 +00:00
|
|
|
pm_val = readl(pm_addr);
|
2013-05-23 14:14:30 +00:00
|
|
|
hlpm_addr = port_array[port_num] + PORTHLPMC;
|
|
|
|
|
field = le32_to_cpu(udev->bos->ext_cap->bmAttributes);
|
2011-09-23 21:19:52 +00:00
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
|
2014-05-08 16:25:54 +00:00
|
|
|
enable ? "enable" : "disable", port_num + 1);
|
2011-09-23 21:19:52 +00:00
|
|
|
|
|
|
|
|
if (enable) {
|
2013-05-23 14:14:30 +00:00
|
|
|
/* Host supports BESL timeout instead of HIRD */
|
|
|
|
|
if (udev->usb2_hw_lpm_besl_capable) {
|
|
|
|
|
/* if device doesn't have a preferred BESL value use a
|
|
|
|
|
* default one which works with mixed HIRD and BESL
|
|
|
|
|
* systems. See XHCI_DEFAULT_BESL definition in xhci.h
|
|
|
|
|
*/
|
|
|
|
|
if ((field & USB_BESL_SUPPORT) &&
|
|
|
|
|
(field & USB_BESL_BASELINE_VALID))
|
|
|
|
|
hird = USB_GET_BESL_BASELINE(field);
|
|
|
|
|
else
|
2013-05-23 14:14:31 +00:00
|
|
|
hird = udev->l1_params.besl;
|
2013-05-23 14:14:30 +00:00
|
|
|
|
|
|
|
|
exit_latency = xhci_besl_encoding[hird];
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
/* USB 3.0 code dedicate one xhci->lpm_command->in_ctx
|
|
|
|
|
* input context for link powermanagement evaluate
|
|
|
|
|
* context commands. It is protected by hcd->bandwidth
|
|
|
|
|
* mutex and is shared by all devices. We need to set
|
|
|
|
|
* the max ext latency in USB 2 BESL LPM as well, so
|
|
|
|
|
* use the same mutex and xhci_change_max_exit_latency()
|
|
|
|
|
*/
|
|
|
|
|
mutex_lock(hcd->bandwidth_mutex);
|
|
|
|
|
ret = xhci_change_max_exit_latency(xhci, udev,
|
|
|
|
|
exit_latency);
|
|
|
|
|
mutex_unlock(hcd->bandwidth_mutex);
|
|
|
|
|
|
|
|
|
|
if (ret < 0)
|
|
|
|
|
return ret;
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
|
|
|
|
|
|
|
|
|
hlpm_val = xhci_calculate_usb2_hw_lpm_params(udev);
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(hlpm_val, hlpm_addr);
|
2013-05-23 14:14:30 +00:00
|
|
|
/* flush write */
|
2013-11-15 03:34:06 +00:00
|
|
|
readl(hlpm_addr);
|
2013-05-23 14:14:30 +00:00
|
|
|
} else {
|
|
|
|
|
hird = xhci_calculate_hird_besl(xhci, udev);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pm_val &= ~PORT_HIRD_MASK;
|
2013-10-08 00:17:20 +00:00
|
|
|
pm_val |= PORT_HIRD(hird) | PORT_RWE | PORT_L1DS(udev->slot_id);
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(pm_val, pm_addr);
|
2013-11-15 03:34:06 +00:00
|
|
|
pm_val = readl(pm_addr);
|
2013-05-23 14:14:30 +00:00
|
|
|
pm_val |= PORT_HLE;
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(pm_val, pm_addr);
|
2013-05-23 14:14:30 +00:00
|
|
|
/* flush write */
|
2013-11-15 03:34:06 +00:00
|
|
|
readl(pm_addr);
|
2011-09-23 21:19:52 +00:00
|
|
|
} else {
|
2013-10-08 00:17:20 +00:00
|
|
|
pm_val &= ~(PORT_HLE | PORT_RWE | PORT_HIRD_MASK | PORT_L1DS_MASK);
|
2013-11-15 03:34:07 +00:00
|
|
|
writel(pm_val, pm_addr);
|
2013-05-23 14:14:30 +00:00
|
|
|
/* flush write */
|
2013-11-15 03:34:06 +00:00
|
|
|
readl(pm_addr);
|
2013-05-23 14:14:30 +00:00
|
|
|
if (udev->usb2_hw_lpm_besl_capable) {
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
mutex_lock(hcd->bandwidth_mutex);
|
|
|
|
|
xhci_change_max_exit_latency(xhci, udev, 0);
|
|
|
|
|
mutex_unlock(hcd->bandwidth_mutex);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2011-09-23 21:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2013-05-23 14:14:28 +00:00
|
|
|
/* check if a usb2 port supports a given extened capability protocol
|
|
|
|
|
* only USB2 ports extended protocol capability values are cached.
|
|
|
|
|
* Return 1 if capability is supported
|
|
|
|
|
*/
|
|
|
|
|
static int xhci_check_usb2_port_capability(struct xhci_hcd *xhci, int port,
|
|
|
|
|
unsigned capability)
|
|
|
|
|
{
|
|
|
|
|
u32 port_offset, port_count;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < xhci->num_ext_caps; i++) {
|
|
|
|
|
if (xhci->ext_caps[i] & capability) {
|
|
|
|
|
/* port offsets starts at 1 */
|
|
|
|
|
port_offset = XHCI_EXT_PORT_OFF(xhci->ext_caps[i]) - 1;
|
|
|
|
|
port_count = XHCI_EXT_PORT_COUNT(xhci->ext_caps[i]);
|
|
|
|
|
if (port >= port_offset &&
|
|
|
|
|
port < port_offset + port_count)
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-21 14:54:42 +00:00
|
|
|
int xhci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
2013-05-23 14:14:28 +00:00
|
|
|
int portnum = udev->portnum - 1;
|
2012-05-21 14:54:42 +00:00
|
|
|
|
usb: Don't enable USB 2.0 Link PM by default.
How it's supposed to work:
--------------------------
USB 2.0 Link PM is a lower power state that some newer USB 2.0 devices
support. USB 3.0 devices certified by the USB-IF are required to
support it if they are plugged into a USB 2.0 only port, or a USB 2.0
cable is used. USB 2.0 Link PM requires both a USB device and a host
controller that supports USB 2.0 hardware-enabled LPM.
USB 2.0 Link PM is designed to be enabled once by software, and the host
hardware handles transitions to the L1 state automatically. The premise
of USB 2.0 Link PM is to be able to put the device into a lower power
link state when the bus is idle or the device NAKs USB IN transfers for
a specified amount of time.
...but hardware is broken:
--------------------------
It turns out many USB 3.0 devices claim to support USB 2.0 Link PM (by
setting the LPM bit in their USB 2.0 BOS descriptor), but they don't
actually implement it correctly. This manifests as the USB device
refusing to respond to transfers when it is plugged into a USB 2.0 only
port under the Haswell-ULT/Lynx Point LP xHCI host.
These devices pass the xHCI driver's simple test to enable USB 2.0 Link
PM, wait for the port to enter L1, and then bring it back into L0. They
only start to break when L1 entry is interleaved with transfers.
Some devices then fail to respond to the next control transfer (usually
a Set Configuration). This results in devices never enumerating.
Other mass storage devices (such as a later model Western Digital My
Passport USB 3.0 hard drive) respond fine to going into L1 between
control transfers. They ACK the entry, come out of L1 when the host
needs to send a control transfer, and respond properly to those control
transfers. However, when the first READ10 SCSI command is sent, the
device NAKs the data phase while it's reading from the spinning disk.
Eventually, the host requests to put the link into L1, and the device
ACKs that request. Then it never responds to the data phase of the
READ10 command. This results in not being able to read from the drive.
Some mass storage devices (like the Corsair Survivor USB 3.0 flash
drive) are well behaved. They ACK the entry into L1 during control
transfers, and when SCSI commands start coming in, they NAK the requests
to go into L1, because they need to be at full power.
Not all USB 3.0 devices advertise USB 2.0 link PM support. My Point
Grey USB 3.0 webcam advertises itself as a USB 2.1 device, but doesn't
have a USB 2.0 BOS descriptor, so we don't enable USB 2.0 Link PM. I
suspect that means the device isn't certified.
What do we do about it?
-----------------------
There's really no good way for the kernel to test these devices.
Therefore, the kernel needs to disable USB 2.0 Link PM by default, and
distros will have to enable it by writing 1 to the sysfs file
/sys/bus/usb/devices/../power/usb2_hardware_lpm. Rip out the xHCI Link
PM test, since it's not sufficient to detect these buggy devices, and
don't automatically enable LPM after the device is addressed.
This patch should be backported to kernels as old as 3.11, that
contain the commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09 "usb: xhci:
add USB2 Link power management BESL support". Without this fix, some
USB 3.0 devices will not enumerate or work properly under USB 2.0 ports
on Haswell-ULT systems.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2013-09-30 14:26:28 +00:00
|
|
|
if (hcd->speed == HCD_USB3 || !xhci->sw_lpm_support ||
|
|
|
|
|
!udev->lpm_capable)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* we only support lpm for non-hub device connected to root hub yet */
|
|
|
|
|
if (!udev->parent || udev->parent->parent ||
|
|
|
|
|
udev->descriptor.bDeviceClass == USB_CLASS_HUB)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
if (xhci->hw_lpm_support == 1 &&
|
|
|
|
|
xhci_check_usb2_port_capability(
|
|
|
|
|
xhci, portnum, XHCI_HLC)) {
|
|
|
|
|
udev->usb2_hw_lpm_capable = 1;
|
|
|
|
|
udev->l1_params.timeout = XHCI_L1_TIMEOUT;
|
|
|
|
|
udev->l1_params.besl = XHCI_DEFAULT_BESL;
|
|
|
|
|
if (xhci_check_usb2_port_capability(xhci, portnum,
|
|
|
|
|
XHCI_BLC))
|
|
|
|
|
udev->usb2_hw_lpm_besl_capable = 1;
|
2012-05-21 14:54:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
|
|
int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
|
|
|
|
|
struct usb_device *udev, int enable)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int xhci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-27 20:14:46 +00:00
|
|
|
#endif /* CONFIG_PM_RUNTIME */
|
2012-05-21 14:54:42 +00:00
|
|
|
|
xhci: Add infrastructure for host-specific LPM policies.
The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific. Here are a few examples of why it's
host specific:
1. Setting the U1/U2 timeout too short may cause the link to go into
U1/U2 in between service intervals, which some hosts may tolerate,
and some may not.
2. The host controller has to modify its bus schedule in order to take
into account the Maximum Exit Latency (MEL) to bring all the links
from the host to the device into U0. If the MEL is too big, and it
takes too long to bring the links into an active state, the host
controller may not be able to service periodic endpoints in time.
3. Host controllers may also have scheduling limitations that force
them to disable U1 or U2 if a USB device is behind too many tiers of
hubs.
We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller. However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands. Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.
Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.
To extend the framework, they will need to:
- Modify the PCI init code to add a new xhci->quirk for their host, and
set the XHCI_LPM_SUPPORT quirk flag.
- Add their own vendor-specific hooks, like the ones that will be added
in xhci_call_host_update_timeout_for_endpoint() and
xhci_check_tier_policy()
- Make the LPM enable/disable methods call those functions based on the
xhci->quirk for their host.
An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 17:55:03 +00:00
|
|
|
/*---------------------- USB 3.0 Link PM functions ------------------------*/
|
|
|
|
|
|
2012-05-21 14:54:42 +00:00
|
|
|
#ifdef CONFIG_PM
|
2012-05-16 20:36:24 +00:00
|
|
|
/* Service interval in nanoseconds = 2^(bInterval - 1) * 125us * 1000ns / 1us */
|
|
|
|
|
static unsigned long long xhci_service_interval_to_ns(
|
|
|
|
|
struct usb_endpoint_descriptor *desc)
|
|
|
|
|
{
|
2012-10-17 08:16:16 +00:00
|
|
|
return (1ULL << (desc->bInterval - 1)) * 125 * 1000;
|
2012-05-16 20:36:24 +00:00
|
|
|
}
|
|
|
|
|
|
xhci: Add infrastructure for host-specific LPM policies.
The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific. Here are a few examples of why it's
host specific:
1. Setting the U1/U2 timeout too short may cause the link to go into
U1/U2 in between service intervals, which some hosts may tolerate,
and some may not.
2. The host controller has to modify its bus schedule in order to take
into account the Maximum Exit Latency (MEL) to bring all the links
from the host to the device into U0. If the MEL is too big, and it
takes too long to bring the links into an active state, the host
controller may not be able to service periodic endpoints in time.
3. Host controllers may also have scheduling limitations that force
them to disable U1 or U2 if a USB device is behind too many tiers of
hubs.
We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller. However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands. Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.
Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.
To extend the framework, they will need to:
- Modify the PCI init code to add a new xhci->quirk for their host, and
set the XHCI_LPM_SUPPORT quirk flag.
- Add their own vendor-specific hooks, like the ones that will be added
in xhci_call_host_update_timeout_for_endpoint() and
xhci_check_tier_policy()
- Make the LPM enable/disable methods call those functions based on the
xhci->quirk for their host.
An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 17:55:03 +00:00
|
|
|
static u16 xhci_get_timeout_no_hub_lpm(struct usb_device *udev,
|
|
|
|
|
enum usb3_link_state state)
|
|
|
|
|
{
|
|
|
|
|
unsigned long long sel;
|
|
|
|
|
unsigned long long pel;
|
|
|
|
|
unsigned int max_sel_pel;
|
|
|
|
|
char *state_name;
|
|
|
|
|
|
|
|
|
|
switch (state) {
|
|
|
|
|
case USB3_LPM_U1:
|
|
|
|
|
/* Convert SEL and PEL stored in nanoseconds to microseconds */
|
|
|
|
|
sel = DIV_ROUND_UP(udev->u1_params.sel, 1000);
|
|
|
|
|
pel = DIV_ROUND_UP(udev->u1_params.pel, 1000);
|
|
|
|
|
max_sel_pel = USB3_LPM_MAX_U1_SEL_PEL;
|
|
|
|
|
state_name = "U1";
|
|
|
|
|
break;
|
|
|
|
|
case USB3_LPM_U2:
|
|
|
|
|
sel = DIV_ROUND_UP(udev->u2_params.sel, 1000);
|
|
|
|
|
pel = DIV_ROUND_UP(udev->u2_params.pel, 1000);
|
|
|
|
|
max_sel_pel = USB3_LPM_MAX_U2_SEL_PEL;
|
|
|
|
|
state_name = "U2";
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
dev_warn(&udev->dev, "%s: Can't get timeout for non-U1 or U2 state.\n",
|
|
|
|
|
__func__);
|
2012-06-07 18:10:32 +00:00
|
|
|
return USB3_LPM_DISABLED;
|
xhci: Add infrastructure for host-specific LPM policies.
The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific. Here are a few examples of why it's
host specific:
1. Setting the U1/U2 timeout too short may cause the link to go into
U1/U2 in between service intervals, which some hosts may tolerate,
and some may not.
2. The host controller has to modify its bus schedule in order to take
into account the Maximum Exit Latency (MEL) to bring all the links
from the host to the device into U0. If the MEL is too big, and it
takes too long to bring the links into an active state, the host
controller may not be able to service periodic endpoints in time.
3. Host controllers may also have scheduling limitations that force
them to disable U1 or U2 if a USB device is behind too many tiers of
hubs.
We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller. However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands. Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.
Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.
To extend the framework, they will need to:
- Modify the PCI init code to add a new xhci->quirk for their host, and
set the XHCI_LPM_SUPPORT quirk flag.
- Add their own vendor-specific hooks, like the ones that will be added
in xhci_call_host_update_timeout_for_endpoint() and
xhci_check_tier_policy()
- Make the LPM enable/disable methods call those functions based on the
xhci->quirk for their host.
An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 17:55:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (sel <= max_sel_pel && pel <= max_sel_pel)
|
|
|
|
|
return USB3_LPM_DEVICE_INITIATED;
|
|
|
|
|
|
|
|
|
|
if (sel > max_sel_pel)
|
|
|
|
|
dev_dbg(&udev->dev, "Device-initiated %s disabled "
|
|
|
|
|
"due to long SEL %llu ms\n",
|
|
|
|
|
state_name, sel);
|
|
|
|
|
else
|
|
|
|
|
dev_dbg(&udev->dev, "Device-initiated %s disabled "
|
2013-07-17 02:25:59 +00:00
|
|
|
"due to long PEL %llu ms\n",
|
xhci: Add infrastructure for host-specific LPM policies.
The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific. Here are a few examples of why it's
host specific:
1. Setting the U1/U2 timeout too short may cause the link to go into
U1/U2 in between service intervals, which some hosts may tolerate,
and some may not.
2. The host controller has to modify its bus schedule in order to take
into account the Maximum Exit Latency (MEL) to bring all the links
from the host to the device into U0. If the MEL is too big, and it
takes too long to bring the links into an active state, the host
controller may not be able to service periodic endpoints in time.
3. Host controllers may also have scheduling limitations that force
them to disable U1 or U2 if a USB device is behind too many tiers of
hubs.
We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller. However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands. Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.
Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.
To extend the framework, they will need to:
- Modify the PCI init code to add a new xhci->quirk for their host, and
set the XHCI_LPM_SUPPORT quirk flag.
- Add their own vendor-specific hooks, like the ones that will be added
in xhci_call_host_update_timeout_for_endpoint() and
xhci_check_tier_policy()
- Make the LPM enable/disable methods call those functions based on the
xhci->quirk for their host.
An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 17:55:03 +00:00
|
|
|
state_name, pel);
|
|
|
|
|
return USB3_LPM_DISABLED;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-16 20:36:24 +00:00
|
|
|
/* Returns the hub-encoded U1 timeout value.
|
|
|
|
|
* The U1 timeout should be the maximum of the following values:
|
|
|
|
|
* - For control endpoints, U1 system exit latency (SEL) * 3
|
|
|
|
|
* - For bulk endpoints, U1 SEL * 5
|
|
|
|
|
* - For interrupt endpoints:
|
|
|
|
|
* - Notification EPs, U1 SEL * 3
|
|
|
|
|
* - Periodic EPs, max(105% of bInterval, U1 SEL * 2)
|
|
|
|
|
* - For isochronous endpoints, max(105% of bInterval, U1 SEL * 2)
|
|
|
|
|
*/
|
|
|
|
|
static u16 xhci_calculate_intel_u1_timeout(struct usb_device *udev,
|
|
|
|
|
struct usb_endpoint_descriptor *desc)
|
|
|
|
|
{
|
|
|
|
|
unsigned long long timeout_ns;
|
|
|
|
|
int ep_type;
|
|
|
|
|
int intr_type;
|
|
|
|
|
|
|
|
|
|
ep_type = usb_endpoint_type(desc);
|
|
|
|
|
switch (ep_type) {
|
|
|
|
|
case USB_ENDPOINT_XFER_CONTROL:
|
|
|
|
|
timeout_ns = udev->u1_params.sel * 3;
|
|
|
|
|
break;
|
|
|
|
|
case USB_ENDPOINT_XFER_BULK:
|
|
|
|
|
timeout_ns = udev->u1_params.sel * 5;
|
|
|
|
|
break;
|
|
|
|
|
case USB_ENDPOINT_XFER_INT:
|
|
|
|
|
intr_type = usb_endpoint_interrupt_type(desc);
|
|
|
|
|
if (intr_type == USB_ENDPOINT_INTR_NOTIFICATION) {
|
|
|
|
|
timeout_ns = udev->u1_params.sel * 3;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
/* Otherwise the calculation is the same as isoc eps */
|
|
|
|
|
case USB_ENDPOINT_XFER_ISOC:
|
|
|
|
|
timeout_ns = xhci_service_interval_to_ns(desc);
|
2012-05-21 15:44:33 +00:00
|
|
|
timeout_ns = DIV_ROUND_UP_ULL(timeout_ns * 105, 100);
|
2012-05-16 20:36:24 +00:00
|
|
|
if (timeout_ns < udev->u1_params.sel * 2)
|
|
|
|
|
timeout_ns = udev->u1_params.sel * 2;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* The U1 timeout is encoded in 1us intervals. */
|
2012-05-21 15:44:33 +00:00
|
|
|
timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 1000);
|
2012-05-16 20:36:24 +00:00
|
|
|
/* Don't return a timeout of zero, because that's USB3_LPM_DISABLED. */
|
|
|
|
|
if (timeout_ns == USB3_LPM_DISABLED)
|
|
|
|
|
timeout_ns++;
|
|
|
|
|
|
|
|
|
|
/* If the necessary timeout value is bigger than what we can set in the
|
|
|
|
|
* USB 3.0 hub, we have to disable hub-initiated U1.
|
|
|
|
|
*/
|
|
|
|
|
if (timeout_ns <= USB3_LPM_U1_MAX_TIMEOUT)
|
|
|
|
|
return timeout_ns;
|
|
|
|
|
dev_dbg(&udev->dev, "Hub-initiated U1 disabled "
|
|
|
|
|
"due to long timeout %llu ms\n", timeout_ns);
|
|
|
|
|
return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns the hub-encoded U2 timeout value.
|
|
|
|
|
* The U2 timeout should be the maximum of:
|
|
|
|
|
* - 10 ms (to avoid the bandwidth impact on the scheduler)
|
|
|
|
|
* - largest bInterval of any active periodic endpoint (to avoid going
|
|
|
|
|
* into lower power link states between intervals).
|
|
|
|
|
* - the U2 Exit Latency of the device
|
|
|
|
|
*/
|
|
|
|
|
static u16 xhci_calculate_intel_u2_timeout(struct usb_device *udev,
|
|
|
|
|
struct usb_endpoint_descriptor *desc)
|
|
|
|
|
{
|
|
|
|
|
unsigned long long timeout_ns;
|
|
|
|
|
unsigned long long u2_del_ns;
|
|
|
|
|
|
|
|
|
|
timeout_ns = 10 * 1000 * 1000;
|
|
|
|
|
|
|
|
|
|
if ((usb_endpoint_xfer_int(desc) || usb_endpoint_xfer_isoc(desc)) &&
|
|
|
|
|
(xhci_service_interval_to_ns(desc) > timeout_ns))
|
|
|
|
|
timeout_ns = xhci_service_interval_to_ns(desc);
|
|
|
|
|
|
2012-10-17 10:17:50 +00:00
|
|
|
u2_del_ns = le16_to_cpu(udev->bos->ss_cap->bU2DevExitLat) * 1000ULL;
|
2012-05-16 20:36:24 +00:00
|
|
|
if (u2_del_ns > timeout_ns)
|
|
|
|
|
timeout_ns = u2_del_ns;
|
|
|
|
|
|
|
|
|
|
/* The U2 timeout is encoded in 256us intervals */
|
2012-05-21 15:44:33 +00:00
|
|
|
timeout_ns = DIV_ROUND_UP_ULL(timeout_ns, 256 * 1000);
|
2012-05-16 20:36:24 +00:00
|
|
|
/* If the necessary timeout value is bigger than what we can set in the
|
|
|
|
|
* USB 3.0 hub, we have to disable hub-initiated U2.
|
|
|
|
|
*/
|
|
|
|
|
if (timeout_ns <= USB3_LPM_U2_MAX_TIMEOUT)
|
|
|
|
|
return timeout_ns;
|
|
|
|
|
dev_dbg(&udev->dev, "Hub-initiated U2 disabled "
|
|
|
|
|
"due to long timeout %llu ms\n", timeout_ns);
|
|
|
|
|
return xhci_get_timeout_no_hub_lpm(udev, USB3_LPM_U2);
|
|
|
|
|
}
|
|
|
|
|
|
xhci: Add infrastructure for host-specific LPM policies.
The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific. Here are a few examples of why it's
host specific:
1. Setting the U1/U2 timeout too short may cause the link to go into
U1/U2 in between service intervals, which some hosts may tolerate,
and some may not.
2. The host controller has to modify its bus schedule in order to take
into account the Maximum Exit Latency (MEL) to bring all the links
from the host to the device into U0. If the MEL is too big, and it
takes too long to bring the links into an active state, the host
controller may not be able to service periodic endpoints in time.
3. Host controllers may also have scheduling limitations that force
them to disable U1 or U2 if a USB device is behind too many tiers of
hubs.
We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller. However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands. Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.
Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.
To extend the framework, they will need to:
- Modify the PCI init code to add a new xhci->quirk for their host, and
set the XHCI_LPM_SUPPORT quirk flag.
- Add their own vendor-specific hooks, like the ones that will be added
in xhci_call_host_update_timeout_for_endpoint() and
xhci_check_tier_policy()
- Make the LPM enable/disable methods call those functions based on the
xhci->quirk for their host.
An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 17:55:03 +00:00
|
|
|
static u16 xhci_call_host_update_timeout_for_endpoint(struct xhci_hcd *xhci,
|
|
|
|
|
struct usb_device *udev,
|
|
|
|
|
struct usb_endpoint_descriptor *desc,
|
|
|
|
|
enum usb3_link_state state,
|
|
|
|
|
u16 *timeout)
|
|
|
|
|
{
|
2012-05-16 20:36:24 +00:00
|
|
|
if (state == USB3_LPM_U1) {
|
|
|
|
|
if (xhci->quirks & XHCI_INTEL_HOST)
|
|
|
|
|
return xhci_calculate_intel_u1_timeout(udev, desc);
|
|
|
|
|
} else {
|
|
|
|
|
if (xhci->quirks & XHCI_INTEL_HOST)
|
|
|
|
|
return xhci_calculate_intel_u2_timeout(udev, desc);
|
|
|
|
|
}
|
|
|
|
|
|
xhci: Add infrastructure for host-specific LPM policies.
The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific. Here are a few examples of why it's
host specific:
1. Setting the U1/U2 timeout too short may cause the link to go into
U1/U2 in between service intervals, which some hosts may tolerate,
and some may not.
2. The host controller has to modify its bus schedule in order to take
into account the Maximum Exit Latency (MEL) to bring all the links
from the host to the device into U0. If the MEL is too big, and it
takes too long to bring the links into an active state, the host
controller may not be able to service periodic endpoints in time.
3. Host controllers may also have scheduling limitations that force
them to disable U1 or U2 if a USB device is behind too many tiers of
hubs.
We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller. However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands. Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.
Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.
To extend the framework, they will need to:
- Modify the PCI init code to add a new xhci->quirk for their host, and
set the XHCI_LPM_SUPPORT quirk flag.
- Add their own vendor-specific hooks, like the ones that will be added
in xhci_call_host_update_timeout_for_endpoint() and
xhci_check_tier_policy()
- Make the LPM enable/disable methods call those functions based on the
xhci->quirk for their host.
An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 17:55:03 +00:00
|
|
|
return USB3_LPM_DISABLED;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int xhci_update_timeout_for_endpoint(struct xhci_hcd *xhci,
|
|
|
|
|
struct usb_device *udev,
|
|
|
|
|
struct usb_endpoint_descriptor *desc,
|
|
|
|
|
enum usb3_link_state state,
|
|
|
|
|
u16 *timeout)
|
|
|
|
|
{
|
|
|
|
|
u16 alt_timeout;
|
|
|
|
|
|
|
|
|
|
alt_timeout = xhci_call_host_update_timeout_for_endpoint(xhci, udev,
|
|
|
|
|
desc, state, timeout);
|
|
|
|
|
|
|
|
|
|
/* If we found we can't enable hub-initiated LPM, or
|
|
|
|
|
* the U1 or U2 exit latency was too high to allow
|
|
|
|
|
* device-initiated LPM as well, just stop searching.
|
|
|
|
|
*/
|
|
|
|
|
if (alt_timeout == USB3_LPM_DISABLED ||
|
|
|
|
|
alt_timeout == USB3_LPM_DEVICE_INITIATED) {
|
|
|
|
|
*timeout = alt_timeout;
|
|
|
|
|
return -E2BIG;
|
|
|
|
|
}
|
|
|
|
|
if (alt_timeout > *timeout)
|
|
|
|
|
*timeout = alt_timeout;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int xhci_update_timeout_for_interface(struct xhci_hcd *xhci,
|
|
|
|
|
struct usb_device *udev,
|
|
|
|
|
struct usb_host_interface *alt,
|
|
|
|
|
enum usb3_link_state state,
|
|
|
|
|
u16 *timeout)
|
|
|
|
|
{
|
|
|
|
|
int j;
|
|
|
|
|
|
|
|
|
|
for (j = 0; j < alt->desc.bNumEndpoints; j++) {
|
|
|
|
|
if (xhci_update_timeout_for_endpoint(xhci, udev,
|
|
|
|
|
&alt->endpoint[j].desc, state, timeout))
|
|
|
|
|
return -E2BIG;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-16 20:36:24 +00:00
|
|
|
static int xhci_check_intel_tier_policy(struct usb_device *udev,
|
|
|
|
|
enum usb3_link_state state)
|
|
|
|
|
{
|
|
|
|
|
struct usb_device *parent;
|
|
|
|
|
unsigned int num_hubs;
|
|
|
|
|
|
|
|
|
|
if (state == USB3_LPM_U2)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
/* Don't enable U1 if the device is on a 2nd tier hub or lower. */
|
|
|
|
|
for (parent = udev->parent, num_hubs = 0; parent->parent;
|
|
|
|
|
parent = parent->parent)
|
|
|
|
|
num_hubs++;
|
|
|
|
|
|
|
|
|
|
if (num_hubs < 2)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
dev_dbg(&udev->dev, "Disabling U1 link state for device"
|
|
|
|
|
" below second-tier hub.\n");
|
|
|
|
|
dev_dbg(&udev->dev, "Plug device into first-tier hub "
|
|
|
|
|
"to decrease power consumption.\n");
|
|
|
|
|
return -E2BIG;
|
|
|
|
|
}
|
|
|
|
|
|
xhci: Add infrastructure for host-specific LPM policies.
The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific. Here are a few examples of why it's
host specific:
1. Setting the U1/U2 timeout too short may cause the link to go into
U1/U2 in between service intervals, which some hosts may tolerate,
and some may not.
2. The host controller has to modify its bus schedule in order to take
into account the Maximum Exit Latency (MEL) to bring all the links
from the host to the device into U0. If the MEL is too big, and it
takes too long to bring the links into an active state, the host
controller may not be able to service periodic endpoints in time.
3. Host controllers may also have scheduling limitations that force
them to disable U1 or U2 if a USB device is behind too many tiers of
hubs.
We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller. However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands. Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.
Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.
To extend the framework, they will need to:
- Modify the PCI init code to add a new xhci->quirk for their host, and
set the XHCI_LPM_SUPPORT quirk flag.
- Add their own vendor-specific hooks, like the ones that will be added
in xhci_call_host_update_timeout_for_endpoint() and
xhci_check_tier_policy()
- Make the LPM enable/disable methods call those functions based on the
xhci->quirk for their host.
An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 17:55:03 +00:00
|
|
|
static int xhci_check_tier_policy(struct xhci_hcd *xhci,
|
|
|
|
|
struct usb_device *udev,
|
|
|
|
|
enum usb3_link_state state)
|
|
|
|
|
{
|
2012-05-16 20:36:24 +00:00
|
|
|
if (xhci->quirks & XHCI_INTEL_HOST)
|
|
|
|
|
return xhci_check_intel_tier_policy(udev, state);
|
xhci: Add infrastructure for host-specific LPM policies.
The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific. Here are a few examples of why it's
host specific:
1. Setting the U1/U2 timeout too short may cause the link to go into
U1/U2 in between service intervals, which some hosts may tolerate,
and some may not.
2. The host controller has to modify its bus schedule in order to take
into account the Maximum Exit Latency (MEL) to bring all the links
from the host to the device into U0. If the MEL is too big, and it
takes too long to bring the links into an active state, the host
controller may not be able to service periodic endpoints in time.
3. Host controllers may also have scheduling limitations that force
them to disable U1 or U2 if a USB device is behind too many tiers of
hubs.
We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller. However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands. Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.
Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.
To extend the framework, they will need to:
- Modify the PCI init code to add a new xhci->quirk for their host, and
set the XHCI_LPM_SUPPORT quirk flag.
- Add their own vendor-specific hooks, like the ones that will be added
in xhci_call_host_update_timeout_for_endpoint() and
xhci_check_tier_policy()
- Make the LPM enable/disable methods call those functions based on the
xhci->quirk for their host.
An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 17:55:03 +00:00
|
|
|
return -EINVAL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns the U1 or U2 timeout that should be enabled.
|
|
|
|
|
* If the tier check or timeout setting functions return with a non-zero exit
|
|
|
|
|
* code, that means the timeout value has been finalized and we shouldn't look
|
|
|
|
|
* at any more endpoints.
|
|
|
|
|
*/
|
|
|
|
|
static u16 xhci_calculate_lpm_timeout(struct usb_hcd *hcd,
|
|
|
|
|
struct usb_device *udev, enum usb3_link_state state)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
|
|
|
|
|
struct usb_host_config *config;
|
|
|
|
|
char *state_name;
|
|
|
|
|
int i;
|
|
|
|
|
u16 timeout = USB3_LPM_DISABLED;
|
|
|
|
|
|
|
|
|
|
if (state == USB3_LPM_U1)
|
|
|
|
|
state_name = "U1";
|
|
|
|
|
else if (state == USB3_LPM_U2)
|
|
|
|
|
state_name = "U2";
|
|
|
|
|
else {
|
|
|
|
|
dev_warn(&udev->dev, "Can't enable unknown link state %i\n",
|
|
|
|
|
state);
|
|
|
|
|
return timeout;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (xhci_check_tier_policy(xhci, udev, state) < 0)
|
|
|
|
|
return timeout;
|
|
|
|
|
|
|
|
|
|
/* Gather some information about the currently installed configuration
|
|
|
|
|
* and alternate interface settings.
|
|
|
|
|
*/
|
|
|
|
|
if (xhci_update_timeout_for_endpoint(xhci, udev, &udev->ep0.desc,
|
|
|
|
|
state, &timeout))
|
|
|
|
|
return timeout;
|
|
|
|
|
|
|
|
|
|
config = udev->actconfig;
|
|
|
|
|
if (!config)
|
|
|
|
|
return timeout;
|
|
|
|
|
|
2013-08-26 20:29:46 +00:00
|
|
|
for (i = 0; i < config->desc.bNumInterfaces; i++) {
|
xhci: Add infrastructure for host-specific LPM policies.
The choice of U1 and U2 timeouts for USB 3.0 Link Power Management (LPM)
is highly host controller specific. Here are a few examples of why it's
host specific:
1. Setting the U1/U2 timeout too short may cause the link to go into
U1/U2 in between service intervals, which some hosts may tolerate,
and some may not.
2. The host controller has to modify its bus schedule in order to take
into account the Maximum Exit Latency (MEL) to bring all the links
from the host to the device into U0. If the MEL is too big, and it
takes too long to bring the links into an active state, the host
controller may not be able to service periodic endpoints in time.
3. Host controllers may also have scheduling limitations that force
them to disable U1 or U2 if a USB device is behind too many tiers of
hubs.
We could take an educated guess at what U1/U2 timeouts may work for a
particular host controller. However, that would result in a binary
search on every new configuration or alt setting installation, with
multiple failed Evaluate Context commands. Worse, the host may blindly
accept the timeouts and just fail to update its schedule for U1/U2 exit
latencies, which could result in randomly delayed periodic transfers.
Since we don't want to cause jitter in periodic transfers, or delay
config/alt setting changes too much, lay down a framework that xHCI
vendors can extend in order to add their own U1/U2 timeout policies.
To extend the framework, they will need to:
- Modify the PCI init code to add a new xhci->quirk for their host, and
set the XHCI_LPM_SUPPORT quirk flag.
- Add their own vendor-specific hooks, like the ones that will be added
in xhci_call_host_update_timeout_for_endpoint() and
xhci_check_tier_policy()
- Make the LPM enable/disable methods call those functions based on the
xhci->quirk for their host.
An example will be provided for the Intel xHCI host controller in the
next patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 17:55:03 +00:00
|
|
|
struct usb_driver *driver;
|
|
|
|
|
struct usb_interface *intf = config->interface[i];
|
|
|
|
|
|
|
|
|
|
if (!intf)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
/* Check if any currently bound drivers want hub-initiated LPM
|
|
|
|
|
* disabled.
|
|
|
|
|
*/
|
|
|
|
|
if (intf->dev.driver) {
|
|
|
|
|
driver = to_usb_driver(intf->dev.driver);
|
|
|
|
|
if (driver && driver->disable_hub_initiated_lpm) {
|
|
|
|
|
dev_dbg(&udev->dev, "Hub-initiated %s disabled "
|
|
|
|
|
"at request of driver %s\n",
|
|
|
|
|
state_name, driver->name);
|
|
|
|
|
return xhci_get_timeout_no_hub_lpm(udev, state);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Not sure how this could happen... */
|
|
|
|
|
if (!intf->cur_altsetting)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (xhci_update_timeout_for_interface(xhci, udev,
|
|
|
|
|
intf->cur_altsetting,
|
|
|
|
|
state, &timeout))
|
|
|
|
|
return timeout;
|
|
|
|
|
}
|
|
|
|
|
return timeout;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int calculate_max_exit_latency(struct usb_device *udev,
|
|
|
|
|
enum usb3_link_state state_changed,
|
|
|
|
|
u16 hub_encoded_timeout)
|
|
|
|
|
{
|
|
|
|
|
unsigned long long u1_mel_us = 0;
|
|
|
|
|
unsigned long long u2_mel_us = 0;
|
|
|
|
|
unsigned long long mel_us = 0;
|
|
|
|
|
bool disabling_u1;
|
|
|
|
|
bool disabling_u2;
|
|
|
|
|
bool enabling_u1;
|
|
|
|
|
bool enabling_u2;
|
|
|
|
|
|
|
|
|
|
disabling_u1 = (state_changed == USB3_LPM_U1 &&
|
|
|
|
|
hub_encoded_timeout == USB3_LPM_DISABLED);
|
|
|
|
|
disabling_u2 = (state_changed == USB3_LPM_U2 &&
|
|
|
|
|
hub_encoded_timeout == USB3_LPM_DISABLED);
|
|
|
|
|
|
|
|
|
|
enabling_u1 = (state_changed == USB3_LPM_U1 &&
|
|
|
|
|
hub_encoded_timeout != USB3_LPM_DISABLED);
|
|
|
|
|
enabling_u2 = (state_changed == USB3_LPM_U2 &&
|
|
|
|
|
hub_encoded_timeout != USB3_LPM_DISABLED);
|
|
|
|
|
|
|
|
|
|
/* If U1 was already enabled and we're not disabling it,
|
|
|
|
|
* or we're going to enable U1, account for the U1 max exit latency.
|
|
|
|
|
*/
|
|
|
|
|
if ((udev->u1_params.timeout != USB3_LPM_DISABLED && !disabling_u1) ||
|
|
|
|
|
enabling_u1)
|
|
|
|
|
u1_mel_us = DIV_ROUND_UP(udev->u1_params.mel, 1000);
|
|
|
|
|
if ((udev->u2_params.timeout != USB3_LPM_DISABLED && !disabling_u2) ||
|
|
|
|
|
enabling_u2)
|
|
|
|
|
u2_mel_us = DIV_ROUND_UP(udev->u2_params.mel, 1000);
|
|
|
|
|
|
|
|
|
|
if (u1_mel_us > u2_mel_us)
|
|
|
|
|
mel_us = u1_mel_us;
|
|
|
|
|
else
|
|
|
|
|
mel_us = u2_mel_us;
|
|
|
|
|
/* xHCI host controller max exit latency field is only 16 bits wide. */
|
|
|
|
|
if (mel_us > MAX_EXIT) {
|
|
|
|
|
dev_warn(&udev->dev, "Link PM max exit latency of %lluus "
|
|
|
|
|
"is too big.\n", mel_us);
|
|
|
|
|
return -E2BIG;
|
|
|
|
|
}
|
|
|
|
|
return mel_us;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Returns the USB3 hub-encoded value for the U1/U2 timeout. */
|
|
|
|
|
int xhci_enable_usb3_lpm_timeout(struct usb_hcd *hcd,
|
|
|
|
|
struct usb_device *udev, enum usb3_link_state state)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
u16 hub_encoded_timeout;
|
|
|
|
|
int mel;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
/* The LPM timeout values are pretty host-controller specific, so don't
|
|
|
|
|
* enable hub-initiated timeouts unless the vendor has provided
|
|
|
|
|
* information about their timeout algorithm.
|
|
|
|
|
*/
|
|
|
|
|
if (!xhci || !(xhci->quirks & XHCI_LPM_SUPPORT) ||
|
|
|
|
|
!xhci->devs[udev->slot_id])
|
|
|
|
|
return USB3_LPM_DISABLED;
|
|
|
|
|
|
|
|
|
|
hub_encoded_timeout = xhci_calculate_lpm_timeout(hcd, udev, state);
|
|
|
|
|
mel = calculate_max_exit_latency(udev, state, hub_encoded_timeout);
|
|
|
|
|
if (mel < 0) {
|
|
|
|
|
/* Max Exit Latency is too big, disable LPM. */
|
|
|
|
|
hub_encoded_timeout = USB3_LPM_DISABLED;
|
|
|
|
|
mel = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ret = xhci_change_max_exit_latency(xhci, udev, mel);
|
|
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
|
|
|
|
return hub_encoded_timeout;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int xhci_disable_usb3_lpm_timeout(struct usb_hcd *hcd,
|
|
|
|
|
struct usb_device *udev, enum usb3_link_state state)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
u16 mel;
|
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
|
|
xhci = hcd_to_xhci(hcd);
|
|
|
|
|
if (!xhci || !(xhci->quirks & XHCI_LPM_SUPPORT) ||
|
|
|
|
|
!xhci->devs[udev->slot_id])
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
mel = calculate_max_exit_latency(udev, state, USB3_LPM_DISABLED);
|
|
|
|
|
ret = xhci_change_max_exit_latency(xhci, udev, mel);
|
|
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2012-05-21 14:54:42 +00:00
|
|
|
#else /* CONFIG_PM */
|
2011-09-23 21:19:51 +00:00
|
|
|
|
2012-05-21 14:54:42 +00:00
|
|
|
int xhci_enable_usb3_lpm_timeout(struct usb_hcd *hcd,
|
|
|
|
|
struct usb_device *udev, enum usb3_link_state state)
|
2011-09-23 21:19:52 +00:00
|
|
|
{
|
2012-05-21 14:54:42 +00:00
|
|
|
return USB3_LPM_DISABLED;
|
2011-09-23 21:19:52 +00:00
|
|
|
}
|
|
|
|
|
|
2012-05-21 14:54:42 +00:00
|
|
|
int xhci_disable_usb3_lpm_timeout(struct usb_hcd *hcd,
|
|
|
|
|
struct usb_device *udev, enum usb3_link_state state)
|
2011-09-23 21:19:51 +00:00
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2012-05-21 14:54:42 +00:00
|
|
|
#endif /* CONFIG_PM */
|
2011-09-23 21:19:51 +00:00
|
|
|
|
2012-05-21 14:54:42 +00:00
|
|
|
/*-------------------------------------------------------------------------*/
|
2011-09-23 21:19:51 +00:00
|
|
|
|
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;
|
|
|
|
|
}
|
2013-04-24 00:11:14 +00:00
|
|
|
ctrl_ctx = xhci_get_input_control_ctx(xhci, config_cmd->in_ctx);
|
|
|
|
|
if (!ctrl_ctx) {
|
|
|
|
|
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
|
|
|
|
|
__func__);
|
|
|
|
|
xhci_free_command(xhci, config_cmd);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
2009-09-04 17:53:20 +00:00
|
|
|
|
|
|
|
|
spin_lock_irqsave(&xhci->lock, flags);
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-02 18:05:47 +00:00
|
|
|
if (hdev->speed == USB_SPEED_HIGH &&
|
|
|
|
|
xhci_alloc_tt_info(xhci, vdev, hdev, tt, GFP_ATOMIC)) {
|
|
|
|
|
xhci_dbg(xhci, "Could not allocate xHCI TT structure.\n");
|
|
|
|
|
xhci_free_command(xhci, config_cmd);
|
|
|
|
|
spin_unlock_irqrestore(&xhci->lock, flags);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-04 17:53:20 +00:00
|
|
|
xhci_slot_copy(xhci, config_cmd->in_ctx, vdev->out_ctx);
|
2011-03-29 02:40:46 +00:00
|
|
|
ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG);
|
2009-09-04 17:53:20 +00:00
|
|
|
slot_ctx = xhci_get_slot_ctx(xhci, config_cmd->in_ctx);
|
2011-03-29 02:40:46 +00:00
|
|
|
slot_ctx->dev_info |= cpu_to_le32(DEV_HUB);
|
2009-09-04 17:53:20 +00:00
|
|
|
if (tt->multi)
|
2011-03-29 02:40:46 +00:00
|
|
|
slot_ctx->dev_info |= cpu_to_le32(DEV_MTT);
|
2009-09-04 17:53:20 +00:00
|
|
|
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);
|
2011-03-29 02:40:46 +00:00
|
|
|
slot_ctx->dev_info2 |= cpu_to_le32(XHCI_MAX_PORTS(hdev->maxchild));
|
2009-09-04 17:53:20 +00:00
|
|
|
/* 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.
|
2011-05-05 10:14:05 +00:00
|
|
|
*
|
|
|
|
|
* xHCI 1.0: this field shall be 0 if the device is not a
|
|
|
|
|
* High-spped hub.
|
2009-09-04 17:53:20 +00:00
|
|
|
*/
|
|
|
|
|
think_time = tt->think_time;
|
|
|
|
|
if (think_time != 0)
|
|
|
|
|
think_time = (think_time / 666) - 1;
|
2011-05-05 10:14:05 +00:00
|
|
|
if (xhci->hci_version < 0x100 || hdev->speed == USB_SPEED_HIGH)
|
|
|
|
|
slot_ctx->tt_info |=
|
|
|
|
|
cpu_to_le32(TT_THINK_TIME(think_time));
|
2009-09-04 17:53:20 +00:00
|
|
|
} 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? */
|
2013-11-15 03:34:06 +00:00
|
|
|
return readl(&xhci->run_regs->microframe_index) >> 3;
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
|
|
|
|
|
2011-09-23 21:20:01 +00:00
|
|
|
int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
|
|
|
|
|
{
|
|
|
|
|
struct xhci_hcd *xhci;
|
|
|
|
|
struct device *dev = hcd->self.controller;
|
|
|
|
|
int retval;
|
|
|
|
|
|
2014-01-31 19:45:02 +00:00
|
|
|
/* Accept arbitrarily long scatter-gather lists */
|
|
|
|
|
hcd->self.sg_tablesize = ~0;
|
2013-08-08 13:48:23 +00:00
|
|
|
|
2014-03-07 15:06:57 +00:00
|
|
|
/* support to build packet from discontinuous buffers */
|
|
|
|
|
hcd->self.no_sg_constraint = 1;
|
|
|
|
|
|
usbdevfs: Add a USBDEVFS_GET_CAPABILITIES ioctl
There are a few (new) usbdevfs capabilities which an application cannot
discover in any other way then checking the kernel version. There are 3
problems with this:
1) It is just not very pretty.
2) Given the tendency of enterprise distros to backport stuff it is not
reliable.
3) As discussed in length on the mailinglist, USBDEVFS_URB_BULK_CONTINUATION
does not work as it should when combined with USBDEVFS_URB_SHORT_NOT_OK
(which is its intended use) on devices attached to an XHCI controller.
So the availability of these features can be host controller dependent,
making depending on them based on the kernel version not a good idea.
This patch besides adding the new ioctl also adds flags for the following
existing capabilities:
USBDEVFS_CAP_ZERO_PACKET, available since 2.6.31
USBDEVFS_CAP_BULK_CONTINUATION, available since 2.6.32, except for XHCI
USBDEVFS_CAP_NO_PACKET_SIZE_LIM, available since 3.3
Note that this patch only does not advertise the USBDEVFS_URB_BULK_CONTINUATION
cap for XHCI controllers, bulk transfers with this flag set will still be
accepted when submitted to XHCI controllers.
Returning -EINVAL for them would break existing apps, and in most cases the
troublesome scenario wrt USBDEVFS_URB_SHORT_NOT_OK urbs on XHCI controllers
will never get hit, so this would break working use cases.
The disadvantage of not returning -EINVAL is that cases were it is causing
real trouble may go undetected / the cause of the trouble may be unclear,
but this is the best we can do.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-07-04 07:18:02 +00:00
|
|
|
/* XHCI controllers don't stop the ep queue on short packets :| */
|
|
|
|
|
hcd->self.no_stop_on_short = 1;
|
2011-09-23 21:20:01 +00:00
|
|
|
|
|
|
|
|
if (usb_hcd_is_primary_hcd(hcd)) {
|
|
|
|
|
xhci = kzalloc(sizeof(struct xhci_hcd), GFP_KERNEL);
|
|
|
|
|
if (!xhci)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
*((struct xhci_hcd **) hcd->hcd_priv) = xhci;
|
|
|
|
|
xhci->main_hcd = hcd;
|
|
|
|
|
/* Mark the first roothub as being USB 2.0.
|
|
|
|
|
* The xHCI driver will register the USB 3.0 roothub.
|
|
|
|
|
*/
|
|
|
|
|
hcd->speed = HCD_USB2;
|
|
|
|
|
hcd->self.root_hub->speed = USB_SPEED_HIGH;
|
|
|
|
|
/*
|
|
|
|
|
* USB 2.0 roothub under xHCI has an integrated TT,
|
|
|
|
|
* (rate matching hub) as opposed to having an OHCI/UHCI
|
|
|
|
|
* companion controller.
|
|
|
|
|
*/
|
|
|
|
|
hcd->has_tt = 1;
|
|
|
|
|
} else {
|
|
|
|
|
/* xHCI private pointer was set in xhci_pci_probe for the second
|
|
|
|
|
* registered roothub.
|
|
|
|
|
*/
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
xhci->cap_regs = hcd->regs;
|
|
|
|
|
xhci->op_regs = hcd->regs +
|
2013-11-15 03:34:06 +00:00
|
|
|
HC_LENGTH(readl(&xhci->cap_regs->hc_capbase));
|
2011-09-23 21:20:01 +00:00
|
|
|
xhci->run_regs = hcd->regs +
|
2013-11-15 03:34:06 +00:00
|
|
|
(readl(&xhci->cap_regs->run_regs_off) & RTSOFF_MASK);
|
2011-09-23 21:20:01 +00:00
|
|
|
/* Cache read-only capability registers */
|
2013-11-15 03:34:06 +00:00
|
|
|
xhci->hcs_params1 = readl(&xhci->cap_regs->hcs_params1);
|
|
|
|
|
xhci->hcs_params2 = readl(&xhci->cap_regs->hcs_params2);
|
|
|
|
|
xhci->hcs_params3 = readl(&xhci->cap_regs->hcs_params3);
|
|
|
|
|
xhci->hcc_params = readl(&xhci->cap_regs->hc_capbase);
|
2011-09-23 21:20:01 +00:00
|
|
|
xhci->hci_version = HC_VERSION(xhci->hcc_params);
|
2013-11-15 03:34:06 +00:00
|
|
|
xhci->hcc_params = readl(&xhci->cap_regs->hcc_params);
|
2011-09-23 21:20:01 +00:00
|
|
|
xhci_print_registers(xhci);
|
|
|
|
|
|
2013-12-09 11:42:48 +00:00
|
|
|
xhci->quirks = quirks;
|
|
|
|
|
|
2011-09-23 21:20:01 +00:00
|
|
|
get_quirks(dev, xhci);
|
|
|
|
|
|
2013-07-01 05:29:12 +00:00
|
|
|
/* In xhci controllers which follow xhci 1.0 spec gives a spurious
|
|
|
|
|
* success event after a short transfer. This quirk will ignore such
|
|
|
|
|
* spurious event.
|
|
|
|
|
*/
|
|
|
|
|
if (xhci->hci_version > 0x96)
|
|
|
|
|
xhci->quirks |= XHCI_SPURIOUS_SUCCESS;
|
|
|
|
|
|
2011-09-23 21:20:01 +00:00
|
|
|
/* Make sure the HC is halted. */
|
|
|
|
|
retval = xhci_halt(xhci);
|
|
|
|
|
if (retval)
|
|
|
|
|
goto error;
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Resetting HCD\n");
|
|
|
|
|
/* Reset the internal HC memory state and registers. */
|
|
|
|
|
retval = xhci_reset(xhci);
|
|
|
|
|
if (retval)
|
|
|
|
|
goto error;
|
|
|
|
|
xhci_dbg(xhci, "Reset complete\n");
|
|
|
|
|
|
xhci: fix dma mask setup in xhci.c
The function dma_set_mask() tests internally whether the dma_mask pointer
for the device is initialized and fails if the dma_mask pointer is NULL.
On pci platforms, the device dma_mask pointer is initialized, when pci
devices are enumerated, to point to the pci_dev->dma_mask which is 0xffffffff.
However, for non-pci platforms, the dma_mask pointer may not be initialized
and in that case dma_set_mask() will fail.
This patch initializes the dma_mask and the coherent_dma_mask to 32bits
in xhci_plat_probe(), before the call to usb_create_hcd() that sets the
"uses_dma" flag for the usb bus and the call to usb_add_hcd() that creates
coherent dma pools for the usb hcd.
Moreover, a call to dma_set_mask() does not set the device coherent_dma_mask.
Since the xhci-hcd driver calls dma_alloc_coherent() and dma_pool_alloc()
to allocate consistent DMA memory blocks, the coherent DMA address mask
has to be set explicitly.
This patch sets the coherent_dma_mask to 64bits in xhci_gen_setup() when
the xHC is capable for 64-bit DMA addressing.
If dma_set_mask() succeeds, for a given bitmask, it is guaranteed that
the given bitmask is also supported for consistent DMA mappings.
Other changes introduced in this patch are:
- The return value of dma_set_mask() is checked to ensure that the required
dma bitmask conforms with the host system's addressing capabilities.
- The dma_mask setup code for the non-primary hcd was removed since both
primary and non-primary hcd refer to the same generic device whose
dma_mask and coherent_dma_mask are already set during the setup of
the primary hcd.
- The code for reading the HCCPARAMS register to find out the addressing
capabilities of xHC was removed since its value is already cached in
xhci->hccparams.
- hcd->self.controller was replaced with the dev variable since it is
already available.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-14 02:55:19 +00:00
|
|
|
/* Set dma_mask and coherent_dma_mask to 64-bits,
|
|
|
|
|
* if xHC supports 64-bit addressing */
|
|
|
|
|
if (HCC_64BIT_ADDR(xhci->hcc_params) &&
|
|
|
|
|
!dma_set_mask(dev, DMA_BIT_MASK(64))) {
|
2011-09-23 21:20:01 +00:00
|
|
|
xhci_dbg(xhci, "Enabling 64-bit DMA addresses.\n");
|
xhci: fix dma mask setup in xhci.c
The function dma_set_mask() tests internally whether the dma_mask pointer
for the device is initialized and fails if the dma_mask pointer is NULL.
On pci platforms, the device dma_mask pointer is initialized, when pci
devices are enumerated, to point to the pci_dev->dma_mask which is 0xffffffff.
However, for non-pci platforms, the dma_mask pointer may not be initialized
and in that case dma_set_mask() will fail.
This patch initializes the dma_mask and the coherent_dma_mask to 32bits
in xhci_plat_probe(), before the call to usb_create_hcd() that sets the
"uses_dma" flag for the usb bus and the call to usb_add_hcd() that creates
coherent dma pools for the usb hcd.
Moreover, a call to dma_set_mask() does not set the device coherent_dma_mask.
Since the xhci-hcd driver calls dma_alloc_coherent() and dma_pool_alloc()
to allocate consistent DMA memory blocks, the coherent DMA address mask
has to be set explicitly.
This patch sets the coherent_dma_mask to 64bits in xhci_gen_setup() when
the xHC is capable for 64-bit DMA addressing.
If dma_set_mask() succeeds, for a given bitmask, it is guaranteed that
the given bitmask is also supported for consistent DMA mappings.
Other changes introduced in this patch are:
- The return value of dma_set_mask() is checked to ensure that the required
dma bitmask conforms with the host system's addressing capabilities.
- The dma_mask setup code for the non-primary hcd was removed since both
primary and non-primary hcd refer to the same generic device whose
dma_mask and coherent_dma_mask are already set during the setup of
the primary hcd.
- The code for reading the HCCPARAMS register to find out the addressing
capabilities of xHC was removed since its value is already cached in
xhci->hccparams.
- hcd->self.controller was replaced with the dev variable since it is
already available.
Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-14 02:55:19 +00:00
|
|
|
dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
|
2011-09-23 21:20:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
xhci_dbg(xhci, "Calling HCD init\n");
|
|
|
|
|
/* Initialize HCD and host controller data structures. */
|
|
|
|
|
retval = xhci_init(hcd);
|
|
|
|
|
if (retval)
|
|
|
|
|
goto error;
|
|
|
|
|
xhci_dbg(xhci, "Called HCD init\n");
|
|
|
|
|
return 0;
|
|
|
|
|
error:
|
|
|
|
|
kfree(xhci);
|
|
|
|
|
return retval;
|
|
|
|
|
}
|
|
|
|
|
|
2009-04-28 02:52:28 +00:00
|
|
|
MODULE_DESCRIPTION(DRIVER_DESC);
|
|
|
|
|
MODULE_AUTHOR(DRIVER_AUTHOR);
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
|
|
|
|
|
|
static int __init xhci_hcd_init(void)
|
|
|
|
|
{
|
2011-09-23 21:20:02 +00:00
|
|
|
int retval;
|
2009-04-28 02:52:28 +00:00
|
|
|
|
|
|
|
|
retval = xhci_register_pci();
|
|
|
|
|
if (retval < 0) {
|
2013-07-02 14:49:26 +00:00
|
|
|
pr_debug("Problem registering PCI driver.\n");
|
2009-04-28 02:52:28 +00:00
|
|
|
return retval;
|
|
|
|
|
}
|
2012-03-13 14:57:41 +00:00
|
|
|
retval = xhci_register_plat();
|
|
|
|
|
if (retval < 0) {
|
2013-07-02 14:49:26 +00:00
|
|
|
pr_debug("Problem registering platform driver.\n");
|
2012-03-13 14:57:41 +00:00
|
|
|
goto unreg_pci;
|
|
|
|
|
}
|
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);
|
2009-04-28 02:52:28 +00:00
|
|
|
return 0;
|
2012-03-13 14:57:41 +00:00
|
|
|
unreg_pci:
|
|
|
|
|
xhci_unregister_pci();
|
|
|
|
|
return retval;
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
|
|
|
|
module_init(xhci_hcd_init);
|
|
|
|
|
|
|
|
|
|
static void __exit xhci_hcd_cleanup(void)
|
|
|
|
|
{
|
|
|
|
|
xhci_unregister_pci();
|
2012-03-13 14:57:41 +00:00
|
|
|
xhci_unregister_plat();
|
2009-04-28 02:52:28 +00:00
|
|
|
}
|
|
|
|
|
module_exit(xhci_hcd_cleanup);
|
