UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/usb/host/xhci-dbg.c

597 lines
17 KiB
C
Raw Normal View History

USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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.
*/
#include "xhci.h"
#define XHCI_INIT_VALUE 0x0
/* Add verbose debugging later, just print everything for now */
void xhci_dbg_regs(struct xhci_hcd *xhci)
{
u32 temp;
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "// xHCI capability registers at %p:\n",
xhci->cap_regs);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
temp = xhci_readl(xhci, &xhci->cap_regs->hc_capbase);
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "// @%p = 0x%x (CAPLENGTH AND HCIVERSION)\n",
&xhci->cap_regs->hc_capbase, temp);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
xhci_dbg(xhci, "// CAPLENGTH: 0x%x\n",
(unsigned int) HC_LENGTH(temp));
#if 0
xhci_dbg(xhci, "// HCIVERSION: 0x%x\n",
(unsigned int) HC_VERSION(temp));
#endif
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "// xHCI operational registers at %p:\n", xhci->op_regs);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
temp = xhci_readl(xhci, &xhci->cap_regs->run_regs_off);
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "// @%p = 0x%x RTSOFF\n",
&xhci->cap_regs->run_regs_off,
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
(unsigned int) temp & RTSOFF_MASK);
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "// xHCI runtime registers at %p:\n", xhci->run_regs);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
temp = xhci_readl(xhci, &xhci->cap_regs->db_off);
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "// @%p = 0x%x DBOFF\n", &xhci->cap_regs->db_off, temp);
xhci_dbg(xhci, "// Doorbell array at %p:\n", xhci->dba);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
}
USB: xhci: Avoid global namespace pollution. Make all globally visible functions start with xhci_ and mark functions as static if they're only called within the same C file. Fix some long lines while we're at it. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:05:20 +08:00
static void xhci_print_cap_regs(struct xhci_hcd *xhci)
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
{
u32 temp;
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "xHCI capability registers at %p:\n", xhci->cap_regs);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
temp = xhci_readl(xhci, &xhci->cap_regs->hc_capbase);
xhci_dbg(xhci, "CAPLENGTH AND HCIVERSION 0x%x:\n",
(unsigned int) temp);
xhci_dbg(xhci, "CAPLENGTH: 0x%x\n",
(unsigned int) HC_LENGTH(temp));
xhci_dbg(xhci, "HCIVERSION: 0x%x\n",
(unsigned int) HC_VERSION(temp));
temp = xhci_readl(xhci, &xhci->cap_regs->hcs_params1);
xhci_dbg(xhci, "HCSPARAMS 1: 0x%x\n",
(unsigned int) temp);
xhci_dbg(xhci, " Max device slots: %u\n",
(unsigned int) HCS_MAX_SLOTS(temp));
xhci_dbg(xhci, " Max interrupters: %u\n",
(unsigned int) HCS_MAX_INTRS(temp));
xhci_dbg(xhci, " Max ports: %u\n",
(unsigned int) HCS_MAX_PORTS(temp));
temp = xhci_readl(xhci, &xhci->cap_regs->hcs_params2);
xhci_dbg(xhci, "HCSPARAMS 2: 0x%x\n",
(unsigned int) temp);
xhci_dbg(xhci, " Isoc scheduling threshold: %u\n",
(unsigned int) HCS_IST(temp));
xhci_dbg(xhci, " Maximum allowed segments in event ring: %u\n",
(unsigned int) HCS_ERST_MAX(temp));
temp = xhci_readl(xhci, &xhci->cap_regs->hcs_params3);
xhci_dbg(xhci, "HCSPARAMS 3 0x%x:\n",
(unsigned int) temp);
xhci_dbg(xhci, " Worst case U1 device exit latency: %u\n",
(unsigned int) HCS_U1_LATENCY(temp));
xhci_dbg(xhci, " Worst case U2 device exit latency: %u\n",
(unsigned int) HCS_U2_LATENCY(temp));
temp = xhci_readl(xhci, &xhci->cap_regs->hcc_params);
xhci_dbg(xhci, "HCC PARAMS 0x%x:\n", (unsigned int) temp);
xhci_dbg(xhci, " HC generates %s bit addresses\n",
HCC_64BIT_ADDR(temp) ? "64" : "32");
/* FIXME */
xhci_dbg(xhci, " FIXME: more HCCPARAMS debugging\n");
temp = xhci_readl(xhci, &xhci->cap_regs->run_regs_off);
xhci_dbg(xhci, "RTSOFF 0x%x:\n", temp & RTSOFF_MASK);
}
USB: xhci: Avoid global namespace pollution. Make all globally visible functions start with xhci_ and mark functions as static if they're only called within the same C file. Fix some long lines while we're at it. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:05:20 +08:00
static void xhci_print_command_reg(struct xhci_hcd *xhci)
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
{
u32 temp;
temp = xhci_readl(xhci, &xhci->op_regs->command);
xhci_dbg(xhci, "USBCMD 0x%x:\n", temp);
xhci_dbg(xhci, " HC is %s\n",
(temp & CMD_RUN) ? "running" : "being stopped");
xhci_dbg(xhci, " HC has %sfinished hard reset\n",
(temp & CMD_RESET) ? "not " : "");
xhci_dbg(xhci, " Event Interrupts %s\n",
(temp & CMD_EIE) ? "enabled " : "disabled");
xhci_dbg(xhci, " Host System Error Interrupts %s\n",
xHCI: correct to print the true HSEE of USBCMD Correct the print of HSEE of USBCMD in xhci-dbg.c. Signed-off-by: Alex He <alex.he@amd.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2012-03-22 15:06:59 +08:00
(temp & CMD_HSEIE) ? "enabled " : "disabled");
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
xhci_dbg(xhci, " HC has %sfinished light reset\n",
(temp & CMD_LRESET) ? "not " : "");
}
USB: xhci: Avoid global namespace pollution. Make all globally visible functions start with xhci_ and mark functions as static if they're only called within the same C file. Fix some long lines while we're at it. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:05:20 +08:00
static void xhci_print_status(struct xhci_hcd *xhci)
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
{
u32 temp;
temp = xhci_readl(xhci, &xhci->op_regs->status);
xhci_dbg(xhci, "USBSTS 0x%x:\n", temp);
xhci_dbg(xhci, " Event ring is %sempty\n",
(temp & STS_EINT) ? "not " : "");
xhci_dbg(xhci, " %sHost System Error\n",
(temp & STS_FATAL) ? "WARNING: " : "No ");
xhci_dbg(xhci, " HC is %s\n",
(temp & STS_HALT) ? "halted" : "running");
}
USB: xhci: Avoid global namespace pollution. Make all globally visible functions start with xhci_ and mark functions as static if they're only called within the same C file. Fix some long lines while we're at it. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:05:20 +08:00
static void xhci_print_op_regs(struct xhci_hcd *xhci)
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
{
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "xHCI operational registers at %p:\n", xhci->op_regs);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
xhci_print_command_reg(xhci);
xhci_print_status(xhci);
}
USB: xhci: Avoid global namespace pollution. Make all globally visible functions start with xhci_ and mark functions as static if they're only called within the same C file. Fix some long lines while we're at it. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:05:20 +08:00
static void xhci_print_ports(struct xhci_hcd *xhci)
USB: xhci: Root hub support. Add functionality for getting port status and hub descriptor for xHCI root hubs. This is WIP because the USB 3.0 hub descriptor is different from the USB 2.0 hub descriptor. For now, we lie about the root hub descriptor because the changes won't effect how the core talks to the root hub. Later we will need to add the USB 3.0 hub descriptor for real hubs, and this code might change. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:12 +08:00
{
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
__le32 __iomem *addr;
USB: xhci: Root hub support. Add functionality for getting port status and hub descriptor for xHCI root hubs. This is WIP because the USB 3.0 hub descriptor is different from the USB 2.0 hub descriptor. For now, we lie about the root hub descriptor because the changes won't effect how the core talks to the root hub. Later we will need to add the USB 3.0 hub descriptor for real hubs, and this code might change. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:12 +08:00
int i, j;
int ports;
char *names[NUM_PORT_REGS] = {
"status",
"power",
"link",
"reserved",
};
ports = HCS_MAX_PORTS(xhci->hcs_params1);
addr = &xhci->op_regs->port_status_base;
for (i = 0; i < ports; i++) {
for (j = 0; j < NUM_PORT_REGS; ++j) {
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "%p port %s reg = 0x%x\n",
addr, names[j],
USB: xhci: Root hub support. Add functionality for getting port status and hub descriptor for xHCI root hubs. This is WIP because the USB 3.0 hub descriptor is different from the USB 2.0 hub descriptor. For now, we lie about the root hub descriptor because the changes won't effect how the core talks to the root hub. Later we will need to add the USB 3.0 hub descriptor for real hubs, and this code might change. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:12 +08:00
(unsigned int) xhci_readl(xhci, addr));
addr++;
}
}
}
USB: xhci: rework xhci_print_ir_set() to get ir set from xhci itself xhci->ir_set points to __iomem region, but xhci_print_ir_set accepts plain struct xhci_intr_reg * causing multiple sparse warning at call sites and inside the fucntion when we try to read that memory. Instead of adding __iomem qualifier to the argument let's rework the function so it itself gets needed register set from xhci and prints it. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-02-09 08:29:33 +08:00
void xhci_print_ir_set(struct xhci_hcd *xhci, int set_num)
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
{
USB: xhci: rework xhci_print_ir_set() to get ir set from xhci itself xhci->ir_set points to __iomem region, but xhci_print_ir_set accepts plain struct xhci_intr_reg * causing multiple sparse warning at call sites and inside the fucntion when we try to read that memory. Instead of adding __iomem qualifier to the argument let's rework the function so it itself gets needed register set from xhci and prints it. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-02-09 08:29:33 +08:00
struct xhci_intr_reg __iomem *ir_set = &xhci->run_regs->ir_set[set_num];
void __iomem *addr;
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
u32 temp;
USB: xhci: Represent 64-bit addresses with one u64. There are several xHCI data structures that use two 32-bit fields to represent a 64-bit address. Since some architectures don't support 64-bit PCI writes, the fields need to be written in two 32-bit writes. The xHCI specification says that if a platform is incapable of generating 64-bit writes, software must write the low 32-bits first, then the high 32-bits. Hardware that supports 64-bit addressing will wait for the high 32-bit write before reading the revised value, and hardware that only supports 32-bit writes will ignore the high 32-bit write. Previous xHCI code represented 64-bit addresses with two u32 values. This lead to buggy code that would write the 32-bits in the wrong order, or forget to write the upper 32-bits. Change the two u32s to one u64 and create a function call to write all 64-bit addresses in the proper order. This new function could be modified in the future if all platforms support 64-bit writes. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:03:31 +08:00
u64 temp_64;
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
addr = &ir_set->irq_pending;
temp = xhci_readl(xhci, addr);
if (temp == XHCI_INIT_VALUE)
return;
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, " %p: ir_set[%i]\n", ir_set, set_num);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, " %p: ir_set.pending = 0x%x\n", addr,
(unsigned int)temp);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
addr = &ir_set->irq_control;
temp = xhci_readl(xhci, addr);
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, " %p: ir_set.control = 0x%x\n", addr,
(unsigned int)temp);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
addr = &ir_set->erst_size;
temp = xhci_readl(xhci, addr);
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, " %p: ir_set.erst_size = 0x%x\n", addr,
(unsigned int)temp);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
addr = &ir_set->rsvd;
temp = xhci_readl(xhci, addr);
if (temp != XHCI_INIT_VALUE)
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, " WARN: %p: ir_set.rsvd = 0x%x\n",
addr, (unsigned int)temp);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
USB: xhci: Represent 64-bit addresses with one u64. There are several xHCI data structures that use two 32-bit fields to represent a 64-bit address. Since some architectures don't support 64-bit PCI writes, the fields need to be written in two 32-bit writes. The xHCI specification says that if a platform is incapable of generating 64-bit writes, software must write the low 32-bits first, then the high 32-bits. Hardware that supports 64-bit addressing will wait for the high 32-bit write before reading the revised value, and hardware that only supports 32-bit writes will ignore the high 32-bit write. Previous xHCI code represented 64-bit addresses with two u32 values. This lead to buggy code that would write the 32-bits in the wrong order, or forget to write the upper 32-bits. Change the two u32s to one u64 and create a function call to write all 64-bit addresses in the proper order. This new function could be modified in the future if all platforms support 64-bit writes. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:03:31 +08:00
addr = &ir_set->erst_base;
temp_64 = xhci_read_64(xhci, addr);
xhci_dbg(xhci, " %p: ir_set.erst_base = @%08llx\n",
addr, temp_64);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
USB: xhci: Represent 64-bit addresses with one u64. There are several xHCI data structures that use two 32-bit fields to represent a 64-bit address. Since some architectures don't support 64-bit PCI writes, the fields need to be written in two 32-bit writes. The xHCI specification says that if a platform is incapable of generating 64-bit writes, software must write the low 32-bits first, then the high 32-bits. Hardware that supports 64-bit addressing will wait for the high 32-bit write before reading the revised value, and hardware that only supports 32-bit writes will ignore the high 32-bit write. Previous xHCI code represented 64-bit addresses with two u32 values. This lead to buggy code that would write the 32-bits in the wrong order, or forget to write the upper 32-bits. Change the two u32s to one u64 and create a function call to write all 64-bit addresses in the proper order. This new function could be modified in the future if all platforms support 64-bit writes. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:03:31 +08:00
addr = &ir_set->erst_dequeue;
temp_64 = xhci_read_64(xhci, addr);
xhci_dbg(xhci, " %p: ir_set.erst_dequeue = @%08llx\n",
addr, temp_64);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
}
void xhci_print_run_regs(struct xhci_hcd *xhci)
{
u32 temp;
int i;
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "xHCI runtime registers at %p:\n", xhci->run_regs);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
temp = xhci_readl(xhci, &xhci->run_regs->microframe_index);
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, " %p: Microframe index = 0x%x\n",
&xhci->run_regs->microframe_index,
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
(unsigned int) temp);
for (i = 0; i < 7; ++i) {
temp = xhci_readl(xhci, &xhci->run_regs->rsvd[i]);
if (temp != XHCI_INIT_VALUE)
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, " WARN: %p: Rsvd[%i] = 0x%x\n",
&xhci->run_regs->rsvd[i],
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
i, (unsigned int) temp);
}
}
void xhci_print_registers(struct xhci_hcd *xhci)
{
xhci_print_cap_regs(xhci);
xhci_print_op_regs(xhci);
USB: xhci: Root hub support. Add functionality for getting port status and hub descriptor for xHCI root hubs. This is WIP because the USB 3.0 hub descriptor is different from the USB 2.0 hub descriptor. For now, we lie about the root hub descriptor because the changes won't effect how the core talks to the root hub. Later we will need to add the USB 3.0 hub descriptor for real hubs, and this code might change. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:12 +08:00
xhci_print_ports(xhci);
USB: xhci: Support xHCI host controllers and USB 3.0 devices. This is the first of many patches to add support for USB 3.0 devices and the hardware that implements the eXtensible Host Controller Interface (xHCI) 0.95 specification. This specification is not yet publicly available, but companies can receive a copy by becoming an xHCI Contributor (see http://www.intel.com/technology/usb/xhcispec.htm). No xHCI hardware has made it onto the market yet, but these patches have been tested under the Fresco Logic host controller prototype. This patch adds the xHCI register sets, which are grouped into five sets: - Generic PCI registers - Host controller "capabilities" registers (cap_regs) short - Host controller "operational" registers (op_regs) - Host controller "runtime" registers (run_regs) - Host controller "doorbell" registers These some of these registers may be virtualized if the Linux driver is running under a VM. Virtualization has not been tested for this patch. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:52:22 +08:00
}
USB: xhci: Ring allocation and initialization. Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 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:52:34 +08:00
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
void xhci_print_trb_offsets(struct xhci_hcd *xhci, union xhci_trb *trb)
{
int i;
for (i = 0; i < 4; ++i)
xhci_dbg(xhci, "Offset 0x%x = 0x%x\n",
i*4, trb->generic.field[i]);
}
/**
* Debug a transfer request block (TRB).
*/
void xhci_debug_trb(struct xhci_hcd *xhci, union xhci_trb *trb)
{
u64 address;
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
u32 type = le32_to_cpu(trb->link.control) & TRB_TYPE_BITMASK;
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
switch (type) {
case TRB_TYPE(TRB_LINK):
xhci_dbg(xhci, "Link TRB:\n");
xhci_print_trb_offsets(xhci, trb);
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
address = le64_to_cpu(trb->link.segment_ptr);
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
xhci_dbg(xhci, "Next ring segment DMA address = 0x%llx\n", address);
xhci_dbg(xhci, "Interrupter target = 0x%x\n",
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
GET_INTR_TARGET(le32_to_cpu(trb->link.intr_target)));
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
xhci_dbg(xhci, "Cycle bit = %u\n",
xhci: Remove some unnecessary casts and tidy some endian swap code Some of the recently-added cpu_to_leXX and leXX_to_cpu made things somewhat messy; this patch neatens some of these areas, removing unnecessary casts in those parts also. In some places (where Y & Z are constants) a comparison of (leXX_to_cpu(X) & Y) == Z has been replaced with (X & cpu_to_leXX(Y)) == cpu_to_leXX(Z). The endian reversal of the constants should wash out at compile time. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-06-01 08:22:55 +08:00
le32_to_cpu(trb->link.control) & TRB_CYCLE);
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
xhci_dbg(xhci, "Toggle cycle bit = %u\n",
xhci: Remove some unnecessary casts and tidy some endian swap code Some of the recently-added cpu_to_leXX and leXX_to_cpu made things somewhat messy; this patch neatens some of these areas, removing unnecessary casts in those parts also. In some places (where Y & Z are constants) a comparison of (leXX_to_cpu(X) & Y) == Z has been replaced with (X & cpu_to_leXX(Y)) == cpu_to_leXX(Z). The endian reversal of the constants should wash out at compile time. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-06-01 08:22:55 +08:00
le32_to_cpu(trb->link.control) & LINK_TOGGLE);
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
xhci_dbg(xhci, "No Snoop bit = %u\n",
xhci: Remove some unnecessary casts and tidy some endian swap code Some of the recently-added cpu_to_leXX and leXX_to_cpu made things somewhat messy; this patch neatens some of these areas, removing unnecessary casts in those parts also. In some places (where Y & Z are constants) a comparison of (leXX_to_cpu(X) & Y) == Z has been replaced with (X & cpu_to_leXX(Y)) == cpu_to_leXX(Z). The endian reversal of the constants should wash out at compile time. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-06-01 08:22:55 +08:00
le32_to_cpu(trb->link.control) & TRB_NO_SNOOP);
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
break;
case TRB_TYPE(TRB_TRANSFER):
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
address = le64_to_cpu(trb->trans_event.buffer);
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
/*
* FIXME: look at flags to figure out if it's an address or if
* the data is directly in the buffer field.
*/
xhci_dbg(xhci, "DMA address or buffer contents= %llu\n", address);
break;
case TRB_TYPE(TRB_COMPLETION):
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
address = le64_to_cpu(trb->event_cmd.cmd_trb);
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
xhci_dbg(xhci, "Command TRB pointer = %llu\n", address);
xhci_dbg(xhci, "Completion status = %u\n",
xhci: Remove some unnecessary casts and tidy some endian swap code Some of the recently-added cpu_to_leXX and leXX_to_cpu made things somewhat messy; this patch neatens some of these areas, removing unnecessary casts in those parts also. In some places (where Y & Z are constants) a comparison of (leXX_to_cpu(X) & Y) == Z has been replaced with (X & cpu_to_leXX(Y)) == cpu_to_leXX(Z). The endian reversal of the constants should wash out at compile time. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-06-01 08:22:55 +08:00
GET_COMP_CODE(le32_to_cpu(trb->event_cmd.status)));
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
xhci_dbg(xhci, "Flags = 0x%x\n",
xhci: Remove some unnecessary casts and tidy some endian swap code Some of the recently-added cpu_to_leXX and leXX_to_cpu made things somewhat messy; this patch neatens some of these areas, removing unnecessary casts in those parts also. In some places (where Y & Z are constants) a comparison of (leXX_to_cpu(X) & Y) == Z has been replaced with (X & cpu_to_leXX(Y)) == cpu_to_leXX(Z). The endian reversal of the constants should wash out at compile time. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-06-01 08:22:55 +08:00
le32_to_cpu(trb->event_cmd.flags));
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
break;
default:
xhci_dbg(xhci, "Unknown TRB with TRB type ID %u\n",
(unsigned int) type>>10);
xhci_print_trb_offsets(xhci, trb);
break;
}
}
USB: xhci: Ring allocation and initialization. Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 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:52:34 +08:00
/**
* Debug a segment with an xHCI ring.
*
* @return The Link TRB of the segment, or NULL if there is no Link TRB
* (which is a bug, since all segments must have a Link TRB).
*
* Prints out all TRBs in the segment, even those after the Link TRB.
*
* XXX: should we print out TRBs that the HC owns? As long as we don't
* write, that should be fine... We shouldn't expect that the memory pointed to
* by the TRB is valid at all. Do we care about ones the HC owns? Probably,
* for HC debugging.
*/
void xhci_debug_segment(struct xhci_hcd *xhci, struct xhci_segment *seg)
{
int i;
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
u64 addr = seg->dma;
USB: xhci: Ring allocation and initialization. Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 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:52:34 +08:00
union xhci_trb *trb = seg->trbs;
for (i = 0; i < TRBS_PER_SEGMENT; ++i) {
trb = &seg->trbs[i];
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
xhci_dbg(xhci, "@%016llx %08x %08x %08x %08x\n", addr,
xhci: Remove some unnecessary casts and tidy some endian swap code Some of the recently-added cpu_to_leXX and leXX_to_cpu made things somewhat messy; this patch neatens some of these areas, removing unnecessary casts in those parts also. In some places (where Y & Z are constants) a comparison of (leXX_to_cpu(X) & Y) == Z has been replaced with (X & cpu_to_leXX(Y)) == cpu_to_leXX(Z). The endian reversal of the constants should wash out at compile time. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-06-01 08:22:55 +08:00
lower_32_bits(le64_to_cpu(trb->link.segment_ptr)),
upper_32_bits(le64_to_cpu(trb->link.segment_ptr)),
le32_to_cpu(trb->link.intr_target),
le32_to_cpu(trb->link.control));
USB: xhci: Ring allocation and initialization. Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 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:52:34 +08:00
addr += sizeof(*trb);
}
}
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
void xhci_dbg_ring_ptrs(struct xhci_hcd *xhci, struct xhci_ring *ring)
{
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "Ring deq = %p (virt), 0x%llx (dma)\n",
ring->dequeue,
USB: xhci: Avoid global namespace pollution. Make all globally visible functions start with xhci_ and mark functions as static if they're only called within the same C file. Fix some long lines while we're at it. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:05:20 +08:00
(unsigned long long)xhci_trb_virt_to_dma(ring->deq_seg,
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
ring->dequeue));
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
xhci_dbg(xhci, "Ring deq updated %u times\n",
ring->deq_updates);
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "Ring enq = %p (virt), 0x%llx (dma)\n",
ring->enqueue,
USB: xhci: Avoid global namespace pollution. Make all globally visible functions start with xhci_ and mark functions as static if they're only called within the same C file. Fix some long lines while we're at it. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:05:20 +08:00
(unsigned long long)xhci_trb_virt_to_dma(ring->enq_seg,
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
ring->enqueue));
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
xhci_dbg(xhci, "Ring enq updated %u times\n",
ring->enq_updates);
}
USB: xhci: Ring allocation and initialization. Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 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:52:34 +08:00
/**
* Debugging for an xHCI ring, which is a queue broken into multiple segments.
*
* Print out each segment in the ring. Check that the DMA address in
* each link segment actually matches the segment's stored DMA address.
* Check that the link end bit is only set at the end of the ring.
* Check that the dequeue and enqueue pointers point to real data in this ring
* (not some other ring).
*/
void xhci_debug_ring(struct xhci_hcd *xhci, struct xhci_ring *ring)
{
/* FIXME: Throw an error if any segment doesn't have a Link TRB */
struct xhci_segment *seg;
struct xhci_segment *first_seg = ring->first_seg;
xhci_debug_segment(xhci, first_seg);
USB: xhci: No-op command queueing and irq handler. xHCI host controllers can optionally implement a no-op test. This simple test ensures the OS has correctly setup all basic data structures and can correctly respond to interrupts from the host controller hardware. There are two rings exercised by the no-op test: the command ring, and the event ring. The host controller driver writes a no-op command TRB to the command ring, and rings the doorbell for the command ring (the first entry in the doorbell array). The hardware receives this event, places a command completion event on the event ring, and fires an interrupt. The host controller driver sees the interrupt, and checks the event ring for TRBs it can process, and sees the command completion event. (See the rules in xhci-ring.c for who "owns" a TRB. This is a simplified set of rules, and may not contain all the details that are in the xHCI 0.95 spec.) A timer fires every 60 seconds to debug the state of the hardware and command and event rings. This timer only runs if CONFIG_USB_XHCI_HCD_DEBUGGING is 'y'. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:53:56 +08:00
if (!ring->enq_updates && !ring->deq_updates) {
xhci_dbg(xhci, " Ring has not been updated\n");
return;
}
USB: xhci: Ring allocation and initialization. Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 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:52:34 +08:00
for (seg = first_seg->next; seg != first_seg; seg = seg->next)
xhci_debug_segment(xhci, seg);
}
USB: xhci: Correct assumptions about number of rings per endpoint. Much of the xHCI driver code assumes that endpoints only have one ring. Now an endpoint can have one ring per enabled stream ID, so correct that assumption. Use functions that translate the stream_id field in the URB or the DMA address of a TRB into the correct stream ring. Correct the polling loop to print out all enabled stream rings. Make the URB cancellation routine find the correct stream ring if the URB has stream_id set. Make sure the URB enqueueing routine does the same. Also correct the code that handles stalled/halted endpoints. Check that commands and registers that can take stream IDs handle them properly. That includes ringing an endpoint doorbell, resetting a stalled/halted endpoint, and setting a transfer ring dequeue pointer (since that command can set the dequeue pointer in a stream context or an endpoint context). Correct the transfer event handler to translate a TRB DMA address into the stream ring it was enqueued to. Make the code to allocate and prepare TD structures adds the TD to the right td_list for the stream ring. Make sure the code to give the first TRB in a TD to the hardware manipulates the correct stream ring. When an endpoint stalls, store the stream ID of the stream ring that stalled in the xhci_virt_ep structure. Use that instead of the stream ID in the URB, since an URB may be re-used after it is given back after a non-control endpoint stall. 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: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)
{
int i;
struct xhci_ring *ring;
if (ep->ep_state & EP_HAS_STREAMS) {
for (i = 1; i < ep->stream_info->num_streams; i++) {
ring = ep->stream_info->stream_rings[i];
xhci_dbg(xhci, "Dev %d endpoint %d stream ID %d:\n",
slot_id, ep_index, i);
xhci_debug_segment(xhci, ring->deq_seg);
}
} else {
ring = ep->ring;
if (!ring)
return;
xhci_dbg(xhci, "Dev %d endpoint ring %d:\n",
slot_id, ep_index);
xhci_debug_segment(xhci, ring->deq_seg);
}
}
USB: xhci: Ring allocation and initialization. Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 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:52:34 +08:00
void xhci_dbg_erst(struct xhci_hcd *xhci, struct xhci_erst *erst)
{
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
u64 addr = erst->erst_dma_addr;
USB: xhci: Ring allocation and initialization. Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 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:52:34 +08:00
int i;
struct xhci_erst_entry *entry;
for (i = 0; i < erst->num_entries; ++i) {
entry = &erst->entries[i];
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
xhci_dbg(xhci, "@%016llx %08x %08x %08x %08x\n",
addr,
lower_32_bits(le64_to_cpu(entry->seg_addr)),
upper_32_bits(le64_to_cpu(entry->seg_addr)),
xhci: Remove some unnecessary casts and tidy some endian swap code Some of the recently-added cpu_to_leXX and leXX_to_cpu made things somewhat messy; this patch neatens some of these areas, removing unnecessary casts in those parts also. In some places (where Y & Z are constants) a comparison of (leXX_to_cpu(X) & Y) == Z has been replaced with (X & cpu_to_leXX(Y)) == cpu_to_leXX(Z). The endian reversal of the constants should wash out at compile time. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-06-01 08:22:55 +08:00
le32_to_cpu(entry->seg_size),
le32_to_cpu(entry->rsvd));
USB: xhci: Ring allocation and initialization. Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 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:52:34 +08:00
addr += sizeof(*entry);
}
}
void xhci_dbg_cmd_ptrs(struct xhci_hcd *xhci)
{
USB: xhci: Represent 64-bit addresses with one u64. There are several xHCI data structures that use two 32-bit fields to represent a 64-bit address. Since some architectures don't support 64-bit PCI writes, the fields need to be written in two 32-bit writes. The xHCI specification says that if a platform is incapable of generating 64-bit writes, software must write the low 32-bits first, then the high 32-bits. Hardware that supports 64-bit addressing will wait for the high 32-bit write before reading the revised value, and hardware that only supports 32-bit writes will ignore the high 32-bit write. Previous xHCI code represented 64-bit addresses with two u32 values. This lead to buggy code that would write the 32-bits in the wrong order, or forget to write the upper 32-bits. Change the two u32s to one u64 and create a function call to write all 64-bit addresses in the proper order. This new function could be modified in the future if all platforms support 64-bit writes. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:03:31 +08:00
u64 val;
USB: xhci: Ring allocation and initialization. Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 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:52:34 +08:00
USB: xhci: Represent 64-bit addresses with one u64. There are several xHCI data structures that use two 32-bit fields to represent a 64-bit address. Since some architectures don't support 64-bit PCI writes, the fields need to be written in two 32-bit writes. The xHCI specification says that if a platform is incapable of generating 64-bit writes, software must write the low 32-bits first, then the high 32-bits. Hardware that supports 64-bit addressing will wait for the high 32-bit write before reading the revised value, and hardware that only supports 32-bit writes will ignore the high 32-bit write. Previous xHCI code represented 64-bit addresses with two u32 values. This lead to buggy code that would write the 32-bits in the wrong order, or forget to write the upper 32-bits. Change the two u32s to one u64 and create a function call to write all 64-bit addresses in the proper order. This new function could be modified in the future if all platforms support 64-bit writes. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:03:31 +08:00
val = xhci_read_64(xhci, &xhci->op_regs->cmd_ring);
xhci_dbg(xhci, "// xHC command ring deq ptr low bits + flags = @%08x\n",
lower_32_bits(val));
xhci_dbg(xhci, "// xHC command ring deq ptr high bits = @%08x\n",
upper_32_bits(val));
USB: xhci: Ring allocation and initialization. Allocate basic xHCI host controller data structures. For every xHC, there is a command ring, an event ring, and a doorbell array. The doorbell array is used to notify the host controller that work has been enqueued onto one of the rings. The host controller driver enqueues commands on the command ring. The HW enqueues command completion events on the event ring and interrupts the system (currently using PCI interrupts, although the xHCI HW will use MSI interrupts eventually). All rings and the doorbell array must be allocated by the xHCI host controller driver. Each ring is comprised of one or more segments, which consists of 16-byte Transfer Request Blocks (TRBs) that can be chained to form a Transfer Descriptor (TD) that represents a multiple-buffer request. Segments are linked into a ring using Link TRBs, which means they are dynamically growable. The producer of the ring enqueues a TD by writing one or more TRBs in the ring and toggling the TRB cycle bit for each TRB. The consumer knows it can process the TRB when the cycle bit matches its internal consumer cycle state for the ring. The consumer cycle state is toggled an odd amount of times in the ring. An example ring (a ring must have a minimum of 16 TRBs on it, but that's too big to draw in ASCII art): chain cycle bit bit ------------------------ | TD A TRB 1 | 1 | 1 |<------------- <-- consumer dequeue ptr ------------------------ | consumer cycle state = 1 | TD A TRB 2 | 1 | 1 | | ------------------------ | | TD A TRB 3 | 0 | 1 | segment 1 | ------------------------ | | TD B TRB 1 | 1 | 1 | | ------------------------ | | TD B TRB 2 | 0 | 1 | | ------------------------ | | Link TRB | 0 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD C TRB 1 | 0 | 1 |<---- | ------------------------ | | TD D TRB 1 | 1 | 1 | | ------------------------ | | TD D TRB 2 | 1 | 1 | segment 2 | ------------------------ | | TD D TRB 3 | 1 | 1 | | ------------------------ | | TD D TRB 4 | 1 | 1 | | ------------------------ | | Link TRB | 1 | 1 |----- | ------------------------ | | | | chain cycle | | bit bit | | ------------------------ | | | TD D TRB 5 | 1 | 1 |<---- | ------------------------ | | TD D TRB 6 | 0 | 1 | | ------------------------ | | TD E TRB 1 | 0 | 1 | segment 3 | ------------------------ | | | 0 | 0 | | <-- producer enqueue ptr ------------------------ | | | 0 | 0 | | ------------------------ | | Link TRB | 0 | 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:52:34 +08:00
}
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
/* Print the last 32 bytes for 64-byte contexts */
static void dbg_rsvd64(struct xhci_hcd *xhci, u64 *ctx, dma_addr_t dma)
{
int i;
for (i = 0; i < 4; ++i) {
xhci_dbg(xhci, "@%p (virt) @%08llx "
"(dma) %#08llx - rsvd64[%d]\n",
&ctx[4 + i], (unsigned long long)dma,
ctx[4 + i], i);
dma += 8;
}
}
USB: xhci: Fix compile issues with xhci_get_slot_state() Randy Dunlap reported this error when compiling the xHCI driver: linux-next-20100104/drivers/usb/host/xhci.h:1214: sorry, unimplemented: inlining failed in call to 'xhci_get_slot_state': function body not available The xhci_get_slot_state() function belongs in xhci-dbg.c, since it involves debugging internal xHCI structures. However, it is only used in xhci-hcd.c. Some toolchains may have issues since the inlined function body is not in the xhci.h header file. Remove the inline keyword to avoid this. Reported-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2010-01-05 04:20:17 +08:00
char *xhci_get_slot_state(struct xhci_hcd *xhci,
USB: xhci: Notify the xHC when a device is reset. When a USB device is reset, the xHCI hardware must know, in order to match the device state and disable all endpoints except control endpoint 0. Issue a Reset Device command after a USB device is successfully reset. Wait on the command to finish, and then cache or free the disabled endpoint rings. There are four different USB device states that the xHCI hardware tracks: - disabled/enabled - device connection has just been detected, - default - the device has been reset and has an address of 0, - addressed - the device has a non-zero address but no configuration has been set, - configured - a set configuration succeeded. The USB core may issue a port reset when a device is in any state, but the Reset Device command will fail for a 0.96 xHC if the device is not in the addressed or configured state. Don't consider this failure as an error, but don't free any endpoint rings if this command fails. A storage driver may request that the USB device be reset during error handling, so use GPF_NOIO instead of GPF_KERNEL while allocating memory for the Reset Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-10 07:59:13 +08:00
struct xhci_container_ctx *ctx)
{
struct xhci_slot_ctx *slot_ctx = xhci_get_slot_ctx(xhci, ctx);
xhci: Make xHCI driver endian-safe This patch changes the struct members defining access to xHCI device-visible memory to use __le32/__le64 where appropriate, and then adds swaps where required. Checked with sparse that all accesses are correct. MMIO accesses use readl/writel so already are performed LE, but prototypes now reflect this with __le*. There were a couple of (debug) instances of DMA pointers being truncated to 32bits which have been fixed too. Signed-off-by: Matt Evans <matt@ozlabs.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-03-29 10:40:46 +08:00
switch (GET_SLOT_STATE(le32_to_cpu(slot_ctx->dev_state))) {
xhci: Add defines for hardcoded slot states This needs to be added to the stable trees back to 2.6.34 to support an upcoming bug fix. Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
2011-06-02 05:27:49 +08:00
case SLOT_STATE_ENABLED:
USB: xhci: Notify the xHC when a device is reset. When a USB device is reset, the xHCI hardware must know, in order to match the device state and disable all endpoints except control endpoint 0. Issue a Reset Device command after a USB device is successfully reset. Wait on the command to finish, and then cache or free the disabled endpoint rings. There are four different USB device states that the xHCI hardware tracks: - disabled/enabled - device connection has just been detected, - default - the device has been reset and has an address of 0, - addressed - the device has a non-zero address but no configuration has been set, - configured - a set configuration succeeded. The USB core may issue a port reset when a device is in any state, but the Reset Device command will fail for a 0.96 xHC if the device is not in the addressed or configured state. Don't consider this failure as an error, but don't free any endpoint rings if this command fails. A storage driver may request that the USB device be reset during error handling, so use GPF_NOIO instead of GPF_KERNEL while allocating memory for the Reset Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-10 07:59:13 +08:00
return "enabled/disabled";
xhci: Add defines for hardcoded slot states This needs to be added to the stable trees back to 2.6.34 to support an upcoming bug fix. Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
2011-06-02 05:27:49 +08:00
case SLOT_STATE_DEFAULT:
USB: xhci: Notify the xHC when a device is reset. When a USB device is reset, the xHCI hardware must know, in order to match the device state and disable all endpoints except control endpoint 0. Issue a Reset Device command after a USB device is successfully reset. Wait on the command to finish, and then cache or free the disabled endpoint rings. There are four different USB device states that the xHCI hardware tracks: - disabled/enabled - device connection has just been detected, - default - the device has been reset and has an address of 0, - addressed - the device has a non-zero address but no configuration has been set, - configured - a set configuration succeeded. The USB core may issue a port reset when a device is in any state, but the Reset Device command will fail for a 0.96 xHC if the device is not in the addressed or configured state. Don't consider this failure as an error, but don't free any endpoint rings if this command fails. A storage driver may request that the USB device be reset during error handling, so use GPF_NOIO instead of GPF_KERNEL while allocating memory for the Reset Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-10 07:59:13 +08:00
return "default";
xhci: Add defines for hardcoded slot states This needs to be added to the stable trees back to 2.6.34 to support an upcoming bug fix. Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
2011-06-02 05:27:49 +08:00
case SLOT_STATE_ADDRESSED:
USB: xhci: Notify the xHC when a device is reset. When a USB device is reset, the xHCI hardware must know, in order to match the device state and disable all endpoints except control endpoint 0. Issue a Reset Device command after a USB device is successfully reset. Wait on the command to finish, and then cache or free the disabled endpoint rings. There are four different USB device states that the xHCI hardware tracks: - disabled/enabled - device connection has just been detected, - default - the device has been reset and has an address of 0, - addressed - the device has a non-zero address but no configuration has been set, - configured - a set configuration succeeded. The USB core may issue a port reset when a device is in any state, but the Reset Device command will fail for a 0.96 xHC if the device is not in the addressed or configured state. Don't consider this failure as an error, but don't free any endpoint rings if this command fails. A storage driver may request that the USB device be reset during error handling, so use GPF_NOIO instead of GPF_KERNEL while allocating memory for the Reset Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-10 07:59:13 +08:00
return "addressed";
xhci: Add defines for hardcoded slot states This needs to be added to the stable trees back to 2.6.34 to support an upcoming bug fix. Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: stable@kernel.org
2011-06-02 05:27:49 +08:00
case SLOT_STATE_CONFIGURED:
USB: xhci: Notify the xHC when a device is reset. When a USB device is reset, the xHCI hardware must know, in order to match the device state and disable all endpoints except control endpoint 0. Issue a Reset Device command after a USB device is successfully reset. Wait on the command to finish, and then cache or free the disabled endpoint rings. There are four different USB device states that the xHCI hardware tracks: - disabled/enabled - device connection has just been detected, - default - the device has been reset and has an address of 0, - addressed - the device has a non-zero address but no configuration has been set, - configured - a set configuration succeeded. The USB core may issue a port reset when a device is in any state, but the Reset Device command will fail for a 0.96 xHC if the device is not in the addressed or configured state. Don't consider this failure as an error, but don't free any endpoint rings if this command fails. A storage driver may request that the USB device be reset during error handling, so use GPF_NOIO instead of GPF_KERNEL while allocating memory for the Reset Device command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-12-10 07:59:13 +08:00
return "configured";
default:
return "reserved";
}
}
USB: xhci: mark local functions as static Functions that are not used outsde of the module they are defined should be marked as static. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-02-09 05:55:59 +08:00
static void xhci_dbg_slot_ctx(struct xhci_hcd *xhci, struct xhci_container_ctx *ctx)
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
{
/* Fields are 32 bits wide, DMA addresses are in bytes */
int field_size = 32 / 8;
USB: xhci: Always align output device contexts to 64 bytes. Make sure the xHCI output device context is 64-byte aligned. Previous code was using the same structure for both the output device context and the input control context. Since the structure had 32 bytes of flags before the device context, the output device context wouldn't be 64-byte aligned. Define a new structure to use for the output device context and clean up the debugging for these two structures. The copy of the device context in the input control context does *not* need to be 64-byte aligned. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:08 +08:00
int i;
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
struct xhci_slot_ctx *slot_ctx = xhci_get_slot_ctx(xhci, ctx);
USB: xhci: Fix slot and endpoint context debugging. Use the virtual address of the memory hardware uses, not the address for the container of that memory. 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>
2009-08-08 05:04:40 +08:00
dma_addr_t dma = ctx->dma +
((unsigned long)slot_ctx - (unsigned long)ctx->bytes);
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
int csz = HCC_64BYTE_CONTEXT(xhci->hcc_params);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
xhci_dbg(xhci, "Slot Context:\n");
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - dev_info\n",
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
&slot_ctx->dev_info,
(unsigned long long)dma, slot_ctx->dev_info);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
dma += field_size;
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - dev_info2\n",
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
&slot_ctx->dev_info2,
(unsigned long long)dma, slot_ctx->dev_info2);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
dma += field_size;
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - tt_info\n",
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
&slot_ctx->tt_info,
(unsigned long long)dma, slot_ctx->tt_info);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
dma += field_size;
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - dev_state\n",
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
&slot_ctx->dev_state,
(unsigned long long)dma, slot_ctx->dev_state);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
dma += field_size;
USB: xhci: fix less- and greater than confusion Without this change the loops won't start Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-13 06:23:47 +08:00
for (i = 0; i < 4; ++i) {
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - rsvd[%d]\n",
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
&slot_ctx->reserved[i], (unsigned long long)dma,
slot_ctx->reserved[i], i);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
dma += field_size;
}
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
if (csz)
dbg_rsvd64(xhci, (u64 *)slot_ctx, dma);
USB: xhci: Always align output device contexts to 64 bytes. Make sure the xHCI output device context is 64-byte aligned. Previous code was using the same structure for both the output device context and the input control context. Since the structure had 32 bytes of flags before the device context, the output device context wouldn't be 64-byte aligned. Define a new structure to use for the output device context and clean up the debugging for these two structures. The copy of the device context in the input control context does *not* need to be 64-byte aligned. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:08 +08:00
}
USB: xhci: mark local functions as static Functions that are not used outsde of the module they are defined should be marked as static. Signed-off-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2011-02-09 05:55:59 +08:00
static void xhci_dbg_ep_ctx(struct xhci_hcd *xhci,
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
struct xhci_container_ctx *ctx,
unsigned int last_ep)
USB: xhci: Always align output device contexts to 64 bytes. Make sure the xHCI output device context is 64-byte aligned. Previous code was using the same structure for both the output device context and the input control context. Since the structure had 32 bytes of flags before the device context, the output device context wouldn't be 64-byte aligned. Define a new structure to use for the output device context and clean up the debugging for these two structures. The copy of the device context in the input control context does *not* need to be 64-byte aligned. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:08 +08:00
{
int i, j;
int last_ep_ctx = 31;
/* Fields are 32 bits wide, DMA addresses are in bytes */
int field_size = 32 / 8;
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
int csz = HCC_64BYTE_CONTEXT(xhci->hcc_params);
USB: xhci: Always align output device contexts to 64 bytes. Make sure the xHCI output device context is 64-byte aligned. Previous code was using the same structure for both the output device context and the input control context. Since the structure had 32 bytes of flags before the device context, the output device context wouldn't be 64-byte aligned. Define a new structure to use for the output device context and clean up the debugging for these two structures. The copy of the device context in the input control context does *not* need to be 64-byte aligned. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:08 +08:00
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
if (last_ep < 31)
last_ep_ctx = last_ep + 1;
for (i = 0; i < last_ep_ctx; ++i) {
usb: xhci-dbg: Display endpoint number and direction in context dump When CONFIG_XHCI_HCD_DEBUGGING is activated, the XHCI driver can dump device and input contexts to the console. The endpoint contexts in that dump are labeled "Endpoint N Context", where N is the XHCI endpoint index (DCI - 1). This can be very confusing, especially for people who are not that familiar with the XHCI specification. This patch introduces an xhci_get_endpoint_address function (as a counterpart to the reverse xhci_get_endpoint_index), and uses it to additionally display the endpoint number and direction when dumping contexts, which are much more commonly used concepts in USB. Signed-off-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-04-16 06:55:04 +08:00
unsigned int epaddr = xhci_get_endpoint_address(i);
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
struct xhci_ep_ctx *ep_ctx = xhci_get_ep_ctx(xhci, ctx, i);
dma_addr_t dma = ctx->dma +
USB: xhci: Fix slot and endpoint context debugging. Use the virtual address of the memory hardware uses, not the address for the container of that memory. 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>
2009-08-08 05:04:40 +08:00
((unsigned long)ep_ctx - (unsigned long)ctx->bytes);
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
usb: xhci-dbg: Display endpoint number and direction in context dump When CONFIG_XHCI_HCD_DEBUGGING is activated, the XHCI driver can dump device and input contexts to the console. The endpoint contexts in that dump are labeled "Endpoint N Context", where N is the XHCI endpoint index (DCI - 1). This can be very confusing, especially for people who are not that familiar with the XHCI specification. This patch introduces an xhci_get_endpoint_address function (as a counterpart to the reverse xhci_get_endpoint_index), and uses it to additionally display the endpoint number and direction when dumping contexts, which are much more commonly used concepts in USB. Signed-off-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-04-16 06:55:04 +08:00
xhci_dbg(xhci, "%s Endpoint %02d Context (ep_index %02d):\n",
usb_endpoint_out(epaddr) ? "OUT" : "IN",
epaddr & USB_ENDPOINT_NUMBER_MASK, i);
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - ep_info\n",
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
&ep_ctx->ep_info,
(unsigned long long)dma, ep_ctx->ep_info);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
dma += field_size;
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - ep_info2\n",
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
&ep_ctx->ep_info2,
(unsigned long long)dma, ep_ctx->ep_info2);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
dma += field_size;
USB: xhci: Represent 64-bit addresses with one u64. There are several xHCI data structures that use two 32-bit fields to represent a 64-bit address. Since some architectures don't support 64-bit PCI writes, the fields need to be written in two 32-bit writes. The xHCI specification says that if a platform is incapable of generating 64-bit writes, software must write the low 32-bits first, then the high 32-bits. Hardware that supports 64-bit addressing will wait for the high 32-bit write before reading the revised value, and hardware that only supports 32-bit writes will ignore the high 32-bit write. Previous xHCI code represented 64-bit addresses with two u32 values. This lead to buggy code that would write the 32-bits in the wrong order, or forget to write the upper 32-bits. Change the two u32s to one u64 and create a function call to write all 64-bit addresses in the proper order. This new function could be modified in the future if all platforms support 64-bit writes. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:03:31 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08llx - deq\n",
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
&ep_ctx->deq,
(unsigned long long)dma, ep_ctx->deq);
USB: xhci: Represent 64-bit addresses with one u64. There are several xHCI data structures that use two 32-bit fields to represent a 64-bit address. Since some architectures don't support 64-bit PCI writes, the fields need to be written in two 32-bit writes. The xHCI specification says that if a platform is incapable of generating 64-bit writes, software must write the low 32-bits first, then the high 32-bits. Hardware that supports 64-bit addressing will wait for the high 32-bit write before reading the revised value, and hardware that only supports 32-bit writes will ignore the high 32-bit write. Previous xHCI code represented 64-bit addresses with two u32 values. This lead to buggy code that would write the 32-bits in the wrong order, or forget to write the upper 32-bits. Change the two u32s to one u64 and create a function call to write all 64-bit addresses in the proper order. This new function could be modified in the future if all platforms support 64-bit writes. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:03:31 +08:00
dma += 2*field_size;
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - tx_info\n",
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
&ep_ctx->tx_info,
(unsigned long long)dma, ep_ctx->tx_info);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
dma += field_size;
for (j = 0; j < 3; ++j) {
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - rsvd[%d]\n",
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
&ep_ctx->reserved[j],
USB: xhci: fix lots of compiler warnings. Turns out someone never built this code on a 64bit platform. Someone owes me a beer... Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 10:14:08 +08:00
(unsigned long long)dma,
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
ep_ctx->reserved[j], j);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
dma += field_size;
}
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
if (csz)
dbg_rsvd64(xhci, (u64 *)ep_ctx, dma);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
}
USB: xhci: Always align output device contexts to 64 bytes. Make sure the xHCI output device context is 64-byte aligned. Previous code was using the same structure for both the output device context and the input control context. Since the structure had 32 bytes of flags before the device context, the output device context wouldn't be 64-byte aligned. Define a new structure to use for the output device context and clean up the debugging for these two structures. The copy of the device context in the input control context does *not* need to be 64-byte aligned. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:08 +08:00
}
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
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)
USB: xhci: Always align output device contexts to 64 bytes. Make sure the xHCI output device context is 64-byte aligned. Previous code was using the same structure for both the output device context and the input control context. Since the structure had 32 bytes of flags before the device context, the output device context wouldn't be 64-byte aligned. Define a new structure to use for the output device context and clean up the debugging for these two structures. The copy of the device context in the input control context does *not* need to be 64-byte aligned. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:08 +08:00
{
int i;
/* Fields are 32 bits wide, DMA addresses are in bytes */
int field_size = 32 / 8;
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
dma_addr_t dma = ctx->dma;
int csz = HCC_64BYTE_CONTEXT(xhci->hcc_params);
if (ctx->type == XHCI_CTX_TYPE_INPUT) {
struct xhci_input_control_ctx *ctrl_ctx =
xhci_get_input_control_ctx(xhci, ctx);
xhci: Remove BUG_ON in xhci_get_input_control_ctx. Fail gracefully, instead of causing the kernel to panic, if the input control context doesn't have the right type (XHCI_CTX_TYPE_INPUT). Push finding the pointer to the input control context up into functions that can fail. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: John Youn <johnyoun@synopsys.com>
2013-04-24 08:11:14 +08:00
if (!ctrl_ctx) {
xhci_warn(xhci, "Could not get input context, bad type.\n");
return;
}
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - drop flags\n",
&ctrl_ctx->drop_flags, (unsigned long long)dma,
ctrl_ctx->drop_flags);
USB: xhci: Always align output device contexts to 64 bytes. Make sure the xHCI output device context is 64-byte aligned. Previous code was using the same structure for both the output device context and the input control context. Since the structure had 32 bytes of flags before the device context, the output device context wouldn't be 64-byte aligned. Define a new structure to use for the output device context and clean up the debugging for these two structures. The copy of the device context in the input control context does *not* need to be 64-byte aligned. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:08 +08:00
dma += field_size;
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - add flags\n",
&ctrl_ctx->add_flags, (unsigned long long)dma,
ctrl_ctx->add_flags);
dma += field_size;
for (i = 0; i < 6; ++i) {
xhci_dbg(xhci, "@%p (virt) @%08llx (dma) %#08x - rsvd2[%d]\n",
&ctrl_ctx->rsvd2[i], (unsigned long long)dma,
ctrl_ctx->rsvd2[i], i);
dma += field_size;
}
if (csz)
dbg_rsvd64(xhci, (u64 *)ctrl_ctx, dma);
USB: xhci: Always align output device contexts to 64 bytes. Make sure the xHCI output device context is 64-byte aligned. Previous code was using the same structure for both the output device context and the input control context. Since the structure had 32 bytes of flags before the device context, the output device context wouldn't be 64-byte aligned. Define a new structure to use for the output device context and clean up the debugging for these two structures. The copy of the device context in the input control context does *not* need to be 64-byte aligned. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:08 +08:00
}
USB: xhci: Support for 64-byte contexts Adds support for controllers that use 64-byte contexts. The following context data structures are affected by this: Device, Input, Input Control, Endpoint, and Slot. To accommodate the use of either 32 or 64-byte contexts, a Device or Input context can only be accessed through functions which look-up and return pointers to their contained contexts. Signed-off-by: John Youn <johnyoun@synopsys.com> Acked-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-07-28 03:05:15 +08:00
xhci_dbg_slot_ctx(xhci, ctx);
xhci_dbg_ep_ctx(xhci, ctx, last_ep);
USB: xhci: Allocate and address USB devices xHCI needs to get a "Slot ID" from the host controller and allocate other data structures for every USB device. Make usb_alloc_dev() and usb_release_dev() allocate and free these device structures. After setting up the xHC device structures, usb_alloc_dev() must wait for the hardware to respond to an Enable Slot command. usb_alloc_dev() fires off a Disable Slot command and does not wait for it to complete. When the USB core wants to choose an address for the device, the xHCI driver must issue a Set Address command and wait for an event for that command. Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-28 10:57:38 +08:00
}
xhci: add traces for debug messages in xhci_address_device() This patch declares an event class for trace events that trace messages with variadic arguments, called xhci_log_msg, and defines a trace event for tracing the debug messages in xhci_address_device() function, called xhci_dbg_address. In order to implement this type of trace events, a wrapper function, called xhci_dbg_trace(), was created that records the format string and variadic arguments into a va_format structure which is passed as argument to the tracepoints of the class xhci_log_msg. All the xhci_dbg() calls in xhci_address_device() are replaced with calls to xhci_dbg_trace(). The functionality of xhci_dbg() log messages was not removed though, but it is placed inside xhci_dbg_trace(). This trace event aims to give the ability to the user or the developper to isolate and trace the debug messages generated when an Address Device Command is issued to xHC. Signed-off-by: Xenia Ragiadakou <burzalodowa@gmail.com> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
2013-08-06 05:22:15 +08:00
void xhci_dbg_trace(struct xhci_hcd *xhci, void (*trace)(struct va_format *),
const char *fmt, ...)
{
struct va_format vaf;
va_list args;
va_start(args, fmt);
vaf.fmt = fmt;
vaf.va = &args;
xhci_dbg(xhci, "%pV\n", &vaf);
trace(&vaf);
va_end(args);
}