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