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 12:50:37PM +0000, Pierre Pronchery wrote:
>                       Hi,
> 
> On Fri, 19 Apr 2013 10:01:46 +0200, Manuel Bouyer wrote:
> > 
> > On Thu, Apr 18, 2013 at 05:31:41PM +0200, Pierre Pronchery wrote:
> >> Another option could be to:
> >> - add a call returning the corresponding interrupt for a given pin, eg
> >>   gpio_to_irq() (and return -1 when the requested type isn't supported)
> >> - use intr_establish() as for regular drivers.
> >> 
> >> That's what Linux does, as far as I could tell from the OMAP code that
> >> I've read there.
> > 
> > That would be a problem if the GPIO module has less interrupt lines than
> > interrupt sources (as in the AM335x: 32 GPIO per module but only 2
> > interrupt lines to the PIC):
> 
> Tell me if I'm wrong, but I don't think you understood what's happening 
> here: the GPIO interrupt range that I described on OMAP is virtual. 
> Therefore, gpio_to_irq() would return a virtual interruption number.

But the interrupt framework doesn't know about "virtual interruption number".
Only the gpio driver knows it. So you can't use intr_establish() (which
is from the interrupt framework, not the gpio driver) with it.

> 
> The underlying GPIO bus driver would be in charge to determine which pin 
> really triggered the interrupt, and tell the corresponding driver. The 
> OMAP GPIO driver does exactly this already.

Yes, of course. So the interrupt framework calls the GPIO interrupt handler,
which calls the driver's handler. It's the GPIO driver which has to know
the driver's interrupt handler, not the interrupt framework.
So the driver has to register its interrupt handler to the GPIO driver,
not to the interrupt framework.

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