linux-toradex.git/include/linux/usb/hcd.h, branch v3.12.42

usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN

2015-03-01T22:34:20+00:00

commit 5efd2ea8c9f4f12916ffc8ba636792ce052f6911 upstream.

the following error pops up during "testusb -a -t 10"
| musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,	f134e000/be842000 (bad dma)
hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
hcd_buffer_alloc() returning memory which is 32 bytes aligned and it
might by identified by buffer_offset() as another buffer. This means the
buffer which is on a 32 byte boundary will not get freed, instead it
tries to free another buffer with the error message.

This patch fixes the issue by creating the smallest DMA buffer with the
size of ARCH_KMALLOC_MINALIGN (or 32 in case ARCH_KMALLOC_MINALIGN is
smaller). This might be 32, 64 or even 128 bytes. The next three pools
will have the size 128, 512 and 2048.
In case the smallest pool is 128 bytes then we have only three pools
instead of four (and zero the first entry in the array).
The last pool size is always 2048 bytes which is the assumed PAGE_SIZE /
2 of 4096. I doubt it makes sense to continue using PAGE_SIZE / 2 where
we would end up with 8KiB buffer in case we have 16KiB pages.
Instead I think it makes sense to have a common size(s) and extend them
if there is need to.
There is a BUILD_BUG_ON() now in case someone has a minalign of more than
128 bytes.

Signed-off-by: Sebastian Andrzej Siewior 
Acked-by: Alan Stern 
Signed-off-by: Jiri Slaby

USB: fix build error when CONFIG_PM_SLEEP isn't enabled

2013-08-30T18:12:06+00:00

This patch fixes a build error that occurs when CONFIG_PM is enabled
and CONFIG_PM_SLEEP isn't:

>> drivers/usb/host/ohci-pci.c:294:10: error: 'usb_hcd_pci_pm_ops' undeclared here (not in a function)
      .pm = &usb_hcd_pci_pm_ops

Since the usb_hcd_pci_pm_ops structure is defined and used when
CONFIG_PM is enabled, its declaration should not be protected by
CONFIG_PM_SLEEP.

Signed-off-by: Alan Stern 
Reported-by: kbuild test robot 
CC: 
Signed-off-by: Greg Kroah-Hartman

USB: HCD: support giveback of URB in tasklet context

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

This patch implements the mechanism of giveback of URB in
tasklet context, so that hardware interrupt handling time for
usb host controller can be saved much, and HCD interrupt handling
can be simplified.

Motivations:

1), on some arch(such as ARM), DMA mapping/unmapping is a bit
time-consuming, for example: when accessing usb mass storage
via EHCI on pandaboard, the common length of transfer buffer is 120KB,
the time consumed on DMA unmapping may reach hundreds of microseconds;
even on A15 based box, the time is still about scores of microseconds

2), on some arch, reading DMA coherent memoery is very time-consuming,
the most common example is usb video class driver[1]

3), driver's complete() callback may do much things which is driver
specific, so the time is consumed unnecessarily in hardware irq context.

4), running driver's complete() callback in hardware irq context causes
that host controller driver has to release its lock in interrupt handler,
so reacquiring the lock after return may busy wait a while and increase
interrupt handling time. More seriously, releasing the HCD lock makes
HCD becoming quite complicated to deal with introduced races.

So the patch proposes to run giveback of URB in tasklet context, then
time consumed in HCD irq handling doesn't depend on drivers' complete and
DMA mapping/unmapping any more, also we can simplify HCD since the HCD
lock isn't needed to be released during irq handling.

The patch should be reasonable and doable:

1), for drivers, they don't care if the complete() is called in hard irq
context or softirq context

2), the biggest change is the situation in which usb_submit_urb() is called
in complete() callback, so the introduced tasklet schedule delay might be a
con, but it shouldn't be a big deal:

	- control/bulk asynchronous transfer isn't sensitive to schedule
	  delay

	- the patch schedules giveback of periodic URBs using
	  tasklet_hi_schedule, so the introduced delay should be very
	  small

	- for ISOC transfer, generally, drivers submit several URBs
	  concurrently to avoid interrupt delay, so it is OK with the
	  little schedule delay.

	- for interrupt transfer, generally, drivers only submit one URB
	  at the same time, but interrupt transfer is often used in event
	  report, polling, ... situations, and a little delay should be OK.

Considered that HCDs may optimize on submitting URB in complete(), the
patch may cause the optimization not working, so introduces one flag to mark
if the HCD supports to run giveback URB in tasklet context. When all HCDs
are ready, the flag can be removed.

[1], http://marc.info/?t=136438111600010&r=1&w=2

Cc: Oliver Neukum 
Acked-by: Alan Stern 
Signed-off-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman

Allow the USB HCD to create Wireless USB root hubs

2013-06-03T17:52:40+00:00

This patch adds Wireless USB root hub support to the USB HCD.  It allows
the HWA to create its root hub which previously failed because the HCD
treated wireless root hubs the same as USB2 high speed hubs.  The creation
of the root hub would fail in that case due to lack of TTs which wireless
root hubs do not support.

