0001 ==========
0002 Interrupts
0003 ==========
0004
0005 2.5.2-rmk5:
0006 This is the first kernel that contains a major shake up of some of the
0007 major architecture-specific subsystems.
0008
0009 Firstly, it contains some pretty major changes to the way we handle the
0010 MMU TLB. Each MMU TLB variant is now handled completely separately -
0011 we have TLB v3, TLB v4 (without write buffer), TLB v4 (with write buffer),
0012 and finally TLB v4 (with write buffer, with I TLB invalidate entry).
0013 There is more assembly code inside each of these functions, mainly to
0014 allow more flexible TLB handling for the future.
0015
0016 Secondly, the IRQ subsystem.
0017
0018 The 2.5 kernels will be having major changes to the way IRQs are handled.
0019 Unfortunately, this means that machine types that touch the irq_desc[]
0020 array (basically all machine types) will break, and this means every
0021 machine type that we currently have.
0022
0023 Lets take an example. On the Assabet with Neponset, we have::
0024
0025 GPIO25 IRR:2
0026 SA1100 ------------> Neponset -----------> SA1111
0027 IIR:1
0028 -----------> USAR
0029 IIR:0
0030 -----------> SMC9196
0031
0032 The way stuff currently works, all SA1111 interrupts are mutually
0033 exclusive of each other - if you're processing one interrupt from the
0034 SA1111 and another comes in, you have to wait for that interrupt to
0035 finish processing before you can service the new interrupt. Eg, an
0036 IDE PIO-based interrupt on the SA1111 excludes all other SA1111 and
0037 SMC9196 interrupts until it has finished transferring its multi-sector
0038 data, which can be a long time. Note also that since we loop in the
0039 SA1111 IRQ handler, SA1111 IRQs can hold off SMC9196 IRQs indefinitely.
0040
0041
0042 The new approach brings several new ideas...
0043
0044 We introduce the concept of a "parent" and a "child". For example,
0045 to the Neponset handler, the "parent" is GPIO25, and the "children"d
0046 are SA1111, SMC9196 and USAR.
0047
0048 We also bring the idea of an IRQ "chip" (mainly to reduce the size of
0049 the irqdesc array). This doesn't have to be a real "IC"; indeed the
0050 SA11x0 IRQs are handled by two separate "chip" structures, one for
0051 GPIO0-10, and another for all the rest. It is just a container for
0052 the various operations (maybe this'll change to a better name).
0053 This structure has the following operations::
0054
0055 struct irqchip {
0056 /*
0057 * Acknowledge the IRQ.
0058 * If this is a level-based IRQ, then it is expected to mask the IRQ
0059 * as well.
0060 */
0061 void (*ack)(unsigned int irq);
0062 /*
0063 * Mask the IRQ in hardware.
0064 */
0065 void (*mask)(unsigned int irq);
0066 /*
0067 * Unmask the IRQ in hardware.
0068 */
0069 void (*unmask)(unsigned int irq);
0070 /*
0071 * Re-run the IRQ
0072 */
0073 void (*rerun)(unsigned int irq);
0074 /*
0075 * Set the type of the IRQ.
0076 */
0077 int (*type)(unsigned int irq, unsigned int, type);
0078 };
0079
0080 ack
0081 - required. May be the same function as mask for IRQs
0082 handled by do_level_IRQ.
0083 mask
0084 - required.
0085 unmask
0086 - required.
0087 rerun
0088 - optional. Not required if you're using do_level_IRQ for all
0089 IRQs that use this 'irqchip'. Generally expected to re-trigger
0090 the hardware IRQ if possible. If not, may call the handler
0091 directly.
0092 type
0093 - optional. If you don't support changing the type of an IRQ,
0094 it should be null so people can detect if they are unable to
0095 set the IRQ type.
0096
0097 For each IRQ, we keep the following information:
0098
0099 - "disable" depth (number of disable_irq()s without enable_irq()s)
0100 - flags indicating what we can do with this IRQ (valid, probe,
0101 noautounmask) as before
0102 - status of the IRQ (probing, enable, etc)
0103 - chip
0104 - per-IRQ handler
0105 - irqaction structure list
0106
0107 The handler can be one of the 3 standard handlers - "level", "edge" and
0108 "simple", or your own specific handler if you need to do something special.
0109
0110 The "level" handler is what we currently have - its pretty simple.
0111 "edge" knows about the brokenness of such IRQ implementations - that you
0112 need to leave the hardware IRQ enabled while processing it, and queueing
0113 further IRQ events should the IRQ happen again while processing. The
0114 "simple" handler is very basic, and does not perform any hardware
0115 manipulation, nor state tracking. This is useful for things like the
0116 SMC9196 and USAR above.
0117
0118 So, what's changed?
0119 ===================
0120
0121 1. Machine implementations must not write to the irqdesc array.
0122
0123 2. New functions to manipulate the irqdesc array. The first 4 are expected
0124 to be useful only to machine specific code. The last is recommended to
0125 only be used by machine specific code, but may be used in drivers if
0126 absolutely necessary.
0127
0128 set_irq_chip(irq,chip)
0129 Set the mask/unmask methods for handling this IRQ
0130
0131 set_irq_handler(irq,handler)
0132 Set the handler for this IRQ (level, edge, simple)
0133
0134 set_irq_chained_handler(irq,handler)
0135 Set a "chained" handler for this IRQ - automatically
0136 enables this IRQ (eg, Neponset and SA1111 handlers).
0137
0138 set_irq_flags(irq,flags)
0139 Set the valid/probe/noautoenable flags.
0140
0141 set_irq_type(irq,type)
0142 Set active the IRQ edge(s)/level. This replaces the
0143 SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge()
0144 function. Type should be one of IRQ_TYPE_xxx defined in
0145 <linux/irq.h>
0146
0147 3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type.
0148
0149 4. Direct access to SA1111 INTPOL is deprecated. Use set_irq_type instead.
0150
0151 5. A handler is expected to perform any necessary acknowledgement of the
0152 parent IRQ via the correct chip specific function. For instance, if
0153 the SA1111 is directly connected to a SA1110 GPIO, then you should
0154 acknowledge the SA1110 IRQ each time you re-read the SA1111 IRQ status.
0155
0156 6. For any child which doesn't have its own IRQ enable/disable controls
0157 (eg, SMC9196), the handler must mask or acknowledge the parent IRQ
0158 while the child handler is called, and the child handler should be the
0159 "simple" handler (not "edge" nor "level"). After the handler completes,
0160 the parent IRQ should be unmasked, and the status of all children must
0161 be re-checked for pending events. (see the Neponset IRQ handler for
0162 details).
0163
0164 7. fixup_irq() is gone, as is `arch/arm/mach-*/include/mach/irq.h`
0165
0166 Please note that this will not solve all problems - some of them are
0167 hardware based. Mixing level-based and edge-based IRQs on the same
0168 parent signal (eg neponset) is one such area where a software based
0169 solution can't provide the full answer to low IRQ latency.
