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

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

On 19/04/2013 23:46, Manuel Bouyer wrote:
> On Fri, Apr 19, 2013 at 09:42:37PM +0200, Pierre Pronchery wrote:
>>>>> 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.
>>
>> As a matter of fact it doesn't have to. I can use intr_establish(),
>> because I am doing it and it works already (even without the patch I
>> attached earlier here). Just look at my original e-mail in this thread
>> (first paragraph + example).
>>
>>>> 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.
>>
>> Consider this:
>> int gpio_to_irq(void * gpio, int pin);
>>
>> The GPIO _device_ driver wants to know which virtual interrupt
>> corresponds to a given pin. It calls gpio_to_irq() with ga_gpio as
>> obtained from "struct gpio_attach_args". This call reaches the GPIO
>> _bus_ driver, which:
>> - knows its own actual interrupt number, but we don't care;
>> - knows its interrupt range reference, which it registered to the
>>   underlying interrupt multiplexer, and adds to "pin" and returns.
> 
> What is the "interrupt multiplexer" ? Where can I find it ?

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.

> 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).

On MIPS I don't know.

HTH,
-- 
khorben