Lines Matching refs:the

4 This is the first kernel that contains a major shake up of some of the
7 Firstly, it contains some pretty major changes to the way we handle the
12 allow more flexible TLB handling for the future.
14 Secondly, the IRQ subsystem.
16 The 2.5 kernels will be having major changes to the way IRQs are handled.
17 Unfortunately, this means that machine types that touch the irq_desc[]
21 Lets take an example.  On the Assabet with Neponset, we have:
31 exclusive of each other - if you're processing one interrupt from the
33 finish processing before you can service the new interrupt.  Eg, an
34 IDE PIO-based interrupt on the SA1111 excludes all other SA1111 and
36 data, which can be a long time.  Note also that since we loop in the
42 We introduce the concept of a "parent" and a "child".  For example,
43 to the Neponset handler, the "parent" is GPIO25, and the "children"d
46 We also bring the idea of an IRQ "chip" (mainly to reduce the size of
47 the irqdesc array).  This doesn't have to be a real "IC"; indeed the
49 GPIO0-10, and another for all the rest.  It is just a container for
50 the various operations (maybe this'll change to a better name).
51 This structure has the following operations:
55          * Acknowledge the IRQ.
56          * If this is a level-based IRQ, then it is expected to mask the IRQ
61          * Mask the IRQ in hardware.
65          * Unmask the IRQ in hardware.
69          * Re-run the IRQ
73          * Set the type of the IRQ.
78 ack    - required.  May be the same function as mask for IRQs
84          the hardware IRQ if possible.  If not, may call the handler
86 type   - optional.  If you don't support changing the type of an IRQ,
88          set the IRQ type.
90 For each IRQ, we keep the following information:
95         - status of the IRQ (probing, enable, etc)
100 The handler can be one of the 3 standard handlers - "level", "edge" and
104 "edge" knows about the brokenness of such IRQ implementations - that you
105 need to leave the hardware IRQ enabled while processing it, and queueing
106 further IRQ events should the IRQ happen again while processing.  The
108 manipulation, nor state tracking.  This is useful for things like the
113 1. Machine implementations must not write to the irqdesc array.
115 2. New functions to manipulate the irqdesc array.  The first 4 are expected
122                 Set the mask/unmask methods for handling this IRQ
126                 Set the handler for this IRQ (level, edge, simple)
135                 Set the valid/probe/noautoenable flags.
139                 Set active the IRQ edge(s)/level.  This replaces the
140                 SA1111 INTPOL manipulation, and the set_GPIO_IRQ_edge()
148 5. A handler is expected to perform any necessary acknowledgement of the
149    parent IRQ via the correct chip specific function.  For instance, if
150    the SA1111 is directly connected to a SA1110 GPIO, then you should
151    acknowledge the SA1110 IRQ each time you re-read the SA1111 IRQ status.
154    (eg, SMC9196), the handler must mask or acknowledge the parent IRQ
155    while the child handler is called, and the child handler should be the
156    "simple" handler (not "edge" nor "level").  After the handler completes,
157    the parent IRQ should be unmasked, and the status of all children must
158    be re-checked for pending events.  (see the Neponset IRQ handler for
164 hardware based.  Mixing level-based and edge-based IRQs on the same
166 solution can't provide the full answer to low IRQ latency.