Documentation/arm/interrupts.rst

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