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

Jean-Jacques Hiblot jjhiblot at traphandler.com
Wed Jan 15 08:44:24 EST 2014


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 ?

>
> so the gpio driver may need to be updated to provide such information to the
> touch driver
>
> Best Regards,
> J.
>>
>> >
>> > I even send a proposition to do this work across the kernel t the CE-Linux for
>> > funding
>> >> 2) I believe that configuration of the direction can be done by
>> >> describing the GPIO in the DT. (pinctrl-at91.c line 592).
>> > No pinctrl is for pinmux ONLY not gpio direction & co
>> >
>> > Best Regards,
>> > J.
>> >
>> >> 3) If all the GPIOs are described in the DT with a proper pinmux
>> >> description, i believe the exclusion is also handled. It's probably
>> >> not the case today though.
>> >
>> >>
>> >> >
>> >> > Best Regards,
>> >> >
>> >> > Boris
>> >> >
>> >> >>
>> >> >> diff --git a/drivers/pinctrl/pinctrl-at91.c
>> >> >> b/drivers/pinctrl/pinctrl-at91.c
>> >> >> index a7549c4..cf91a35 100644
>> >> >> --- a/drivers/pinctrl/pinctrl-at91.c
>> >> >> +++ b/drivers/pinctrl/pinctrl-at91.c
>> >> >> @@ -1463,14 +1463,6 @@ static int at91_gpio_irq_domain_xlate(struct
>> >> >> irq_domain *d,
>> >> >>          *out_hwirq = intspec[0];
>> >> >>          *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
>> >> >>
>> >> >> -       ret = gpio_request(pin, ctrlr->full_name);
>> >> >> -       if (ret)
>> >> >> -               return ret;
>> >> >> -
>> >> >> -       ret = gpio_direction_input(pin);
>> >> >> -       if (ret)
>> >> >> -               return ret;
>> >> >> -
>> >> >>          return 0;
>> >> >>   }
>> >> >>
>> >> >> Jean-Jacques
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> linux-arm-kernel mailing list
>> >> linux-arm-kernel at lists.infradead.org
>> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



More information about the linux-arm-kernel mailing list