xref: /linux/Documentation/usb/dwc3.rst (revision ecefae6d)
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