On Mon, Jul 11, 2011 at 3:52 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

...

> The __exception annotation on a function causes this to happen:
>
> [<c002406c>] (asm_do_IRQ+0x6c/0x8c) from [<c0024b84>]
> (__irq_svc+0x44/0xcc)
> Exception stack(0xc3897c78 to 0xc3897cc0)
> 7c60:                                                       4022d320 4022e000
> 7c80: 08000075 00001000 c32273c0 c03ce1c0 c2b49b78 4022d000 c2b420b4 00000001
> 7ca0: 00000000 c3897cfc 00000000 c3897cc0 c00afc54 c002edd8 00000013 ffffffff
>
> Where that stack dump represents the pt_regs for the exception which
> happened.  Any function found in while unwinding will cause this to
> be printed.
>
> If you insert a C function between the IRQ assembly and asm_do_IRQ,
> the
> dump you get from asm_do_IRQ will be the stack for your function,
> not
> the pt_regs.  That makes the feature useless.
>

When __irq_svc - or any of the other exception handling assembly code -
calls the C code, the stack pointer will be pointing at the pt_regs
structure.

All the entry points into C code from the exception handling code are
marked with __exception or __exception_irq_enter to indicate that they
are one of the functions which has pt_regs above them.

Normally, when you've entered asm_do_IRQ() you will have this stack
layout (higher address towards top):

       pt_regs
       asm_do_IRQ frame

If you insert a C function between the exception assembly code and
asm_do_IRQ, you end up with this stack layout instead:

       pt_regs
       your function frame
       asm_do_IRQ frame

This means when we unwind, we'll get to asm_do_IRQ, and rather than
dumping out the pt_regs, we'll dump out your functions stack frame
instead, because that's what is above the asm_do_IRQ stack frame
rather than the expected pt_regs structure.

The fix is to introduce handle_IRQ() for no exception stack dump, so
it can be called with MULTI_IRQ_HANDLER is selected and a C function
is between the assembly code and the actual IRQ handling code.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

So to allow NR_IRQS to be dynamic and platforms to specify the number
of IRQs really needed.
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

irq.h is using struct pt_regs *. Due to this compilation
warning is comming. Removing this warning by adding declaration
of struct pt_regs.
Signed-off-by: NViresh Kumar <viresh.kumar@st.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

RiscPC is the only platform using the default setting for NR_IRQS,
so the default NR_IRQS doesn't really make sense; remove it and
make RiscPC provide such a definition.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This just leaves include/asm-arm/plat-* to deal with.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Move platform independent header files to arch/arm/include/asm, leaving
those in asm/arch* and asm/plat* alone.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

IRQT_* and __IRQT_* were obsoleted long ago by patch [3692/1].
Remove them completely. Sed script for the reference:

s/__IRQT_RISEDGE/IRQ_TYPE_EDGE_RISING/g
s/__IRQT_FALEDGE/IRQ_TYPE_EDGE_FALLING/g
s/__IRQT_LOWLVL/IRQ_TYPE_LEVEL_LOW/g
s/__IRQT_HIGHLVL/IRQ_TYPE_LEVEL_HIGH/g
s/IRQT_RISING/IRQ_TYPE_EDGE_RISING/g
s/IRQT_FALLING/IRQ_TYPE_EDGE_FALLING/g
s/IRQT_BOTHEDGE/IRQ_TYPE_EDGE_BOTH/g
s/IRQT_LOW/IRQ_TYPE_LEVEL_LOW/g
s/IRQT_HIGH/IRQ_TYPE_LEVEL_HIGH/g
s/IRQT_PROBE/IRQ_TYPE_PROBE/g
s/IRQT_NOEDGE/IRQ_TYPE_NONE/g
Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As reminded in http://lkml.org/lkml/2006/12/23/26, one should use
asm/hardware.h and asm/irq.h but absent-minded devs like me tends to use
asm/arch/hardware.h and/or asm/arch/irqs.h.
This patch aims at preventing such things.

In order to make it work, I had to modify asm-arm/irq.h too so that it can
be included from assembly files.
Also, as a side effect, I had to modify some headers who were using the
asm/arch/hardware.h or asm/arch/irqs.h.
Signed-off-by: NArnaud Patard <arnaud.patard@rtp-net.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Thomas Gleixner

From: Thomas Gleixner <tglx@linutronix.de>

Switch the ARM irq core handling to the generic implementation. The
ARM specific header files now contain mostly migration stubs and
helper macros. Note that each machine type must be converted after
this step seperately. This was seperated out from the patch for easier
review.

The main changes for the machine type code is the conversion of the
type handlers to a 'type flow' and 'chip' model. This affects only the
multiplex interrupt handlers. A conversion macro needs to be added to
those implementations, which defines the data structure which is
registered by the set_irq_chained_handler() macro.

Some minor fixups of include files and the conversion of data
structure access is necessary all over the place.

The mostly macro based conversion was provided to allow an easy
migration of the existing implementations.

The code compiles on all defconfigs available in arch/arm/configs
except those which were broken also before applying the conversion
patches.

The code has been boot and runtime tested on most ARM platforms. The
results of an extensive testing and bugfixing series can be found
at: http://www.linutronix.de/index.php?page=testingSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Correct the return type of handle_IRQ_event() (inconsistency noticed during
Xen development), and remove redundant declarations.  The return type
adjustment required breaking out the definition of irqreturn_t into a
separate header, in order to satisfy current include order dependencies.
Signed-off-by: NJan Beulich <jbeulich@novell.com>

Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Ian Molton <spyro@f2s.com>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Hirokazu Takata <takata.hirokazu@renesas.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: William Lee Irwin III <wli@holomorphy.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Miles Bader <uclinux-v850@lsi.nec.co.jp>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The IRQ resource flags are IORESOURCE_IRQ not IRQRESOURCE_IRQ.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Some ARM platforms have the ability to program the interrupt controller to
detect various interrupt edges and/or levels.  For some platforms, this is
critical to setup correctly, particularly those which the setting is dependent
on the device.

Currently, ARM drivers do (eg) the following:

	err = request_irq(irq, ...);

	set_irq_type(irq, IRQT_RISING);

However, if the interrupt has previously been programmed to be level sensitive
(for whatever reason) then this will cause an interrupt storm.

Hence, if we combine set_irq_type() with request_irq(), we can then safely set
the type prior to unmasking the interrupt.  The unfortunate problem is that in
order to support this, these flags need to be visible outside of the ARM
architecture - drivers such as smc91x need these flags and they're
cross-architecture.

Finally, the SA_TRIGGER_* flag passed to request_irq() should reflect the
property that the device would like.  The IRQ controller code should do its
best to select the most appropriate supported mode.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch adds the infrastructure to support hotplug CPU on ARM
platforms.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!