Signed-off-by: Thomas Pugliese 
Signed-off-by: Greg Kroah-Hartman

USB: remove CONFIG_USB_SUSPEND option

2013-03-28T18:10:22+00:00

This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially
replacing it everywhere with CONFIG_PM_RUNTIME (except for one place
in hub.c, where it is replaced with CONFIG_PM because the code needs
to be used in both runtime and system PM).  The net result is code
shrinkage and simplification.

There's very little point in keeping CONFIG_USB_SUSPEND because almost
everybody enables it.  The few that don't will find that the usbcore
module has gotten somewhat bigger and they will have to take active
measures if they want to prevent hubs from being runtime suspended.

Signed-off-by: Alan Stern 
CC: Peter Chen 
Signed-off-by: Greg Kroah-Hartman

usb: add find_raw_port_number callback to struct hc_driver()

2013-03-25T17:39:17+00:00

xhci driver divides the root hub into two logical hubs which work
respectively for usb 2.0 and usb 3.0 devices. They are independent
devices in the usb core. But in the ACPI table, it's one device node
and all usb2.0 and usb3.0 ports are under it. Binding usb port with
its acpi node needs the raw port number which is reflected in the xhci
extended capabilities table. This patch is to add find_raw_port_number
callback to struct hc_driver(), fill it with xhci_find_raw_port_number()
which will return raw port number and add a wrap usb_hcd_find_raw_port_number().

Otherwise, refactor xhci_find_real_port_number(). Using
xhci_find_raw_port_number() to get real index in the HW port status
registers instead of scanning through the xHCI roothub port array.
This can help to speed up.

All addresses in xhci->usb2_ports and xhci->usb3_ports array are
kown good ports and don't include following bad ports in the extended
capabilities talbe.
     (1) root port that doesn't have an entry
     (2) root port with unknown speed
     (3) root port that is listed twice and with different speeds.

So xhci_find_raw_port_number() will only return port num of good ones
and never touch bad ports above.

Signed-off-by: Lan Tianyu 
Signed-off-by: Sarah Sharp

USB: add usb_hcd_{start,end}_port_resume

2013-01-25T23:06:01+00:00

This patch (as1649) adds a mechanism for host controller drivers to
inform usbcore when they have begun or ended resume signalling on a
particular root-hub port.  The core will then make sure that the root
hub does not get runtime-suspended while the port resume is going on.

Since commit 596d789a211d134dc5f94d1e5957248c204ef850 (USB: set hub's
default autosuspend delay as 0), the system tries to suspend hubs
whenever they aren't in use.  While a root-hub port is being resumed,
the root hub does not appear to be in use.  Attempted runtime suspends
fail because of the ongoing port resume, but the PM core just keeps on
trying over and over again.  We want to prevent this wasteful effort.

Signed-off-by: Alan Stern 
Tested-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman

usb: hcd: use resource_size_t for specifying resource data

2012-08-16T21:04:14+00:00

Changed the type of rsrc_start and rsrc_len from u64 to resource_size_t
so that it behaves well with resource API's like *resource_size()* on both
32bit and 64bit devices.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Felipe Balbi 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'usb-linus' into usb-next

2012-06-13T22:22:54+00:00

This is to pick up the changes to the option driver, which are needed
for follow-on patches from Johan.

Signed-off-by: Greg Kroah-Hartman

USB: add NO_D3_DURING_SLEEP flag and revert 151b61284776be2

2012-06-13T20:11:39+00:00

This patch (as1558) fixes a problem affecting several ASUS computers:
The machine crashes or corrupts memory when going into suspend if the
ehci-hcd driver is bound to any controllers.  Users have been forced
to unbind or unload ehci-hcd before putting their systems to sleep.

After extensive testing, it was determined that the machines don't
like going into suspend when any EHCI controllers are in the PCI D3
power state.  Presumably this is a firmware bug, but there's nothing
we can do about it except to avoid putting the controllers in D3
during system sleep.

The patch adds a new flag to indicate whether the problem is present,
and avoids changing the controller's power state if the flag is set.
Runtime suspend is unaffected; this matters only for system suspend.
However as a side effect, the controller will not respond to remote
wakeup requests while the system is asleep.  Hence USB wakeup is not
functional -- but of course, this is already true in the current state
of affairs.

A similar patch has already been applied as commit
151b61284776be2d6f02d48c23c3625678960b97 (USB: EHCI: fix crash during
suspend on ASUS computers).  The patch supersedes that one and reverts
it.  There are two differences:

	The old patch added the flag at the USB level; this patch
	adds it at the PCI level.

	The old patch applied to all chipsets with the same vendor,
	subsystem vendor, and product IDs; this patch makes an
	exception for a known-good system (based on DMI information).

Signed-off-by: Alan Stern 
Tested-by: Dâniel Fraga 
Tested-by: Andrey Rahmatullin 
Tested-by: Steven Rostedt 
Cc: stable 
Reviewed-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman