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