device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
Jean-Christophe PLAGNIOL-VILLARD
plagnioj at jcrosoft.com
Wed Jan 15 13:00:08 EST 2014
On 16:30 Wed 15 Jan , Jean-Jacques Hiblot wrote:
> 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.
so use deglitch one this will do the tric
Best Regards,
J.
More information about the linux-arm-kernel
mailing list