]>
Commit | Line | Data |
---|---|---|
dc7a12bd MCC |
1 | ========== |
2 | Interrupts | |
3 | ========== | |
1da177e4 | 4 | |
dc7a12bd MCC |
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. | |
1da177e4 LT |
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 | ||
dc7a12bd | 23 | Lets take an example. On the Assabet with Neponset, we have:: |
1da177e4 LT |
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). | |
dc7a12bd MCC |
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 | |
1da177e4 | 82 | handled by do_level_IRQ. |
dc7a12bd MCC |
83 | mask |
84 | - required. | |
85 | unmask | |
86 | - required. | |
87 | rerun | |
88 | - optional. Not required if you're using do_level_IRQ for all | |
1da177e4 LT |
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. | |
dc7a12bd MCC |
92 | type |
93 | - optional. If you don't support changing the type of an IRQ, | |
1da177e4 LT |
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? | |
dc7a12bd | 119 | =================== |
1da177e4 LT |
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) | |
1da177e4 LT |
129 | Set the mask/unmask methods for handling this IRQ |
130 | ||
131 | set_irq_handler(irq,handler) | |
1da177e4 LT |
132 | Set the handler for this IRQ (level, edge, simple) |
133 | ||
134 | set_irq_chained_handler(irq,handler) | |
1da177e4 LT |
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) | |
1da177e4 LT |
139 | Set the valid/probe/noautoenable flags. |
140 | ||
141 | set_irq_type(irq,type) | |
1da177e4 LT |
142 | Set active the IRQ edge(s)/level. This replaces the |
143 | SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge() | |
6cab4860 DB |
144 | function. Type should be one of IRQ_TYPE_xxx defined in |
145 | <linux/irq.h> | |
1da177e4 LT |
146 | |
147 | 3. set_GPIO_IRQ_edge() is obsolete, and should be replaced by set_irq_type. | |
148 | ||
1591275c | 149 | 4. Direct access to SA1111 INTPOL is deprecated. Use set_irq_type instead. |
1da177e4 LT |
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 | ||
dc7a12bd | 164 | 7. fixup_irq() is gone, as is `arch/arm/mach-*/include/mach/irq.h` |
1da177e4 LT |
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. |