1========== 2Interrupts 3========== 4 52.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 9Firstly, it contains some pretty major changes to the way we handle the 10MMU TLB. Each MMU TLB variant is now handled completely separately - 11we have TLB v3, TLB v4 (without write buffer), TLB v4 (with write buffer), 12and finally TLB v4 (with write buffer, with I TLB invalidate entry). 13There is more assembly code inside each of these functions, mainly to 14allow more flexible TLB handling for the future. 15 16Secondly, the IRQ subsystem. 17 18The 2.5 kernels will be having major changes to the way IRQs are handled. 19Unfortunately, this means that machine types that touch the irq_desc[] 20array (basically all machine types) will break, and this means every 21machine type that we currently have. 22 23Lets 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 32The way stuff currently works, all SA1111 interrupts are mutually 33exclusive of each other - if you're processing one interrupt from the 34SA1111 and another comes in, you have to wait for that interrupt to 35finish processing before you can service the new interrupt. Eg, an 36IDE PIO-based interrupt on the SA1111 excludes all other SA1111 and 37SMC9196 interrupts until it has finished transferring its multi-sector 38data, which can be a long time. Note also that since we loop in the 39SA1111 IRQ handler, SA1111 IRQs can hold off SMC9196 IRQs indefinitely. 40 41 42The new approach brings several new ideas... 43 44We introduce the concept of a "parent" and a "child". For example, 45to the Neponset handler, the "parent" is GPIO25, and the "children"d 46are SA1111, SMC9196 and USAR. 47 48We also bring the idea of an IRQ "chip" (mainly to reduce the size of 49the irqdesc array). This doesn't have to be a real "IC"; indeed the 50SA11x0 IRQs are handled by two separate "chip" structures, one for 51GPIO0-10, and another for all the rest. It is just a container for 52the various operations (maybe this'll change to a better name). 53This 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 80ack 81 - required. May be the same function as mask for IRQs 82 handled by do_level_IRQ. 83mask 84 - required. 85unmask 86 - required. 87rerun 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. 92type 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 97For 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 107The 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 110The "level" handler is what we currently have - its pretty simple. 111"edge" knows about the brokenness of such IRQ implementations - that you 112need to leave the hardware IRQ enabled while processing it, and queueing 113further IRQ events should the IRQ happen again while processing. The 114"simple" handler is very basic, and does not perform any hardware 115manipulation, nor state tracking. This is useful for things like the 116SMC9196 and USAR above. 117 118So, what's changed? 119=================== 120 1211. Machine implementations must not write to the irqdesc array. 122 1232. 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 1473. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type. 148 1494. Direct access to SA1111 INTPOL is deprecated. Use set_irq_type instead. 150 1515. 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 1566. 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 1647. fixup_irq() is gone, as is `arch/arm/mach-*/include/mach/irq.h` 165 166Please note that this will not solve all problems - some of them are 167hardware based. Mixing level-based and edge-based IRQs on the same 168parent signal (eg neponset) is one such area where a software based 169solution can't provide the full answer to low IRQ latency. 170