From: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>,
Kevin Hilman <khilman@linaro.org>,
Stephen Warren <swarren@wwwdotorg.org>,
Lars Poeschel <larsi@wh2.tu-dresden.de>,
Grant Likely <grant.likely@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ian.campbell@citrix.com>,
Kumar Gala <galak@codeaurora.org>,
Pawel Moll <pawel.moll@arm.com>,
Tomasz Figa <tomasz.figa@gmail.com>,
Enric Balletbo i Serra <eballetbo@gmail.com>,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Balaji T K <balajitk@ti.com>, Tony Lindgren <tony@atomide.com>,
Jon Hunter <jgchunter@gmail.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Linux-OMAP <linux-omap@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] gpio/omap: auto-setup a GPIO when used as an IRQ
Date: Tue, 24 Sep 2013 07:41:08 +0200 [thread overview]
Message-ID: <524125F4.4060608@collabora.co.uk> (raw)
In-Reply-To: <CACRpkdb35DouKsZ+9aWfQmER1vmAaK1dR7VXjoFHTLRR+hBezg@mail.gmail.com>
On 09/23/2013 10:15 PM, Linus Walleij wrote:
> On Sun, Sep 22, 2013 at 4:40 PM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
>
>> To use a GPIO pin as an interrupt line, two previous configurations
>> have to be made:
>>
>> a) Map the GPIO pin as an interrupt line into the Linux irq space
>> b) Enable the GPIO bank and configure the GPIO direction as input
>>
>> Most GPIO/IRQ chip drivers just create a mapping for every single
>> GPIO pin with irq_create_mapping() on .probe so users usually can
>> assume a) and only have to do b) by using the following sequence:
>>
>> gpio_request(gpio, "foo IRQ");
>> gpio_direction_input(gpio);
>>
>> and then request a IRQ with:
>>
>> irq = gpio_to_irq(gpio);
>> request_irq(irq, ...);
>
> I guess I have to live with this approach, but I'd like to - if possible -
> address my pet issue.
>
> - It is OK that the HW get set up as GPIO input by the IRQ
> request function alone. (Through gpio_irq_type I guess).
>
Yes, this is how is made on this patch indeed.
> - When a second caller calls omap_gpio_request() it should
> be OK as well, but only if the flags corresponds to the
> previously enabled input mode. Else it should be
> disallowed.
>
> - The same should happen for _set_gpio_direction() if a pin
> previously set up for IRQ gets a request to be used as
> output.
>
> If this cannot be tracked in the driver, it is certainly a candidate
> for something that gpiolib should be doing. And then I'm open to
> solutions to how we can do that.
>
Ok, this can be tracked in the driver, will add it when posting v2 soon.
> If this needs to be applied pronto to fix the regression I'm
> happy with that too, if we add a big boilerplate stating the above
> problem and that it needs to be *fixed* at some point.
>
> But in either case I want this to be tested on OMAP1 before
> I apply it, as in a Tested-by tag.
>
Agreed. Even though this is a fix for a long standing issue I prefer it to be
tested extensively than applying the patch in a rush just to learn that causes
regressions and have to be reverted as it happens last time.
So as you said let's wait until we have a few Tested-by tags by people using
different OMAP platforms specially OMAP1.
> Yours,
> Linus Walleij
>
Thanks a lot and best regards,
Javier
next prev parent reply other threads:[~2013-09-24 5:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-22 14:40 Javier Martinez Canillas
2013-09-23 16:14 ` Stephen Warren
2013-09-23 16:31 ` Javier Martinez Canillas
2013-09-23 16:45 ` Tony Lindgren
2013-09-23 17:00 ` Javier Martinez Canillas
2013-09-23 17:07 ` Tony Lindgren
2013-09-23 18:35 ` Santosh Shilimkar
2013-09-24 7:39 ` Sricharan R
2013-09-24 7:54 ` Javier Martinez Canillas
2013-09-24 8:47 ` Sricharan R
2013-09-23 20:15 ` Linus Walleij
2013-09-24 5:41 ` Javier Martinez Canillas [this message]
2013-09-24 15:27 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=524125F4.4060608@collabora.co.uk \
--to=javier.martinez@collabora.co.uk \
--cc=balajitk@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=eballetbo@gmail.com \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=ian.campbell@citrix.com \
--cc=jgchunter@gmail.com \
--cc=khilman@linaro.org \
--cc=larsi@wh2.tu-dresden.de \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=plagnioj@jcrosoft.com \
--cc=santosh.shilimkar@ti.com \
--cc=swarren@wwwdotorg.org \
--cc=tomasz.figa@gmail.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome