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

2014/1/16 Nicolas Ferre [off-list ref]:

On 16/01/2014 09:54, boris brezillon :

quoted

On 15/01/2014 19:06, Jean-Christophe PLAGNIOL-VILLARD wrote:

quoted

On 11:35 Mon 13 Jan     , boris brezillon wrote:

quoted

On 13/01/2014 11:29, Jean-Jacques Hiblot wrote:

quoted

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

quoted

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

I share your view on this.

Linus,
 the root of the issue is the fact that a GPIO can't be requested
twice. But IMO it's safe for a single device to request it more than
once and use it for different purposes (irq and electrical signal
value). Maybe we can rework the GPIO request to include this ownership
information. I can post a draft implementation for this if you think
it's worthwhile.

Jean-Jacques

Bye,
--
Nicolas Ferre