This definition produces processor specific code in generic function
pxa_gpio_mode(), thus creating inconsistencies for support of pxa25x
and pxa27x in a single zImage.

As David Brownell suggests, make it a run-time variable and initialize
at run-time according to the number of GPIOs on the processor. For now
the initialization happens in pxa_init_irq_gpio(),  since there is
already a parameter for that, besides, this is and MUST be earlier
than any subsequent calls to pxa_gpio_mode().
Signed-off-by: Neric miao <eric.y.miao@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As pointed out by Jrgen, we are overflowing the number of GPIOs
in pxa_init_irq_gpio(). I'm seeing the same problem on my HTC
Universal PXA270 based PDA.
According to Eric, the function argument is the number of GPIOs,
so we should keep the semantics and reduce the number of
iteration by 1.
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
Acked-by: NJrgen Schindele <linux@schindele.name>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

/* should be ok this time, I aligned this patch to your arm:pxa2.mbox */

1. move pxa25x specific IRQ initialization code to pxa25x_init_irq()
and pxa27x code to pxa27x_init_irq(), remove pxa_init_irq()

2. replace all pxa_init_irq() with their PXA25x or PXA27x specific
functions
Signed-off-by: Neric miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

1. use GPIO_IRQ_mask[] to select those bits of interest, actually
   only those "unmasked" GPIO IRQs with their corresponding bits
   in GPIO_IRQ_mask[] set to "1" should be checked

2. remove #ifdef PXA_LAST_GPIO > 96 .. #endif, GPIO_IRQ_mask[]
   is used to mask out the irrelevant bits, so that even though
   the GEDR3 on PXA25x is reserved, it will be masked, and the
   following code will never run. Another point is that GPIO85-
   GPIO95 bits within GEDR2 will also be masked out on PXA25x
Signed-off-by: Neric miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

move the GPIO IRQ initialization code to pxa_init_irq_gpio()
Signed-off-by: Neric miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

1. move low IRQ initialization code to pxa_init_irq_low()
Signed-off-by: Neric miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

1. define PXA_GPIO_IRQ_BASE to be right after the internal IRQs,
   and define PXA_GPIO_IRQ_NUM to be 128 for all PXA2xx variants

2. make the code specific to the high IRQ numbers (32..64) to be
   PXA27x specific

3. add a function pxa_init_irq_high() to initialize the internal
   high IRQ chip, the invoke of this function could be moved to
   PXA27x specific initialization code
Signed-off-by: Neric miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

1. PXA_IRQ_SKIP is defined to be 7 on PXA25x so that the first IRQ
   starts from zero. This makes IRQ numbering inconsistent between
   PXA25x and PXA27x. Remove this macro so that the same IRQ_XXXXX
   definition has the same value on both PXA25x and PXA27x.

2. make IRQ_SSP3..IRQ_PWRI2C valid only if PXA27x is defined, this
   avoids unintentional use of these macros on PXA25x
Signed-off-by: Neric miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

pxa_set_gpio_wake handles GPIOs > 1, so IRQ_TO_GPIO has to be used
instead of just substracting IRQ_GPIO0 from the irq number.

Lots of places in arch/arm were needlessly including linux/ptrace.h,
resumably because we used to pass a struct pt_regs to interrupt
handlers.  Now that we don't, all these ptrace.h includes are
redundant.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

set_irq_chipdata -> set_irq_chip_data
get_irq_chipdata -> get_irq_chip_data
do_level_IRQ -> handle_level_irq
do_edge_IRQ -> handle_edge_irq
do_simple_IRQ -> handle_simple_irq
irqdesc -> irq_desc
irqchip -> irq_chip
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Untested, but this should fix up the bulk of the totally mechanical
issues, and should make the actual detail fixing easier.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Patch from David Brownell

ARM genirq cleanups/updates:

    - Start switching platforms to newer APIs
        * use "irq_chip" name, not "irqchip"
        * providing irq_chip.name

    - Show irq_chip.name in /proc/interrupts, like on x86.

This update a bit more than half of the ARM code.  The irq_chip.name
values were chosen to match docs (if I have them) or be otherwise
obvious ("FPGA", "CPLD", or matching the code).
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Guennadi Liakhovetski

Currently probe_irq_on() on PXA will silently reconfigure all output GPIOs, that are not configured as alternate functions, for input. Avoid that. Upon CPU reset all GPIOs are configured as inputs, so, if a GPIO is configured as output, it has been done so intentionally.
Signed-off-by: NG. Liakhovetski <gl@dsa-ac.de>
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This is part of Thomas Gleixner's generic IRQ patch, which converts
ARM to use the generic IRQ subsystem.  Here, we wrap calls to
desc->handler() in an inline function, desc_handle_irq().  This
reduces the size of Thomas' patch since the changes become more
localised.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This is part of Thomas Gleixner's generic IRQ patch, which converts
ARM to use the generic IRQ subsystem.  Here, we rename two of the
irq_chip methods - wake becomes set_wake, and type becomes set_type.
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!