[PATCH 1/9] ARM: Kirkwood: Add interrupt controller support for DT boards

[Arnd Bergmann]

On Thursday 14 June 2012, Andrew Lunn wrote:
> > I think if you compute the number of interrupts in the domain from the number of
> > registers that are described in the device tree, call orion_irq_init()
> > based on those registers, and use irq domains for the gpio stuff as Rob suggested,
> > this init_irq function can become completely generic to all orion platforms.
> 
> I'm reworking the GPIO stuff at the moment, moving it to use IRQ
> domains for its interrupts. That code will be generic to all Orion
> platforms. I'm modeling the code on the AT91 GPIO handler, since that
> has a similar structure, one hardware interrupt for a number of GPIO
> lines, which is in software demultiplexed and triggers secondary level
> interrupts. The major difference is that AT91 has one hardware
> interrupt for a GPIO chip with 32 lines, where as Orion has 4 hardware
> interrupt lines, so maybe four interrupt domains, for one GPIO chip
> with 32 lines.

My guess is that you're still better off with a single interrupt domain
for 32 lines, or even for all the gpio lines, but I'm sure you can
find a solution that works best for you.

> Non-GPIO interrupts are more of a problem. Underneath it uses the
> generic-chip interrupt code. The patchset to add _domain versions of
> these calls is stalled. So i think for the moment, we need to stay
> with the domain bolted on top, until generic-chip gets domain
> support. I would also expect that generic-chip also gets a common DT
> binding which any SoC can use.

I suggested that before, and the comments I got back then were that
we should treat the generic irq chip more like a library and keep
the device tree binding at a higher level. If I understood things right,
that means we would just have one plat-orion (or mach-mvebu later)
irq chip abstraction that handles the DT binding and the irq domains
itself but uses the generic irq chip code to implement the actual
irq handling.

> My aim at the moment is to get something which works well enough that
> we can add DT support to other drivers. Without interrupts, we are not
> going to get very far. We can later rip it out what i create now and
> replace it once generic-chip becomes domain and DT aware, and there
> should be no effect on other drivers.

Right. I just want to ensure that we don't need to change the bindings
in incompatible ways.

	Arnd