summaryrefslogtreecommitdiff
path: root/Documentation/usb
diff options
context:
space:
mode:
authorFelipe Balbi <balbi@ti.com>2011-08-19 19:10:58 +0400
committerGreg Kroah-Hartman <gregkh@suse.de>2011-08-23 03:03:11 +0400
commit72246da40f3719af3bfd104a2365b32537c27d83 (patch)
treedb6a4b139c24340e0d5dccab8d9df0b23ab509ef /Documentation/usb
parent500fdf8becb9c8d51970c7ac6a4fa308a5481ebe (diff)
downloadlinux-72246da40f3719af3bfd104a2365b32537c27d83.tar.xz
usb: Introduce DesignWare USB3 DRD Driver
The DesignWare USB3 is a highly configurable IP Core which can be instantiated as Dual-Role Device (DRD), Peripheral Only and Host Only (XHCI) configurations. Several other parameters can be configured like amount of FIFO space, amount of TX and RX endpoints, amount of Host Interrupters, etc. The current driver has been validated with a virtual model of version 1.73a of that core and with an FPGA burned with version 1.83a of the DRD core. We have support for PCIe bus, which is used on FPGA prototyping, and for the OMAP5, more adaptation (or glue) layers can be easily added and the driver is half prepared to handle any possible configuration the HW engineer has chosen considering we have the information on one of the GHWPARAMS registers to do runtime checking of certain features. More runtime checks can, and should, be added in order to make this driver even more flexible with regards to number of endpoints, FIFO sizes, transfer types, etc. While this supports only the device side, for now, we will add support for Host side (xHCI - see the updated series Sebastian has sent [1]) and OTG after we have it all stabilized. [1] http://marc.info/?l=linux-usb&m=131341992020339&w=2 Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'Documentation/usb')
-rw-r--r--Documentation/usb/dwc3.txt53
1 files changed, 53 insertions, 0 deletions
diff --git a/Documentation/usb/dwc3.txt b/Documentation/usb/dwc3.txt
new file mode 100644
index 000000000000..2f658532b9db
--- /dev/null
+++ b/Documentation/usb/dwc3.txt
@@ -0,0 +1,53 @@
+
+ TODO
+~~~~~~
+Please pick something while reading :)
+
+- Implement streaming support for BULK endpoints
+ Tatyana's patch "usb: Add streams support to the gadget framework"
+ introduces streaming support for the gadget driver.
+ Every usb_request has new field called stream_id which holds its id.
+ Every usb_ep has a field num_supported_strms which describes the max
+ number of streams supported (for this ep).
+ UAS is AFAIK the only gadget with streaming support.
+
+- Convert interrupt handler to per-ep-thread-irq
+
+ As it turns out some DWC3-commands ~1ms to complete. Currently we spin
+ until the command completes which is bad.
+
+ Implementation idea:
+ - dwc core implements a demultiplexing irq chip for interrupts per
+ endpoint. The interrupt numbers are allocated during probe and belong
+ to the device. If MSI provides per-endpoint interrupt this dummy
+ interrupt chip can be replaced with "real" interrupts.
+ - interrupts are requested / allocated on usb_ep_enable() and removed on
+ usb_ep_disable(). Worst case are 32 interrupts, the lower limit is two
+ for ep0/1.
+ - dwc3_send_gadget_ep_cmd() will sleep in wait_for_completion_timeout()
+ until the command completes.
+ - the interrupt handler is split into the following pieces:
+ - primary handler of the device
+ goes through every event and calls generic_handle_irq() for event
+ it. On return from generic_handle_irq() in acknowledges the event
+ counter so interrupt goes away (eventually).
+
+ - threaded handler of the device
+ none
+
+ - primary handler of the EP-interrupt
+ reads the event and tries to process it. Everything that requries
+ sleeping is handed over to the Thread. The event is saved in an
+ per-endpoint data-structure.
+ We probably have to pay attention not to process events once we
+ handed something to thread so we don't process event X prio Y
+ where X > Y.
+
+ - threaded handler of the EP-interrupt
+ handles the remaining EP work which might sleep such as waiting
+ for command completion.
+
+ Latency:
+ There should be no increase in latency since the interrupt-thread has a
+ high priority and will be run before an average task in user land
+ (except the user changed priorities).