arch/arm/interrupts.rst

5 2.5.2-rmk5:
7   major architecture-specific subsystems.
10 MMU TLB.  Each MMU TLB variant is now handled completely separately -
26         SA1100 ------------> Neponset -----------> SA1111
28                                       -----------> USAR
30                                       -----------> SMC9196
33 exclusive of each other - if you're processing one interrupt from the
36 IDE PIO-based interrupt on the SA1111 excludes all other SA1111 and
37 SMC9196 interrupts until it has finished transferring its multi-sector
51 GPIO0-10, and another for all the rest.  It is just a container for
58            * If this is a level-based IRQ, then it is expected to mask the IRQ
71            * Re-run the IRQ
81        - required.  May be the same function as mask for IRQs
84        - required.
86        - required.
88        - optional.  Not required if you're using do_level_IRQ for all
89          IRQs that use this 'irqchip'.  Generally expected to re-trigger
93        - optional.  If you don't support changing the type of an IRQ,
99         - "disable" depth (number of disable_irq()s without enable_irq()s)
100         - flags indicating what we can do with this IRQ (valid, probe,
102         - status of the IRQ (probing, enable, etc)
103         - chip
104         - per-IRQ handler
105         - irqaction structure list
107 The handler can be one of the 3 standard handlers - "level", "edge" and
110 The "level" handler is what we currently have - its pretty simple.
111 "edge" knows about the brokenness of such IRQ implementations - that you
135                 Set a "chained" handler for this IRQ - automatically
154    acknowledge the SA1110 IRQ each time you re-read the SA1111 IRQ status.
161    be re-checked for pending events.  (see the Neponset IRQ handler for
164 7. fixup_irq() is gone, as is `arch/arm/mach-*/include/mach/irq.h`
166 Please note that this will not solve all problems - some of them are
167 hardware based.  Mixing level-based and edge-based IRQs on the same