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

[Jean-Christophe PLAGNIOL-VILLARD]

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

Best Regards,
J.
> 
> >
> > Best Regards,
> > J.