PageRenderTime 7ms CodeModel.GetById 1ms app.highlight 3ms RepoModel.GetById 1ms app.codeStats 0ms

/Documentation/arm/Interrupts

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