d1bef4ed5f
This patch-queue improves the generic IRQ layer to be truly generic, by adding various abstractions and features to it, without impacting existing functionality. While the queue can be best described as "fix and improve everything in the generic IRQ layer that we could think of", and thus it consists of many smaller features and lots of cleanups, the one feature that stands out most is the new 'irq chip' abstraction. The irq-chip abstraction is about describing and coding and IRQ controller driver by mapping its raw hardware capabilities [and quirks, if needed] in a straightforward way, without having to think about "IRQ flow" (level/edge/etc.) type of details. This stands in contrast with the current 'irq-type' model of genirq architectures, which 'mixes' raw hardware capabilities with 'flow' details. The patchset supports both types of irq controller designs at once, and converts i386 and x86_64 to the new irq-chip design. As a bonus side-effect of the irq-chip approach, chained interrupt controllers (master/slave PIC constructs, etc.) are now supported by design as well. The end result of this patchset intends to be simpler architecture-level code and more consolidation between architectures. We reused many bits of code and many concepts from Russell King's ARM IRQ layer, the merging of which was one of the motivations for this patchset. This patch: rename desc->handler to desc->chip. Originally i did not want to do this, because it's a big patch. But having both "desc->handler", "desc->handle_irq" and "action->handler" caused a large degree of confusion and made the code appear alot less clean than it truly is. I have also attempted a dual approach as well by introducing a desc->chip alias - but that just wasnt robust enough and broke frequently. So lets get over with this quickly. The conversion was done automatically via scripts and converts all the code in the kernel. This renaming patch is the first one amongst the patches, so that the remaining patches can stay flexible and can be merged and split up without having some big monolithic patch act as a merge barrier. [akpm@osdl.org: build fix] [akpm@osdl.org: another build fix] Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> |
||
|---|---|---|
| .. | ||
| configs | ||
| kernel | ||
| lib | ||
| Kconfig | ||
| Kconfig.debug | ||
| Makefile | ||
| README | ||
README
This port to the NEC V850E processor supports the following platforms:
"sim"
The gdb v850e simulator (CONFIG_V850E_SIM).
"rte-ma1-cb"
The Midas labs RTE-V850E/MA1-CB and RTE-V850E/NB85E-CB evaluation
boards (CONFIG_RTE_CB_MA1 and CONFIG_RTE_CB_NB85E). This support
has only been tested when running with the Multi-debugger monitor
ROM (for the Green Hills Multi debugger). The optional NEC
Solution Gear RTE-MOTHER-A motherboard is also supported, which
allows PCI boards to be used (CONFIG_RTE_MB_A_PCI).
"rte-me2-cb"
The Midas labs RTE-V850E/ME2-CB evaluation board (CONFIG_RTE_CB_ME2).
This has only been tested using a kernel downloaded via an ICE
connection using the Multi debugger. Support for the RTE-MOTHER-A is
present, but hasn't been tested (unlike the other Midas labs cpu
boards, the RTE-V850E/ME2-CB includes an ethernet adaptor).
"as85ep1"
The NEC AS85EP1 V850E evaluation chip/board (CONFIG_V850E_AS85EP1).
"anna"
The NEC `Anna' (board/chip) implementation of the V850E2 processor
(CONFIG_V850E2_ANNA).
"sim85e2c", "sim85e2s"
The sim85e2c and sim85e2s simulators, which are verilog simulations
of the V850E2 NA85E2C/NA85E2S cpu cores (CONFIG_V850E2_SIM85E2C and
CONFIG_V850E2_SIM85E2S).
"fpga85e2c"
A FPGA implementation of the V850E2 NA85E2C cpu core
(CONFIG_V850E2_FPGA85E2C).
To get a default kernel configuration for a particular platform, you can
use a <platform>_defconfig make target (e.g., "make rte-me2-cb_defconfig");
to see which default configurations are possible, look in the directory
"arch/v850/configs".
Porting to anything with a V850E/MA1 or MA2 processor should be simple.
See the file <asm-v850/machdep.h> and the files it includes for an example of
how to add platform/chip-specific support.