public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Lars Poeschel <poeschel@lemonage.de>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Javier Martinez Canillas <javier.martinez@collabora.co.uk>,
	Linus Walleij <linus.walleij@linaro.org>,
	Lars Poeschel <larsi@wh2.tu-dresden.de>,
	Grant Likely <grant.likely@linaro.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.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>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Kevin Hilman <khilman@linaro.org>, Balaji T K <balajitk@ti.com>,
	Tony Lindgren <tony@atomide.com>,
	Jon Hunter <jgchunter@gmail.com>
Subject: Re: [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs
Date: Mon, 02 Sep 2013 11:25:25 +0200	[thread overview]
Message-ID: <1521079.WSLhhfqBXl@lem-wkst-02> (raw)
In-Reply-To: <5220F8AE.2080300@wwwdotorg.org>

Am Freitag, 30. August 2013, 13:55:26 schrieb Stephen Warren:
> On 08/29/2013 06:24 PM, Javier Martinez Canillas wrote:
> ...
> 
> > We have been trying to solve this issue for a few months by now and Linus'
> > approach seems to be the most sensible solution to me.
> > 
> > Drivers that request an IRQ and assume that platform code will request and
> > setup the GPIO have been broken since the boards using these drivers were
> > migrated to DT (e.g: smsc911x on OMAP2+ boards).
> 
> That's only true if the driver for the GPIO controller is buggy.
> Whatever request_irq() maps down to in the GPIO/IRQ controller driver
> simply needs to set up the pin as an interrupt input, then it doesn't
> matter which order the driver does things.

Is it really that easy?
request_irq() should request the gpio and set it to input that it needs to 
fulfill the irq request. That would then be the way to go for new drivers and 
in the DT case.
Some leagcy drivers currently do this:

request_gpio(gpio);
gpio_direction_input(gpio);
request_irq(gpio_to_irq(gpio));

In that case request_irq should not fail because the driver is already the 
correct owner of this gpio. But if some other entity owns this gpio it should 
fail.

Also if I understand you correct the other way round should also possible:

request_irq(gpio_to_irq(gpio));
request_gpio(gpio);
gpio_direction_input(gpio);

request_irq() also requests the gpio then but the following request_gpio() 
should also not fail.

To have it work that way we have to track the owners of all requested gpios 
somewhere. Or am I wrong here?
Where and how to record these owners? Can gpio system achieve this? gpios are 
requested without an owning device.

  reply	other threads:[~2013-09-02  9:25 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-26 14:07 [PATCH v3] gpio: interrupt consistency check for OF GPIO IRQs Lars Poeschel
2013-08-27 20:17 ` Stephen Warren
2013-08-27 20:38   ` Santosh Shilimkar
2013-08-29 19:26   ` Linus Walleij
2013-08-30  0:24     ` Javier Martinez Canillas
2013-08-30 19:55       ` Stephen Warren
2013-09-02  9:25         ` Lars Poeschel [this message]
2013-09-03 17:27           ` Stephen Warren
2013-09-04  9:05             ` Lars Poeschel
2013-09-04 20:16               ` Stephen Warren
2013-09-09 16:19                 ` Mark Brown
2013-09-10  8:47                   ` Lars Poeschel
2013-09-10 13:56                     ` Javier Martinez Canillas
2013-09-10 19:52                       ` Stephen Warren
2013-09-10 21:23                         ` Javier Martinez Canillas
2013-09-11  5:24                           ` Joel Fernandes
2013-09-10 19:53                     ` Stephen Warren
2013-09-10 21:37                       ` Mark Brown
2013-09-10 22:34                         ` Stephen Warren
2013-09-11  0:52                           ` Javier Martinez Canillas
2013-09-11 19:43                             ` Stephen Warren
     [not found]                               ` <5230C7F6.3080803-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-09-16 16:03                                 ` Lars Poeschel
2013-09-16 17:09                                   ` Stephen Warren
     [not found]                                     ` <52373B34.4060709-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-09-22 17:01                                       ` Javier Martinez Canillas
2013-09-23 20:01                                     ` Linus Walleij
2013-09-23 20:21                                       ` Stephen Warren
2013-09-24  8:31                                         ` Linus Walleij
     [not found]                                           ` <CACRpkdZ7E7MGppbkTiObvTDHdmphnbysMKVc1OZjsPXKVuKttQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-09-24 16:59                                             ` Stephen Warren
     [not found]                                               ` <5241C4DB.9090200-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-10-11  8:16                                                 ` Linus Walleij
2013-09-23 19:41                                 ` Linus Walleij
2013-09-23 19:53                               ` Linus Walleij
2013-09-23 20:12                                 ` Stephen Warren
2013-09-24  8:26                                   ` Linus Walleij
     [not found]                                     ` <CACRpkdZKqW9veHzc1Rgj4oKsjGRATk+Sz8vJaP3EfT4de+bjQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-09-24 16:56                                       ` Stephen Warren
     [not found]                   ` <20130909161924.GT29403-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-11-11 18:28                     ` Gerlando Falauto
2013-11-11 18:53                       ` Stephen Warren
     [not found]                         ` <528127B2.80109-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-11 19:17                           ` Gerlando Falauto
2013-11-11 19:33                             ` Stephen Warren
2013-11-11 19:38                               ` Tomasz Figa
2013-11-12 10:29                               ` Linus Walleij
2013-09-03 12:43         ` Linus Walleij
2013-09-03 17:32           ` Stephen Warren
2013-08-30 19:53     ` Stephen Warren
2013-09-02  9:38       ` Lars Poeschel
2013-09-03 17:29         ` Stephen Warren
2013-09-04  9:21           ` Lars Poeschel
2013-09-04 20:18             ` Stephen Warren
2013-09-03 12:35       ` Linus Walleij
2013-09-03 17:29         ` Stephen Warren
2013-09-04  8:35           ` Lars Poeschel
2013-09-04 20:13             ` Stephen Warren
     [not found]       ` <CAK7N6vrEXVyLHpY-v+SJ668hC0wvHrWOgtviAQ+w5yis7p_E4Q@mail.gmail.com>
2013-09-03 17:22         ` Stephen Warren
2013-08-29 15:14 ` Strashko, Grygorii

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=1521079.WSLhhfqBXl@lem-wkst-02 \
    --to=poeschel@lemonage.de \
    --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=javier.martinez@collabora.co.uk \
    --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=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