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

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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.

> 
> > And I couldn't find a gpio_to_irq() function in the source
> > (neither in arm code, nor in MI code).
> 
> This was an hypothetical proposal, based on what Linux does.
> 
> > Maybe I missed something in the arm code. I know better the x86 or mips
> > ports, and I'm sure that this "interrupt multiplexer" concept is not
> > implemented here.
> 
> 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

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.
I'm not sure the ARM interface as used by omap2_gpio.c can be
expanded as is to x86 (it looks like it doesn't allow interrupt sharing
for example).

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--