Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



Am 19.04.13 21:42, schrieb Pierre Pronchery:
>                       Hi,
> 
> On 19/04/2013 17:12, Manuel Bouyer wrote:
>> On Fri, Apr 19, 2013 at 12:50:37PM +0000, Pierre Pronchery wrote:
>>>
>>> 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.
> 
> 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.
> 
> Voila, you have the virtual interrupt, and you can call intr_establish().

I don't if I you understand right, but

intr_establish() should not be called from a driver that attaches to
gpio pins, but the underlying driver, when instructed to do so by the
gpio framework.

> 
> HTH,
> 



Home | Main Index | Thread Index | Old Index