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

2014/1/15 Jean-Christophe PLAGNIOL-VILLARD [off-list ref]:

On 15:41 Wed 15 Jan     , Jean-Jacques Hiblot wrote:

quoted

2014/1/15 Jean-Christophe PLAGNIOL-VILLARD [off-list ref]:

quoted

On 14:44 Wed 15 Jan     , Jean-Jacques Hiblot wrote:

quoted

2014/1/15 Jean-Christophe PLAGNIOL-VILLARD [off-list ref]:

quoted

On 14:04 Wed 15 Jan     , Jean-Jacques Hiblot wrote:

quoted

2014/1/15 Jean-Christophe PLAGNIOL-VILLARD [off-list ref]:

quoted

On 12:05 Mon 13 Jan     , Jean-Jacques Hiblot wrote:

quoted

Hi Boris,

2014/1/13 boris brezillon [off-list ref]:

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

That's what I did first, and was about to submit the patch for the
touchscreen driver.
However it doesn't feel right. Being able to get the state of a gpio
that is also an interrupt seems very useful to me, not only for a
touchscreen controller.

I understand why it's being done here. It's a matter of being sure
that the GPIO is an input and that it'll not be configured otherwise
latter.
But:
1) I'm wondering why the atmel pinctrl is the only one to do that.

because this the only to start to do it right
I had a very long discussion woth LinusW and Grant the Gpio need to stop to
use gpio_to_irq & co for irq.

How can you get the value of the gpio that is also an interrupt source then ?
Can you give a short example?

you just have to check the irq source

failing or raising

but on 9261 impossible the gpio does not have such detail

but anyway this is the invert you need to get the information from the IRQ no the way
arround

Should I modify the touchscreen driver to use irq_to_gpio() in this
case then ? or is this also not proper ?

no as said by arnd irq_to_gpio does not exsit

that's why I said the irq need to provide you the information as it's a
raising or failing irq

Even when this kind of information is available it's not enough to
know for sure the state of the gpio. Think of short pulses such as the
glitches you have when you press a button.

this why you have debounce in the gpio IP to solve this

Unfortunately, the debounce filter in the IP not appropriate to handle
the glitches such as what you have in the case of a button.
It may be good enough to filter EMI induced pulses but not mechanical
ones which are way too long.

Best Regards,
J.

quoted

quoted

Best Regards,
J.