2007-12-31 07:28:50 +08:00
|
|
|
/*
|
|
|
|
* EHCI HCD (Host Controller Driver) for USB.
|
|
|
|
*
|
|
|
|
* Bus Glue for PPC On-Chip EHCI driver on the of_platform bus
|
|
|
|
* Tested on AMCC PPC 440EPx
|
|
|
|
*
|
|
|
|
* Valentine Barshak <vbarshak@ru.mvista.com>
|
|
|
|
*
|
|
|
|
* Based on "ehci-ppc-soc.c" by Stefan Roese <sr@denx.de>
|
|
|
|
* and "ohci-ppc-of.c" by Sylvain Munaut <tnt@246tNt.com>
|
|
|
|
*
|
|
|
|
* This file is licenced under the GPL.
|
|
|
|
*/
|
|
|
|
|
2013-01-21 18:09:22 +08:00
|
|
|
#include <linux/err.h>
|
2007-12-31 07:28:50 +08:00
|
|
|
#include <linux/signal.h>
|
|
|
|
|
|
|
|
#include <linux/of.h>
|
|
|
|
#include <linux/of_platform.h>
|
|
|
|
|
|
|
|
|
|
|
|
static const struct hc_driver ehci_ppc_of_hc_driver = {
|
|
|
|
.description = hcd_name,
|
|
|
|
.product_desc = "OF EHCI",
|
|
|
|
.hcd_priv_size = sizeof(struct ehci_hcd),
|
|
|
|
|
|
|
|
/*
|
|
|
|
* generic hardware linkage
|
|
|
|
*/
|
|
|
|
.irq = ehci_irq,
|
USB: EHCI: support running URB giveback in tasklet context
All 4 transfer types can work well on EHCI HCD after switching to run
URB giveback in tasklet context, so mark all HCD drivers to support
it.
Also we don't need to release ehci->lock during URB giveback any more.
>From below test results on 3 machines(2 ARM and one x86), time
consumed by EHCI interrupt handler droped much without performance
loss.
1 test description
1.1 mass storage performance test:
- run below command 10 times and compute the average performance
dd if=/dev/sdN iflag=direct of=/dev/null bs=200M count=1
- two usb mass storage device:
A: sandisk extreme USB 3.0 16G(used in test case 1 & case 2)
B: kingston DataTraveler G2 4GB(only used in test case 2)
1.2 uvc function test:
- run one simple capture program in the below link
http://kernel.ubuntu.com/~ming/up/capture.c
- capture format 640*480 and results in High Bandwidth mode on the
uvc device: Z-Star 0x0ac8/0x3450
- on T410(x86) laptop, also use guvcview to watch video capture/playback
1.3 about test2 and test4
- both two devices involved are tested concurrently by above test items
1.4 how to compute irq time(the time consumed by ehci_irq)
- use trace points of irq:irq_handler_entry and irq:irq_handler_exit
1.5 kernel
3.10.0-rc3-next-20130528
1.6 test machines
Pandaboard A1: ARM CortexA9 dural core
Arndale board: ARM CortexA15 dural core
T410: i5 CPU 2.67GHz quad core
2 test result
2.1 test case1: single mass storage device performance test
--------------------------------------------------------------------
upstream | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1: 25.280(avg:145,max:772) | 25.540(avg:14, max:75)
Arndale board: 29.700(avg:33, max:129) | 29.700(avg:10, max:50)
T410: 34.430(avg:17, max:154*)| 34.660(avg:12, max:155)
---------------------------------------------------------------------
2.2 test case2: two mass storage devices' performance test
--------------------------------------------------------------------
upstream | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1: 15.840/15.580(avg:158,max:1216) | 16.500/16.160(avg:15,max:139)
Arndale board: 17.370/16.220(avg:33 max:234) | 17.480/16.200(avg:11, max:91)
T410: 21.180/19.820(avg:18 max:160) | 21.220/19.880(avg:11, max:149)
---------------------------------------------------------------------
2.3 test case3: one uvc streaming test
- uvc device works well(on x86, luvcview can be used too and has
same result with uvc capture)
--------------------------------------------------------------------
upstream | patched
irq time(us) | irq time(us)
--------------------------------------------------------------------
Pandaboard A1: (avg:445, max:873) | (avg:33, max:44)
Arndale board: (avg:316, max:630) | (avg:20, max:27)
T410: (avg:39, max:107) | (avg:10, max:65)
---------------------------------------------------------------------
2.4 test case4: one uvc streaming plus one mass storage device test
--------------------------------------------------------------------
upstream | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1: 20.340(avg:259,max:1704)| 20.390(avg:24, max:101)
Arndale board: 23.460(avg:124,max:726) | 23.370(avg:15, max:52)
T410: 28.520(avg:27, max:169) | 28.630(avg:13, max:160)
---------------------------------------------------------------------
2.5 test case5: read single mass storage device with small transfer
- run below command 10 times and compute the average speed
dd if=/dev/sdN iflag=direct of=/dev/null bs=4K count=4000
1), test device A:
--------------------------------------------------------------------
upstream | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1: 6.5(avg:21, max:64) | 6.5(avg:10, max:24)
Arndale board: 8.13(avg:12, max:23) | 8.06(avg:7, max:17)
T410: 6.66(avg:13, max:131) | 6.84(avg:11, max:149)
---------------------------------------------------------------------
2), test device B:
--------------------------------------------------------------------
upstream | patched
perf(MB/s)+irq time(us) | perf(MB/s)+irq time(us)
--------------------------------------------------------------------
Pandaboard A1: 5.5(avg:21,max:43) | 5.49(avg:10, max:24)
Arndale board: 5.9(avg:12, max:22) | 5.9(avg:7, max:17)
T410: 5.48(avg:13, max:155) | 5.48(avg:7, max:140)
---------------------------------------------------------------------
* On T410, sometimes read ehci status register in ehci_irq takes more
than 100us, and the problem has been reported on the link:
http://marc.info/?t=137065867300001&r=1&w=2
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-07-03 22:53:11 +08:00
|
|
|
.flags = HCD_MEMORY | HCD_USB2 | HCD_BH,
|
2007-12-31 07:28:50 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* basic lifecycle operations
|
|
|
|
*/
|
2012-07-10 03:55:14 +08:00
|
|
|
.reset = ehci_setup,
|
2007-12-31 07:28:50 +08:00
|
|
|
.start = ehci_run,
|
|
|
|
.stop = ehci_stop,
|
|
|
|
.shutdown = ehci_shutdown,
|
|
|
|
|
|
|
|
/*
|
|
|
|
* managing i/o requests and associated device resources
|
|
|
|
*/
|
|
|
|
.urb_enqueue = ehci_urb_enqueue,
|
|
|
|
.urb_dequeue = ehci_urb_dequeue,
|
|
|
|
.endpoint_disable = ehci_endpoint_disable,
|
2009-05-28 06:21:56 +08:00
|
|
|
.endpoint_reset = ehci_endpoint_reset,
|
2007-12-31 07:28:50 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* scheduling support
|
|
|
|
*/
|
|
|
|
.get_frame_number = ehci_get_frame,
|
|
|
|
|
|
|
|
/*
|
|
|
|
* root hub support
|
|
|
|
*/
|
|
|
|
.hub_status_data = ehci_hub_status_data,
|
|
|
|
.hub_control = ehci_hub_control,
|
|
|
|
#ifdef CONFIG_PM
|
|
|
|
.bus_suspend = ehci_bus_suspend,
|
|
|
|
.bus_resume = ehci_bus_resume,
|
|
|
|
#endif
|
2008-05-21 04:58:11 +08:00
|
|
|
.relinquish_port = ehci_relinquish_port,
|
2008-05-21 04:58:29 +08:00
|
|
|
.port_handed_over = ehci_port_handed_over,
|
2009-06-29 22:47:30 +08:00
|
|
|
|
|
|
|
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
|
2007-12-31 07:28:50 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 440EPx Errata USBH_3
|
|
|
|
* Fix: Enable Break Memory Transfer (BMT) in INSNREG3
|
|
|
|
*/
|
|
|
|
#define PPC440EPX_EHCI0_INSREG_BMT (0x1 << 0)
|
2012-11-20 02:21:48 +08:00
|
|
|
static int
|
2007-12-31 07:28:50 +08:00
|
|
|
ppc44x_enable_bmt(struct device_node *dn)
|
|
|
|
{
|
|
|
|
__iomem u32 *insreg_virt;
|
|
|
|
|
|
|
|
insreg_virt = of_iomap(dn, 1);
|
|
|
|
if (!insreg_virt)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
out_be32(insreg_virt + 3, PPC440EPX_EHCI0_INSREG_BMT);
|
|
|
|
|
|
|
|
iounmap(insreg_virt);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2012-11-20 02:21:48 +08:00
|
|
|
static int ehci_hcd_ppc_of_probe(struct platform_device *op)
|
2007-12-31 07:28:50 +08:00
|
|
|
{
|
2010-04-14 07:12:29 +08:00
|
|
|
struct device_node *dn = op->dev.of_node;
|
2007-12-31 07:28:50 +08:00
|
|
|
struct usb_hcd *hcd;
|
USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]
A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller. If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed. When an ehci driver
is loaded, it explicitly takes control of the ports. If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not. If it
is high speed, the driver retains control of the port. If it is not,
the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-10 02:43:30 +08:00
|
|
|
struct ehci_hcd *ehci = NULL;
|
2007-12-31 07:28:50 +08:00
|
|
|
struct resource res;
|
|
|
|
int irq;
|
|
|
|
int rv;
|
|
|
|
|
USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]
A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller. If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed. When an ehci driver
is loaded, it explicitly takes control of the ports. If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not. If it
is high speed, the driver retains control of the port. If it is not,
the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-10 02:43:30 +08:00
|
|
|
struct device_node *np;
|
|
|
|
|
2007-12-31 07:28:50 +08:00
|
|
|
if (usb_disabled())
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
dev_dbg(&op->dev, "initializing PPC-OF USB Controller\n");
|
|
|
|
|
|
|
|
rv = of_address_to_resource(dn, 0, &res);
|
|
|
|
if (rv)
|
|
|
|
return rv;
|
|
|
|
|
|
|
|
hcd = usb_create_hcd(&ehci_ppc_of_hc_driver, &op->dev, "PPC-OF USB");
|
|
|
|
if (!hcd)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
hcd->rsrc_start = res.start;
|
2011-06-10 00:13:32 +08:00
|
|
|
hcd->rsrc_len = resource_size(&res);
|
2007-12-31 07:28:50 +08:00
|
|
|
|
|
|
|
irq = irq_of_parse_and_map(dn, 0);
|
|
|
|
if (irq == NO_IRQ) {
|
2010-02-06 09:51:13 +08:00
|
|
|
printk(KERN_ERR "%s: irq_of_parse_and_map failed\n", __FILE__);
|
2007-12-31 07:28:50 +08:00
|
|
|
rv = -EBUSY;
|
|
|
|
goto err_irq;
|
|
|
|
}
|
|
|
|
|
2013-01-21 18:09:22 +08:00
|
|
|
hcd->regs = devm_ioremap_resource(&op->dev, &res);
|
|
|
|
if (IS_ERR(hcd->regs)) {
|
|
|
|
rv = PTR_ERR(hcd->regs);
|
2007-12-31 07:28:50 +08:00
|
|
|
goto err_ioremap;
|
|
|
|
}
|
|
|
|
|
|
|
|
ehci = hcd_to_ehci(hcd);
|
USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]
A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller. If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed. When an ehci driver
is loaded, it explicitly takes control of the ports. If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not. If it
is high speed, the driver retains control of the port. If it is not,
the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-10 02:43:30 +08:00
|
|
|
np = of_find_compatible_node(NULL, NULL, "ibm,usb-ohci-440epx");
|
|
|
|
if (np != NULL) {
|
|
|
|
/* claim we really affected by usb23 erratum */
|
|
|
|
if (!of_address_to_resource(np, 0, &res))
|
2012-07-30 22:43:45 +08:00
|
|
|
ehci->ohci_hcctrl_reg =
|
|
|
|
devm_ioremap(&op->dev,
|
|
|
|
res.start + OHCI_HCCTRL_OFFSET,
|
|
|
|
OHCI_HCCTRL_LEN);
|
USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]
A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller. If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed. When an ehci driver
is loaded, it explicitly takes control of the ports. If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not. If it
is high speed, the driver retains control of the port. If it is not,
the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-10 02:43:30 +08:00
|
|
|
else
|
2010-02-06 09:51:13 +08:00
|
|
|
pr_debug("%s: no ohci offset in fdt\n", __FILE__);
|
USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]
A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller. If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed. When an ehci driver
is loaded, it explicitly takes control of the ports. If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not. If it
is high speed, the driver retains control of the port. If it is not,
the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-10 02:43:30 +08:00
|
|
|
if (!ehci->ohci_hcctrl_reg) {
|
2010-02-06 09:51:13 +08:00
|
|
|
pr_debug("%s: ioremap for ohci hcctrl failed\n", __FILE__);
|
USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]
A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller. If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed. When an ehci driver
is loaded, it explicitly takes control of the ports. If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not. If it
is high speed, the driver retains control of the port. If it is not,
the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-10 02:43:30 +08:00
|
|
|
} else {
|
|
|
|
ehci->has_amcc_usb23 = 1;
|
|
|
|
}
|
|
|
|
}
|
2007-12-31 07:28:50 +08:00
|
|
|
|
|
|
|
if (of_get_property(dn, "big-endian", NULL)) {
|
|
|
|
ehci->big_endian_mmio = 1;
|
|
|
|
ehci->big_endian_desc = 1;
|
|
|
|
}
|
|
|
|
if (of_get_property(dn, "big-endian-regs", NULL))
|
|
|
|
ehci->big_endian_mmio = 1;
|
|
|
|
if (of_get_property(dn, "big-endian-desc", NULL))
|
|
|
|
ehci->big_endian_desc = 1;
|
|
|
|
|
|
|
|
ehci->caps = hcd->regs;
|
|
|
|
|
|
|
|
if (of_device_is_compatible(dn, "ibm,usb-ehci-440epx")) {
|
|
|
|
rv = ppc44x_enable_bmt(dn);
|
|
|
|
ehci_dbg(ehci, "Break Memory Transfer (BMT) is %senabled!\n",
|
|
|
|
rv ? "NOT ": "");
|
|
|
|
}
|
|
|
|
|
|
|
|
rv = usb_add_hcd(hcd, irq, 0);
|
2010-08-14 17:06:19 +08:00
|
|
|
if (rv)
|
2012-07-30 22:43:45 +08:00
|
|
|
goto err_ioremap;
|
2010-08-14 17:06:19 +08:00
|
|
|
|
|
|
|
return 0;
|
2007-12-31 07:28:50 +08:00
|
|
|
|
|
|
|
err_ioremap:
|
|
|
|
irq_dispose_mapping(irq);
|
|
|
|
err_irq:
|
|
|
|
usb_put_hcd(hcd);
|
|
|
|
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-08-06 23:25:50 +08:00
|
|
|
static int ehci_hcd_ppc_of_remove(struct platform_device *op)
|
2007-12-31 07:28:50 +08:00
|
|
|
{
|
2013-05-23 18:18:39 +08:00
|
|
|
struct usb_hcd *hcd = platform_get_drvdata(op);
|
USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]
A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller. If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed. When an ehci driver
is loaded, it explicitly takes control of the ports. If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not. If it
is high speed, the driver retains control of the port. If it is not,
the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-10 02:43:30 +08:00
|
|
|
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
|
|
|
|
|
|
|
|
struct device_node *np;
|
|
|
|
struct resource res;
|
|
|
|
|
2007-12-31 07:28:50 +08:00
|
|
|
dev_dbg(&op->dev, "stopping PPC-OF USB Controller\n");
|
|
|
|
|
|
|
|
usb_remove_hcd(hcd);
|
|
|
|
|
|
|
|
irq_dispose_mapping(hcd->irq);
|
|
|
|
|
USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]
A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller. If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed. When an ehci driver
is loaded, it explicitly takes control of the ports. If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not. If it
is high speed, the driver retains control of the port. If it is not,
the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-10 02:43:30 +08:00
|
|
|
/* use request_mem_region to test if the ohci driver is loaded. if so
|
|
|
|
* ensure the ohci core is operational.
|
|
|
|
*/
|
|
|
|
if (ehci->has_amcc_usb23) {
|
|
|
|
np = of_find_compatible_node(NULL, NULL, "ibm,usb-ohci-440epx");
|
|
|
|
if (np != NULL) {
|
|
|
|
if (!of_address_to_resource(np, 0, &res))
|
|
|
|
if (!request_mem_region(res.start,
|
|
|
|
0x4, hcd_name))
|
|
|
|
set_ohci_hcfs(ehci, 1);
|
|
|
|
else
|
|
|
|
release_mem_region(res.start, 0x4);
|
|
|
|
else
|
2010-02-06 09:51:13 +08:00
|
|
|
pr_debug("%s: no ohci offset in fdt\n", __FILE__);
|
USB: powerpc: Workaround for the PPC440EPX USBH_23 errata [take 3]
A published errata for ppc440epx states, that when running Linux with
both EHCI and OHCI modules loaded, the EHCI module experiences a fatal
error when a high-speed device is connected to the USB2.0, and
functions normally if OHCI module is not loaded.
There used to be recommendation to use only hi-speed or full-speed
devices with specific conditions, when respective module was unloaded.
Later, it was observed that ohci suspend is enough to keep things
going, and it was turned into workaround, as explained below.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In
USB 2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers
is connected at any one time. In the 440EPx, there is only one OHCI
companion controller, and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion
controller. If you load only an ohci driver, it will have control of
the ports and any deviceplugged in will operate, although high speed
devices will be forced to operate at full speed. When an ehci driver
is loaded, it explicitly takes control of the ports. If there is a
device connected, and / or every time there is a new device connected,
the ehci driver determines if the device is high speed or not. If it
is high speed, the driver retains control of the port. If it is not,
the driver explicitly gives the companion controller control of the
port.
The is a software workaround that uses
Initial version of the software workaround was posted to
linux-usb-devel:
http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg54019.html
and later available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1&family=15&ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to
get rid of (some) hardcoded defines.
Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-11-10 02:43:30 +08:00
|
|
|
of_node_put(np);
|
|
|
|
}
|
|
|
|
}
|
2007-12-31 07:28:50 +08:00
|
|
|
usb_put_hcd(hcd);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2010-01-10 22:35:03 +08:00
|
|
|
static const struct of_device_id ehci_hcd_ppc_of_match[] = {
|
2007-12-31 07:28:50 +08:00
|
|
|
{
|
|
|
|
.compatible = "usb-ehci",
|
|
|
|
},
|
|
|
|
{},
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, ehci_hcd_ppc_of_match);
|
|
|
|
|
|
|
|
|
2011-02-23 12:08:34 +08:00
|
|
|
static struct platform_driver ehci_hcd_ppc_of_driver = {
|
2007-12-31 07:28:50 +08:00
|
|
|
.probe = ehci_hcd_ppc_of_probe,
|
|
|
|
.remove = ehci_hcd_ppc_of_remove,
|
2013-07-22 20:04:50 +08:00
|
|
|
.shutdown = usb_hcd_platform_shutdown,
|
2010-04-14 07:13:02 +08:00
|
|
|
.driver = {
|
|
|
|
.name = "ppc-of-ehci",
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.of_match_table = ehci_hcd_ppc_of_match,
|
2007-12-31 07:28:50 +08:00
|
|
|
},
|
|
|
|
};
|