kernel/git/stable/linux.git/drivers/usb/host/ehci-octeon.c, branch master

USB: host: Remove ehci-octeon and ohci-octeon drivers

2014-11-25T17:19:28+00:00

Remove special-purpose octeon drivers and instead use ehci-platform and ohci-platform as suggested with http://marc.info/?l=linux-mips&m=140139694721623&w=2 [andreas.herrmann: fixed compile error] Cc: David Daney Cc: Alex Smith Signed-off-by: Alan Stern Signed-off-by: Andreas Herrmann Acked-by: Ralf Baechle Tested-by: Aaro Koskinen Signed-off-by: Greg Kroah-Hartman

host: ehci-octeon: remove duplicate check on resource

2014-11-07T17:01:50+00:00

Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by: Varka Bhadram Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

USB: ehci-octeon: Use devm_ioremap_resource()

2013-12-19T00:34:20+00:00

Use devm_ioremap_resource() to make cleanup paths simpler. Signed-off-by: Jingoo Han Acked-by: David Daney Signed-off-by: Greg Kroah-Hartman

usb: hcd: move controller wakeup setting initialization to individual driver

2013-12-09T02:06:46+00:00

Individual controller driver has different requirement for wakeup setting, so move it from core to itself. In order to align with current etting the default wakeup setting is enabled (except for chipidea host). Pass compile test with below commands: make O=outout/all allmodconfig make -j$CPU_NUM O=outout/all drivers/usb Signed-off-by: Peter Chen Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

DMA-API: usb: use dma_set_coherent_mask()

2013-10-31T14:49:01+00:00

The correct way for a driver to specify the coherent DMA mask is not to directly access the field in the struct device, but to use dma_set_coherent_mask(). Only arch and bus code should access this member directly. Convert all direct write accesses to using the correct API. Acked-by: Felipe Balbi Acked-by: Nicolas Ferre Signed-off-by: Russell King

USB: EHCI: support running URB giveback in tasklet context

2013-08-12T18:43:49+00:00

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 Signed-off-by: Ming Lei Signed-off-by: Greg Kroah-Hartman

USB: ehci-octeon: remove unnecessary platform_set_drvdata()

2013-05-17T00:47:15+00:00

The driver core clears the driver data to NULL after device_release or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d (device-core: Ensure drvdata = NULL when no driver is bound). Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han Signed-off-by: Greg Kroah-Hartman

USB: EHCI: remove ehci_port_power() routine

2012-10-31T19:48:07+00:00

This patch (as1623) removes the ehci_port_power() routine and all the places that call it. There's no reason for ehci-hcd to change the port power settings; the hub driver takes care of all that stuff. There is one exception: When the controller is resumed from hibernation or following a loss of power, the ports that are supposed to be handed over to a companion controller must be powered on first. Otherwise the handover won't work. This process is not visible to the hub driver, so it has to be handled in ehci-hcd. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

EHCI: centralize controller initialization

2012-07-09T20:35:05+00:00

This patch (as1564c) converts the EHCI platform drivers to use the central ehci_setup() routine for generic controller initialization rather than each having its own idiosyncratic approach. The major point of difficulty lies in ehci-pci's many vendor- and device-specific workarounds. Some of them have to be applied before calling ehci_setup() and some after, which necessitates a fair amount of code motion. The other platform drivers require much smaller changes. One point not addressed by the patch is whether ports should be powered on or off following initialization. The different drivers appear to handle this pretty much at random. In fact it shouldn't matter, because the hub driver turns on power to all ports when it binds to the root hub. Straightening that out will be left for another day. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

usb: Remove ehci_reset call from ehci_run

2011-12-08T17:38:53+00:00

Remove the ehci_reset() call done in the ehci_run() routine of the USB EHCI host controller driver and add an ehci_reset() call to the probe processing of all EHCI platform drivers that do not already call ehci_reset(). The call to ehci_reset() from ehci_run() was problematic for several platform drivers, and unnecessary for others. This change moves the decision to call ehci_reset() at driver startup to the platform driver code. Signed-off-by: Geoff Levand Acked-by: Alan Stern