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

[Jean-Jacques Hiblot]

2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>:
> On 15:41 Wed 15 Jan     , Jean-Jacques Hiblot wrote:
>> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>:
>> > On 14:44 Wed 15 Jan     , Jean-Jacques Hiblot wrote:
>> >> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>:
>> >> > On 14:04 Wed 15 Jan     , Jean-Jacques Hiblot wrote:
>> >> >> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>:
>> >> >> > On 12:05 Mon 13 Jan     , Jean-Jacques Hiblot wrote:
>> >> >> >> Hi Boris,
>> >> >> >>
>> >> >> >> 2014/1/13 boris brezillon <b.brezillon at overkiz.com>:
>> >> >> >> > 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.
>> >> >> >> > 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.
>>
>> >
>> > Best Regards,
>> > J.