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