2015-03-06 23:14:21 +08:00
|
|
|
|
2009-04-28 10:52:22 +08:00
|
|
|
/*
|
|
|
|
* xHCI host controller driver
|
|
|
|
*
|
|
|
|
* Copyright (C) 2008 Intel Corp.
|
|
|
|
*
|
|
|
|
* Author: Sarah Sharp
|
|
|
|
* Some code borrowed from the Linux EHCI driver.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
|
|
|
|
* or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
|
|
|
|
* for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
* Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __LINUX_XHCI_HCD_H
|
|
|
|
#define __LINUX_XHCI_HCD_H
|
|
|
|
|
|
|
|
#include <linux/usb.h>
|
2009-04-28 10:53:56 +08:00
|
|
|
#include <linux/timer.h>
|
2009-07-28 03:03:31 +08:00
|
|
|
#include <linux/kernel.h>
|
2010-04-25 05:21:52 +08:00
|
|
|
#include <linux/usb/hcd.h>
|
2015-11-07 06:22:15 +08:00
|
|
|
#include <linux/io-64-nonatomic-lo-hi.h>
|
2015-10-09 18:30:09 +08:00
|
|
|
|
2009-04-28 10:52:22 +08:00
|
|
|
/* Code sharing between pci-quirks and xhci hcd */
|
|
|
|
#include "xhci-ext-caps.h"
|
2011-03-22 17:08:14 +08:00
|
|
|
#include "pci-quirks.h"
|
2009-04-28 10:52:22 +08:00
|
|
|
|
|
|
|
/* xHCI PCI Configuration Registers */
|
|
|
|
#define XHCI_SBRN_OFFSET (0x60)
|
|
|
|
|
2009-04-28 10:52:28 +08:00
|
|
|
/* Max number of USB devices for any host controller - limit in section 6.1 */
|
|
|
|
#define MAX_HC_SLOTS 256
|
2009-04-28 10:57:12 +08:00
|
|
|
/* Section 5.3.3 - MaxPorts */
|
|
|
|
#define MAX_HC_PORTS 127
|
2009-04-28 10:52:28 +08:00
|
|
|
|
2009-04-28 10:52:22 +08:00
|
|
|
/*
|
|
|
|
* xHCI register interface.
|
|
|
|
* This corresponds to the eXtensible Host Controller Interface (xHCI)
|
|
|
|
* Revision 0.95 specification
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* struct xhci_cap_regs - xHCI Host Controller Capability Registers.
|
|
|
|
* @hc_capbase: length of the capabilities register and HC version number
|
|
|
|
* @hcs_params1: HCSPARAMS1 - Structural Parameters 1
|
|
|
|
* @hcs_params2: HCSPARAMS2 - Structural Parameters 2
|
|
|
|
* @hcs_params3: HCSPARAMS3 - Structural Parameters 3
|
|
|
|
* @hcc_params: HCCPARAMS - Capability Parameters
|
|
|
|
* @db_off: DBOFF - Doorbell array offset
|
|
|
|
* @run_regs_off: RTSOFF - Runtime register space offset
|
2015-10-01 23:40:31 +08:00
|
|
|
* @hcc_params2: HCCPARAMS2 Capability Parameters 2, xhci 1.1 only
|
2009-04-28 10:52:22 +08:00
|
|
|
*/
|
|
|
|
struct xhci_cap_regs {
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 hc_capbase;
|
|
|
|
__le32 hcs_params1;
|
|
|
|
__le32 hcs_params2;
|
|
|
|
__le32 hcs_params3;
|
|
|
|
__le32 hcc_params;
|
|
|
|
__le32 db_off;
|
|
|
|
__le32 run_regs_off;
|
2015-10-01 23:40:31 +08:00
|
|
|
__le32 hcc_params2; /* xhci 1.1 */
|
2009-04-28 10:52:22 +08:00
|
|
|
/* Reserved up to (CAPLENGTH - 0x1C) */
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:52:22 +08:00
|
|
|
|
|
|
|
/* hc_capbase bitmasks */
|
|
|
|
/* bits 7:0 - how long is the Capabilities register */
|
|
|
|
#define HC_LENGTH(p) XHCI_HC_LENGTH(p)
|
|
|
|
/* bits 31:16 */
|
|
|
|
#define HC_VERSION(p) (((p) >> 16) & 0xffff)
|
|
|
|
|
|
|
|
/* HCSPARAMS1 - hcs_params1 - bitmasks */
|
|
|
|
/* bits 0:7, Max Device Slots */
|
|
|
|
#define HCS_MAX_SLOTS(p) (((p) >> 0) & 0xff)
|
|
|
|
#define HCS_SLOTS_MASK 0xff
|
|
|
|
/* bits 8:18, Max Interrupters */
|
|
|
|
#define HCS_MAX_INTRS(p) (((p) >> 8) & 0x7ff)
|
|
|
|
/* bits 24:31, Max Ports - max value is 0x7F = 127 ports */
|
|
|
|
#define HCS_MAX_PORTS(p) (((p) >> 24) & 0x7f)
|
|
|
|
|
|
|
|
/* HCSPARAMS2 - hcs_params2 - bitmasks */
|
|
|
|
/* bits 0:3, frames or uframes that SW needs to queue transactions
|
|
|
|
* ahead of the HW to meet periodic deadlines */
|
|
|
|
#define HCS_IST(p) (((p) >> 0) & 0xf)
|
|
|
|
/* bits 4:7, max number of Event Ring segments */
|
|
|
|
#define HCS_ERST_MAX(p) (((p) >> 4) & 0xf)
|
2015-02-25 00:27:01 +08:00
|
|
|
/* bits 21:25 Hi 5 bits of Scratchpad buffers SW must allocate for the HW */
|
2009-04-28 10:52:22 +08:00
|
|
|
/* bit 26 Scratchpad restore - for save/restore HW state - not used yet */
|
2015-02-25 00:27:01 +08:00
|
|
|
/* bits 27:31 Lo 5 bits of Scratchpad buffers SW must allocate for the HW */
|
|
|
|
#define HCS_MAX_SCRATCHPAD(p) ((((p) >> 16) & 0x3e0) | (((p) >> 27) & 0x1f))
|
2009-04-28 10:52:22 +08:00
|
|
|
|
|
|
|
/* HCSPARAMS3 - hcs_params3 - bitmasks */
|
|
|
|
/* bits 0:7, Max U1 to U0 latency for the roothub ports */
|
|
|
|
#define HCS_U1_LATENCY(p) (((p) >> 0) & 0xff)
|
|
|
|
/* bits 16:31, Max U2 to U0 latency for the roothub ports */
|
|
|
|
#define HCS_U2_LATENCY(p) (((p) >> 16) & 0xffff)
|
|
|
|
|
|
|
|
/* HCCPARAMS - hcc_params - bitmasks */
|
|
|
|
/* true: HC can use 64-bit address pointers */
|
|
|
|
#define HCC_64BIT_ADDR(p) ((p) & (1 << 0))
|
|
|
|
/* true: HC can do bandwidth negotiation */
|
|
|
|
#define HCC_BANDWIDTH_NEG(p) ((p) & (1 << 1))
|
|
|
|
/* true: HC uses 64-byte Device Context structures
|
|
|
|
* FIXME 64-byte context structures aren't supported yet.
|
|
|
|
*/
|
|
|
|
#define HCC_64BYTE_CONTEXT(p) ((p) & (1 << 2))
|
|
|
|
/* true: HC has port power switches */
|
|
|
|
#define HCC_PPC(p) ((p) & (1 << 3))
|
|
|
|
/* true: HC has port indicators */
|
|
|
|
#define HCS_INDICATOR(p) ((p) & (1 << 4))
|
|
|
|
/* true: HC has Light HC Reset Capability */
|
|
|
|
#define HCC_LIGHT_RESET(p) ((p) & (1 << 5))
|
|
|
|
/* true: HC supports latency tolerance messaging */
|
|
|
|
#define HCC_LTC(p) ((p) & (1 << 6))
|
|
|
|
/* true: no secondary Stream ID Support */
|
|
|
|
#define HCC_NSS(p) ((p) & (1 << 7))
|
2015-08-07 00:24:01 +08:00
|
|
|
/* true: HC supports Stopped - Short Packet */
|
|
|
|
#define HCC_SPC(p) ((p) & (1 << 9))
|
2015-08-07 00:24:00 +08:00
|
|
|
/* true: HC has Contiguous Frame ID Capability */
|
|
|
|
#define HCC_CFC(p) ((p) & (1 << 11))
|
2009-04-28 10:52:22 +08:00
|
|
|
/* Max size for Primary Stream Arrays - 2^(n+1), where n is bits 12:15 */
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
#define HCC_MAX_PSA(p) (1 << ((((p) >> 12) & 0xf) + 1))
|
2009-04-28 10:52:22 +08:00
|
|
|
/* Extended Capabilities pointer from PCI base - section 5.3.6 */
|
|
|
|
#define HCC_EXT_CAPS(p) XHCI_HCC_EXT_CAPS(p)
|
|
|
|
|
|
|
|
/* db_off bitmask - bits 0:1 reserved */
|
|
|
|
#define DBOFF_MASK (~0x3)
|
|
|
|
|
|
|
|
/* run_regs_off bitmask - bits 0:4 reserved */
|
|
|
|
#define RTSOFF_MASK (~0x1f)
|
|
|
|
|
2015-10-01 23:40:31 +08:00
|
|
|
/* HCCPARAMS2 - hcc_params2 - bitmasks */
|
|
|
|
/* true: HC supports U3 entry Capability */
|
|
|
|
#define HCC2_U3C(p) ((p) & (1 << 0))
|
|
|
|
/* true: HC supports Configure endpoint command Max exit latency too large */
|
|
|
|
#define HCC2_CMC(p) ((p) & (1 << 1))
|
|
|
|
/* true: HC supports Force Save context Capability */
|
|
|
|
#define HCC2_FSC(p) ((p) & (1 << 2))
|
|
|
|
/* true: HC supports Compliance Transition Capability */
|
|
|
|
#define HCC2_CTC(p) ((p) & (1 << 3))
|
|
|
|
/* true: HC support Large ESIT payload Capability > 48k */
|
|
|
|
#define HCC2_LEC(p) ((p) & (1 << 4))
|
|
|
|
/* true: HC support Configuration Information Capability */
|
|
|
|
#define HCC2_CIC(p) ((p) & (1 << 5))
|
|
|
|
/* true: HC support Extended TBC Capability, Isoc burst count > 65535 */
|
|
|
|
#define HCC2_ETC(p) ((p) & (1 << 6))
|
2009-04-28 10:52:22 +08:00
|
|
|
|
|
|
|
/* Number of registers per port */
|
|
|
|
#define NUM_PORT_REGS 4
|
|
|
|
|
2013-05-23 22:14:29 +08:00
|
|
|
#define PORTSC 0
|
|
|
|
#define PORTPMSC 1
|
|
|
|
#define PORTLI 2
|
|
|
|
#define PORTHLPMC 3
|
|
|
|
|
2009-04-28 10:52:22 +08:00
|
|
|
/**
|
|
|
|
* struct xhci_op_regs - xHCI Host Controller Operational Registers.
|
|
|
|
* @command: USBCMD - xHC command register
|
|
|
|
* @status: USBSTS - xHC status register
|
|
|
|
* @page_size: This indicates the page size that the host controller
|
|
|
|
* supports. If bit n is set, the HC supports a page size
|
|
|
|
* of 2^(n+12), up to a 128MB page size.
|
|
|
|
* 4K is the minimum page size.
|
|
|
|
* @cmd_ring: CRP - 64-bit Command Ring Pointer
|
|
|
|
* @dcbaa_ptr: DCBAAP - 64-bit Device Context Base Address Array Pointer
|
|
|
|
* @config_reg: CONFIG - Configure Register
|
|
|
|
* @port_status_base: PORTSCn - base address for Port Status and Control
|
|
|
|
* Each port has a Port Status and Control register,
|
|
|
|
* followed by a Port Power Management Status and Control
|
|
|
|
* register, a Port Link Info register, and a reserved
|
|
|
|
* register.
|
|
|
|
* @port_power_base: PORTPMSCn - base address for
|
|
|
|
* Port Power Management Status and Control
|
|
|
|
* @port_link_base: PORTLIn - base address for Port Link Info (current
|
|
|
|
* Link PM state and control) for USB 2.1 and USB 3.0
|
|
|
|
* devices.
|
|
|
|
*/
|
|
|
|
struct xhci_op_regs {
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 command;
|
|
|
|
__le32 status;
|
|
|
|
__le32 page_size;
|
|
|
|
__le32 reserved1;
|
|
|
|
__le32 reserved2;
|
|
|
|
__le32 dev_notification;
|
|
|
|
__le64 cmd_ring;
|
2009-04-28 10:52:22 +08:00
|
|
|
/* rsvd: offset 0x20-2F */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 reserved3[4];
|
|
|
|
__le64 dcbaa_ptr;
|
|
|
|
__le32 config_reg;
|
2009-04-28 10:52:22 +08:00
|
|
|
/* rsvd: offset 0x3C-3FF */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 reserved4[241];
|
2009-04-28 10:52:22 +08:00
|
|
|
/* port 1 registers, which serve as a base address for other ports */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 port_status_base;
|
|
|
|
__le32 port_power_base;
|
|
|
|
__le32 port_link_base;
|
|
|
|
__le32 reserved5;
|
2009-04-28 10:52:22 +08:00
|
|
|
/* registers for ports 2-255 */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 reserved6[NUM_PORT_REGS*254];
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:52:22 +08:00
|
|
|
|
|
|
|
/* USBCMD - USB command - command bitmasks */
|
|
|
|
/* start/stop HC execution - do not write unless HC is halted*/
|
|
|
|
#define CMD_RUN XHCI_CMD_RUN
|
|
|
|
/* Reset HC - resets internal HC state machine and all registers (except
|
|
|
|
* PCI config regs). HC does NOT drive a USB reset on the downstream ports.
|
|
|
|
* The xHCI driver must reinitialize the xHC after setting this bit.
|
|
|
|
*/
|
|
|
|
#define CMD_RESET (1 << 1)
|
|
|
|
/* Event Interrupt Enable - a '1' allows interrupts from the host controller */
|
|
|
|
#define CMD_EIE XHCI_CMD_EIE
|
|
|
|
/* Host System Error Interrupt Enable - get out-of-band signal for HC errors */
|
|
|
|
#define CMD_HSEIE XHCI_CMD_HSEIE
|
|
|
|
/* bits 4:6 are reserved (and should be preserved on writes). */
|
|
|
|
/* light reset (port status stays unchanged) - reset completed when this is 0 */
|
|
|
|
#define CMD_LRESET (1 << 7)
|
2010-10-14 22:23:06 +08:00
|
|
|
/* host controller save/restore state. */
|
2009-04-28 10:52:22 +08:00
|
|
|
#define CMD_CSS (1 << 8)
|
|
|
|
#define CMD_CRS (1 << 9)
|
|
|
|
/* Enable Wrap Event - '1' means xHC generates an event when MFINDEX wraps. */
|
|
|
|
#define CMD_EWE XHCI_CMD_EWE
|
|
|
|
/* MFINDEX power management - '1' means xHC can stop MFINDEX counter if all root
|
|
|
|
* hubs are in U3 (selective suspend), disconnect, disabled, or powered-off.
|
|
|
|
* '0' means the xHC can power it off if all ports are in the disconnect,
|
|
|
|
* disabled, or powered-off state.
|
|
|
|
*/
|
|
|
|
#define CMD_PM_INDEX (1 << 11)
|
2016-02-12 22:40:18 +08:00
|
|
|
/* bit 14 Extended TBC Enable, changes Isoc TRB fields to support larger TBC */
|
|
|
|
#define CMD_ETE (1 << 14)
|
|
|
|
/* bits 15:31 are reserved (and should be preserved on writes). */
|
2009-04-28 10:52:22 +08:00
|
|
|
|
2012-03-15 22:37:08 +08:00
|
|
|
/* IMAN - Interrupt Management Register */
|
2013-02-26 02:56:01 +08:00
|
|
|
#define IMAN_IE (1 << 1)
|
|
|
|
#define IMAN_IP (1 << 0)
|
2012-03-15 22:37:08 +08:00
|
|
|
|
2009-04-28 10:52:22 +08:00
|
|
|
/* USBSTS - USB status - status bitmasks */
|
|
|
|
/* HC not running - set to 1 when run/stop bit is cleared. */
|
|
|
|
#define STS_HALT XHCI_STS_HALT
|
|
|
|
/* serious error, e.g. PCI parity error. The HC will clear the run/stop bit. */
|
|
|
|
#define STS_FATAL (1 << 2)
|
|
|
|
/* event interrupt - clear this prior to clearing any IP flags in IR set*/
|
|
|
|
#define STS_EINT (1 << 3)
|
|
|
|
/* port change detect */
|
|
|
|
#define STS_PORT (1 << 4)
|
|
|
|
/* bits 5:7 reserved and zeroed */
|
|
|
|
/* save state status - '1' means xHC is saving state */
|
|
|
|
#define STS_SAVE (1 << 8)
|
|
|
|
/* restore state status - '1' means xHC is restoring state */
|
|
|
|
#define STS_RESTORE (1 << 9)
|
|
|
|
/* true: save or restore error */
|
|
|
|
#define STS_SRE (1 << 10)
|
|
|
|
/* true: Controller Not Ready to accept doorbell or op reg writes after reset */
|
|
|
|
#define STS_CNR XHCI_STS_CNR
|
|
|
|
/* true: internal Host Controller Error - SW needs to reset and reinitialize */
|
|
|
|
#define STS_HCE (1 << 12)
|
|
|
|
/* bits 13:31 reserved and should be preserved */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* DNCTRL - Device Notification Control Register - dev_notification bitmasks
|
|
|
|
* Generate a device notification event when the HC sees a transaction with a
|
|
|
|
* notification type that matches a bit set in this bit field.
|
|
|
|
*/
|
|
|
|
#define DEV_NOTE_MASK (0xffff)
|
2011-03-20 17:15:17 +08:00
|
|
|
#define ENABLE_DEV_NOTE(x) (1 << (x))
|
2009-04-28 10:52:22 +08:00
|
|
|
/* Most of the device notification types should only be used for debug.
|
|
|
|
* SW does need to pay attention to function wake notifications.
|
|
|
|
*/
|
|
|
|
#define DEV_NOTE_FWAKE ENABLE_DEV_NOTE(1)
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
/* CRCR - Command Ring Control Register - cmd_ring bitmasks */
|
|
|
|
/* bit 0 is the command ring cycle state */
|
|
|
|
/* stop ring operation after completion of the currently executing command */
|
|
|
|
#define CMD_RING_PAUSE (1 << 1)
|
|
|
|
/* stop ring immediately - abort the currently executing command */
|
|
|
|
#define CMD_RING_ABORT (1 << 2)
|
|
|
|
/* true: command ring is running */
|
|
|
|
#define CMD_RING_RUNNING (1 << 3)
|
|
|
|
/* bits 4:5 reserved and should be preserved */
|
|
|
|
/* Command Ring pointer - bit mask for the lower 32 bits. */
|
2009-07-28 03:03:31 +08:00
|
|
|
#define CMD_RING_RSVD_BITS (0x3f)
|
2009-04-28 10:52:34 +08:00
|
|
|
|
2009-04-28 10:52:22 +08:00
|
|
|
/* CONFIG - Configure Register - config_reg bitmasks */
|
|
|
|
/* bits 0:7 - maximum number of device slots enabled (NumSlotsEn) */
|
|
|
|
#define MAX_DEVS(p) ((p) & 0xff)
|
2015-10-01 23:40:31 +08:00
|
|
|
/* bit 8: U3 Entry Enabled, assert PLC when root port enters U3, xhci 1.1 */
|
|
|
|
#define CONFIG_U3E (1 << 8)
|
|
|
|
/* bit 9: Configuration Information Enable, xhci 1.1 */
|
|
|
|
#define CONFIG_CIE (1 << 9)
|
|
|
|
/* bits 10:31 - reserved and should be preserved */
|
2009-04-28 10:52:22 +08:00
|
|
|
|
|
|
|
/* PORTSC - Port Status and Control Register - port_status_base bitmasks */
|
|
|
|
/* true: device connected */
|
|
|
|
#define PORT_CONNECT (1 << 0)
|
|
|
|
/* true: port enabled */
|
|
|
|
#define PORT_PE (1 << 1)
|
|
|
|
/* bit 2 reserved and zeroed */
|
|
|
|
/* true: port has an over-current condition */
|
|
|
|
#define PORT_OC (1 << 3)
|
|
|
|
/* true: port reset signaling asserted */
|
|
|
|
#define PORT_RESET (1 << 4)
|
|
|
|
/* Port Link State - bits 5:8
|
|
|
|
* A read gives the current link PM state of the port,
|
|
|
|
* a write with Link State Write Strobe set sets the link state.
|
|
|
|
*/
|
2010-10-14 22:22:57 +08:00
|
|
|
#define PORT_PLS_MASK (0xf << 5)
|
|
|
|
#define XDEV_U0 (0x0 << 5)
|
2011-09-24 05:19:51 +08:00
|
|
|
#define XDEV_U2 (0x2 << 5)
|
2010-10-14 22:22:57 +08:00
|
|
|
#define XDEV_U3 (0x3 << 5)
|
2015-07-21 22:20:30 +08:00
|
|
|
#define XDEV_INACTIVE (0x6 << 5)
|
2010-10-14 22:22:57 +08:00
|
|
|
#define XDEV_RESUME (0xf << 5)
|
2009-04-28 10:52:22 +08:00
|
|
|
/* true: port has power (see HCC_PPC) */
|
|
|
|
#define PORT_POWER (1 << 9)
|
|
|
|
/* bits 10:13 indicate device speed:
|
|
|
|
* 0 - undefined speed - port hasn't be initialized by a reset yet
|
|
|
|
* 1 - full speed
|
|
|
|
* 2 - low speed
|
|
|
|
* 3 - high speed
|
|
|
|
* 4 - super speed
|
|
|
|
* 5-15 reserved
|
|
|
|
*/
|
2009-04-28 10:57:38 +08:00
|
|
|
#define DEV_SPEED_MASK (0xf << 10)
|
|
|
|
#define XDEV_FS (0x1 << 10)
|
|
|
|
#define XDEV_LS (0x2 << 10)
|
|
|
|
#define XDEV_HS (0x3 << 10)
|
|
|
|
#define XDEV_SS (0x4 << 10)
|
2015-10-01 23:40:36 +08:00
|
|
|
#define XDEV_SSP (0x5 << 10)
|
2009-04-28 10:52:22 +08:00
|
|
|
#define DEV_UNDEFSPEED(p) (((p) & DEV_SPEED_MASK) == (0x0<<10))
|
2009-04-28 10:57:38 +08:00
|
|
|
#define DEV_FULLSPEED(p) (((p) & DEV_SPEED_MASK) == XDEV_FS)
|
|
|
|
#define DEV_LOWSPEED(p) (((p) & DEV_SPEED_MASK) == XDEV_LS)
|
|
|
|
#define DEV_HIGHSPEED(p) (((p) & DEV_SPEED_MASK) == XDEV_HS)
|
|
|
|
#define DEV_SUPERSPEED(p) (((p) & DEV_SPEED_MASK) == XDEV_SS)
|
2015-10-01 23:40:36 +08:00
|
|
|
#define DEV_SUPERSPEEDPLUS(p) (((p) & DEV_SPEED_MASK) == XDEV_SSP)
|
|
|
|
#define DEV_SUPERSPEED_ANY(p) (((p) & DEV_SPEED_MASK) >= XDEV_SS)
|
2015-10-01 23:40:39 +08:00
|
|
|
#define DEV_PORT_SPEED(p) (((p) >> 10) & 0x0f)
|
2015-10-01 23:40:36 +08:00
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
/* Bits 20:23 in the Slot Context are the speed for the device */
|
|
|
|
#define SLOT_SPEED_FS (XDEV_FS << 10)
|
|
|
|
#define SLOT_SPEED_LS (XDEV_LS << 10)
|
|
|
|
#define SLOT_SPEED_HS (XDEV_HS << 10)
|
|
|
|
#define SLOT_SPEED_SS (XDEV_SS << 10)
|
2016-01-25 21:30:47 +08:00
|
|
|
#define SLOT_SPEED_SSP (XDEV_SSP << 10)
|
2009-04-28 10:52:22 +08:00
|
|
|
/* Port Indicator Control */
|
|
|
|
#define PORT_LED_OFF (0 << 14)
|
|
|
|
#define PORT_LED_AMBER (1 << 14)
|
|
|
|
#define PORT_LED_GREEN (2 << 14)
|
|
|
|
#define PORT_LED_MASK (3 << 14)
|
|
|
|
/* Port Link State Write Strobe - set this when changing link state */
|
|
|
|
#define PORT_LINK_STROBE (1 << 16)
|
|
|
|
/* true: connect status change */
|
|
|
|
#define PORT_CSC (1 << 17)
|
|
|
|
/* true: port enable change */
|
|
|
|
#define PORT_PEC (1 << 18)
|
|
|
|
/* true: warm reset for a USB 3.0 device is done. A "hot" reset puts the port
|
|
|
|
* into an enabled state, and the device into the default state. A "warm" reset
|
|
|
|
* also resets the link, forcing the device through the link training sequence.
|
|
|
|
* SW can also look at the Port Reset register to see when warm reset is done.
|
|
|
|
*/
|
|
|
|
#define PORT_WRC (1 << 19)
|
|
|
|
/* true: over-current change */
|
|
|
|
#define PORT_OCC (1 << 20)
|
|
|
|
/* true: reset change - 1 to 0 transition of PORT_RESET */
|
|
|
|
#define PORT_RC (1 << 21)
|
|
|
|
/* port link status change - set on some port link state transitions:
|
|
|
|
* Transition Reason
|
|
|
|
* ------------------------------------------------------------------------------
|
|
|
|
* - U3 to Resume Wakeup signaling from a device
|
|
|
|
* - Resume to Recovery to U0 USB 3.0 device resume
|
|
|
|
* - Resume to U0 USB 2.0 device resume
|
|
|
|
* - U3 to Recovery to U0 Software resume of USB 3.0 device complete
|
|
|
|
* - U3 to U0 Software resume of USB 2.0 device complete
|
|
|
|
* - U2 to U0 L1 resume of USB 2.1 device complete
|
|
|
|
* - U0 to U0 (???) L1 entry rejection by USB 2.1 device
|
|
|
|
* - U0 to disabled L1 entry error with USB 2.1 device
|
|
|
|
* - Any state to inactive Error on USB 3.0 port
|
|
|
|
*/
|
|
|
|
#define PORT_PLC (1 << 22)
|
|
|
|
/* port configure error change - port failed to configure its link partner */
|
|
|
|
#define PORT_CEC (1 << 23)
|
2012-06-18 21:20:00 +08:00
|
|
|
/* Cold Attach Status - xHC can set this bit to report device attached during
|
|
|
|
* Sx state. Warm port reset should be perfomed to clear this bit and move port
|
|
|
|
* to connected state.
|
|
|
|
*/
|
|
|
|
#define PORT_CAS (1 << 24)
|
2009-04-28 10:52:22 +08:00
|
|
|
/* wake on connect (enable) */
|
|
|
|
#define PORT_WKCONN_E (1 << 25)
|
|
|
|
/* wake on disconnect (enable) */
|
|
|
|
#define PORT_WKDISC_E (1 << 26)
|
|
|
|
/* wake on over-current (enable) */
|
|
|
|
#define PORT_WKOC_E (1 << 27)
|
|
|
|
/* bits 28:29 reserved */
|
2014-11-28 00:19:17 +08:00
|
|
|
/* true: device is non-removable - for USB 3.0 roothub emulation */
|
2009-04-28 10:52:22 +08:00
|
|
|
#define PORT_DEV_REMOVE (1 << 30)
|
|
|
|
/* Initiate a warm port reset - complete when PORT_WRC is '1' */
|
|
|
|
#define PORT_WR (1 << 31)
|
|
|
|
|
2011-03-18 03:39:49 +08:00
|
|
|
/* We mark duplicate entries with -1 */
|
|
|
|
#define DUPLICATE_ENTRY ((u8)(-1))
|
|
|
|
|
2009-04-28 10:52:22 +08:00
|
|
|
/* Port Power Management Status and Control - port_power_base bitmasks */
|
|
|
|
/* Inactivity timer value for transitions into U1, in microseconds.
|
|
|
|
* Timeout can be up to 127us. 0xFF means an infinite timeout.
|
|
|
|
*/
|
|
|
|
#define PORT_U1_TIMEOUT(p) ((p) & 0xff)
|
2011-11-11 08:02:13 +08:00
|
|
|
#define PORT_U1_TIMEOUT_MASK 0xff
|
2009-04-28 10:52:22 +08:00
|
|
|
/* Inactivity timer value for transitions into U2 */
|
|
|
|
#define PORT_U2_TIMEOUT(p) (((p) & 0xff) << 8)
|
2011-11-11 08:02:13 +08:00
|
|
|
#define PORT_U2_TIMEOUT_MASK (0xff << 8)
|
2009-04-28 10:52:22 +08:00
|
|
|
/* Bits 24:31 for port testing */
|
|
|
|
|
2010-10-14 22:23:03 +08:00
|
|
|
/* USB2 Protocol PORTSPMSC */
|
2011-09-24 05:19:51 +08:00
|
|
|
#define PORT_L1S_MASK 7
|
|
|
|
#define PORT_L1S_SUCCESS 1
|
|
|
|
#define PORT_RWE (1 << 3)
|
|
|
|
#define PORT_HIRD(p) (((p) & 0xf) << 4)
|
2011-09-24 05:19:52 +08:00
|
|
|
#define PORT_HIRD_MASK (0xf << 4)
|
2013-10-08 08:17:20 +08:00
|
|
|
#define PORT_L1DS_MASK (0xff << 8)
|
2011-09-24 05:19:51 +08:00
|
|
|
#define PORT_L1DS(p) (((p) & 0xff) << 8)
|
2011-09-24 05:19:52 +08:00
|
|
|
#define PORT_HLE (1 << 16)
|
2009-04-28 10:52:22 +08:00
|
|
|
|
2015-10-01 23:40:39 +08:00
|
|
|
/* USB3 Protocol PORTLI Port Link Information */
|
|
|
|
#define PORT_RX_LANES(p) (((p) >> 16) & 0xf)
|
|
|
|
#define PORT_TX_LANES(p) (((p) >> 20) & 0xf)
|
2013-05-23 22:14:30 +08:00
|
|
|
|
|
|
|
/* USB2 Protocol PORTHLPMC */
|
|
|
|
#define PORT_HIRDM(p)((p) & 3)
|
|
|
|
#define PORT_L1_TIMEOUT(p)(((p) & 0xff) << 2)
|
|
|
|
#define PORT_BESLD(p)(((p) & 0xf) << 10)
|
|
|
|
|
|
|
|
/* use 512 microseconds as USB2 LPM L1 default timeout. */
|
|
|
|
#define XHCI_L1_TIMEOUT 512
|
|
|
|
|
|
|
|
/* Set default HIRD/BESL value to 4 (350/400us) for USB2 L1 LPM resume latency.
|
|
|
|
* Safe to use with mixed HIRD and BESL systems (host and device) and is used
|
|
|
|
* by other operating systems.
|
|
|
|
*
|
|
|
|
* XHCI 1.0 errata 8/14/12 Table 13 notes:
|
|
|
|
* "Software should choose xHC BESL/BESLD field values that do not violate a
|
|
|
|
* device's resume latency requirements,
|
|
|
|
* e.g. not program values > '4' if BLC = '1' and a HIRD device is attached,
|
|
|
|
* or not program values < '4' if BLC = '0' and a BESL device is attached.
|
|
|
|
*/
|
|
|
|
#define XHCI_DEFAULT_BESL 4
|
|
|
|
|
2009-04-28 10:52:22 +08:00
|
|
|
/**
|
2009-05-15 02:44:18 +08:00
|
|
|
* struct xhci_intr_reg - Interrupt Register Set
|
2009-04-28 10:52:22 +08:00
|
|
|
* @irq_pending: IMAN - Interrupt Management Register. Used to enable
|
|
|
|
* interrupts and check for pending interrupts.
|
|
|
|
* @irq_control: IMOD - Interrupt Moderation Register.
|
|
|
|
* Used to throttle interrupts.
|
|
|
|
* @erst_size: Number of segments in the Event Ring Segment Table (ERST).
|
|
|
|
* @erst_base: ERST base address.
|
|
|
|
* @erst_dequeue: Event ring dequeue pointer.
|
|
|
|
*
|
|
|
|
* Each interrupter (defined by a MSI-X vector) has an event ring and an Event
|
|
|
|
* Ring Segment Table (ERST) associated with it. The event ring is comprised of
|
|
|
|
* multiple segments of the same size. The HC places events on the ring and
|
|
|
|
* "updates the Cycle bit in the TRBs to indicate to software the current
|
|
|
|
* position of the Enqueue Pointer." The HCD (Linux) processes those events and
|
|
|
|
* updates the dequeue pointer.
|
|
|
|
*/
|
2009-05-15 02:44:18 +08:00
|
|
|
struct xhci_intr_reg {
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 irq_pending;
|
|
|
|
__le32 irq_control;
|
|
|
|
__le32 erst_size;
|
|
|
|
__le32 rsvd;
|
|
|
|
__le64 erst_base;
|
|
|
|
__le64 erst_dequeue;
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:52:22 +08:00
|
|
|
|
2009-04-28 10:52:28 +08:00
|
|
|
/* irq_pending bitmasks */
|
2009-04-28 10:52:22 +08:00
|
|
|
#define ER_IRQ_PENDING(p) ((p) & 0x1)
|
2009-04-28 10:52:28 +08:00
|
|
|
/* bits 2:31 need to be preserved */
|
2009-04-28 10:53:56 +08:00
|
|
|
/* THIS IS BUGGY - FIXME - IP IS WRITE 1 TO CLEAR */
|
2009-04-28 10:52:28 +08:00
|
|
|
#define ER_IRQ_CLEAR(p) ((p) & 0xfffffffe)
|
|
|
|
#define ER_IRQ_ENABLE(p) ((ER_IRQ_CLEAR(p)) | 0x2)
|
|
|
|
#define ER_IRQ_DISABLE(p) ((ER_IRQ_CLEAR(p)) & ~(0x2))
|
|
|
|
|
|
|
|
/* irq_control bitmasks */
|
|
|
|
/* Minimum interval between interrupts (in 250ns intervals). The interval
|
|
|
|
* between interrupts will be longer if there are no events on the event ring.
|
|
|
|
* Default is 4000 (1 ms).
|
|
|
|
*/
|
|
|
|
#define ER_IRQ_INTERVAL_MASK (0xffff)
|
|
|
|
/* Counter used to count down the time to the next interrupt - HW use only */
|
|
|
|
#define ER_IRQ_COUNTER_MASK (0xffff << 16)
|
|
|
|
|
|
|
|
/* erst_size bitmasks */
|
2009-04-28 10:52:22 +08:00
|
|
|
/* Preserve bits 16:31 of erst_size */
|
2009-04-28 10:52:28 +08:00
|
|
|
#define ERST_SIZE_MASK (0xffff << 16)
|
|
|
|
|
|
|
|
/* erst_dequeue bitmasks */
|
|
|
|
/* Dequeue ERST Segment Index (DESI) - Segment number (or alias)
|
|
|
|
* where the current dequeue pointer lies. This is an optional HW hint.
|
|
|
|
*/
|
|
|
|
#define ERST_DESI_MASK (0x7)
|
|
|
|
/* Event Handler Busy (EHB) - is the event ring scheduled to be serviced by
|
|
|
|
* a work queue (or delayed service routine)?
|
|
|
|
*/
|
|
|
|
#define ERST_EHB (1 << 3)
|
2009-04-28 10:52:34 +08:00
|
|
|
#define ERST_PTR_MASK (0xf)
|
2009-04-28 10:52:22 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* struct xhci_run_regs
|
|
|
|
* @microframe_index:
|
|
|
|
* MFINDEX - current microframe number
|
|
|
|
*
|
|
|
|
* Section 5.5 Host Controller Runtime Registers:
|
|
|
|
* "Software should read and write these registers using only Dword (32 bit)
|
|
|
|
* or larger accesses"
|
|
|
|
*/
|
|
|
|
struct xhci_run_regs {
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 microframe_index;
|
|
|
|
__le32 rsvd[7];
|
2009-05-15 02:44:18 +08:00
|
|
|
struct xhci_intr_reg ir_set[128];
|
|
|
|
};
|
2009-04-28 10:52:22 +08:00
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
/**
|
|
|
|
* struct doorbell_array
|
|
|
|
*
|
2010-12-16 03:18:11 +08:00
|
|
|
* Bits 0 - 7: Endpoint target
|
|
|
|
* Bits 8 - 15: RsvdZ
|
|
|
|
* Bits 16 - 31: Stream ID
|
|
|
|
*
|
2009-04-28 10:52:34 +08:00
|
|
|
* Section 5.6
|
|
|
|
*/
|
|
|
|
struct xhci_doorbell_array {
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 doorbell[256];
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:52:34 +08:00
|
|
|
|
2010-12-16 03:18:11 +08:00
|
|
|
#define DB_VALUE(ep, stream) ((((ep) + 1) & 0xff) | ((stream) << 16))
|
|
|
|
#define DB_VALUE_HOST 0x00000000
|
2009-04-28 10:52:34 +08:00
|
|
|
|
2010-10-27 07:47:13 +08:00
|
|
|
/**
|
|
|
|
* struct xhci_protocol_caps
|
|
|
|
* @revision: major revision, minor revision, capability ID,
|
|
|
|
* and next capability pointer.
|
|
|
|
* @name_string: Four ASCII characters to say which spec this xHC
|
|
|
|
* follows, typically "USB ".
|
|
|
|
* @port_info: Port offset, count, and protocol-defined information.
|
|
|
|
*/
|
|
|
|
struct xhci_protocol_caps {
|
|
|
|
u32 revision;
|
|
|
|
u32 name_string;
|
|
|
|
u32 port_info;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define XHCI_EXT_PORT_MAJOR(x) (((x) >> 24) & 0xff)
|
2015-10-01 23:40:34 +08:00
|
|
|
#define XHCI_EXT_PORT_MINOR(x) (((x) >> 16) & 0xff)
|
|
|
|
#define XHCI_EXT_PORT_PSIC(x) (((x) >> 28) & 0x0f)
|
2010-10-27 07:47:13 +08:00
|
|
|
#define XHCI_EXT_PORT_OFF(x) ((x) & 0xff)
|
|
|
|
#define XHCI_EXT_PORT_COUNT(x) (((x) >> 8) & 0xff)
|
|
|
|
|
2015-10-01 23:40:34 +08:00
|
|
|
#define XHCI_EXT_PORT_PSIV(x) (((x) >> 0) & 0x0f)
|
|
|
|
#define XHCI_EXT_PORT_PSIE(x) (((x) >> 4) & 0x03)
|
|
|
|
#define XHCI_EXT_PORT_PLT(x) (((x) >> 6) & 0x03)
|
|
|
|
#define XHCI_EXT_PORT_PFD(x) (((x) >> 8) & 0x01)
|
|
|
|
#define XHCI_EXT_PORT_LP(x) (((x) >> 14) & 0x03)
|
|
|
|
#define XHCI_EXT_PORT_PSIM(x) (((x) >> 16) & 0xffff)
|
|
|
|
|
|
|
|
#define PLT_MASK (0x03 << 6)
|
|
|
|
#define PLT_SYM (0x00 << 6)
|
|
|
|
#define PLT_ASYM_RX (0x02 << 6)
|
|
|
|
#define PLT_ASYM_TX (0x03 << 6)
|
|
|
|
|
2009-07-28 03:05:15 +08:00
|
|
|
/**
|
|
|
|
* struct xhci_container_ctx
|
|
|
|
* @type: Type of context. Used to calculated offsets to contained contexts.
|
|
|
|
* @size: Size of the context data
|
|
|
|
* @bytes: The raw context data given to HW
|
|
|
|
* @dma: dma address of the bytes
|
|
|
|
*
|
|
|
|
* Represents either a Device or Input context. Holds a pointer to the raw
|
|
|
|
* memory used for the context (bytes) and dma address of it (dma).
|
|
|
|
*/
|
|
|
|
struct xhci_container_ctx {
|
|
|
|
unsigned type;
|
|
|
|
#define XHCI_CTX_TYPE_DEVICE 0x1
|
|
|
|
#define XHCI_CTX_TYPE_INPUT 0x2
|
|
|
|
|
|
|
|
int size;
|
|
|
|
|
|
|
|
u8 *bytes;
|
|
|
|
dma_addr_t dma;
|
|
|
|
};
|
|
|
|
|
2009-04-28 10:53:42 +08:00
|
|
|
/**
|
|
|
|
* struct xhci_slot_ctx
|
|
|
|
* @dev_info: Route string, device speed, hub info, and last valid endpoint
|
|
|
|
* @dev_info2: Max exit latency for device number, root hub port number
|
|
|
|
* @tt_info: tt_info is used to construct split transaction tokens
|
|
|
|
* @dev_state: slot state and device address
|
|
|
|
*
|
|
|
|
* Slot Context - section 6.2.1.1. This assumes the HC uses 32-byte context
|
|
|
|
* structures. If the HC uses 64-byte contexts, there is an additional 32 bytes
|
|
|
|
* reserved at the end of the slot context for HC internal use.
|
|
|
|
*/
|
|
|
|
struct xhci_slot_ctx {
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 dev_info;
|
|
|
|
__le32 dev_info2;
|
|
|
|
__le32 tt_info;
|
|
|
|
__le32 dev_state;
|
2009-04-28 10:53:42 +08:00
|
|
|
/* offset 0x10 to 0x1f reserved for HC internal use */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 reserved[4];
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:53:42 +08:00
|
|
|
|
|
|
|
/* dev_info bitmasks */
|
|
|
|
/* Route String - 0:19 */
|
|
|
|
#define ROUTE_STRING_MASK (0xfffff)
|
|
|
|
/* Device speed - values defined by PORTSC Device Speed field - 20:23 */
|
|
|
|
#define DEV_SPEED (0xf << 20)
|
|
|
|
/* bit 24 reserved */
|
|
|
|
/* Is this LS/FS device connected through a HS hub? - bit 25 */
|
|
|
|
#define DEV_MTT (0x1 << 25)
|
|
|
|
/* Set if the device is a hub - bit 26 */
|
|
|
|
#define DEV_HUB (0x1 << 26)
|
|
|
|
/* Index of the last valid endpoint context in this device context - 27:31 */
|
2009-04-28 10:57:38 +08:00
|
|
|
#define LAST_CTX_MASK (0x1f << 27)
|
|
|
|
#define LAST_CTX(p) ((p) << 27)
|
|
|
|
#define LAST_CTX_TO_EP_NUM(p) (((p) >> 27) - 1)
|
|
|
|
#define SLOT_FLAG (1 << 0)
|
|
|
|
#define EP0_FLAG (1 << 1)
|
2009-04-28 10:53:42 +08:00
|
|
|
|
|
|
|
/* dev_info2 bitmasks */
|
|
|
|
/* Max Exit Latency (ms) - worst case time to wake up all links in dev path */
|
|
|
|
#define MAX_EXIT (0xffff)
|
|
|
|
/* Root hub port number that is needed to access the USB device */
|
2009-04-28 10:57:38 +08:00
|
|
|
#define ROOT_HUB_PORT(p) (((p) & 0xff) << 16)
|
2010-10-14 22:22:57 +08:00
|
|
|
#define DEVINFO_TO_ROOT_HUB_PORT(p) (((p) >> 16) & 0xff)
|
2009-09-05 01:53:20 +08:00
|
|
|
/* Maximum number of ports under a hub device */
|
|
|
|
#define XHCI_MAX_PORTS(p) (((p) & 0xff) << 24)
|
2009-04-28 10:53:42 +08:00
|
|
|
|
|
|
|
/* tt_info bitmasks */
|
|
|
|
/*
|
|
|
|
* TT Hub Slot ID - for low or full speed devices attached to a high-speed hub
|
|
|
|
* The Slot ID of the hub that isolates the high speed signaling from
|
|
|
|
* this low or full-speed device. '0' if attached to root hub port.
|
|
|
|
*/
|
|
|
|
#define TT_SLOT (0xff)
|
|
|
|
/*
|
|
|
|
* The number of the downstream facing port of the high-speed hub
|
|
|
|
* '0' if the device is not low or full speed.
|
|
|
|
*/
|
|
|
|
#define TT_PORT (0xff << 8)
|
2009-09-05 01:53:20 +08:00
|
|
|
#define TT_THINK_TIME(p) (((p) & 0x3) << 16)
|
2009-04-28 10:53:42 +08:00
|
|
|
|
|
|
|
/* dev_state bitmasks */
|
|
|
|
/* USB device address - assigned by the HC */
|
2009-04-28 10:57:38 +08:00
|
|
|
#define DEV_ADDR_MASK (0xff)
|
2009-04-28 10:53:42 +08:00
|
|
|
/* bits 8:26 reserved */
|
|
|
|
/* Slot state */
|
|
|
|
#define SLOT_STATE (0x1f << 27)
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
#define GET_SLOT_STATE(p) (((p) & (0x1f << 27)) >> 27)
|
2009-04-28 10:53:42 +08:00
|
|
|
|
2011-06-02 05:27:49 +08:00
|
|
|
#define SLOT_STATE_DISABLED 0
|
|
|
|
#define SLOT_STATE_ENABLED SLOT_STATE_DISABLED
|
|
|
|
#define SLOT_STATE_DEFAULT 1
|
|
|
|
#define SLOT_STATE_ADDRESSED 2
|
|
|
|
#define SLOT_STATE_CONFIGURED 3
|
2009-04-28 10:53:42 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* struct xhci_ep_ctx
|
|
|
|
* @ep_info: endpoint state, streams, mult, and interval information.
|
|
|
|
* @ep_info2: information on endpoint type, max packet size, max burst size,
|
|
|
|
* error count, and whether the HC will force an event for all
|
|
|
|
* transactions.
|
2009-04-28 10:57:38 +08:00
|
|
|
* @deq: 64-bit ring dequeue pointer address. If the endpoint only
|
|
|
|
* defines one stream, this points to the endpoint transfer ring.
|
|
|
|
* Otherwise, it points to a stream context array, which has a
|
|
|
|
* ring pointer for each flow.
|
|
|
|
* @tx_info:
|
|
|
|
* Average TRB lengths for the endpoint ring and
|
|
|
|
* max payload within an Endpoint Service Interval Time (ESIT).
|
2009-04-28 10:53:42 +08:00
|
|
|
*
|
|
|
|
* Endpoint Context - section 6.2.1.2. This assumes the HC uses 32-byte context
|
|
|
|
* structures. If the HC uses 64-byte contexts, there is an additional 32 bytes
|
|
|
|
* reserved at the end of the endpoint context for HC internal use.
|
|
|
|
*/
|
|
|
|
struct xhci_ep_ctx {
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 ep_info;
|
|
|
|
__le32 ep_info2;
|
|
|
|
__le64 deq;
|
|
|
|
__le32 tx_info;
|
2009-04-28 10:53:42 +08:00
|
|
|
/* offset 0x14 - 0x1f reserved for HC internal use */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 reserved[3];
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:53:42 +08:00
|
|
|
|
|
|
|
/* ep_info bitmasks */
|
|
|
|
/*
|
|
|
|
* Endpoint State - bits 0:2
|
|
|
|
* 0 - disabled
|
|
|
|
* 1 - running
|
|
|
|
* 2 - halted due to halt condition - ok to manipulate endpoint ring
|
|
|
|
* 3 - stopped
|
|
|
|
* 4 - TRB error
|
|
|
|
* 5-7 - reserved
|
|
|
|
*/
|
2009-04-28 10:58:01 +08:00
|
|
|
#define EP_STATE_MASK (0xf)
|
|
|
|
#define EP_STATE_DISABLED 0
|
|
|
|
#define EP_STATE_RUNNING 1
|
|
|
|
#define EP_STATE_HALTED 2
|
|
|
|
#define EP_STATE_STOPPED 3
|
|
|
|
#define EP_STATE_ERROR 4
|
2009-04-28 10:53:42 +08:00
|
|
|
/* Mult - Max number of burtst within an interval, in EP companion desc. */
|
2011-03-20 17:15:17 +08:00
|
|
|
#define EP_MULT(p) (((p) & 0x3) << 8)
|
2011-09-03 02:05:48 +08:00
|
|
|
#define CTX_TO_EP_MULT(p) (((p) >> 8) & 0x3)
|
2009-04-28 10:53:42 +08:00
|
|
|
/* bits 10:14 are Max Primary Streams */
|
|
|
|
/* bit 15 is Linear Stream Array */
|
|
|
|
/* Interval - period between requests to an endpoint - 125u increments. */
|
2011-03-20 17:15:17 +08:00
|
|
|
#define EP_INTERVAL(p) (((p) & 0xff) << 16)
|
2009-09-03 03:14:28 +08:00
|
|
|
#define EP_INTERVAL_TO_UFRAMES(p) (1 << (((p) >> 16) & 0xff))
|
2011-09-03 02:05:48 +08:00
|
|
|
#define CTX_TO_EP_INTERVAL(p) (((p) >> 16) & 0xff)
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
#define EP_MAXPSTREAMS_MASK (0x1f << 10)
|
|
|
|
#define EP_MAXPSTREAMS(p) (((p) << 10) & EP_MAXPSTREAMS_MASK)
|
|
|
|
/* Endpoint is set up with a Linear Stream Array (vs. Secondary Stream Array) */
|
|
|
|
#define EP_HAS_LSA (1 << 15)
|
2009-04-28 10:53:42 +08:00
|
|
|
|
|
|
|
/* ep_info2 bitmasks */
|
|
|
|
/*
|
|
|
|
* Force Event - generate transfer events for all TRBs for this endpoint
|
|
|
|
* This will tell the HC to ignore the IOC and ISP flags (for debugging only).
|
|
|
|
*/
|
|
|
|
#define FORCE_EVENT (0x1)
|
|
|
|
#define ERROR_COUNT(p) (((p) & 0x3) << 1)
|
2009-08-08 05:04:52 +08:00
|
|
|
#define CTX_TO_EP_TYPE(p) (((p) >> 3) & 0x7)
|
2009-04-28 10:53:42 +08:00
|
|
|
#define EP_TYPE(p) ((p) << 3)
|
|
|
|
#define ISOC_OUT_EP 1
|
|
|
|
#define BULK_OUT_EP 2
|
|
|
|
#define INT_OUT_EP 3
|
|
|
|
#define CTRL_EP 4
|
|
|
|
#define ISOC_IN_EP 5
|
|
|
|
#define BULK_IN_EP 6
|
|
|
|
#define INT_IN_EP 7
|
|
|
|
/* bit 6 reserved */
|
|
|
|
/* bit 7 is Host Initiate Disable - for disabling stream selection */
|
|
|
|
#define MAX_BURST(p) (((p)&0xff) << 8)
|
2011-09-03 02:05:48 +08:00
|
|
|
#define CTX_TO_MAX_BURST(p) (((p) >> 8) & 0xff)
|
2009-04-28 10:53:42 +08:00
|
|
|
#define MAX_PACKET(p) (((p)&0xffff) << 16)
|
2009-08-08 05:04:49 +08:00
|
|
|
#define MAX_PACKET_MASK (0xffff << 16)
|
|
|
|
#define MAX_PACKET_DECODED(p) (((p) >> 16) & 0xffff)
|
2009-04-28 10:53:42 +08:00
|
|
|
|
2010-11-11 17:43:57 +08:00
|
|
|
/* Get max packet size from ep desc. Bit 10..0 specify the max packet size.
|
|
|
|
* USB2.0 spec 9.6.6.
|
|
|
|
*/
|
|
|
|
#define GET_MAX_PACKET(p) ((p) & 0x7ff)
|
|
|
|
|
USB: xhci: properly set endpoint context fields for periodic eps.
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval. The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload). This is used by the hardware for bandwidth
management and scheduling of packets.
For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor). Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.
For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).
For FS/LS devices, this is just the max packet size.
The other thing we must set in the endpoint context is the Average TRB
Length. This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD. This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.
It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together. Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD. The Linux
xHCI driver does not use Event Data TRBs.
In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately. For now,
we set it to the same number as the Max ESIT payload.
The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-16 23:07:27 +08:00
|
|
|
/* tx_info bitmasks */
|
2016-02-12 22:40:15 +08:00
|
|
|
#define EP_AVG_TRB_LENGTH(p) ((p) & 0xffff)
|
|
|
|
#define EP_MAX_ESIT_PAYLOAD_LO(p) (((p) & 0xffff) << 16)
|
2016-02-12 22:40:16 +08:00
|
|
|
#define EP_MAX_ESIT_PAYLOAD_HI(p) ((((p) >> 16) & 0xff) << 24)
|
2011-09-03 02:05:48 +08:00
|
|
|
#define CTX_TO_MAX_ESIT_PAYLOAD(p) (((p) >> 16) & 0xffff)
|
USB: xhci: properly set endpoint context fields for periodic eps.
For periodic endpoints, we must let the xHCI hardware know the maximum
payload an endpoint can transfer in one service interval. The xHCI
specification refers to this as the Maximum Endpoint Service Interval Time
Payload (Max ESIT Payload). This is used by the hardware for bandwidth
management and scheduling of packets.
For SuperSpeed endpoints, the maximum is calculated by multiplying the max
packet size by the number of bursts and the number of opportunities to
transfer within a service interval (the Mult field of the SuperSpeed
Endpoint companion descriptor). Devices advertise this in the
wBytesPerInterval field of their SuperSpeed Endpoint Companion Descriptor.
For high speed devices, this is taken by multiplying the max packet size by the
"number of additional transaction opportunities per microframe" (the high
bits of the wMaxPacketSize field in the endpoint descriptor).
For FS/LS devices, this is just the max packet size.
The other thing we must set in the endpoint context is the Average TRB
Length. This is supposed to be the average of the total bytes in the
transfer descriptor (TD), divided by the number of transfer request blocks
(TRBs) it takes to describe the TD. This gives the host controller an
indication of whether the driver will be enqueuing a scatter gather list
with many entries comprised of small buffers, or one contiguous buffer.
It also takes into account the number of extra TRBs you need for every TD.
This includes No-op TRBs and Link TRBs used to link ring segments
together. Some drivers may choose to chain an Event Data TRB on the end
of every TD, thus increasing the average number of TRBs per TD. The Linux
xHCI driver does not use Event Data TRBs.
In theory, if there was an API to allow drivers to state what their
bandwidth requirements are, we could set this field accurately. For now,
we set it to the same number as the Max ESIT payload.
The Average TRB Length should also be set for bulk and control endpoints,
but I have no idea how to guess what it should be.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-16 23:07:27 +08:00
|
|
|
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 07:46:42 +08:00
|
|
|
/* deq bitmasks */
|
|
|
|
#define EP_CTX_CYCLE_MASK (1 << 0)
|
2013-10-04 06:29:49 +08:00
|
|
|
#define SCTX_DEQ_MASK (~0xfL)
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 07:46:42 +08:00
|
|
|
|
2009-04-28 10:53:42 +08:00
|
|
|
|
|
|
|
/**
|
2009-07-28 03:05:15 +08:00
|
|
|
* struct xhci_input_control_context
|
|
|
|
* Input control context; see section 6.2.5.
|
2009-04-28 10:53:42 +08:00
|
|
|
*
|
|
|
|
* @drop_context: set the bit of the endpoint context you want to disable
|
|
|
|
* @add_context: set the bit of the endpoint context you want to enable
|
|
|
|
*/
|
2009-07-28 03:05:15 +08:00
|
|
|
struct xhci_input_control_ctx {
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 drop_flags;
|
|
|
|
__le32 add_flags;
|
|
|
|
__le32 rsvd2[6];
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:53:42 +08:00
|
|
|
|
2011-09-03 02:05:48 +08:00
|
|
|
#define EP_IS_ADDED(ctrl_ctx, i) \
|
|
|
|
(le32_to_cpu(ctrl_ctx->add_flags) & (1 << (i + 1)))
|
|
|
|
#define EP_IS_DROPPED(ctrl_ctx, i) \
|
|
|
|
(le32_to_cpu(ctrl_ctx->drop_flags) & (1 << (i + 1)))
|
|
|
|
|
2009-09-05 01:53:13 +08:00
|
|
|
/* Represents everything that is needed to issue a command on the command ring.
|
|
|
|
* It's useful to pre-allocate these for commands that cannot fail due to
|
|
|
|
* out-of-memory errors, like freeing streams.
|
|
|
|
*/
|
|
|
|
struct xhci_command {
|
|
|
|
/* Input context for changing device state */
|
|
|
|
struct xhci_container_ctx *in_ctx;
|
|
|
|
u32 status;
|
|
|
|
/* If completion is null, no one is waiting on this command
|
|
|
|
* and the structure can be freed after the command completes.
|
|
|
|
*/
|
|
|
|
struct completion *completion;
|
|
|
|
union xhci_trb *command_trb;
|
|
|
|
struct list_head cmd_list;
|
|
|
|
};
|
|
|
|
|
2009-04-28 10:53:42 +08:00
|
|
|
/* drop context bitmasks */
|
|
|
|
#define DROP_EP(x) (0x1 << x)
|
|
|
|
/* add context bitmasks */
|
|
|
|
#define ADD_EP(x) (0x1 << x)
|
|
|
|
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
struct xhci_stream_ctx {
|
|
|
|
/* 64-bit stream ring address, cycle state, and stream type */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le64 stream_ring;
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
/* offset 0x14 - 0x1f reserved for HC internal use */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 reserved[2];
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Stream Context Types (section 6.4.1) - bits 3:1 of stream ctx deq ptr */
|
2013-08-27 04:29:47 +08:00
|
|
|
#define SCT_FOR_CTX(p) (((p) & 0x7) << 1)
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
/* Secondary stream array type, dequeue pointer is to a transfer ring */
|
|
|
|
#define SCT_SEC_TR 0
|
|
|
|
/* Primary stream array type, dequeue pointer is to a transfer ring */
|
|
|
|
#define SCT_PRI_TR 1
|
|
|
|
/* Dequeue pointer is for a secondary stream array (SSA) with 8 entries */
|
|
|
|
#define SCT_SSA_8 2
|
|
|
|
#define SCT_SSA_16 3
|
|
|
|
#define SCT_SSA_32 4
|
|
|
|
#define SCT_SSA_64 5
|
|
|
|
#define SCT_SSA_128 6
|
|
|
|
#define SCT_SSA_256 7
|
|
|
|
|
|
|
|
/* Assume no secondary streams for now */
|
|
|
|
struct xhci_stream_info {
|
|
|
|
struct xhci_ring **stream_rings;
|
|
|
|
/* Number of streams, including stream 0 (which drivers can't use) */
|
|
|
|
unsigned int num_streams;
|
|
|
|
/* The stream context array may be bigger than
|
|
|
|
* the number of streams the driver asked for
|
|
|
|
*/
|
|
|
|
struct xhci_stream_ctx *stream_ctx_array;
|
|
|
|
unsigned int num_stream_ctxs;
|
|
|
|
dma_addr_t ctx_array_dma;
|
|
|
|
/* For mapping physical TRB addresses to segments in stream rings */
|
|
|
|
struct radix_tree_root trb_address_map;
|
|
|
|
struct xhci_command *free_streams_command;
|
|
|
|
};
|
|
|
|
|
|
|
|
#define SMALL_STREAM_ARRAY_SIZE 256
|
|
|
|
#define MEDIUM_STREAM_ARRAY_SIZE 1024
|
|
|
|
|
2011-09-03 02:05:48 +08:00
|
|
|
/* Some Intel xHCI host controllers need software to keep track of the bus
|
|
|
|
* bandwidth. Keep track of endpoint info here. Each root port is allocated
|
|
|
|
* the full bus bandwidth. We must also treat TTs (including each port under a
|
|
|
|
* multi-TT hub) as a separate bandwidth domain. The direct memory interface
|
|
|
|
* (DMI) also limits the total bandwidth (across all domains) that can be used.
|
|
|
|
*/
|
|
|
|
struct xhci_bw_info {
|
2011-09-14 07:41:12 +08:00
|
|
|
/* ep_interval is zero-based */
|
2011-09-03 02:05:48 +08:00
|
|
|
unsigned int ep_interval;
|
2011-09-14 07:41:12 +08:00
|
|
|
/* mult and num_packets are one-based */
|
2011-09-03 02:05:48 +08:00
|
|
|
unsigned int mult;
|
|
|
|
unsigned int num_packets;
|
|
|
|
unsigned int max_packet_size;
|
|
|
|
unsigned int max_esit_payload;
|
|
|
|
unsigned int type;
|
|
|
|
};
|
|
|
|
|
2011-09-03 02:05:52 +08:00
|
|
|
/* "Block" sizes in bytes the hardware uses for different device speeds.
|
|
|
|
* The logic in this part of the hardware limits the number of bits the hardware
|
|
|
|
* can use, so must represent bandwidth in a less precise manner to mimic what
|
|
|
|
* the scheduler hardware computes.
|
|
|
|
*/
|
|
|
|
#define FS_BLOCK 1
|
|
|
|
#define HS_BLOCK 4
|
|
|
|
#define SS_BLOCK 16
|
|
|
|
#define DMI_BLOCK 32
|
|
|
|
|
|
|
|
/* Each device speed has a protocol overhead (CRC, bit stuffing, etc) associated
|
|
|
|
* with each byte transferred. SuperSpeed devices have an initial overhead to
|
|
|
|
* set up bursts. These are in blocks, see above. LS overhead has already been
|
|
|
|
* translated into FS blocks.
|
|
|
|
*/
|
|
|
|
#define DMI_OVERHEAD 8
|
|
|
|
#define DMI_OVERHEAD_BURST 4
|
|
|
|
#define SS_OVERHEAD 8
|
|
|
|
#define SS_OVERHEAD_BURST 32
|
|
|
|
#define HS_OVERHEAD 26
|
|
|
|
#define FS_OVERHEAD 20
|
|
|
|
#define LS_OVERHEAD 128
|
|
|
|
/* The TTs need to claim roughly twice as much bandwidth (94 bytes per
|
|
|
|
* microframe ~= 24Mbps) of the HS bus as the devices can actually use because
|
|
|
|
* of overhead associated with split transfers crossing microframe boundaries.
|
|
|
|
* 31 blocks is pure protocol overhead.
|
|
|
|
*/
|
|
|
|
#define TT_HS_OVERHEAD (31 + 94)
|
|
|
|
#define TT_DMI_OVERHEAD (25 + 12)
|
|
|
|
|
|
|
|
/* Bandwidth limits in blocks */
|
|
|
|
#define FS_BW_LIMIT 1285
|
|
|
|
#define TT_BW_LIMIT 1320
|
|
|
|
#define HS_BW_LIMIT 1607
|
|
|
|
#define SS_BW_LIMIT_IN 3906
|
|
|
|
#define DMI_BW_LIMIT_IN 3906
|
|
|
|
#define SS_BW_LIMIT_OUT 3906
|
|
|
|
#define DMI_BW_LIMIT_OUT 3906
|
|
|
|
|
|
|
|
/* Percentage of bus bandwidth reserved for non-periodic transfers */
|
|
|
|
#define FS_BW_RESERVED 10
|
|
|
|
#define HS_BW_RESERVED 20
|
2011-09-14 07:41:13 +08:00
|
|
|
#define SS_BW_RESERVED 10
|
2011-09-03 02:05:52 +08:00
|
|
|
|
2009-09-05 01:53:09 +08:00
|
|
|
struct xhci_virt_ep {
|
|
|
|
struct xhci_ring *ring;
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
/* Related to endpoints that are configured to use stream IDs only */
|
|
|
|
struct xhci_stream_info *stream_info;
|
2009-09-05 01:53:09 +08:00
|
|
|
/* Temporary storage in case the configure endpoint command fails and we
|
|
|
|
* have to restore the device state to the previous state
|
|
|
|
*/
|
|
|
|
struct xhci_ring *new_ring;
|
|
|
|
unsigned int ep_state;
|
|
|
|
#define SET_DEQ_PENDING (1 << 0)
|
USB: xhci: Handle URB cancel, complete and resubmit race.
In the old code, there was a race condition between the stop endpoint
command and the URB submission process. When the stop endpoint command is
handled by the event handler, the endpoint ring is assumed to be stopped.
When a stop endpoint command is queued, URB submissions are to not ring
the doorbell. The old code would check the number of pending URBs to be
canceled, and would not ring the doorbell if it was non-zero.
However, the following race condition could occur with the old code:
1. Cancel an URB, add it to the list of URBs to be canceled, queue the stop
endpoint command, and increment ep->cancels_pending to 1.
2. The URB finishes on the HW, and an event is enqueued to the event ring
(at the same time as 1).
3. The stop endpoint command finishes, and the endpoint is halted. An
event is queued to the event ring.
4. The event handler sees the finished URB, notices it was to be
canceled, decrements ep->cancels_pending to 0, and removes it from the to
be canceled list.
5. The event handler drops the lock and gives back the URB. The
completion handler requeues the URB (or a different driver enqueues a new
URB). This causes the endpoint's doorbell to be rung, since
ep->cancels_pending == 0. The endpoint is now running.
6. A second URB is canceled, and it's added to the canceled list.
Since ep->cancels_pending == 0, a new stop endpoint command is queued, and
ep->cancels_pending is incremented to 1.
7. The event handler then sees the completed stop endpoint command. The
handler assumes the endpoint is stopped, but it isn't. It attempts to
move the dequeue pointer or change TDs to cancel the second URB, while the
hardware is actively accessing the endpoint ring.
To eliminate this race condition, a new endpoint state bit is introduced,
EP_HALT_PENDING. When this bit is set, a stop endpoint command has been
queued, and the command handler has not begun to process the URB
cancellation list yet. The endpoint doorbell should not be rung when this
is set. Set this when a stop endpoint command is queued, clear it when
the handler for that command runs, and check if it's set before ringing a
doorbell. ep->cancels_pending is eliminated, because it is no longer
used.
Make sure to ring the doorbell for an endpoint when the stop endpoint
command handler runs, even if the canceled URB list is empty. All
canceled URBs could have completed and new URBs could have been enqueued
without the doorbell being rung before the command was handled.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:55:52 +08:00
|
|
|
#define EP_HALTED (1 << 1) /* For stall handling */
|
|
|
|
#define EP_HALT_PENDING (1 << 2) /* For URB cancellation */
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
/* Transitioning the endpoint to using streams, don't enqueue URBs */
|
|
|
|
#define EP_GETTING_STREAMS (1 << 3)
|
|
|
|
#define EP_HAS_STREAMS (1 << 4)
|
|
|
|
/* Transitioning the endpoint to not using streams, don't enqueue URBs */
|
|
|
|
#define EP_GETTING_NO_STREAMS (1 << 5)
|
2009-09-05 01:53:09 +08:00
|
|
|
/* ---- Related to URB cancellation ---- */
|
|
|
|
struct list_head cancelled_td_list;
|
|
|
|
struct xhci_td *stopped_td;
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int stopped_stream;
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
/* Watchdog timer for stop endpoint command to cancel URBs */
|
|
|
|
struct timer_list stop_cmd_timer;
|
|
|
|
int stop_cmds_pending;
|
|
|
|
struct xhci_hcd *xhci;
|
xhci: Update internal dequeue pointers after stalls.
When an endpoint stalls, the xHCI driver must move the endpoint ring's
dequeue pointer past the stalled transfer. To do that, the driver issues
a Set TR Dequeue Pointer command, which will complete some time later.
Takashi was having issues with USB 1.1 audio devices that stalled, and his
analysis of the code was that the old code would not update the xHCI
driver's ring dequeue pointer after the command completes. However, the
dequeue pointer is set in xhci_find_new_dequeue_state(), just before the
set command is issued to the hardware.
Setting the dequeue pointer before the Set TR Dequeue Pointer command
completes is a dangerous thing to do, since the xHCI hardware can fail the
command. Instead, store the new dequeue pointer in the xhci_virt_ep
structure, and update the ring's dequeue pointer when the Set TR dequeue
pointer command completes.
While we're at it, make sure we can't queue another Set TR Dequeue Command
while the first one is still being processed. This just won't work with
the internal xHCI state code. I'm still not sure if this is the right
thing to do, since we might have a case where a driver queues multiple
URBs to a control ring, one of the URBs Stalls, and then the driver tries
to cancel the second URB. There may be a race condition there where the
xHCI driver might try to issue multiple Set TR Dequeue Pointer commands,
but I would have to think very hard about how the Stop Endpoint and
cancellation code works. Keep the fix simple until when/if we run into
that case.
This patch should be queued to kernels all the way back to 2.6.31.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Cc: stable@kernel.org
2011-02-24 07:46:42 +08:00
|
|
|
/* Dequeue pointer and dequeue segment for a submitted Set TR Dequeue
|
|
|
|
* command. We'll need to update the ring's dequeue segment and dequeue
|
|
|
|
* pointer after the command completes.
|
|
|
|
*/
|
|
|
|
struct xhci_segment *queued_deq_seg;
|
|
|
|
union xhci_trb *queued_deq_ptr;
|
2010-07-23 06:23:25 +08:00
|
|
|
/*
|
|
|
|
* Sometimes the xHC can not process isochronous endpoint ring quickly
|
|
|
|
* enough, and it will miss some isoc tds on the ring and generate
|
|
|
|
* a Missed Service Error Event.
|
|
|
|
* Set skip flag when receive a Missed Service Error Event and
|
|
|
|
* process the missed tds on the endpoint ring.
|
|
|
|
*/
|
|
|
|
bool skip;
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
/* Bandwidth checking storage */
|
2011-09-03 02:05:48 +08:00
|
|
|
struct xhci_bw_info bw_info;
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
struct list_head bw_endpoint_list;
|
2015-08-07 00:24:00 +08:00
|
|
|
/* Isoch Frame ID checking storage */
|
|
|
|
int next_frame_id;
|
2016-02-12 22:40:18 +08:00
|
|
|
/* Use new Isoch TRB layout needed for extended TBC support */
|
|
|
|
bool use_extended_tbc;
|
2009-09-05 01:53:09 +08:00
|
|
|
};
|
|
|
|
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
enum xhci_overhead_type {
|
|
|
|
LS_OVERHEAD_TYPE = 0,
|
|
|
|
FS_OVERHEAD_TYPE,
|
|
|
|
HS_OVERHEAD_TYPE,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct xhci_interval_bw {
|
|
|
|
unsigned int num_packets;
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
/* Sorted by max packet size.
|
|
|
|
* Head of the list is the greatest max packet size.
|
|
|
|
*/
|
|
|
|
struct list_head endpoints;
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
/* How many endpoints of each speed are present. */
|
|
|
|
unsigned int overhead[3];
|
|
|
|
};
|
|
|
|
|
|
|
|
#define XHCI_MAX_INTERVAL 16
|
|
|
|
|
|
|
|
struct xhci_interval_bw_table {
|
|
|
|
unsigned int interval0_esit_payload;
|
|
|
|
struct xhci_interval_bw interval_bw[XHCI_MAX_INTERVAL];
|
2011-09-03 02:05:52 +08:00
|
|
|
/* Includes reserved bandwidth for async endpoints */
|
|
|
|
unsigned int bw_used;
|
2011-09-14 07:41:13 +08:00
|
|
|
unsigned int ss_bw_in;
|
|
|
|
unsigned int ss_bw_out;
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
struct xhci_virt_device {
|
2010-10-14 22:22:45 +08:00
|
|
|
struct usb_device *udev;
|
2009-04-28 10:57:38 +08:00
|
|
|
/*
|
|
|
|
* Commands to the hardware are passed an "input context" that
|
|
|
|
* tells the hardware what to change in its data structures.
|
|
|
|
* The hardware will return changes in an "output context" that
|
|
|
|
* software must allocate for the hardware. We need to keep
|
|
|
|
* track of input and output contexts separately because
|
|
|
|
* these commands might fail and we don't trust the hardware.
|
|
|
|
*/
|
2009-07-28 03:05:15 +08:00
|
|
|
struct xhci_container_ctx *out_ctx;
|
2009-04-28 10:57:38 +08:00
|
|
|
/* Used for addressing devices and configuration changes */
|
2009-07-28 03:05:15 +08:00
|
|
|
struct xhci_container_ctx *in_ctx;
|
2009-12-04 01:44:29 +08:00
|
|
|
/* Rings saved to ensure old alt settings can be re-instated */
|
|
|
|
struct xhci_ring **ring_cache;
|
|
|
|
int num_rings_cached;
|
|
|
|
#define XHCI_MAX_RINGS_CACHED 31
|
2009-09-05 01:53:09 +08:00
|
|
|
struct xhci_virt_ep eps[31];
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:58:38 +08:00
|
|
|
struct completion cmd_completion;
|
2011-09-03 02:05:41 +08:00
|
|
|
u8 fake_port;
|
2011-09-03 02:05:45 +08:00
|
|
|
u8 real_port;
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
struct xhci_interval_bw_table *bw_table;
|
|
|
|
struct xhci_tt_bw_info *tt_info;
|
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-10 01:55:03 +08:00
|
|
|
/* The current max exit latency for the enabled USB3 link states. */
|
|
|
|
u16 current_mel;
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* For each roothub, keep track of the bandwidth information for each periodic
|
|
|
|
* interval.
|
|
|
|
*
|
|
|
|
* If a high speed hub is attached to the roothub, each TT associated with that
|
|
|
|
* hub is a separate bandwidth domain. The interval information for the
|
|
|
|
* endpoints on the devices under that TT will appear in the TT structure.
|
|
|
|
*/
|
|
|
|
struct xhci_root_port_bw_info {
|
|
|
|
struct list_head tts;
|
|
|
|
unsigned int num_active_tts;
|
|
|
|
struct xhci_interval_bw_table bw_table;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct xhci_tt_bw_info {
|
|
|
|
struct list_head tt_list;
|
|
|
|
int slot_id;
|
|
|
|
int ttport;
|
|
|
|
struct xhci_interval_bw_table bw_table;
|
|
|
|
int active_eps;
|
2009-04-28 10:57:38 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2009-04-28 10:53:42 +08:00
|
|
|
/**
|
|
|
|
* struct xhci_device_context_array
|
|
|
|
* @dev_context_ptr array of 64-bit DMA addresses for device contexts
|
|
|
|
*/
|
|
|
|
struct xhci_device_context_array {
|
|
|
|
/* 64-bit device addresses; we only write 32-bit addresses */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le64 dev_context_ptrs[MAX_HC_SLOTS];
|
2009-04-28 10:53:42 +08:00
|
|
|
/* private xHCD pointers */
|
|
|
|
dma_addr_t dma;
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:53:42 +08:00
|
|
|
/* TODO: write function to set the 64-bit device DMA address */
|
|
|
|
/*
|
|
|
|
* TODO: change this to be dynamically sized at HC mem init time since the HC
|
|
|
|
* might not be able to handle the maximum number of devices possible.
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
struct xhci_transfer_event {
|
|
|
|
/* 64-bit buffer address, or immediate data */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le64 buffer;
|
|
|
|
__le32 transfer_len;
|
2009-04-28 10:52:34 +08:00
|
|
|
/* This field is interpreted differently based on the type of TRB */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 flags;
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:52:34 +08:00
|
|
|
|
2013-03-21 14:36:48 +08:00
|
|
|
/* Transfer event TRB length bit mask */
|
|
|
|
/* bits 0:23 */
|
|
|
|
#define EVENT_TRB_LEN(p) ((p) & 0xffffff)
|
|
|
|
|
2009-04-28 10:58:01 +08:00
|
|
|
/** Transfer Event bit fields **/
|
|
|
|
#define TRB_TO_EP_ID(p) (((p) >> 16) & 0x1f)
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
/* Completion Code - only applicable for some types of TRBs */
|
|
|
|
#define COMP_CODE_MASK (0xff << 24)
|
|
|
|
#define GET_COMP_CODE(p) (((p) & COMP_CODE_MASK) >> 24)
|
|
|
|
#define COMP_SUCCESS 1
|
|
|
|
/* Data Buffer Error */
|
|
|
|
#define COMP_DB_ERR 2
|
|
|
|
/* Babble Detected Error */
|
|
|
|
#define COMP_BABBLE 3
|
|
|
|
/* USB Transaction Error */
|
|
|
|
#define COMP_TX_ERR 4
|
|
|
|
/* TRB Error - some TRB field is invalid */
|
|
|
|
#define COMP_TRB_ERR 5
|
|
|
|
/* Stall Error - USB device is stalled */
|
|
|
|
#define COMP_STALL 6
|
|
|
|
/* Resource Error - HC doesn't have memory for that device configuration */
|
|
|
|
#define COMP_ENOMEM 7
|
|
|
|
/* Bandwidth Error - not enough room in schedule for this dev config */
|
|
|
|
#define COMP_BW_ERR 8
|
|
|
|
/* No Slots Available Error - HC ran out of device slots */
|
|
|
|
#define COMP_ENOSLOTS 9
|
|
|
|
/* Invalid Stream Type Error */
|
|
|
|
#define COMP_STREAM_ERR 10
|
|
|
|
/* Slot Not Enabled Error - doorbell rung for disabled device slot */
|
|
|
|
#define COMP_EBADSLT 11
|
|
|
|
/* Endpoint Not Enabled Error */
|
|
|
|
#define COMP_EBADEP 12
|
|
|
|
/* Short Packet */
|
|
|
|
#define COMP_SHORT_TX 13
|
|
|
|
/* Ring Underrun - doorbell rung for an empty isoc OUT ep ring */
|
|
|
|
#define COMP_UNDERRUN 14
|
|
|
|
/* Ring Overrun - isoc IN ep ring is empty when ep is scheduled to RX */
|
|
|
|
#define COMP_OVERRUN 15
|
|
|
|
/* Virtual Function Event Ring Full Error */
|
|
|
|
#define COMP_VF_FULL 16
|
|
|
|
/* Parameter Error - Context parameter is invalid */
|
|
|
|
#define COMP_EINVAL 17
|
|
|
|
/* Bandwidth Overrun Error - isoc ep exceeded its allocated bandwidth */
|
|
|
|
#define COMP_BW_OVER 18
|
|
|
|
/* Context State Error - illegal context state transition requested */
|
|
|
|
#define COMP_CTX_STATE 19
|
|
|
|
/* No Ping Response Error - HC didn't get PING_RESPONSE in time to TX */
|
|
|
|
#define COMP_PING_ERR 20
|
|
|
|
/* Event Ring is full */
|
|
|
|
#define COMP_ER_FULL 21
|
2011-06-08 18:34:06 +08:00
|
|
|
/* Incompatible Device Error */
|
|
|
|
#define COMP_DEV_ERR 22
|
2009-04-28 10:52:34 +08:00
|
|
|
/* Missed Service Error - HC couldn't service an isoc ep within interval */
|
|
|
|
#define COMP_MISSED_INT 23
|
|
|
|
/* Successfully stopped command ring */
|
|
|
|
#define COMP_CMD_STOP 24
|
|
|
|
/* Successfully aborted current command and stopped command ring */
|
|
|
|
#define COMP_CMD_ABORT 25
|
|
|
|
/* Stopped - transfer was terminated by a stop endpoint command */
|
|
|
|
#define COMP_STOP 26
|
2011-03-31 09:57:33 +08:00
|
|
|
/* Same as COMP_EP_STOPPED, but the transferred length in the event is invalid */
|
2009-04-28 10:52:34 +08:00
|
|
|
#define COMP_STOP_INVAL 27
|
2015-08-07 00:24:01 +08:00
|
|
|
/* Same as COMP_EP_STOPPED, but a short packet detected */
|
|
|
|
#define COMP_STOP_SHORT 28
|
2011-05-05 18:14:12 +08:00
|
|
|
/* Max Exit Latency Too Large Error */
|
|
|
|
#define COMP_MEL_ERR 29
|
|
|
|
/* TRB type 30 reserved */
|
2009-04-28 10:52:34 +08:00
|
|
|
/* Isoc Buffer Overrun - an isoc IN ep sent more data than could fit in TD */
|
|
|
|
#define COMP_BUFF_OVER 31
|
|
|
|
/* Event Lost Error - xHC has an "internal event overrun condition" */
|
|
|
|
#define COMP_ISSUES 32
|
|
|
|
/* Undefined Error - reported when other error codes don't apply */
|
|
|
|
#define COMP_UNKNOWN 33
|
|
|
|
/* Invalid Stream ID Error */
|
|
|
|
#define COMP_STRID_ERR 34
|
|
|
|
/* Secondary Bandwidth Error - may be returned by a Configure Endpoint cmd */
|
|
|
|
#define COMP_2ND_BW_ERR 35
|
|
|
|
/* Split Transaction Error */
|
|
|
|
#define COMP_SPLIT_ERR 36
|
|
|
|
|
|
|
|
struct xhci_link_trb {
|
|
|
|
/* 64-bit segment pointer*/
|
2011-03-29 10:40:46 +08:00
|
|
|
__le64 segment_ptr;
|
|
|
|
__le32 intr_target;
|
|
|
|
__le32 control;
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
/* control bitfields */
|
|
|
|
#define LINK_TOGGLE (0x1<<1)
|
|
|
|
|
2009-04-28 10:53:56 +08:00
|
|
|
/* Command completion event TRB */
|
|
|
|
struct xhci_event_cmd {
|
|
|
|
/* Pointer to command TRB, or the value passed by the event data trb */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le64 cmd_trb;
|
|
|
|
__le32 status;
|
|
|
|
__le32 flags;
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:52:34 +08:00
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
/* flags bitmasks */
|
2013-12-06 09:07:27 +08:00
|
|
|
|
|
|
|
/* Address device - disable SetAddress */
|
|
|
|
#define TRB_BSR (1<<9)
|
|
|
|
enum xhci_setup_dev {
|
|
|
|
SETUP_CONTEXT_ONLY,
|
|
|
|
SETUP_CONTEXT_ADDRESS,
|
|
|
|
};
|
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
/* bits 16:23 are the virtual function ID */
|
|
|
|
/* bits 24:31 are the slot ID */
|
|
|
|
#define TRB_TO_SLOT_ID(p) (((p) & (0xff<<24)) >> 24)
|
|
|
|
#define SLOT_ID_FOR_TRB(p) (((p) & 0xff) << 24)
|
2009-04-28 10:52:34 +08:00
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
/* Stop Endpoint TRB - ep_index to endpoint ID for this TRB */
|
|
|
|
#define TRB_TO_EP_INDEX(p) ((((p) & (0x1f << 16)) >> 16) - 1)
|
|
|
|
#define EP_ID_FOR_TRB(p) ((((p) + 1) & 0x1f) << 16)
|
|
|
|
|
2010-10-14 22:22:57 +08:00
|
|
|
#define SUSPEND_PORT_FOR_TRB(p) (((p) & 1) << 23)
|
|
|
|
#define TRB_TO_SUSPEND_PORT(p) (((p) & (1 << 23)) >> 23)
|
|
|
|
#define LAST_EP_INDEX 30
|
|
|
|
|
2013-10-04 06:29:48 +08:00
|
|
|
/* Set TR Dequeue Pointer command TRB fields, 6.4.3.9 */
|
2010-04-03 06:34:43 +08:00
|
|
|
#define TRB_TO_STREAM_ID(p) ((((p) & (0xffff << 16)) >> 16))
|
|
|
|
#define STREAM_ID_FOR_TRB(p) ((((p)) & 0xffff) << 16)
|
2013-10-04 06:29:48 +08:00
|
|
|
#define SCT_FOR_TRB(p) (((p) << 1) & 0x7)
|
2010-04-03 06:34:43 +08:00
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
|
2009-04-28 10:57:12 +08:00
|
|
|
/* Port Status Change Event TRB fields */
|
|
|
|
/* Port ID - bits 31:24 */
|
|
|
|
#define GET_PORT_ID(p) (((p) & (0xff << 24)) >> 24)
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
/* Normal TRB fields */
|
|
|
|
/* transfer_len bitmasks - bits 0:16 */
|
|
|
|
#define TRB_LEN(p) ((p) & 0x1ffff)
|
2015-10-09 18:30:08 +08:00
|
|
|
/* TD Size, packets remaining in this TD, bits 21:17 (5 bits, so max 31) */
|
|
|
|
#define TRB_TD_SIZE(p) (min((p), (u32)31) << 17)
|
2016-02-12 22:40:18 +08:00
|
|
|
/* xhci 1.1 uses the TD_SIZE field for TBC if Extended TBC is enabled (ETE) */
|
|
|
|
#define TRB_TD_SIZE_TBC(p) (min((p), (u32)31) << 17)
|
2009-04-28 10:52:34 +08:00
|
|
|
/* Interrupter Target - which MSI-X vector to target the completion event at */
|
|
|
|
#define TRB_INTR_TARGET(p) (((p) & 0x3ff) << 22)
|
|
|
|
#define GET_INTR_TARGET(p) (((p) >> 22) & 0x3ff)
|
2016-02-12 22:40:18 +08:00
|
|
|
/* Total burst count field, Rsvdz on xhci 1.1 with Extended TBC enabled (ETE) */
|
2011-04-09 00:37:29 +08:00
|
|
|
#define TRB_TBC(p) (((p) & 0x3) << 7)
|
2011-04-20 08:43:33 +08:00
|
|
|
#define TRB_TLBPC(p) (((p) & 0xf) << 16)
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
/* Cycle bit - indicates TRB ownership by HC or HCD */
|
|
|
|
#define TRB_CYCLE (1<<0)
|
|
|
|
/*
|
|
|
|
* Force next event data TRB to be evaluated before task switch.
|
|
|
|
* Used to pass OS data back after a TD completes.
|
|
|
|
*/
|
|
|
|
#define TRB_ENT (1<<1)
|
|
|
|
/* Interrupt on short packet */
|
|
|
|
#define TRB_ISP (1<<2)
|
|
|
|
/* Set PCIe no snoop attribute */
|
|
|
|
#define TRB_NO_SNOOP (1<<3)
|
|
|
|
/* Chain multiple TRBs into a TD */
|
|
|
|
#define TRB_CHAIN (1<<4)
|
|
|
|
/* Interrupt on completion */
|
|
|
|
#define TRB_IOC (1<<5)
|
|
|
|
/* The buffer pointer contains immediate data */
|
|
|
|
#define TRB_IDT (1<<6)
|
|
|
|
|
2011-05-05 18:14:02 +08:00
|
|
|
/* Block Event Interrupt */
|
|
|
|
#define TRB_BEI (1<<9)
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
/* Control transfer TRB specific fields */
|
|
|
|
#define TRB_DIR_IN (1<<16)
|
2011-05-05 18:13:56 +08:00
|
|
|
#define TRB_TX_TYPE(p) ((p) << 16)
|
|
|
|
#define TRB_DATA_OUT 2
|
|
|
|
#define TRB_DATA_IN 3
|
2009-04-28 10:52:34 +08:00
|
|
|
|
2010-07-23 06:23:39 +08:00
|
|
|
/* Isochronous TRB specific fields */
|
|
|
|
#define TRB_SIA (1<<31)
|
2015-08-07 00:24:00 +08:00
|
|
|
#define TRB_FRAME_ID(p) (((p) & 0x7ff) << 20)
|
2010-07-23 06:23:39 +08:00
|
|
|
|
2009-04-28 10:53:56 +08:00
|
|
|
struct xhci_generic_trb {
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 field[4];
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:53:56 +08:00
|
|
|
|
|
|
|
union xhci_trb {
|
|
|
|
struct xhci_link_trb link;
|
|
|
|
struct xhci_transfer_event trans_event;
|
|
|
|
struct xhci_event_cmd event_cmd;
|
|
|
|
struct xhci_generic_trb generic;
|
|
|
|
};
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
/* TRB bit mask */
|
|
|
|
#define TRB_TYPE_BITMASK (0xfc00)
|
|
|
|
#define TRB_TYPE(p) ((p) << 10)
|
2010-05-25 04:25:28 +08:00
|
|
|
#define TRB_FIELD_TO_TYPE(p) (((p) & TRB_TYPE_BITMASK) >> 10)
|
2009-04-28 10:52:34 +08:00
|
|
|
/* TRB type IDs */
|
|
|
|
/* bulk, interrupt, isoc scatter/gather, and control data stage */
|
|
|
|
#define TRB_NORMAL 1
|
|
|
|
/* setup stage for control transfers */
|
|
|
|
#define TRB_SETUP 2
|
|
|
|
/* data stage for control transfers */
|
|
|
|
#define TRB_DATA 3
|
|
|
|
/* status stage for control transfers */
|
|
|
|
#define TRB_STATUS 4
|
|
|
|
/* isoc transfers */
|
|
|
|
#define TRB_ISOC 5
|
|
|
|
/* TRB for linking ring segments */
|
|
|
|
#define TRB_LINK 6
|
|
|
|
#define TRB_EVENT_DATA 7
|
|
|
|
/* Transfer Ring No-op (not for the command ring) */
|
|
|
|
#define TRB_TR_NOOP 8
|
|
|
|
/* Command TRBs */
|
|
|
|
/* Enable Slot Command */
|
|
|
|
#define TRB_ENABLE_SLOT 9
|
|
|
|
/* Disable Slot Command */
|
|
|
|
#define TRB_DISABLE_SLOT 10
|
|
|
|
/* Address Device Command */
|
|
|
|
#define TRB_ADDR_DEV 11
|
|
|
|
/* Configure Endpoint Command */
|
|
|
|
#define TRB_CONFIG_EP 12
|
|
|
|
/* Evaluate Context Command */
|
|
|
|
#define TRB_EVAL_CONTEXT 13
|
2009-07-28 03:03:15 +08:00
|
|
|
/* Reset Endpoint Command */
|
|
|
|
#define TRB_RESET_EP 14
|
2009-04-28 10:52:34 +08:00
|
|
|
/* Stop Transfer Ring Command */
|
|
|
|
#define TRB_STOP_RING 15
|
|
|
|
/* Set Transfer Ring Dequeue Pointer Command */
|
|
|
|
#define TRB_SET_DEQ 16
|
|
|
|
/* Reset Device Command */
|
|
|
|
#define TRB_RESET_DEV 17
|
|
|
|
/* Force Event Command (opt) */
|
|
|
|
#define TRB_FORCE_EVENT 18
|
|
|
|
/* Negotiate Bandwidth Command (opt) */
|
|
|
|
#define TRB_NEG_BANDWIDTH 19
|
|
|
|
/* Set Latency Tolerance Value Command (opt) */
|
|
|
|
#define TRB_SET_LT 20
|
|
|
|
/* Get port bandwidth Command */
|
|
|
|
#define TRB_GET_BW 21
|
|
|
|
/* Force Header Command - generate a transaction or link management packet */
|
|
|
|
#define TRB_FORCE_HEADER 22
|
|
|
|
/* No-op Command - not for transfer rings */
|
|
|
|
#define TRB_CMD_NOOP 23
|
|
|
|
/* TRB IDs 24-31 reserved */
|
|
|
|
/* Event TRBS */
|
|
|
|
/* Transfer Event */
|
|
|
|
#define TRB_TRANSFER 32
|
|
|
|
/* Command Completion Event */
|
|
|
|
#define TRB_COMPLETION 33
|
|
|
|
/* Port Status Change Event */
|
|
|
|
#define TRB_PORT_STATUS 34
|
|
|
|
/* Bandwidth Request Event (opt) */
|
|
|
|
#define TRB_BANDWIDTH_EVENT 35
|
|
|
|
/* Doorbell Event (opt) */
|
|
|
|
#define TRB_DOORBELL 36
|
|
|
|
/* Host Controller Event */
|
|
|
|
#define TRB_HC_EVENT 37
|
|
|
|
/* Device Notification Event - device sent function wake notification */
|
|
|
|
#define TRB_DEV_NOTE 38
|
|
|
|
/* MFINDEX Wrap Event - microframe counter wrapped */
|
|
|
|
#define TRB_MFINDEX_WRAP 39
|
|
|
|
/* TRB IDs 40-47 reserved, 48-63 is vendor-defined */
|
|
|
|
|
2010-05-25 04:25:28 +08:00
|
|
|
/* Nec vendor-specific command completion event. */
|
|
|
|
#define TRB_NEC_CMD_COMP 48
|
|
|
|
/* Get NEC firmware revision. */
|
|
|
|
#define TRB_NEC_GET_FW 49
|
|
|
|
|
2011-06-01 08:22:55 +08:00
|
|
|
#define TRB_TYPE_LINK(x) (((x) & TRB_TYPE_BITMASK) == TRB_TYPE(TRB_LINK))
|
|
|
|
/* Above, but for __le32 types -- can avoid work by swapping constants: */
|
|
|
|
#define TRB_TYPE_LINK_LE32(x) (((x) & cpu_to_le32(TRB_TYPE_BITMASK)) == \
|
|
|
|
cpu_to_le32(TRB_TYPE(TRB_LINK)))
|
|
|
|
#define TRB_TYPE_NOOP_LE32(x) (((x) & cpu_to_le32(TRB_TYPE_BITMASK)) == \
|
|
|
|
cpu_to_le32(TRB_TYPE(TRB_TR_NOOP)))
|
|
|
|
|
2010-05-25 04:25:28 +08:00
|
|
|
#define NEC_FW_MINOR(p) (((p) >> 0) & 0xff)
|
|
|
|
#define NEC_FW_MAJOR(p) (((p) >> 8) & 0xff)
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
/*
|
|
|
|
* TRBS_PER_SEGMENT must be a multiple of 4,
|
|
|
|
* since the command ring is 64-byte aligned.
|
|
|
|
* It must also be greater than 16.
|
|
|
|
*/
|
2015-04-30 22:16:03 +08:00
|
|
|
#define TRBS_PER_SEGMENT 256
|
2009-09-05 01:53:13 +08:00
|
|
|
/* Allow two commands + a link TRB, along with any reserved command TRBs */
|
|
|
|
#define MAX_RSVD_CMD_TRBS (TRBS_PER_SEGMENT - 3)
|
2013-03-29 02:48:35 +08:00
|
|
|
#define TRB_SEGMENT_SIZE (TRBS_PER_SEGMENT*16)
|
|
|
|
#define TRB_SEGMENT_SHIFT (ilog2(TRB_SEGMENT_SIZE))
|
2009-04-28 10:58:50 +08:00
|
|
|
/* TRB buffer pointers can't cross 64KB boundaries */
|
|
|
|
#define TRB_MAX_BUFF_SHIFT 16
|
|
|
|
#define TRB_MAX_BUFF_SIZE (1 << TRB_MAX_BUFF_SHIFT)
|
2016-04-22 18:17:09 +08:00
|
|
|
/* How much data is left before the 64KB boundary? */
|
|
|
|
#define TRB_BUFF_LEN_UP_TO_BOUNDARY(addr) (TRB_MAX_BUFF_SIZE - \
|
|
|
|
(addr & (TRB_MAX_BUFF_SIZE - 1)))
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
struct xhci_segment {
|
|
|
|
union xhci_trb *trbs;
|
|
|
|
/* private to HCD */
|
|
|
|
struct xhci_segment *next;
|
|
|
|
dma_addr_t dma;
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:52:34 +08:00
|
|
|
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
struct xhci_td {
|
|
|
|
struct list_head td_list;
|
|
|
|
struct list_head cancelled_td_list;
|
|
|
|
struct urb *urb;
|
|
|
|
struct xhci_segment *start_seg;
|
|
|
|
union xhci_trb *first_trb;
|
|
|
|
union xhci_trb *last_trb;
|
2015-03-06 23:14:21 +08:00
|
|
|
/* actual_length of the URB has already been set */
|
|
|
|
bool urb_length_set;
|
USB: xhci: URB cancellation support.
Add URB cancellation support to the xHCI host controller driver. This
currently supports cancellation for endpoints that do not have streams
enabled.
An URB is represented by a number of Transaction Request Buffers (TRBs),
that are chained together to make one (or more) Transaction Descriptors
(TDs) on an endpoint ring. The ring is comprised of contiguous segments,
linked together with Link TRBs (which may or may not be chained into a TD).
To cancel an URB, we must stop the endpoint ring, make the hardware skip
over the TDs in the URB (either by turning them into No-op TDs, or by
moving the hardware's ring dequeue pointer past the last TRB in the last
TD), and then restart the ring.
There are times when we must drop the xHCI lock during this process, like
when we need to complete cancelled URBs. We must ensure that additional
URBs can be marked as cancelled, and that new URBs can be enqueued (since
the URB completion handlers can do either). The new endpoint ring
variables cancels_pending and state (which can only be modified while
holding the xHCI lock) ensure that future cancellation and enqueueing do
not interrupt any pending cancellation code.
To facilitate cancellation, we must keep track of the starting ring
segment, first TRB, and last TRB for each URB. We also need to keep track
of the list of TDs that have been marked as cancelled, separate from the
list of TDs that are queued for this endpoint. The new variables and
cancellation list are stored in the xhci_td structure.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:02:31 +08:00
|
|
|
};
|
|
|
|
|
2012-06-27 16:31:52 +08:00
|
|
|
/* xHCI command default timeout value */
|
|
|
|
#define XHCI_CMD_DEFAULT_TIMEOUT (5 * HZ)
|
|
|
|
|
2012-06-27 16:31:12 +08:00
|
|
|
/* command descriptor */
|
|
|
|
struct xhci_cd {
|
|
|
|
struct xhci_command *command;
|
|
|
|
union xhci_trb *cmd_trb;
|
|
|
|
};
|
|
|
|
|
2009-08-08 05:04:55 +08:00
|
|
|
struct xhci_dequeue_state {
|
|
|
|
struct xhci_segment *new_deq_seg;
|
|
|
|
union xhci_trb *new_deq_ptr;
|
|
|
|
int new_cycle_state;
|
|
|
|
};
|
|
|
|
|
2012-03-05 17:49:32 +08:00
|
|
|
enum xhci_ring_type {
|
|
|
|
TYPE_CTRL = 0,
|
|
|
|
TYPE_ISOC,
|
|
|
|
TYPE_BULK,
|
|
|
|
TYPE_INTR,
|
|
|
|
TYPE_STREAM,
|
|
|
|
TYPE_COMMAND,
|
|
|
|
TYPE_EVENT,
|
|
|
|
};
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
struct xhci_ring {
|
|
|
|
struct xhci_segment *first_seg;
|
2012-03-05 17:49:33 +08:00
|
|
|
struct xhci_segment *last_seg;
|
2009-04-28 10:52:34 +08:00
|
|
|
union xhci_trb *enqueue;
|
2009-04-28 10:53:56 +08:00
|
|
|
struct xhci_segment *enq_seg;
|
|
|
|
unsigned int enq_updates;
|
2009-04-28 10:52:34 +08:00
|
|
|
union xhci_trb *dequeue;
|
2009-04-28 10:53:56 +08:00
|
|
|
struct xhci_segment *deq_seg;
|
|
|
|
unsigned int deq_updates;
|
2009-04-28 10:58:01 +08:00
|
|
|
struct list_head td_list;
|
2009-04-28 10:52:34 +08:00
|
|
|
/*
|
|
|
|
* Write the cycle state into the TRB cycle field to give ownership of
|
|
|
|
* the TRB to the host controller (if we are the producer), or to check
|
|
|
|
* if we own the TRB (if we are the consumer). See section 4.9.1.
|
|
|
|
*/
|
|
|
|
u32 cycle_state;
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int stream_id;
|
2012-03-05 17:49:33 +08:00
|
|
|
unsigned int num_segs;
|
2012-03-05 17:49:34 +08:00
|
|
|
unsigned int num_trbs_free;
|
|
|
|
unsigned int num_trbs_free_temp;
|
2012-03-05 17:49:32 +08:00
|
|
|
enum xhci_ring_type type;
|
2011-05-26 01:43:56 +08:00
|
|
|
bool last_td_was_short;
|
2013-10-04 06:29:44 +08:00
|
|
|
struct radix_tree_root *trb_address_map;
|
2009-04-28 10:52:34 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct xhci_erst_entry {
|
|
|
|
/* 64-bit event ring segment address */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le64 seg_addr;
|
|
|
|
__le32 seg_size;
|
2009-04-28 10:52:34 +08:00
|
|
|
/* Set to zero */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 rsvd;
|
2009-05-15 02:44:18 +08:00
|
|
|
};
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
struct xhci_erst {
|
|
|
|
struct xhci_erst_entry *entries;
|
|
|
|
unsigned int num_entries;
|
|
|
|
/* xhci->event_ring keeps track of segment dma addresses */
|
|
|
|
dma_addr_t erst_dma_addr;
|
|
|
|
/* Num entries the ERST can contain */
|
|
|
|
unsigned int erst_size;
|
|
|
|
};
|
|
|
|
|
2009-07-28 03:05:03 +08:00
|
|
|
struct xhci_scratchpad {
|
|
|
|
u64 *sp_array;
|
|
|
|
dma_addr_t sp_dma;
|
|
|
|
void **sp_buffers;
|
|
|
|
dma_addr_t *sp_dma_buffers;
|
|
|
|
};
|
|
|
|
|
2010-07-23 06:23:31 +08:00
|
|
|
struct urb_priv {
|
|
|
|
int length;
|
|
|
|
int td_cnt;
|
|
|
|
struct xhci_td *td[0];
|
|
|
|
};
|
|
|
|
|
2009-04-28 10:52:34 +08:00
|
|
|
/*
|
|
|
|
* Each segment table entry is 4*32bits long. 1K seems like an ok size:
|
|
|
|
* (1K bytes * 8bytes/bit) / (4*32 bits) = 64 segment entries in the table,
|
|
|
|
* meaning 64 ring segments.
|
|
|
|
* Initial allocated size of the ERST, in number of entries */
|
|
|
|
#define ERST_NUM_SEGS 1
|
|
|
|
/* Initial allocated size of the ERST, in number of entries */
|
|
|
|
#define ERST_SIZE 64
|
|
|
|
/* Initial number of event segment rings allocated */
|
|
|
|
#define ERST_ENTRIES 1
|
2009-04-28 10:53:56 +08:00
|
|
|
/* Poll every 60 seconds */
|
|
|
|
#define POLL_TIMEOUT 60
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
/* Stop endpoint command timeout (secs) for URB cancellation watchdog timer */
|
|
|
|
#define XHCI_STOP_EP_CMD_TIMEOUT 5
|
2009-04-28 10:52:34 +08:00
|
|
|
/* XXX: Make these module parameters */
|
|
|
|
|
2010-10-14 22:23:06 +08:00
|
|
|
struct s3_save {
|
|
|
|
u32 command;
|
|
|
|
u32 dev_nt;
|
|
|
|
u64 dcbaa_ptr;
|
|
|
|
u32 config_reg;
|
|
|
|
u32 irq_pending;
|
|
|
|
u32 irq_control;
|
|
|
|
u32 erst_size;
|
|
|
|
u64 erst_base;
|
|
|
|
u64 erst_dequeue;
|
|
|
|
};
|
2009-04-28 10:52:22 +08:00
|
|
|
|
2011-09-24 05:19:51 +08:00
|
|
|
/* Use for lpm */
|
|
|
|
struct dev_info {
|
|
|
|
u32 dev_id;
|
|
|
|
struct list_head list;
|
|
|
|
};
|
|
|
|
|
2010-12-16 04:47:14 +08:00
|
|
|
struct xhci_bus_state {
|
|
|
|
unsigned long bus_suspended;
|
|
|
|
unsigned long next_statechange;
|
|
|
|
|
|
|
|
/* Port suspend arrays are indexed by the portnum of the fake roothub */
|
|
|
|
/* ports suspend status arrays - max 31 ports for USB2, 15 for USB3 */
|
|
|
|
u32 port_c_suspend;
|
|
|
|
u32 suspended_ports;
|
USB/xHCI: Support device-initiated USB 3.0 resume.
USB 3.0 hubs don't have a port suspend change bit (that bit is now
reserved). Instead, when a host-initiated resume finishes, the hub sets
the port link state change bit.
When a USB 3.0 device initiates remote wakeup, the parent hubs with
their upstream links in U3 will pass the LFPS up the chain. The first
hub that has an upstream link in U0 (which may be the roothub) will
reflect that LFPS back down the path to the device.
However, the parent hubs in the resumed path will not set their link
state change bit. Instead, the device that initiated the resume has to
send an asynchronous "Function Wake" Device Notification up to the host
controller. Therefore, we need a way to notify the USB core of a device
resume without going through the normal hub URB completion method.
First, make the xHCI roothub act like an external USB 3.0 hub and not
pass up the port link state change bit when a device-initiated resume
finishes. Introduce a new xHCI bit field, port_remote_wakeup, so that
we can tell the difference between a port coming out of the U3Exit state
(host-initiated resume) and the RExit state (ending state of
device-initiated resume).
Since the USB core can't tell whether a port on a hub has resumed by
looking at the Hub Status buffer, we need to introduce a bitfield,
wakeup_bits, that indicates which ports have resumed. When the xHCI
driver notices a port finishing a device-initiated resume, we call into
a new USB core function, usb_wakeup_notification(), that will set
the right bit in wakeup_bits, and kick khubd for that hub.
We also call usb_wakeup_notification() when the Function Wake Device
Notification is received by the xHCI driver. This covers the case where
the link between the roothub and the first-tier hub is in U0, and the
hub reflects the resume signaling back to the device without giving any
indication it has done so until the device sends the Function Wake
notification.
Change the code in khubd that handles the remote wakeup to look at the
state the USB core thinks the device is in, and handle the remote wakeup
if the port's wakeup bit is set.
This patch only takes care of the case where the device is attached
directly to the roothub, or the USB 3.0 hub that is attached to the root
hub is the device sending the Function Wake Device Notification (e.g.
because a new USB device was attached). The other cases will be covered
in a second patch.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-11-15 10:00:01 +08:00
|
|
|
u32 port_remote_wakeup;
|
2010-12-16 04:47:14 +08:00
|
|
|
unsigned long resume_done[USB_MAXCHILDREN];
|
2012-04-14 02:54:30 +08:00
|
|
|
/* which ports have started to resume */
|
|
|
|
unsigned long resuming_ports;
|
usb: Fix xHCI host issues on remote wakeup.
When a device signals remote wakeup on a roothub, and the suspend change
bit is set, the host controller driver must not give control back to the
USB core until the port goes back into the active state.
EHCI accomplishes this by waiting in the get port status function until
the PORT_RESUME bit is cleared:
/* stop resume signaling */
temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME);
ehci_writel(ehci, temp, status_reg);
clear_bit(wIndex, &ehci->resuming_ports);
retval = ehci_handshake(ehci, status_reg,
PORT_RESUME, 0, 2000 /* 2msec */);
Similarly, the xHCI host should wait until the port goes into U0, before
passing control up to the USB core. When the port transitions from the
RExit state to U0, the xHCI driver will get a port status change event.
We need to wait for that event before passing control up to the USB
core.
After the port transitions to the active state, the USB core should time
a recovery interval before it talks to the device. The length of that
recovery interval is TRSMRCY, 10 ms, mentioned in the USB 2.0 spec,
section 7.1.7.7. The previous xHCI code (which did not wait for the
port to go into U0) would cause the USB core to violate that recovery
interval.
This bug caused numerous USB device disconnects on remote wakeup under
ChromeOS and a Lynx Point LP xHCI host that takes up to 20 ms to move
from RExit to U0. ChromeOS is very aggressive about power savings, and
sets the autosuspend_delay to 100 ms, and disables USB persist.
I attempted to replicate this bug with Ubuntu 12.04, but could not. I
used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
was triggered on ChromeOS with. I also changed the USB sysfs settings
as described above, but still could not reproduce the bug under Ubuntu.
It may be that ChromeOS userspace triggers this bug through additional
settings.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-20 23:12:12 +08:00
|
|
|
/* Which ports are waiting on RExit to U0 transition. */
|
|
|
|
unsigned long rexit_ports;
|
|
|
|
struct completion rexit_done[USB_MAXCHILDREN];
|
2010-12-16 04:47:14 +08:00
|
|
|
};
|
|
|
|
|
usb: Fix xHCI host issues on remote wakeup.
When a device signals remote wakeup on a roothub, and the suspend change
bit is set, the host controller driver must not give control back to the
USB core until the port goes back into the active state.
EHCI accomplishes this by waiting in the get port status function until
the PORT_RESUME bit is cleared:
/* stop resume signaling */
temp &= ~(PORT_RWC_BITS | PORT_SUSPEND | PORT_RESUME);
ehci_writel(ehci, temp, status_reg);
clear_bit(wIndex, &ehci->resuming_ports);
retval = ehci_handshake(ehci, status_reg,
PORT_RESUME, 0, 2000 /* 2msec */);
Similarly, the xHCI host should wait until the port goes into U0, before
passing control up to the USB core. When the port transitions from the
RExit state to U0, the xHCI driver will get a port status change event.
We need to wait for that event before passing control up to the USB
core.
After the port transitions to the active state, the USB core should time
a recovery interval before it talks to the device. The length of that
recovery interval is TRSMRCY, 10 ms, mentioned in the USB 2.0 spec,
section 7.1.7.7. The previous xHCI code (which did not wait for the
port to go into U0) would cause the USB core to violate that recovery
interval.
This bug caused numerous USB device disconnects on remote wakeup under
ChromeOS and a Lynx Point LP xHCI host that takes up to 20 ms to move
from RExit to U0. ChromeOS is very aggressive about power savings, and
sets the autosuspend_delay to 100 ms, and disables USB persist.
I attempted to replicate this bug with Ubuntu 12.04, but could not. I
used Ubuntu 12.04 on the same platform, with the same BIOS that the bug
was triggered on ChromeOS with. I also changed the USB sysfs settings
as described above, but still could not reproduce the bug under Ubuntu.
It may be that ChromeOS userspace triggers this bug through additional
settings.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-20 23:12:12 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* It can take up to 20 ms to transition from RExit to U0 on the
|
|
|
|
* Intel Lynx Point LP xHCI host.
|
|
|
|
*/
|
|
|
|
#define XHCI_MAX_REXIT_TIMEOUT (20 * 1000)
|
|
|
|
|
2010-12-16 04:47:14 +08:00
|
|
|
static inline unsigned int hcd_index(struct usb_hcd *hcd)
|
|
|
|
{
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
if (hcd->speed == HCD_USB3)
|
|
|
|
return 0;
|
|
|
|
else
|
|
|
|
return 1;
|
2010-12-16 04:47:14 +08:00
|
|
|
}
|
|
|
|
|
2015-10-01 23:40:34 +08:00
|
|
|
struct xhci_hub {
|
|
|
|
u8 maj_rev;
|
|
|
|
u8 min_rev;
|
|
|
|
u32 *psi; /* array of protocol speed ID entries */
|
|
|
|
u8 psi_count;
|
|
|
|
u8 psi_uid_count;
|
|
|
|
};
|
|
|
|
|
2011-06-29 06:50:19 +08:00
|
|
|
/* There is one xhci_hcd structure per controller */
|
2009-04-28 10:52:22 +08:00
|
|
|
struct xhci_hcd {
|
2010-10-27 02:03:44 +08:00
|
|
|
struct usb_hcd *main_hcd;
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
struct usb_hcd *shared_hcd;
|
2009-04-28 10:52:22 +08:00
|
|
|
/* glue to PCI and HCD framework */
|
|
|
|
struct xhci_cap_regs __iomem *cap_regs;
|
|
|
|
struct xhci_op_regs __iomem *op_regs;
|
|
|
|
struct xhci_run_regs __iomem *run_regs;
|
2009-04-28 10:52:34 +08:00
|
|
|
struct xhci_doorbell_array __iomem *dba;
|
2009-04-28 10:52:28 +08:00
|
|
|
/* Our HCD's current interrupter register set */
|
2009-05-15 02:44:18 +08:00
|
|
|
struct xhci_intr_reg __iomem *ir_set;
|
2009-04-28 10:52:22 +08:00
|
|
|
|
|
|
|
/* Cached register copies of read-only HC data */
|
|
|
|
__u32 hcs_params1;
|
|
|
|
__u32 hcs_params2;
|
|
|
|
__u32 hcs_params3;
|
|
|
|
__u32 hcc_params;
|
2015-10-01 23:40:31 +08:00
|
|
|
__u32 hcc_params2;
|
2009-04-28 10:52:22 +08:00
|
|
|
|
|
|
|
spinlock_t lock;
|
|
|
|
|
|
|
|
/* packed release number */
|
|
|
|
u8 sbrn;
|
|
|
|
u16 hci_version;
|
|
|
|
u8 max_slots;
|
|
|
|
u8 max_interrupters;
|
|
|
|
u8 max_ports;
|
|
|
|
u8 isoc_threshold;
|
|
|
|
int event_ring_max;
|
|
|
|
int addr_64;
|
2009-04-28 10:52:28 +08:00
|
|
|
/* 4KB min, 128MB max */
|
2009-04-28 10:52:22 +08:00
|
|
|
int page_size;
|
2009-04-28 10:52:28 +08:00
|
|
|
/* Valid values are 12 to 20, inclusive */
|
|
|
|
int page_shift;
|
2010-07-22 07:56:08 +08:00
|
|
|
/* msi-x vectors */
|
2009-04-28 10:52:28 +08:00
|
|
|
int msix_count;
|
|
|
|
struct msix_entry *msix_entries;
|
2014-05-15 18:17:32 +08:00
|
|
|
/* optional clock */
|
|
|
|
struct clk *clk;
|
2009-04-28 10:52:34 +08:00
|
|
|
/* data structures */
|
2009-04-28 10:53:42 +08:00
|
|
|
struct xhci_device_context_array *dcbaa;
|
2009-04-28 10:52:34 +08:00
|
|
|
struct xhci_ring *cmd_ring;
|
2012-06-27 16:30:57 +08:00
|
|
|
unsigned int cmd_ring_state;
|
|
|
|
#define CMD_RING_STATE_RUNNING (1 << 0)
|
|
|
|
#define CMD_RING_STATE_ABORTED (1 << 1)
|
|
|
|
#define CMD_RING_STATE_STOPPED (1 << 2)
|
2014-05-09 00:26:01 +08:00
|
|
|
struct list_head cmd_list;
|
2009-09-05 01:53:13 +08:00
|
|
|
unsigned int cmd_ring_reserved_trbs;
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-09 00:26:03 +08:00
|
|
|
struct timer_list cmd_timer;
|
|
|
|
struct xhci_command *current_cmd;
|
2009-04-28 10:52:34 +08:00
|
|
|
struct xhci_ring *event_ring;
|
|
|
|
struct xhci_erst erst;
|
2009-07-28 03:05:03 +08:00
|
|
|
/* Scratchpad */
|
|
|
|
struct xhci_scratchpad *scratchpad;
|
2011-09-24 05:19:51 +08:00
|
|
|
/* Store LPM test failed devices' information */
|
|
|
|
struct list_head lpm_failed_devs;
|
2009-07-28 03:05:03 +08:00
|
|
|
|
2009-04-28 10:57:38 +08:00
|
|
|
/* slot enabling and address device helpers */
|
2015-05-19 21:30:51 +08:00
|
|
|
/* these are not thread safe so use mutex */
|
|
|
|
struct mutex mutex;
|
2009-04-28 10:57:38 +08:00
|
|
|
struct completion addr_dev;
|
|
|
|
int slot_id;
|
2012-05-08 22:32:03 +08:00
|
|
|
/* For USB 3.0 LPM enable/disable. */
|
|
|
|
struct xhci_command *lpm_command;
|
2009-04-28 10:57:38 +08:00
|
|
|
/* Internal mirror of the HW's dcbaa */
|
|
|
|
struct xhci_virt_device *devs[MAX_HC_SLOTS];
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
/* For keeping track of bandwidth domains per roothub. */
|
|
|
|
struct xhci_root_port_bw_info *rh_bw;
|
2009-04-28 10:52:34 +08:00
|
|
|
|
|
|
|
/* DMA pools */
|
|
|
|
struct dma_pool *device_pool;
|
|
|
|
struct dma_pool *segment_pool;
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
struct dma_pool *small_streams_pool;
|
|
|
|
struct dma_pool *medium_streams_pool;
|
2009-04-28 10:53:56 +08:00
|
|
|
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
/* Host controller watchdog timer structures */
|
|
|
|
unsigned int xhc_state;
|
2010-10-14 22:23:03 +08:00
|
|
|
|
|
|
|
u32 command;
|
2010-10-14 22:23:06 +08:00
|
|
|
struct s3_save s3;
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
/* Host controller is dying - not responding to commands. "I'm not dead yet!"
|
|
|
|
*
|
|
|
|
* xHC interrupts have been disabled and a watchdog timer will (or has already)
|
|
|
|
* halt the xHCI host, and complete all URBs with an -ESHUTDOWN code. Any code
|
|
|
|
* that sees this status (other than the timer that set it) should stop touching
|
|
|
|
* hardware immediately. Interrupt handlers should return immediately when
|
|
|
|
* they see this status (any time they drop and re-acquire xhci->lock).
|
|
|
|
* xhci_urb_dequeue() should call usb_hcd_check_unlink_urb() and return without
|
|
|
|
* putting the TD on the canceled list, etc.
|
|
|
|
*
|
|
|
|
* There are no reports of xHCI host controllers that display this issue.
|
|
|
|
*/
|
|
|
|
#define XHCI_STATE_DYING (1 << 0)
|
2011-03-12 02:20:58 +08:00
|
|
|
#define XHCI_STATE_HALTED (1 << 1)
|
2016-04-08 21:25:10 +08:00
|
|
|
#define XHCI_STATE_REMOVING (1 << 2)
|
2009-04-28 10:53:56 +08:00
|
|
|
/* Statistics */
|
|
|
|
int error_bitmask;
|
2009-08-08 05:04:36 +08:00
|
|
|
unsigned int quirks;
|
|
|
|
#define XHCI_LINK_TRB_QUIRK (1 << 0)
|
2009-08-08 05:04:55 +08:00
|
|
|
#define XHCI_RESET_EP_QUIRK (1 << 1)
|
2010-05-25 04:25:28 +08:00
|
|
|
#define XHCI_NEC_HOST (1 << 2)
|
2011-03-22 17:08:14 +08:00
|
|
|
#define XHCI_AMD_PLL_FIX (1 << 3)
|
2011-05-26 01:43:56 +08:00
|
|
|
#define XHCI_SPURIOUS_SUCCESS (1 << 4)
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-12 07:14:58 +08:00
|
|
|
/*
|
|
|
|
* Certain Intel host controllers have a limit to the number of endpoint
|
|
|
|
* contexts they can handle. Ideally, they would signal that they can't handle
|
|
|
|
* anymore endpoint contexts by returning a Resource Error for the Configure
|
|
|
|
* Endpoint command, but they don't. Instead they expect software to keep track
|
|
|
|
* of the number of active endpoints for them, across configure endpoint
|
|
|
|
* commands, reset device commands, disable slot commands, and address device
|
|
|
|
* commands.
|
|
|
|
*/
|
|
|
|
#define XHCI_EP_LIMIT_QUIRK (1 << 5)
|
2011-06-03 02:33:02 +08:00
|
|
|
#define XHCI_BROKEN_MSI (1 << 6)
|
2011-06-16 05:47:21 +08:00
|
|
|
#define XHCI_RESET_ON_RESUME (1 << 7)
|
2011-09-03 02:05:52 +08:00
|
|
|
#define XHCI_SW_BW_CHECKING (1 << 8)
|
xHCI: AMD isoc link TRB chain bit quirk
Setting the chain (CH) bit in the link TRB of isochronous transfer rings
is required by AMD 0.96 xHCI host controller to successfully transverse
multi-TRB TD that span through different memory segments.
When a Missed Service Error event occurs, if the chain bit is not set in
the link TRB and the host skips TDs which just across a link TRB, the
host may falsely recognize the link TRB as a normal TRB. You can see
this may cause big trouble - the host does not jump to the right address
which is pointed by the link TRB, but continue fetching the memory which
is after the link TRB address, which may not even belong to the host,
and the result cannot be predicted.
This causes some big problems. Without the former patch I sent: "xHCI:
prevent infinite loop when processing MSE event", the system may hang.
With that patch applied, system does not hang, but the host still access
wrong memory address and isoc transfer will fail. With this patch,
isochronous transfer works as expected.
This patch should be applied to kernels as old as 2.6.36, which was when
the first isochronous support was added for the xHCI host controller.
Signed-off-by: Andiry Xu <andiry.xu@amd.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-24 05:19:54 +08:00
|
|
|
#define XHCI_AMD_0x96_HOST (1 << 9)
|
xhci: Add new short TX quirk for Fresco Logic host.
Sergio reported that when he recorded audio from a USB headset mic
plugged into the USB 3.0 port on his ASUS N53SV-DH72, the audio sounded
"robotic". When plugged into the USB 2.0 port under EHCI on the same
laptop, the audio sounded fine. The device is:
Bus 002 Device 004: ID 046d:0a0c Logitech, Inc. Clear Chat Comfort USB Headset
The problem was tracked down to the Fresco Logic xHCI host controller
not correctly reporting short transfers on isochronous IN endpoints.
The driver would submit a 96 byte transfer, the device would only send
88 or 90 bytes, and the xHCI host would report the transfer had a
"successful" completion code, with an untransferred buffer length of 8
or 6 bytes.
The successful completion code and non-zero untransferred length is a
contradiction. The xHCI host is supposed to only mark a transfer as
successful if all the bytes are transferred. Otherwise, the transfer
should be marked with a short packet completion code. Without the EHCI
bus trace, we wouldn't know whether the xHCI driver should trust the
completion code or the untransferred length. With it, we know to trust
the untransferred length.
Add a new xHCI quirk for the Fresco Logic host controller. If a
transfer is reported as successful, but the untransferred length is
non-zero, print a warning. For the Fresco Logic host, change the
completion code to COMP_SHORT_TX and process the transfer like a short
transfer.
This should be backported to stable kernels that contain the commit
f5182b4155b9d686c5540a6822486400e34ddd98 "xhci: Disable MSI for some
Fresco Logic hosts." That commit was marked for stable kernels as old
as 2.6.36.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Sergio Correia <lists@uece.net>
Tested-by: Sergio Correia <lists@uece.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-05-09 00:22:49 +08:00
|
|
|
#define XHCI_TRUST_TX_LENGTH (1 << 10)
|
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-10 01:55:03 +08:00
|
|
|
#define XHCI_LPM_SUPPORT (1 << 11)
|
2012-05-17 04:36:24 +08:00
|
|
|
#define XHCI_INTEL_HOST (1 << 12)
|
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 23:59:30 +08:00
|
|
|
#define XHCI_SPURIOUS_REBOOT (1 << 13)
|
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-04 03:00:27 +08:00
|
|
|
#define XHCI_COMP_MODE_QUIRK (1 << 14)
|
xhci: Intel Panther Point BEI quirk.
When a device with an isochronous endpoint is behind a hub plugged into
the Intel Panther Point xHCI host controller, and the driver submits
multiple frames per URB, the xHCI driver will set the Block Event
Interrupt (BEI) flag on all but the last TD for the URB. This causes
the host controller to place an event on the event ring, but not send an
interrupt. When the last TD for the URB completes, BEI is cleared, and
we get an interrupt for the whole URB.
However, under a Panther Point xHCI host controller, if the parent hub
is unplugged when one or more events from transfers with BEI set are on
the event ring, a port status change event is placed on the event ring,
but no interrupt is generated. This means URBs stop completing, and the
USB device disconnect is not noticed. Something like a USB headset will
cause mplayer to hang when the device is disconnected.
If another transfer is sent (such as running `sudo lsusb -v`), the next
transfer event seems to "unstick" the event ring, the xHCI driver gets
an interrupt, and the disconnect is reported to the USB core.
The fix is not to use the BEI flag under the Panther Point xHCI host.
This will impact power consumption and system responsiveness, because
the xHCI driver will receive an interrupt for every frame in all
isochronous URBs instead of once per URB.
Intel chipset developers confirm that this bug will be hit if the BEI
flag is used on any endpoint, not just ones that are behind a hub.
This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable@vger.kernel.org
2012-09-20 07:27:26 +08:00
|
|
|
#define XHCI_AVOID_BEI (1 << 15)
|
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-09 01:08:34 +08:00
|
|
|
#define XHCI_PLAT (1 << 16)
|
2013-09-30 21:50:54 +08:00
|
|
|
#define XHCI_SLOW_SUSPEND (1 << 17)
|
2013-09-12 14:11:06 +08:00
|
|
|
#define XHCI_SPURIOUS_WAKEUP (1 << 18)
|
2014-07-26 04:01:18 +08:00
|
|
|
/* For controllers with a broken beyond repair streams implementation */
|
|
|
|
#define XHCI_BROKEN_STREAMS (1 << 19)
|
2015-03-06 23:23:19 +08:00
|
|
|
#define XHCI_PME_STUCK_QUIRK (1 << 20)
|
2015-11-24 19:09:55 +08:00
|
|
|
#define XHCI_MTK_HOST (1 << 21)
|
2016-01-26 23:50:06 +08:00
|
|
|
#define XHCI_SSIC_PORT_UNUSED (1 << 22)
|
2016-04-08 21:25:07 +08:00
|
|
|
#define XHCI_NO_64BIT_SUPPORT (1 << 23)
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-12 07:14:58 +08:00
|
|
|
unsigned int num_active_eps;
|
|
|
|
unsigned int limit_active_eps;
|
xhci: Register second xHCI roothub.
This patch changes the xHCI driver to allocate two roothubs. This touches
the driver initialization and shutdown paths, roothub emulation code, and
port status change event handlers. This is a rather large patch, but it
can't be broken up, or it would break git-bisect.
Make the xHCI driver register its own PCI probe function. This will call
the USB core to create the USB 2.0 roothub, and then create the USB 3.0
roothub. This gets the code for registering a shared roothub out of the
USB core, and allows other HCDs later to decide if and how many shared
roothubs they want to allocate.
Make sure the xHCI's reset method marks the xHCI host controller's primary
roothub as the USB 2.0 roothub. This ensures that the high speed bus will
be processed first when the PCI device is resumed, and any USB 3.0 devices
that have migrated over to high speed will migrate back after being reset.
This ensures that USB persist works with these odd devices.
The reset method will also mark the xHCI USB2 roothub as having an
integrated TT. Like EHCI host controllers with a "rate matching hub" the
xHCI USB 2.0 roothub doesn't have an OHCI or UHCI companion controller.
It doesn't really have a TT, but we'll lie and say it has an integrated
TT. We need to do this because the USB core will reject LS/FS devices
under a HS hub without a TT.
Other details:
-------------
The roothub emulation code is changed to return the correct number of
ports for the two roothubs. For the USB 3.0 roothub, it only reports the
USB 3.0 ports. For the USB 2.0 roothub, it reports all the LS/FS/HS
ports. The code to disable a port now checks the speed of the roothub,
and refuses to disable SuperSpeed ports under the USB 3.0 roothub.
The code for initializing a new device context must be changed to set the
proper roothub port number. Since we've split the xHCI host into two
roothubs, we can't just use the port number in the ancestor hub. Instead,
we loop through the array of hardware port status register speeds and find
the Nth port with a similar speed.
The port status change event handler is updated to figure out whether the
port that reported the change is a USB 3.0 port, or a non-SuperSpeed port.
Once it figures out the port speed, it kicks the proper roothub.
The function to find a slot ID based on the port index is updated to take
into account that the two roothubs will have over-lapping port indexes.
It checks that the virtual device with a matching port index is the same
speed as the passed in roothub.
There's also changes to the driver initialization and shutdown paths:
1. Make sure that the xhci_hcd pointer is shared across the two
usb_hcd structures. The xhci_hcd pointer is allocated and the
registers are mapped in when xhci_pci_setup() is called with the
primary HCD. When xhci_pci_setup() is called with the non-primary
HCD, the xhci_hcd pointer is stored.
2. Make sure to set the sg_tablesize for both usb_hcd structures. Set
the PCI DMA mask for the non-primary HCD to allow for 64-bit or 32-bit
DMA. (The PCI DMA mask is set from the primary HCD further down in
the xhci_pci_setup() function.)
3. Ensure that the host controller doesn't start kicking khubd in
response to port status changes before both usb_hcd structures are
registered. xhci_run() only starts the xHC running once it has been
called with the non-primary roothub. Similarly, the xhci_stop()
function only halts the host controller when it is called with the
non-primary HCD. Then on the second call, it resets and cleans up the
MSI-X irqs.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2010-12-17 03:21:10 +08:00
|
|
|
/* There are two roothubs to keep track of bus suspend info for */
|
|
|
|
struct xhci_bus_state bus_state[2];
|
2010-10-27 07:47:13 +08:00
|
|
|
/* Is each xHCI roothub port a USB 3.0, USB 2.0, or USB 1.1 port? */
|
|
|
|
u8 *port_array;
|
|
|
|
/* Array of pointers to USB 3.0 PORTSC registers */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 __iomem **usb3_ports;
|
2010-10-27 07:47:13 +08:00
|
|
|
unsigned int num_usb3_ports;
|
|
|
|
/* Array of pointers to USB 2.0 PORTSC registers */
|
2011-03-29 10:40:46 +08:00
|
|
|
__le32 __iomem **usb2_ports;
|
2015-10-01 23:40:34 +08:00
|
|
|
struct xhci_hub usb2_rhub;
|
|
|
|
struct xhci_hub usb3_rhub;
|
2010-10-27 07:47:13 +08:00
|
|
|
unsigned int num_usb2_ports;
|
2011-09-24 05:19:51 +08:00
|
|
|
/* support xHCI 0.96 spec USB2 software LPM */
|
|
|
|
unsigned sw_lpm_support:1;
|
|
|
|
/* support xHCI 1.0 spec USB2 hardware LPM */
|
|
|
|
unsigned hw_lpm_support:1;
|
2013-05-23 22:14:28 +08:00
|
|
|
/* cached usb2 extened protocol capabilites */
|
|
|
|
u32 *ext_caps;
|
|
|
|
unsigned int num_ext_caps;
|
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-04 03:00:27 +08:00
|
|
|
/* Compliance Mode Recovery Data */
|
|
|
|
struct timer_list comp_mode_recovery_timer;
|
|
|
|
u32 port_status_u0;
|
|
|
|
/* Compliance Mode Timer Triggered every 2 seconds */
|
|
|
|
#define COMP_MODE_RCVRY_MSECS 2000
|
2015-11-24 19:09:48 +08:00
|
|
|
|
|
|
|
/* platform-specific data -- must come last */
|
|
|
|
unsigned long priv[0] __aligned(sizeof(s64));
|
2009-04-28 10:52:22 +08:00
|
|
|
};
|
|
|
|
|
2015-05-29 22:01:46 +08:00
|
|
|
/* Platform specific overrides to generic XHCI hc_driver ops */
|
|
|
|
struct xhci_driver_overrides {
|
|
|
|
size_t extra_priv_size;
|
|
|
|
int (*reset)(struct usb_hcd *hcd);
|
|
|
|
int (*start)(struct usb_hcd *hcd);
|
|
|
|
};
|
|
|
|
|
2015-08-07 00:24:00 +08:00
|
|
|
#define XHCI_CFC_DELAY 10
|
|
|
|
|
2009-04-28 10:52:22 +08:00
|
|
|
/* convert between an HCD pointer and the corresponding EHCI_HCD */
|
|
|
|
static inline struct xhci_hcd *hcd_to_xhci(struct usb_hcd *hcd)
|
|
|
|
{
|
2015-05-29 22:01:46 +08:00
|
|
|
struct usb_hcd *primary_hcd;
|
|
|
|
|
|
|
|
if (usb_hcd_is_primary_hcd(hcd))
|
|
|
|
primary_hcd = hcd;
|
|
|
|
else
|
|
|
|
primary_hcd = hcd->primary_hcd;
|
|
|
|
|
|
|
|
return (struct xhci_hcd *) (primary_hcd->hcd_priv);
|
2009-04-28 10:52:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct usb_hcd *xhci_to_hcd(struct xhci_hcd *xhci)
|
|
|
|
{
|
2010-10-27 02:03:44 +08:00
|
|
|
return xhci->main_hcd;
|
2009-04-28 10:52:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#define xhci_dbg(xhci, fmt, args...) \
|
2013-07-02 22:49:27 +08:00
|
|
|
dev_dbg(xhci_to_hcd(xhci)->self.controller , fmt , ## args)
|
2009-04-28 10:52:22 +08:00
|
|
|
#define xhci_err(xhci, fmt, args...) \
|
|
|
|
dev_err(xhci_to_hcd(xhci)->self.controller , fmt , ## args)
|
|
|
|
#define xhci_warn(xhci, fmt, args...) \
|
|
|
|
dev_warn(xhci_to_hcd(xhci)->self.controller , fmt , ## args)
|
2012-07-26 01:52:45 +08:00
|
|
|
#define xhci_warn_ratelimited(xhci, fmt, args...) \
|
|
|
|
dev_warn_ratelimited(xhci_to_hcd(xhci)->self.controller , fmt , ## args)
|
2015-01-16 23:54:01 +08:00
|
|
|
#define xhci_info(xhci, fmt, args...) \
|
|
|
|
dev_info(xhci_to_hcd(xhci)->self.controller , fmt , ## args)
|
2009-04-28 10:52:22 +08:00
|
|
|
|
2014-01-30 06:02:00 +08:00
|
|
|
/*
|
|
|
|
* Registers should always be accessed with double word or quad word accesses.
|
|
|
|
*
|
|
|
|
* Some xHCI implementations may support 64-bit address pointers. Registers
|
|
|
|
* with 64-bit address pointers should be written to with dword accesses by
|
|
|
|
* writing the low dword first (ptr[0]), then the high dword (ptr[1]) second.
|
|
|
|
* xHCI implementations that do not support 64-bit address pointers will ignore
|
|
|
|
* the high dword, and write order is irrelevant.
|
|
|
|
*/
|
2014-01-31 05:27:49 +08:00
|
|
|
static inline u64 xhci_read_64(const struct xhci_hcd *xhci,
|
|
|
|
__le64 __iomem *regs)
|
|
|
|
{
|
2015-10-09 18:30:09 +08:00
|
|
|
return lo_hi_readq(regs);
|
2014-01-31 05:27:49 +08:00
|
|
|
}
|
2014-01-30 06:02:00 +08:00
|
|
|
static inline void xhci_write_64(struct xhci_hcd *xhci,
|
|
|
|
const u64 val, __le64 __iomem *regs)
|
|
|
|
{
|
2015-10-09 18:30:09 +08:00
|
|
|
lo_hi_writeq(val, regs);
|
2014-01-30 06:02:00 +08:00
|
|
|
}
|
|
|
|
|
2009-08-08 05:04:36 +08:00
|
|
|
static inline int xhci_link_trb_quirk(struct xhci_hcd *xhci)
|
|
|
|
{
|
2011-09-14 07:41:10 +08:00
|
|
|
return xhci->quirks & XHCI_LINK_TRB_QUIRK;
|
2009-08-08 05:04:36 +08:00
|
|
|
}
|
|
|
|
|
2009-04-28 10:52:28 +08:00
|
|
|
/* xHCI debugging */
|
2011-02-09 08:29:33 +08:00
|
|
|
void xhci_print_ir_set(struct xhci_hcd *xhci, int set_num);
|
2009-04-28 10:52:28 +08:00
|
|
|
void xhci_print_registers(struct xhci_hcd *xhci);
|
2009-04-28 10:52:34 +08:00
|
|
|
void xhci_dbg_regs(struct xhci_hcd *xhci);
|
|
|
|
void xhci_print_run_regs(struct xhci_hcd *xhci);
|
2009-04-28 10:58:01 +08:00
|
|
|
void xhci_print_trb_offsets(struct xhci_hcd *xhci, union xhci_trb *trb);
|
|
|
|
void xhci_debug_trb(struct xhci_hcd *xhci, union xhci_trb *trb);
|
2009-04-28 10:53:56 +08:00
|
|
|
void xhci_debug_segment(struct xhci_hcd *xhci, struct xhci_segment *seg);
|
2009-04-28 10:52:34 +08:00
|
|
|
void xhci_debug_ring(struct xhci_hcd *xhci, struct xhci_ring *ring);
|
|
|
|
void xhci_dbg_erst(struct xhci_hcd *xhci, struct xhci_erst *erst);
|
|
|
|
void xhci_dbg_cmd_ptrs(struct xhci_hcd *xhci);
|
2009-04-28 10:53:56 +08:00
|
|
|
void xhci_dbg_ring_ptrs(struct xhci_hcd *xhci, struct xhci_ring *ring);
|
2009-07-28 03:05:15 +08:00
|
|
|
void xhci_dbg_ctx(struct xhci_hcd *xhci, struct xhci_container_ctx *ctx, unsigned int last_ep);
|
2010-01-05 04:20:17 +08:00
|
|
|
char *xhci_get_slot_state(struct xhci_hcd *xhci,
|
2009-12-10 07:59:13 +08:00
|
|
|
struct xhci_container_ctx *ctx);
|
2010-04-03 06:34:43 +08:00
|
|
|
void xhci_dbg_ep_rings(struct xhci_hcd *xhci,
|
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
|
|
|
struct xhci_virt_ep *ep);
|
2013-08-06 05:22:15 +08:00
|
|
|
void xhci_dbg_trace(struct xhci_hcd *xhci, void (*trace)(struct va_format *),
|
|
|
|
const char *fmt, ...);
|
2009-04-28 10:52:28 +08:00
|
|
|
|
2009-07-23 14:31:31 +08:00
|
|
|
/* xHCI memory management */
|
2009-04-28 10:52:28 +08:00
|
|
|
void xhci_mem_cleanup(struct xhci_hcd *xhci);
|
|
|
|
int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags);
|
2009-04-28 10:57:38 +08:00
|
|
|
void xhci_free_virt_device(struct xhci_hcd *xhci, int slot_id);
|
|
|
|
int xhci_alloc_virt_device(struct xhci_hcd *xhci, int slot_id, struct usb_device *udev, gfp_t flags);
|
|
|
|
int xhci_setup_addressable_virt_dev(struct xhci_hcd *xhci, struct usb_device *udev);
|
2010-07-09 23:08:54 +08:00
|
|
|
void xhci_copy_ep0_dequeue_into_input_ctx(struct xhci_hcd *xhci,
|
|
|
|
struct usb_device *udev);
|
2009-04-28 10:58:01 +08:00
|
|
|
unsigned int xhci_get_endpoint_index(struct usb_endpoint_descriptor *desc);
|
2013-04-16 06:55:04 +08:00
|
|
|
unsigned int xhci_get_endpoint_address(unsigned int ep_index);
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:58:38 +08:00
|
|
|
unsigned int xhci_get_endpoint_flag(struct usb_endpoint_descriptor *desc);
|
2009-08-08 05:04:55 +08:00
|
|
|
unsigned int xhci_get_endpoint_flag_from_index(unsigned int ep_index);
|
|
|
|
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 10:58:38 +08:00
|
|
|
void xhci_endpoint_zero(struct xhci_hcd *xhci, struct xhci_virt_device *virt_dev, struct usb_host_endpoint *ep);
|
xhci: Track interval bandwidth tables per port/TT.
In order to update the root port or TT's bandwidth interval table, we will
need to keep track of a list of endpoints, per interval. That way we can
easily know the new largest max packet size when we have to remove an
endpoint.
Add an endpoint list for each root port or TT structure, sorted by
endpoint max packet size. Insert new endpoints into the list such that
the head of the list always has the endpoint with the greatest max packet
size. Only insert endpoints and update the interval table with new
information when those endpoints are periodic.
Make sure to update the number of active TTs when we add or drop periodic
endpoints. A TT is only considered active if it has one or more periodic
endpoints attached (control and bulk are best effort, and counted in the
20% reserved on the high speed bus). If the number of active endpoints
for a TT was zero, and it's now non-zero, increment the number of active
TTs for the rootport. If the number of active endpoints was non-zero, and
it's now zero, decrement the number of active TTs.
We have to be careful when we're checking the bandwidth for a new
configuration/alt setting. If we don't have enough bandwidth, we need to
be able to "roll back" the bandwidth information stored in the endpoint
and the root port/TT interval bandwidth table. We can't just create a
copy of the interval bandwidth table, modify it, and check the bandwidth
with the copy because we have lists of endpoints and entries can't be on
more than one list. Instead, we copy the old endpoint bandwidth
information, and use it to revert the interval table when the bandwidth
check fails.
We don't check the bandwidth after endpoints are dropped from the interval
table when a device is reset or freed after a disconnect, because having
endpoints use less bandwidth should not push the bandwidth usage over the
limits. Besides which, we can't fail a device disconnect.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:50 +08:00
|
|
|
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);
|
|
|
|
void xhci_update_tt_active_eps(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
int old_active_eps);
|
2011-09-03 02:05:48 +08:00
|
|
|
void xhci_clear_endpoint_bw_info(struct xhci_bw_info *bw_info);
|
|
|
|
void xhci_update_bw_info(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_container_ctx *in_ctx,
|
|
|
|
struct xhci_input_control_ctx *ctrl_ctx,
|
|
|
|
struct xhci_virt_device *virt_dev);
|
2009-08-08 05:04:43 +08:00
|
|
|
void xhci_endpoint_copy(struct xhci_hcd *xhci,
|
2009-09-05 01:53:13 +08:00
|
|
|
struct xhci_container_ctx *in_ctx,
|
|
|
|
struct xhci_container_ctx *out_ctx,
|
|
|
|
unsigned int ep_index);
|
|
|
|
void xhci_slot_copy(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_container_ctx *in_ctx,
|
|
|
|
struct xhci_container_ctx *out_ctx);
|
2009-05-15 02:44:22 +08:00
|
|
|
int xhci_endpoint_init(struct xhci_hcd *xhci, struct xhci_virt_device *virt_dev,
|
|
|
|
struct usb_device *udev, struct usb_host_endpoint *ep,
|
|
|
|
gfp_t mem_flags);
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:58:38 +08:00
|
|
|
void xhci_ring_free(struct xhci_hcd *xhci, struct xhci_ring *ring);
|
2012-03-05 17:49:37 +08:00
|
|
|
int xhci_ring_expansion(struct xhci_hcd *xhci, struct xhci_ring *ring,
|
|
|
|
unsigned int num_trbs, gfp_t flags);
|
2009-12-10 07:59:01 +08:00
|
|
|
void xhci_free_or_cache_endpoint_ring(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
unsigned int ep_index);
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
struct xhci_stream_info *xhci_alloc_stream_info(struct xhci_hcd *xhci,
|
|
|
|
unsigned int num_stream_ctxs,
|
|
|
|
unsigned int num_streams, gfp_t flags);
|
|
|
|
void xhci_free_stream_info(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_stream_info *stream_info);
|
|
|
|
void xhci_setup_streams_ep_input_ctx(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_ep_ctx *ep_ctx,
|
|
|
|
struct xhci_stream_info *stream_info);
|
2015-01-09 22:06:31 +08:00
|
|
|
void xhci_setup_no_streams_ep_input_ctx(struct xhci_ep_ctx *ep_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-03 06:34:16 +08:00
|
|
|
struct xhci_virt_ep *ep);
|
Intel xhci: Limit number of active endpoints to 64.
The Panther Point chipset has an xHCI host controller that has a limit to
the number of active endpoints it can handle. Ideally, it would signal
that it can't handle anymore endpoints by returning a Resource Error for
the Configure Endpoint command, but they don't. Instead it needs software
to keep track of the number of active endpoints, across configure endpoint
commands, reset device commands, disable slot commands, and address device
commands.
Add a new endpoint context counter, xhci_hcd->num_active_eps, and use it
to track the number of endpoints the xHC has active. This gets a little
tricky, because commands to change the number of active endpoints can
fail. This patch adds a new xHCI quirk for these Intel hosts, and the new
code should not have any effect on other xHCI host controllers.
Fail a new device allocation if we don't have room for the new default
control endpoint. Use the endpoint ring pointers to determine what
endpoints were active before a Reset Device command or a Disable Slot
command, and drop those once the command completes.
Fail a configure endpoint command if it would add too many new endpoints.
We have to be a bit over zealous here, and only count the number of new
endpoints to be added, without subtracting the number of dropped
endpoints. That's because a second configure endpoint command for a
different device could sneak in before we know if the first command is
completed. If the first command dropped resources, the host controller
fails the command for some reason, and we're nearing the limit of
endpoints, we could end up oversubscribing the host.
To fix this race condition, when evaluating whether a configure endpoint
command will fix in our bandwidth budget, only add the new endpoints to
xhci->num_active_eps, and don't subtract the dropped endpoints. Ignore
changed endpoints (ones that are dropped and then re-added), as that
shouldn't effect the host's endpoint resources. When the configure
endpoint command completes, subtract off the dropped endpoints.
This may mean some configuration changes may temporarily fail, but it's
always better to under-subscribe than over-subscribe resources.
(Originally my plan had been to push the resource allocation down into the
ring allocation functions. However, that would cause us to allocate
unnecessary resources when endpoints were changed, because the xHCI driver
allocates a new ring for the changed endpoint, and only deletes the old
ring once the Configure Endpoint command succeeds. A further complication
would have been dealing with the per-device endpoint ring cache.)
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-05-12 07:14:58 +08:00
|
|
|
void xhci_free_device_endpoint_resources(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_virt_device *virt_dev, bool drop_control_ep);
|
2010-04-03 06:34:43 +08:00
|
|
|
struct xhci_ring *xhci_dma_to_transfer_ring(
|
|
|
|
struct xhci_virt_ep *ep,
|
|
|
|
u64 address);
|
|
|
|
struct xhci_ring *xhci_stream_id_to_ring(
|
|
|
|
struct xhci_virt_device *dev,
|
|
|
|
unsigned int ep_index,
|
|
|
|
unsigned int stream_id);
|
2009-09-05 01:53:13 +08:00
|
|
|
struct xhci_command *xhci_alloc_command(struct xhci_hcd *xhci,
|
2009-12-10 07:59:03 +08:00
|
|
|
bool allocate_in_ctx, bool allocate_completion,
|
|
|
|
gfp_t mem_flags);
|
2015-01-09 22:06:31 +08:00
|
|
|
void xhci_urb_free_priv(struct urb_priv *urb_priv);
|
2009-09-05 01:53:13 +08:00
|
|
|
void xhci_free_command(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_command *command);
|
2009-04-28 10:52:28 +08:00
|
|
|
|
|
|
|
/* xHCI host controller glue */
|
2011-09-24 05:20:01 +08:00
|
|
|
typedef void (*xhci_get_quirks_t)(struct device *, struct xhci_hcd *);
|
2015-01-09 22:06:28 +08:00
|
|
|
int xhci_handshake(void __iomem *ptr, u32 mask, u32 done, int usec);
|
2009-10-28 01:56:33 +08:00
|
|
|
void xhci_quiesce(struct xhci_hcd *xhci);
|
2009-04-28 10:52:28 +08:00
|
|
|
int xhci_halt(struct xhci_hcd *xhci);
|
|
|
|
int xhci_reset(struct xhci_hcd *xhci);
|
|
|
|
int xhci_init(struct usb_hcd *hcd);
|
|
|
|
int xhci_run(struct usb_hcd *hcd);
|
|
|
|
void xhci_stop(struct usb_hcd *hcd);
|
|
|
|
void xhci_shutdown(struct usb_hcd *hcd);
|
2011-09-24 05:20:01 +08:00
|
|
|
int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks);
|
2015-05-29 22:01:46 +08:00
|
|
|
void xhci_init_driver(struct hc_driver *drv,
|
|
|
|
const struct xhci_driver_overrides *over);
|
2010-10-16 05:59:15 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_PM
|
2014-11-18 17:27:14 +08:00
|
|
|
int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup);
|
2010-10-14 22:23:06 +08:00
|
|
|
int xhci_resume(struct xhci_hcd *xhci, bool hibernated);
|
2010-10-16 05:59:15 +08:00
|
|
|
#else
|
|
|
|
#define xhci_suspend NULL
|
|
|
|
#define xhci_resume NULL
|
|
|
|
#endif
|
|
|
|
|
2009-04-28 10:52:28 +08:00
|
|
|
int xhci_get_frame(struct usb_hcd *hcd);
|
2009-04-28 10:53:56 +08:00
|
|
|
irqreturn_t xhci_irq(struct usb_hcd *hcd);
|
2013-05-24 10:54:19 +08:00
|
|
|
irqreturn_t xhci_msi_irq(int irq, void *hcd);
|
2009-04-28 10:57:38 +08:00
|
|
|
int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device *udev);
|
|
|
|
void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev);
|
xhci: Store information about roothubs and TTs.
For upcoming patches, we need to keep information about the bandwidth
domains under the xHCI host. Each root port is a separate primary
bandwidth domain, and each high speed hub's TT (and potentially each port
on a multi-TT hub) is a secondary bandwidth domain.
If the table were in text form, it would look a bit like this:
EP Interval Sum of Number Largest Max Max Packet
of Packets Packet Size Overhead
0 N mps overhead
...
15 N mps overhead
Overhead is the maximum packet overhead (for bit stuffing, CRC, protocol
overhead, etc) for all the endpoints in this interval. Devices with
different speeds have different max packet overhead. For example, if
there is a low speed and a full speed endpoint that both have an interval
of 3, we would use the higher overhead (the low speed overhead). Interval
0 is a bit special, since we really just want to know the sum of the max
ESIT payloads instead of the largest max packet size. That's stored in
the interval0_esit_payload variable. For root ports, we also need to keep
track of the number of active TTs.
For each root port, and each TT under a root port, store some information
about the bandwidth consumption. Dynamically allocate an array of root
port bandwidth information for the number of root ports on the xHCI host.
Each root port stores a list of TTs under the root port. A single TT hub
only has one entry in the list, but a multi-TT hub will have an entry per
port.
When the USB core says that a USB device is a hub, create one or more
entries in the root port TT list for the hub. When a device is deleted,
and it is a hub, search through the root port TT list and delete all
TT entries for the hub. Keep track of which TT entry is associated with a
device under a TT.
LS/FS devices attached directly to the root port will have usb_device->tt
set to the roothub. Ignore that, and treat it like a primary bandwidth
domain, since there isn't really a high speed bus between the roothub and
the host.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-09-03 02:05:47 +08:00
|
|
|
int xhci_alloc_tt_info(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_virt_device *virt_dev,
|
|
|
|
struct usb_device *hdev,
|
|
|
|
struct usb_tt *tt, gfp_t mem_flags);
|
USB: xhci: Add memory allocation for USB3 bulk streams.
Add support for allocating streams for USB 3.0 bulk endpoints. See
Documentation/usb/bulk-streams.txt for more information about how and why
you would use streams.
When an endpoint has streams enabled, instead of having one ring where all
transfers are enqueued to the hardware, it has several rings. The ring
dequeue pointer in the endpoint context is changed to point to a "Stream
Context Array". This is basically an array of pointers to transfer rings,
one for each stream ID that the driver wants to use.
The Stream Context Array size must be a power of two, and host controllers
can place a limit on the size of the array (4 to 2^16 entries). These
two facts make calculating the size of the Stream Context Array and the
number of entries actually used by the driver a bit tricky.
Besides the Stream Context Array and rings for all the stream IDs, we need
one more data structure. The xHCI hardware will not tell us which stream
ID a transfer event was for, but it will give us the slot ID, endpoint
index, and physical address for the TRB that caused the event. For every
endpoint on a device, add a radix tree to map physical TRB addresses to
virtual segments within a stream ring.
Keep track of whether an endpoint is transitioning to using streams, and
don't enqueue any URBs while that's taking place. Refuse to transition an
endpoint to streams if there are already URBs enqueued for that endpoint.
We need to make sure that freeing streams does not fail, since a driver's
disconnect() function may attempt to do this, and it cannot fail.
Pre-allocate the command structure used to issue the Configure Endpoint
command, and reserve space on the command ring for each stream endpoint.
This may be a bit overkill, but it is permissible for the driver to
allocate all streams in one call and free them in multiple calls. (It is
not advised, however, since it is a waste of resources and time.)
Even with the memory and ring room pre-allocated, freeing streams can
still fail because the xHC rejects the configure endpoint command. It is
valid (by the xHCI 0.96 spec) to return a "Bandwidth Error" or a "Resource
Error" for a configure endpoint command. We should never see a Bandwidth
Error, since bulk endpoints do not effect the reserved bandwidth. The
host controller can still return a Resource Error, but it's improbable
since the xHC would be going from a more resource-intensive configuration
(streams) to a less resource-intensive configuration (no streams).
If the xHC returns a Resource Error, the endpoint will be stuck with
streams and will be unusable for drivers. It's an unavoidable consequence
of broken host controller hardware.
Includes bug fixes from the original patch, contributed by
John Youn <John.Youn@synopsys.com> and Andy Green <AGreen@PLXTech.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-04-03 06:34:16 +08:00
|
|
|
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 xhci_free_streams(struct usb_hcd *hcd, struct usb_device *udev,
|
|
|
|
struct usb_host_endpoint **eps, unsigned int num_eps,
|
|
|
|
gfp_t mem_flags);
|
2009-04-28 10:57:38 +08:00
|
|
|
int xhci_address_device(struct usb_hcd *hcd, struct usb_device *udev);
|
2013-12-06 09:07:27 +08:00
|
|
|
int xhci_enable_device(struct usb_hcd *hcd, struct usb_device *udev);
|
2011-09-24 05:19:51 +08:00
|
|
|
int xhci_update_device(struct usb_hcd *hcd, struct usb_device *udev);
|
2011-09-24 05:19:52 +08:00
|
|
|
int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
|
|
|
|
struct usb_device *udev, int enable);
|
2009-09-05 01:53:20 +08:00
|
|
|
int xhci_update_hub_device(struct usb_hcd *hcd, struct usb_device *hdev,
|
|
|
|
struct usb_tt *tt, gfp_t mem_flags);
|
2009-04-28 10:58:01 +08:00
|
|
|
int xhci_urb_enqueue(struct usb_hcd *hcd, struct urb *urb, gfp_t mem_flags);
|
|
|
|
int xhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status);
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:58:38 +08:00
|
|
|
int xhci_add_endpoint(struct usb_hcd *hcd, struct usb_device *udev, struct usb_host_endpoint *ep);
|
|
|
|
int xhci_drop_endpoint(struct usb_hcd *hcd, struct usb_device *udev, struct usb_host_endpoint *ep);
|
2009-07-28 03:03:15 +08:00
|
|
|
void xhci_endpoint_reset(struct usb_hcd *hcd, struct usb_host_endpoint *ep);
|
2010-10-14 22:22:48 +08:00
|
|
|
int xhci_discover_or_reset_device(struct usb_hcd *hcd, struct usb_device *udev);
|
USB: xhci: Bandwidth allocation support
Since the xHCI host controller hardware (xHC) has an internal schedule, it
needs a better representation of what devices are consuming bandwidth on
the bus. Each device is represented by a device context, with data about
the device, endpoints, and pointers to each endpoint ring.
We need to update the endpoint information for a device context before a
new configuration or alternate interface setting is selected. We setup an
input device context with modified endpoint information and newly
allocated endpoint rings, and then submit a Configure Endpoint Command to
the hardware.
The host controller can reject the new configuration if it exceeds the bus
bandwidth, or the host controller doesn't have enough internal resources
for the configuration. If the command fails, we still have the older
device context with the previous configuration. If the command succeeds,
we free the old endpoint rings.
The root hub isn't a real device, so always say yes to any bandwidth
changes for it.
The USB core will enable, disable, and then enable endpoint 0 several
times during the initialization sequence. The device will always have an
endpoint ring for endpoint 0 and bandwidth allocated for that, unless the
device is disconnected or gets a SetAddress 0 request. So we don't pay
attention for when xhci_check_bandwidth() is called for a re-add of
endpoint 0.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:58:38 +08:00
|
|
|
int xhci_check_bandwidth(struct usb_hcd *hcd, struct usb_device *udev);
|
|
|
|
void xhci_reset_bandwidth(struct usb_hcd *hcd, struct usb_device *udev);
|
2009-04-28 10:53:56 +08:00
|
|
|
|
|
|
|
/* xHCI ring, segment, TRB, and TD functions */
|
2009-04-30 10:05:20 +08:00
|
|
|
dma_addr_t xhci_trb_virt_to_dma(struct xhci_segment *seg, union xhci_trb *trb);
|
2014-08-20 21:41:51 +08:00
|
|
|
struct xhci_segment *trb_in_td(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_segment *start_seg, union xhci_trb *start_trb,
|
|
|
|
union xhci_trb *end_trb, dma_addr_t suspect_dma, bool debug);
|
2009-12-10 07:59:06 +08:00
|
|
|
int xhci_is_vendor_info_code(struct xhci_hcd *xhci, unsigned int trb_comp_code);
|
2009-04-30 10:05:20 +08:00
|
|
|
void xhci_ring_cmd_db(struct xhci_hcd *xhci);
|
2014-05-09 00:26:00 +08:00
|
|
|
int xhci_queue_slot_control(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
u32 trb_type, u32 slot_id);
|
|
|
|
int xhci_queue_address_device(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
dma_addr_t in_ctx_ptr, u32 slot_id, enum xhci_setup_dev);
|
|
|
|
int xhci_queue_vendor_command(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
2010-05-25 04:25:28 +08:00
|
|
|
u32 field1, u32 field2, u32 field3, u32 field4);
|
2014-05-09 00:26:00 +08:00
|
|
|
int xhci_queue_stop_endpoint(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
int slot_id, unsigned int ep_index, int suspend);
|
2009-04-30 10:05:20 +08:00
|
|
|
int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t mem_flags, struct urb *urb,
|
|
|
|
int slot_id, unsigned int ep_index);
|
|
|
|
int xhci_queue_bulk_tx(struct xhci_hcd *xhci, gfp_t mem_flags, struct urb *urb,
|
|
|
|
int slot_id, unsigned int ep_index);
|
2009-09-03 03:14:28 +08:00
|
|
|
int xhci_queue_intr_tx(struct xhci_hcd *xhci, gfp_t mem_flags, struct urb *urb,
|
|
|
|
int slot_id, unsigned int ep_index);
|
2010-07-23 06:23:39 +08:00
|
|
|
int xhci_queue_isoc_tx_prepare(struct xhci_hcd *xhci, gfp_t mem_flags,
|
|
|
|
struct urb *urb, int slot_id, unsigned int ep_index);
|
2014-05-09 00:26:00 +08:00
|
|
|
int xhci_queue_configure_endpoint(struct xhci_hcd *xhci,
|
|
|
|
struct xhci_command *cmd, dma_addr_t in_ctx_ptr, u32 slot_id,
|
|
|
|
bool command_must_succeed);
|
|
|
|
int xhci_queue_evaluate_context(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
dma_addr_t in_ctx_ptr, u32 slot_id, bool command_must_succeed);
|
|
|
|
int xhci_queue_reset_ep(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
int slot_id, unsigned int ep_index);
|
|
|
|
int xhci_queue_reset_device(struct xhci_hcd *xhci, struct xhci_command *cmd,
|
|
|
|
u32 slot_id);
|
2009-07-28 03:05:21 +08:00
|
|
|
void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
|
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int stream_id, struct xhci_td *cur_td,
|
|
|
|
struct xhci_dequeue_state *state);
|
2009-07-28 03:05:21 +08:00
|
|
|
void xhci_queue_new_dequeue_state(struct xhci_hcd *xhci,
|
2009-09-05 01:53:09 +08:00
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
2010-04-03 06:34:43 +08:00
|
|
|
unsigned int stream_id,
|
2009-09-05 01:53:09 +08:00
|
|
|
struct xhci_dequeue_state *deq_state);
|
2009-08-08 05:04:52 +08:00
|
|
|
void xhci_cleanup_stalled_ring(struct xhci_hcd *xhci,
|
2014-11-28 00:19:16 +08:00
|
|
|
unsigned int ep_index, struct xhci_td *td);
|
2009-08-08 05:04:55 +08:00
|
|
|
void xhci_queue_config_ep_quirk(struct xhci_hcd *xhci,
|
|
|
|
unsigned int slot_id, unsigned int ep_index,
|
|
|
|
struct xhci_dequeue_state *deq_state);
|
USB: xhci: Add watchdog timer for URB cancellation.
In order to giveback a canceled URB, we must ensure that the xHCI
hardware will not access the buffer in an URB. We can't modify the
buffer pointers on endpoint rings without issuing and waiting for a stop
endpoint command. Since URBs can be canceled in interrupt context, we
can't wait on that command. The old code trusted that the host
controller would respond to the command, and would giveback the URBs in
the event handler. If the hardware never responds to the stop endpoint
command, the URBs will never be completed, and we might hang the USB
subsystem.
Implement a watchdog timer that is spawned whenever a stop endpoint
command is queued. If a stop endpoint command event is found on the
event ring during an interrupt, we need to stop the watchdog timer with
del_timer(). Since del_timer() can fail if the timer is running and
waiting on the xHCI lock, we need a way to signal to the timer that
everything is fine and it should exit. If we simply clear
EP_HALT_PENDING, a new stop endpoint command could sneak in and set it
before the watchdog timer can grab the lock.
Instead we use a combination of the EP_HALT_PENDING flag and a counter
for the number of pending stop endpoint commands
(xhci_virt_ep->stop_cmds_pending). If we need to cancel the watchdog
timer and del_timer() succeeds, we decrement the number of pending stop
endpoint commands. If del_timer() fails, we leave the number of pending
stop endpoint commands alone. In either case, we clear the
EP_HALT_PENDING flag.
The timer will decrement the number of pending stop endpoint commands
once it obtains the lock. If the timer is the tail end of the last stop
endpoint command (xhci_virt_ep->stop_cmds_pending == 0), and the
endpoint's command is still pending (EP_HALT_PENDING is set), we assume
the host is dying. The watchdog timer will set XHCI_STATE_DYING, try to
halt the xHCI host, and give back all pending URBs.
Various other places in the driver need to check whether the xHCI host
is dying. If the interrupt handler ever notices, it should immediately
stop processing events. The URB enqueue function should also return
-ESHUTDOWN. The URB dequeue function should simply return the value
of usb_hcd_check_unlink_urb() and the watchdog timer will take care of
giving the URB back. When a device is disconnected, the xHCI hardware
structures should be freed without issuing a disable slot command (since
the hardware probably won't respond to it anyway). The debugging
polling loop should stop polling if the host is dying.
When a device is disconnected, any pending watchdog timers are killed
with del_timer_sync(). It must be synchronous so that the watchdog
timer doesn't attempt to access the freed endpoint structures.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-10-28 01:57:01 +08:00
|
|
|
void xhci_stop_endpoint_command_watchdog(unsigned long arg);
|
xhci: rework command timeout and cancellation,
Use one timer to control command timeout.
start/kick the timer every time a command is completed and a
new command is waiting, or a new command is added to a empty list.
If the timer runs out, then tag the current command as "aborted", and
start the xhci command abortion process.
Previously each function that submitted a command had its own timer.
If that command timed out, a new command structure for the
command was created and it was put on a cancel_cmd_list list,
then a pci write to abort the command ring was issued.
when the ring was aborted, it checked if the current command
was the one to be canceled, later when the ring was stopped the
driver got ownership of the TRBs in the command ring,
compared then to the TRBs in the cancel_cmd_list,
and turned them into No-ops.
Now, instead, at timeout we tag the status of the command in the
command queue to be aborted, and start the ring abortion.
Ring abortion stops the command ring and gives control of the
commands to us.
All the aborted commands are now turned into No-ops.
If the ring is already stopped when the command times outs its not possible
to start the ring abortion, in this case the command is turnd to No-op
right away.
All these changes allows us to remove the entire cancel_cmd_list code.
The functions waiting for a command to finish no longer have their own timeouts.
They will wait either until the command completes normally,
or until the whole command abortion is done.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-09 00:26:03 +08:00
|
|
|
void xhci_handle_command_timeout(unsigned long data);
|
|
|
|
|
2010-10-14 22:22:57 +08:00
|
|
|
void xhci_ring_ep_doorbell(struct xhci_hcd *xhci, unsigned int slot_id,
|
|
|
|
unsigned int ep_index, unsigned int stream_id);
|
2014-05-09 00:26:01 +08:00
|
|
|
void xhci_cleanup_command_queue(struct xhci_hcd *xhci);
|
2009-04-28 10:52:28 +08:00
|
|
|
|
2009-04-28 10:57:12 +08:00
|
|
|
/* xHCI roothub code */
|
2011-09-24 05:19:48 +08:00
|
|
|
void xhci_set_link_state(struct xhci_hcd *xhci, __le32 __iomem **port_array,
|
|
|
|
int port_id, u32 link_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-10 01:55:03 +08:00
|
|
|
int xhci_enable_usb3_lpm_timeout(struct usb_hcd *hcd,
|
|
|
|
struct usb_device *udev, enum usb3_link_state state);
|
|
|
|
int xhci_disable_usb3_lpm_timeout(struct usb_hcd *hcd,
|
|
|
|
struct usb_device *udev, enum usb3_link_state state);
|
2011-09-24 05:19:49 +08:00
|
|
|
void xhci_test_and_clear_bit(struct xhci_hcd *xhci, __le32 __iomem **port_array,
|
|
|
|
int port_id, u32 port_bit);
|
2009-04-28 10:57:12 +08:00
|
|
|
int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue, u16 wIndex,
|
|
|
|
char *buf, u16 wLength);
|
|
|
|
int xhci_hub_status_data(struct usb_hcd *hcd, char *buf);
|
2013-03-19 16:48:12 +08:00
|
|
|
int xhci_find_raw_port_number(struct usb_hcd *hcd, int port1);
|
2010-10-16 05:59:15 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_PM
|
2010-10-14 22:23:03 +08:00
|
|
|
int xhci_bus_suspend(struct usb_hcd *hcd);
|
|
|
|
int xhci_bus_resume(struct usb_hcd *hcd);
|
2010-10-16 05:59:15 +08:00
|
|
|
#else
|
|
|
|
#define xhci_bus_suspend NULL
|
|
|
|
#define xhci_bus_resume NULL
|
|
|
|
#endif /* CONFIG_PM */
|
|
|
|
|
2010-10-14 22:23:00 +08:00
|
|
|
u32 xhci_port_state_to_neutral(u32 state);
|
2010-12-17 02:49:09 +08:00
|
|
|
int xhci_find_slot_id_by_port(struct usb_hcd *hcd, struct xhci_hcd *xhci,
|
|
|
|
u16 port);
|
2010-10-14 22:23:00 +08:00
|
|
|
void xhci_ring_device(struct xhci_hcd *xhci, int slot_id);
|
2009-04-28 10:57:12 +08:00
|
|
|
|
2009-07-28 03:05:15 +08:00
|
|
|
/* xHCI contexts */
|
2015-01-09 22:06:31 +08:00
|
|
|
struct xhci_input_control_ctx *xhci_get_input_control_ctx(struct xhci_container_ctx *ctx);
|
2009-07-28 03:05:15 +08:00
|
|
|
struct xhci_slot_ctx *xhci_get_slot_ctx(struct xhci_hcd *xhci, struct xhci_container_ctx *ctx);
|
|
|
|
struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci, struct xhci_container_ctx *ctx, unsigned int ep_index);
|
|
|
|
|
2009-04-28 10:52:22 +08:00
|
|
|
#endif /* __LINUX_XHCI_HCD_H */
|