^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ==========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Interrupts
^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) 2.5.2-rmk5:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) This is the first kernel that contains a major shake up of some of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) major architecture-specific subsystems.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) Firstly, it contains some pretty major changes to the way we handle the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) MMU TLB. Each MMU TLB variant is now handled completely separately -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) we have TLB v3, TLB v4 (without write buffer), TLB v4 (with write buffer),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) and finally TLB v4 (with write buffer, with I TLB invalidate entry).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) There is more assembly code inside each of these functions, mainly to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) allow more flexible TLB handling for the future.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) Secondly, the IRQ subsystem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) The 2.5 kernels will be having major changes to the way IRQs are handled.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) Unfortunately, this means that machine types that touch the irq_desc[]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) array (basically all machine types) will break, and this means every
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) machine type that we currently have.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) Lets take an example. On the Assabet with Neponset, we have::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) GPIO25 IRR:2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) SA1100 ------------> Neponset -----------> SA1111
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) IIR:1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) -----------> USAR
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) IIR:0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) -----------> SMC9196
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) The way stuff currently works, all SA1111 interrupts are mutually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) exclusive of each other - if you're processing one interrupt from the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) SA1111 and another comes in, you have to wait for that interrupt to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) finish processing before you can service the new interrupt. Eg, an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) IDE PIO-based interrupt on the SA1111 excludes all other SA1111 and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) SMC9196 interrupts until it has finished transferring its multi-sector
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) data, which can be a long time. Note also that since we loop in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) SA1111 IRQ handler, SA1111 IRQs can hold off SMC9196 IRQs indefinitely.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) The new approach brings several new ideas...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) We introduce the concept of a "parent" and a "child". For example,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) to the Neponset handler, the "parent" is GPIO25, and the "children"d
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) are SA1111, SMC9196 and USAR.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) We also bring the idea of an IRQ "chip" (mainly to reduce the size of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) the irqdesc array). This doesn't have to be a real "IC"; indeed the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) SA11x0 IRQs are handled by two separate "chip" structures, one for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) GPIO0-10, and another for all the rest. It is just a container for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) the various operations (maybe this'll change to a better name).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) This structure has the following operations::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) struct irqchip {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) * Acknowledge the IRQ.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) * If this is a level-based IRQ, then it is expected to mask the IRQ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) * as well.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) void (*ack)(unsigned int irq);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) * Mask the IRQ in hardware.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) void (*mask)(unsigned int irq);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) * Unmask the IRQ in hardware.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) void (*unmask)(unsigned int irq);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) * Re-run the IRQ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) void (*rerun)(unsigned int irq);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) /*
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) * Set the type of the IRQ.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) int (*type)(unsigned int irq, unsigned int, type);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) ack
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) - required. May be the same function as mask for IRQs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) handled by do_level_IRQ.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) mask
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) - required.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) unmask
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) - required.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) rerun
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) - optional. Not required if you're using do_level_IRQ for all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) IRQs that use this 'irqchip'. Generally expected to re-trigger
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) the hardware IRQ if possible. If not, may call the handler
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) directly.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) - optional. If you don't support changing the type of an IRQ,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) it should be null so people can detect if they are unable to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) set the IRQ type.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) For each IRQ, we keep the following information:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) - "disable" depth (number of disable_irq()s without enable_irq()s)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) - flags indicating what we can do with this IRQ (valid, probe,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) noautounmask) as before
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) - status of the IRQ (probing, enable, etc)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) - chip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) - per-IRQ handler
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) - irqaction structure list
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) The handler can be one of the 3 standard handlers - "level", "edge" and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) "simple", or your own specific handler if you need to do something special.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) The "level" handler is what we currently have - its pretty simple.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) "edge" knows about the brokenness of such IRQ implementations - that you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) need to leave the hardware IRQ enabled while processing it, and queueing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) further IRQ events should the IRQ happen again while processing. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) "simple" handler is very basic, and does not perform any hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) manipulation, nor state tracking. This is useful for things like the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) SMC9196 and USAR above.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) So, what's changed?
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) ===================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) 1. Machine implementations must not write to the irqdesc array.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) 2. New functions to manipulate the irqdesc array. The first 4 are expected
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) to be useful only to machine specific code. The last is recommended to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) only be used by machine specific code, but may be used in drivers if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) absolutely necessary.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) set_irq_chip(irq,chip)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) Set the mask/unmask methods for handling this IRQ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) set_irq_handler(irq,handler)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) Set the handler for this IRQ (level, edge, simple)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) set_irq_chained_handler(irq,handler)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) Set a "chained" handler for this IRQ - automatically
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) enables this IRQ (eg, Neponset and SA1111 handlers).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) set_irq_flags(irq,flags)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) Set the valid/probe/noautoenable flags.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) set_irq_type(irq,type)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) Set active the IRQ edge(s)/level. This replaces the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) function. Type should be one of IRQ_TYPE_xxx defined in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) <linux/irq.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) 3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) 4. Direct access to SA1111 INTPOL is deprecated. Use set_irq_type instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) 5. A handler is expected to perform any necessary acknowledgement of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) parent IRQ via the correct chip specific function. For instance, if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) the SA1111 is directly connected to a SA1110 GPIO, then you should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) acknowledge the SA1110 IRQ each time you re-read the SA1111 IRQ status.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) 6. For any child which doesn't have its own IRQ enable/disable controls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) (eg, SMC9196), the handler must mask or acknowledge the parent IRQ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) while the child handler is called, and the child handler should be the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) "simple" handler (not "edge" nor "level"). After the handler completes,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) the parent IRQ should be unmasked, and the status of all children must
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) be re-checked for pending events. (see the Neponset IRQ handler for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) details).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) 7. fixup_irq() is gone, as is `arch/arm/mach-*/include/mach/irq.h`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) Please note that this will not solve all problems - some of them are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) hardware based. Mixing level-based and edge-based IRQs on the same
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) parent signal (eg neponset) is one such area where a software based
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) solution can't provide the full answer to low IRQ latency.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags