Orange Pi5 kernel

Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards

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