device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.

[Nicolas Ferre]

On 16/01/2014 09:54, boris brezillon :
> On 15/01/2014 19:06, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 11:35 Mon 13 Jan     , boris brezillon wrote:
>>> On 13/01/2014 11:29, Jean-Jacques Hiblot wrote:
>>>> Hello Nicolas, Jean-Christophe,
>>>>
>>>> As I was trying to enable the touchscreen on the at91sam9261ek with
>>>> device-tree support, I ran into an issue. The touchscreen driver needs
>>>> to know the state of the pendown gpio and also needs it as an
>>>> interrupt source.
>>>>
>>>> The problem is that when a gpio is used as an interrupt, it's
>>>> requested by the pinctrl driver during the xlate stage, marking it
>>>> unavaliable for the other driver.
>>>> It looks like the at91 pinctrl driver is the only one to use
>>>> gpio_request() in the xlate stage. Maybe we should remove this:
>>> You should only request it as a GPIO and then use gpio_to_irq to get the
>>> related IRQ.
>> This here a HUGE issue in the hole kernel
>>
>> You should NEVER known ti's a gpio in the driver at all gpio_to_irq should never
>> exist you need to only see the irq
>>
>>> Because what is done here, is to solve the case where only the irq
>>> is request, and in this specific case we need to request the pin as a
>>> GPIO.
>> this need to be handled at irq level not drivers
> 
> Then propose something (or at least give us a deadline for this new 
> interrupt
> model to come out), because the ADS7843E touchscreen is not working anymore
> (at least on at91 platforms).
> 
> What this driver needs is a level IRQ (not an edge IRQ). The code in 
> ads7846_hard_irq<http://lxr.free-electrons.com/ident?i=ads7846_hard_irq>
> interrupt handler is here to transform an edge IRQ into a level IRQ.
> 
> Is there a way to provide a generic framework to transform edge IRQs 
> into level IRQs
> (because some GPIO controllers do not support level IRQs, and this is 
> the case for the
> at91sam9261 one) ?
> 
> 
> Of cource the gpio_to_irq approach is not perfect, but at least it as 
> the benefit to quickly
> fix the bug, and we will still be able to improve this later, when we 
> have enough tools
> (or mechanisms) to do it.

Moreover, I do not see the rationale behind the concept of "interrupt
with an electrical value". An interrupt signals an event and this event
can be a transition or a state but an electrical value is the
responsibility of a GPIO line, not the other way around.

I see a code that could give the value of an electrical line related to
an interrupt as a twisted interpretation of the notion of "interrupt".
It surprises me that it could be thought as an enhancement that an IRQ
coming from a GPIO could give a value!

Isn't it why other people are also using this simple distinction to use
their GPIO/IRQ mechanism? Maybe this is why we are the only ones to
completely forbid this possibility.

So, let's fix the bug, submit the modification to mainline, make
platform work and see if somebody can convince me that retrieving an
electrical line status from a GPIO is a "bad" thing...

Bye,
-- 
Nicolas Ferre