mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-23 12:43:55 +08:00
94dfd7edfd
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 <oliver@neukum.org> 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> |
||
---|---|---|
.. | ||
atm | ||
c67x00 | ||
chipidea | ||
class | ||
core | ||
dwc3 | ||
early | ||
gadget | ||
host | ||
image | ||
misc | ||
mon | ||
musb | ||
phy | ||
renesas_usbhs | ||
serial | ||
storage | ||
wusbcore | ||
Kconfig | ||
Makefile | ||
README | ||
usb-common.c | ||
usb-skeleton.c |
To understand all the Linux-USB framework, you'll use these resources: * This source code. This is necessarily an evolving work, and includes kerneldoc that should help you get a current overview. ("make pdfdocs", and then look at "usb.pdf" for host side and "gadget.pdf" for peripheral side.) Also, Documentation/usb has more information. * The USB 2.0 specification (from www.usb.org), with supplements such as those for USB OTG and the various device classes. The USB specification has a good overview chapter, and USB peripherals conform to the widely known "Chapter 9". * Chip specifications for USB controllers. Examples include host controllers (on PCs, servers, and more); peripheral controllers (in devices with Linux firmware, like printers or cell phones); and hard-wired peripherals like Ethernet adapters. * Specifications for other protocols implemented by USB peripheral functions. Some are vendor-specific; others are vendor-neutral but just standardized outside of the www.usb.org team. Here is a list of what each subdirectory here is, and what is contained in them. core/ - This is for the core USB host code, including the usbfs files and the hub class driver ("khubd"). host/ - This is for USB host controller drivers. This includes UHCI, OHCI, EHCI, and others that might be used with more specialized "embedded" systems. gadget/ - This is for USB peripheral controller drivers and the various gadget drivers which talk to them. Individual USB driver directories. A new driver should be added to the first subdirectory in the list below that it fits into. image/ - This is for still image drivers, like scanners or digital cameras. ../input/ - This is for any driver that uses the input subsystem, like keyboard, mice, touchscreens, tablets, etc. ../media/ - This is for multimedia drivers, like video cameras, radios, and any other drivers that talk to the v4l subsystem. ../net/ - This is for network drivers. serial/ - This is for USB to serial drivers. storage/ - This is for USB mass-storage drivers. class/ - This is for all USB device drivers that do not fit into any of the above categories, and work for a range of USB Class specified devices. misc/ - This is for all USB device drivers that do not fit into any of the above categories.