Felipe Balbi | 72246da | 2011-08-19 18:10:58 +0300 | [diff] [blame^] | 1 | |
| 2 | TODO |
| 3 | ~~~~~~ |
| 4 | Please pick something while reading :) |
| 5 | |
| 6 | - Implement streaming support for BULK endpoints |
| 7 | Tatyana's patch "usb: Add streams support to the gadget framework" |
| 8 | introduces streaming support for the gadget driver. |
| 9 | Every usb_request has new field called stream_id which holds its id. |
| 10 | Every usb_ep has a field num_supported_strms which describes the max |
| 11 | number of streams supported (for this ep). |
| 12 | UAS is AFAIK the only gadget with streaming support. |
| 13 | |
| 14 | - Convert interrupt handler to per-ep-thread-irq |
| 15 | |
| 16 | As it turns out some DWC3-commands ~1ms to complete. Currently we spin |
| 17 | until the command completes which is bad. |
| 18 | |
| 19 | Implementation idea: |
| 20 | - dwc core implements a demultiplexing irq chip for interrupts per |
| 21 | endpoint. The interrupt numbers are allocated during probe and belong |
| 22 | to the device. If MSI provides per-endpoint interrupt this dummy |
| 23 | interrupt chip can be replaced with "real" interrupts. |
| 24 | - interrupts are requested / allocated on usb_ep_enable() and removed on |
| 25 | usb_ep_disable(). Worst case are 32 interrupts, the lower limit is two |
| 26 | for ep0/1. |
| 27 | - dwc3_send_gadget_ep_cmd() will sleep in wait_for_completion_timeout() |
| 28 | until the command completes. |
| 29 | - the interrupt handler is split into the following pieces: |
| 30 | - primary handler of the device |
| 31 | goes through every event and calls generic_handle_irq() for event |
| 32 | it. On return from generic_handle_irq() in acknowledges the event |
| 33 | counter so interrupt goes away (eventually). |
| 34 | |
| 35 | - threaded handler of the device |
| 36 | none |
| 37 | |
| 38 | - primary handler of the EP-interrupt |
| 39 | reads the event and tries to process it. Everything that requries |
| 40 | sleeping is handed over to the Thread. The event is saved in an |
| 41 | per-endpoint data-structure. |
| 42 | We probably have to pay attention not to process events once we |
| 43 | handed something to thread so we don't process event X prio Y |
| 44 | where X > Y. |
| 45 | |
| 46 | - threaded handler of the EP-interrupt |
| 47 | handles the remaining EP work which might sleep such as waiting |
| 48 | for command completion. |
| 49 | |
| 50 | Latency: |
| 51 | There should be no increase in latency since the interrupt-thread has a |
| 52 | high priority and will be run before an average task in user land |
| 53 | (except the user changed priorities). |