Commit Graph

4 Commits

Author SHA1 Message Date
Eric Miao b393c69652 [ARM] pxa: move PCMCIA definitions out of pxa-regs.h into pxa2xx_base.c
Move the processor specific initialization (largely resources initialization)
out of soc_common_drv_pcmcia_probe() into dedicated sa11xx_drv_pcmcia_probe()
and __pxa2xx_drv_pcmcia_probe().

By doing this, we are now able to move the PCMCIA related definitions out of
pxa-regs.h and back into pxa2xx_base.c.

As a result, remove that reference of _PCMCIA1IO in arch/arm/mach-pxa/viper.c.

Signed-off-by: Eric Miao <eric.miao@marvell.com>
2009-03-09 21:22:39 +08:00
Eric Miao 51c62982a3 [ARM] pxa: introduce pxa{25x,27x,300,320,930}.h for board usage
Considering the header mess ATM, it is not always possible to include
the correct header files within board code. Let's keep this simple:

  <mach/pxa25x.h>  - for pxa25x based platforms
  <mach/pxa27x.h>  - for pxa27x based platforms
  <mach/pxa300.h>  - for pxa300 based platforms
  <mach/pxa320.h>  - for pxa320 based platforms
  <mach/pxa930.h>  - for pxa930 based platforms

NOTE:

1. one header one board file, they are not compatible (i.e. they have
   conflicting definitions which won't compile if included together).

2. Unless strictly necessary, the following header files are considered
   to be SoC files use _only_, and is not recommended to be included in
   board code:

    <mach/hardware.h>
    <mach/pxa-regs.h>
    <mach/pxa2xx-regs.h>
    <mach/pxa3xx-regs.h>
    <mach/mfp.h>
    <mach/mfp-pxa2xx.h>
    <mach/mfp-pxa25x.h>
    <mach/mfp-pxa27x.h>
    <mach/mfp-pxa3xx.h>
    <mach/mfp-pxa300.h>
    <mach/mfp-pxa320.h>
    <mach/mfp-pxa930.h>

Signed-off-by: Eric Miao <eric.miao@marvell.com>
2009-03-09 21:22:36 +08:00
Marc Zyngier a9ff8f6462 [ARM] 5308/1: Fix Viper ISA IRQ handling
The ISA IRQ renumbering broke the Viper ISA code in interesting ways.
It originally assumed that ISA interrupt were numbered in the order that
is defined by the CPLD registers. Unfortunately, this is no longer the
case.

Furthermore, the viper_irq_handler() function being a chained IRQ
handler, it must ACK the interrupt by itself, or the handler will be
immediately reentered, with the expected damages.

This fix was made possible thanks to the help of David Raeman, who
provided debug information and tested each version of this patch.

Tested-by: David Raeman <david.raeman@gmail.com>

Signed-off-by: Marc Zyngier <maz@misterjones.org>
Acked-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-10-15 13:01:36 +01:00
Marc Zyngier 352699a3d7 Basic support for the Arcom/Eurotech Viper SBC.
Signed-off-by: Marc Zyngier <marc.zyngier@altran.com>
2008-09-09 17:41:46 +02:00