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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
spi-devel-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
