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=testing
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Catalin Marinas
If the low interrupt latency mode is enabled for the CPU (from ARMv6
onwards), the ldm/stm instructions are no longer atomic. An ldm instruction
restoring the sp and pc registers can be interrupted immediately after sp
was updated but before the pc. If this happens, the CPU restores the base
register to the value before the ldm instruction but if the base register
is not sp, the interrupt routine will corrupt the stack and the restarted
ldm instruction will load garbage.
Note that future ARM cores might always run in the low interrupt latency
mode.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell 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!
