Re: Adding an interrupt locator to the GPIO, I2C and SPI buses

[Pierre Pronchery <khorben%defora.org@localhost>]

On 20/04/2013 00:12, Manuel Bouyer wrote:
> On Fri, Apr 19, 2013 at 11:59:17PM +0200, Pierre Pronchery wrote:
>> Look at sys/arch/arm/omap/omap2_gpio.c. The whole process is built
>> around "struct pic_ops" and "struct pic_softc", which is a bit difficult
>> to follow at a first glance but ends up doing exactly this job.
> 
> OK, I see. It's a highlty MD interface, even some ARM platforms don't have
> it. You can't use it for MI drivers.

Well, the OMAP1 GPIO driver (and every one of them) could be rewritten
to do the same that the OMAP2/3 does.

The real problem is that although intr_establish() exists everywhere, I
did not realize that it cannot be used the same way everywhere. On some
platforms (or buses) it just needs an interrupt number, while on some
others it wants a tag, abstracting away the complexity.

The ARM code could easily be changed to use a tag abstraction, which
could still be fit for the kernel configuration file - but that may not
be true of every architecture.

Anyway, for this reason my patch is also incorrect in the context of the
I2C and SPI buses, and I will not commit. I will therefore push my new
drivers to sys/arch/evbarm/n900 for the time being.

>> AFAIK on x86 that's pretty much what happens with IRQ 2 on the 8259
>> master PIC (IRQ#0 to 7), which is then checking the slave PIC if its
>> IRQ# 8 to 15 were really meant (the old way before APIC).
> 
> No, it's not the same thing. You don't have 2 drivers, just a PIC which is
> composed of 2 distinct chips, and a single driver. There's no way for e.g.
> a GPIO driver to register to the pic its own interrupt source to the
> PIC as is done in omap2_gpio.c

My point was that the master PIC is multiplexing IRQ 2 to IRQs 8-15.
True enough, in turn these IRQs are handled by hardware again, instead
of being mapped logically - but the concept is the same.

And my GPIO device drivers (like n900acad and n900lckbtn) are
registering their interrupt sources to the GPIO bus driver - but yes, as
of today it is specific to the OMAP2/3 GPIO bus driver.

> Note that I'm not saying that code can't be changed to allow it,
> maybe it would even be desireable (I would have a use case for
> Xen, I think). But such a MI interface would need carefull design.

Definitely.

Cheers,
-- 
khorben