All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
To: Mark Brown
	<broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
Cc: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org"
	<alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org>,
	"linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org"
	<ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org>,
	"olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org"
	<olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>,
	Liam Girdwood <lrg-l0cyMroinI0@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 1/3] irq: If an IRQ is a GPIO, request and configure it
Date: Fri, 5 Aug 2011 09:06:20 +0100	[thread overview]
Message-ID: <20110805080620.GE28651@trinity.fluff.org> (raw)
In-Reply-To: <20110805053510.GA16956-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>


On Fri, Aug 05, 2011 at 06:35:11AM +0100, Mark Brown wrote:
> On Thu, Aug 04, 2011 at 08:53:34PM -0700, Stephen Warren wrote:
> 
> > Well, things break. This is essentially the problem I was describing in
> > the PATCH 0 email, just with a slightly different motivation.
> 
> There's a bunch of existing code using that idiom.
> 
> > I suppose that an alternative here would be to simply ignore any errors
> > from gpio_request. This might have the benefit of removing the need for
> > the other two patches I posted in the series. However, it seems a little
> > dirty; one benefit of the IRQ code calling gpio_request and honoring
> > errors would be to detect when some completely unrelated code had a bug
> > and had called gpio_request on the GPIO before. Such detection would be
> > non-existent if we don't error out on gpio_request. Perhaps some mechanism
> > is needed to indicate that the driver has explicitly already called
> > gpio_request for a legitimate shared purpose, and only then ignore
> > errors?
> 
> But it's not a bug to use a GPIO as an IRQ source, otherwise we wouldn't
> have gpio_to_irq() in the first place.  Feels like we need a backchannel
> between gpiolib and the IRQ code to do this.  Or perhaps the drivers
> that implement this should be taking care of setting up the GPIO mode?

Converting GPIOs to IRQs is really useful. The reverse mapping is not as
easy, as when go NR->CHIP->to_irq() method, but the reverse is not being
tracked at the moment, which makes life difficult.

I would say that setting the interrupt should deal with all the necessary
configuration to get that interrupt working. In the case of pretty much all
of the SoCs I have been involved with have always set the GPIO's function
to allow the interrupt to pass through.

Whilst there's a case for having this being done either in the core IRQ
code (may break for everyone else) we could quite easily do this in the
GPIO driver.

As a note, we are actuallly trying to remove the irq_to_gpio() calls, as
they are not widely used across the kernel, very sparsely and badly
implemented across ARM and are very rarely used (the IIO system is the
only system currently doing this, for some fairly nasty reasons)

-- 
Ben Dooks, ben-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.

WARNING: multiple messages have this Message-ID (diff)
From: Ben Dooks <ben-linux@fluff.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Stephen Warren <swarren@nvidia.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"ccross@android.com" <ccross@android.com>,
	"olof@lixom.net" <olof@lixom.net>,
	Thomas Gleixner <tglx@linutronix.de>, Chris Ball <cjb@laptop.org>,
	Liam Girdwood <lrg@ti.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/3] irq: If an IRQ is a GPIO, request and configure it
Date: Fri, 5 Aug 2011 09:06:20 +0100	[thread overview]
Message-ID: <20110805080620.GE28651@trinity.fluff.org> (raw)
In-Reply-To: <20110805053510.GA16956@opensource.wolfsonmicro.com>


On Fri, Aug 05, 2011 at 06:35:11AM +0100, Mark Brown wrote:
> On Thu, Aug 04, 2011 at 08:53:34PM -0700, Stephen Warren wrote:
> 
> > Well, things break. This is essentially the problem I was describing in
> > the PATCH 0 email, just with a slightly different motivation.
> 
> There's a bunch of existing code using that idiom.
> 
> > I suppose that an alternative here would be to simply ignore any errors
> > from gpio_request. This might have the benefit of removing the need for
> > the other two patches I posted in the series. However, it seems a little
> > dirty; one benefit of the IRQ code calling gpio_request and honoring
> > errors would be to detect when some completely unrelated code had a bug
> > and had called gpio_request on the GPIO before. Such detection would be
> > non-existent if we don't error out on gpio_request. Perhaps some mechanism
> > is needed to indicate that the driver has explicitly already called
> > gpio_request for a legitimate shared purpose, and only then ignore
> > errors?
> 
> But it's not a bug to use a GPIO as an IRQ source, otherwise we wouldn't
> have gpio_to_irq() in the first place.  Feels like we need a backchannel
> between gpiolib and the IRQ code to do this.  Or perhaps the drivers
> that implement this should be taking care of setting up the GPIO mode?

Converting GPIOs to IRQs is really useful. The reverse mapping is not as
easy, as when go NR->CHIP->to_irq() method, but the reverse is not being
tracked at the moment, which makes life difficult.

I would say that setting the interrupt should deal with all the necessary
configuration to get that interrupt working. In the case of pretty much all
of the SoCs I have been involved with have always set the GPIO's function
to allow the interrupt to pass through.

Whilst there's a case for having this being done either in the core IRQ
code (may break for everyone else) we could quite easily do this in the
GPIO driver.

As a note, we are actuallly trying to remove the irq_to_gpio() calls, as
they are not widely used across the kernel, very sparsely and badly
implemented across ARM and are very rarely used (the IIO system is the
only system currently doing this, for some fairly nasty reasons)

-- 
Ben Dooks, ben@fluff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.


WARNING: multiple messages have this Message-ID (diff)
From: ben-linux@fluff.org (Ben Dooks)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] irq: If an IRQ is a GPIO, request and configure it
Date: Fri, 5 Aug 2011 09:06:20 +0100	[thread overview]
Message-ID: <20110805080620.GE28651@trinity.fluff.org> (raw)
In-Reply-To: <20110805053510.GA16956@opensource.wolfsonmicro.com>


On Fri, Aug 05, 2011 at 06:35:11AM +0100, Mark Brown wrote:
> On Thu, Aug 04, 2011 at 08:53:34PM -0700, Stephen Warren wrote:
> 
> > Well, things break. This is essentially the problem I was describing in
> > the PATCH 0 email, just with a slightly different motivation.
> 
> There's a bunch of existing code using that idiom.
> 
> > I suppose that an alternative here would be to simply ignore any errors
> > from gpio_request. This might have the benefit of removing the need for
> > the other two patches I posted in the series. However, it seems a little
> > dirty; one benefit of the IRQ code calling gpio_request and honoring
> > errors would be to detect when some completely unrelated code had a bug
> > and had called gpio_request on the GPIO before. Such detection would be
> > non-existent if we don't error out on gpio_request. Perhaps some mechanism
> > is needed to indicate that the driver has explicitly already called
> > gpio_request for a legitimate shared purpose, and only then ignore
> > errors?
> 
> But it's not a bug to use a GPIO as an IRQ source, otherwise we wouldn't
> have gpio_to_irq() in the first place.  Feels like we need a backchannel
> between gpiolib and the IRQ code to do this.  Or perhaps the drivers
> that implement this should be taking care of setting up the GPIO mode?

Converting GPIOs to IRQs is really useful. The reverse mapping is not as
easy, as when go NR->CHIP->to_irq() method, but the reverse is not being
tracked at the moment, which makes life difficult.

I would say that setting the interrupt should deal with all the necessary
configuration to get that interrupt working. In the case of pretty much all
of the SoCs I have been involved with have always set the GPIO's function
to allow the interrupt to pass through.

Whilst there's a case for having this being done either in the core IRQ
code (may break for everyone else) we could quite easily do this in the
GPIO driver.

As a note, we are actuallly trying to remove the irq_to_gpio() calls, as
they are not widely used across the kernel, very sparsely and badly
implemented across ARM and are very rarely used (the IIO system is the
only system currently doing this, for some fairly nasty reasons)

-- 
Ben Dooks, ben at fluff.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.

  parent reply	other threads:[~2011-08-05  8:06 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 23:00 [RFC PATCH 0/3] If an IRQ is a GPIO, request and configure it Stephen Warren
2011-08-04 23:00 ` Stephen Warren
2011-08-04 23:00 ` Stephen Warren
     [not found] ` <1312498820-2275-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2011-08-04 23:00   ` [PATCH 1/3] irq: " Stephen Warren
2011-08-04 23:00     ` Stephen Warren
2011-08-04 23:00     ` Stephen Warren
2011-08-05  0:01     ` Mark Brown
2011-08-05  0:01       ` Mark Brown
2011-08-05  0:01       ` Mark Brown
     [not found]       ` <20110805000148.GB13321-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-08-05  3:53         ` Stephen Warren
2011-08-05  3:53           ` Stephen Warren
2011-08-05  3:53           ` Stephen Warren
2011-08-05  5:35           ` Mark Brown
2011-08-05  5:35             ` Mark Brown
2011-08-05  5:35             ` Mark Brown
     [not found]             ` <20110805053510.GA16956-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2011-08-05  8:06               ` Ben Dooks [this message]
2011-08-05  8:06                 ` Ben Dooks
2011-08-05  8:06                 ` Ben Dooks
2011-08-05  8:29                 ` Mark Brown
2011-08-05  8:29                   ` Mark Brown
2011-08-05  8:29                   ` Mark Brown
2011-08-05 15:29             ` Stephen Warren
2011-08-05 15:29               ` Stephen Warren
2011-08-05 15:29               ` Stephen Warren
2011-08-05 16:15               ` Mark Brown
2011-08-05 16:15                 ` Mark Brown
2011-08-05 16:15                 ` Mark Brown
2011-08-05  1:54     ` Rob Herring
2011-08-05  1:54       ` Rob Herring
2011-08-05  4:05       ` Stephen Warren
2011-08-05  4:05         ` Stephen Warren
2011-08-05  4:05         ` Stephen Warren
2011-08-05  7:58     ` Ben Dooks
2011-08-05  7:58       ` Ben Dooks
2011-09-02  8:36     ` Thomas Gleixner
2011-09-02  8:36       ` Thomas Gleixner
2011-09-02 15:24       ` Stephen Warren
2011-09-02 15:24         ` Stephen Warren
2011-09-02 15:24         ` Stephen Warren
     [not found]         ` <74CDBE0F657A3D45AFBB94109FB122FF04B327A55C-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-09-02 15:34           ` Stephen Warren
2011-09-02 15:34             ` Stephen Warren
2011-09-02 15:34             ` Stephen Warren
2011-09-02 15:50           ` Thomas Gleixner
2011-09-02 15:50             ` Thomas Gleixner
2011-09-02 15:50             ` Thomas Gleixner
2011-08-04 23:00   ` [PATCH 2/3] mmc: tegra: Don't gpio_request GPIOs used as IRQs Stephen Warren
2011-08-04 23:00     ` Stephen Warren
2011-08-04 23:00     ` Stephen Warren
2011-08-04 23:00   ` [PATCH 3/3] ASoC: jack_add_gpios: " Stephen Warren
2011-08-04 23:00     ` Stephen Warren
2011-08-04 23:00     ` Stephen Warren
2011-08-05  7:55   ` [RFC PATCH 0/3] If an IRQ is a GPIO, request and configure it Ben Dooks
2011-08-05  7:55     ` Ben Dooks
2011-08-05  7:55     ` Ben Dooks
2011-08-05  9:40 ` Russell King - ARM Linux
2011-08-05  9:40   ` Russell King - ARM Linux
     [not found]   ` <20110805094017.GC20575-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2011-08-05 10:30     ` Ben Dooks
2011-08-05 10:30       ` Ben Dooks
2011-08-05 10:30       ` Ben Dooks
2011-08-05 20:25       ` Linus Walleij
2011-08-05 20:25         ` Linus Walleij
2011-08-05 15:43   ` Stephen Warren
2011-08-05 15:43     ` Stephen Warren
2011-08-05 15:43     ` Stephen Warren
2011-08-05 19:15     ` Russell King - ARM Linux
2011-08-05 19:15       ` Russell King - ARM Linux
2011-08-05 19:15       ` Russell King - ARM Linux
2011-08-05 19:33       ` Stephen Warren
2011-08-05 19:33         ` Stephen Warren
2011-08-05 19:33         ` Stephen Warren
2011-08-05 21:40         ` Russell King - ARM Linux
2011-08-05 21:40           ` Russell King - ARM Linux
2011-08-05 21:40           ` Russell King - ARM Linux

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=20110805080620.GE28651@trinity.fluff.org \
    --to=ben-linux-elnmno+kys3ytjvyw6ydsg@public.gmane.org \
    --cc=alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org \
    --cc=broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org \
    --cc=ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org \
    --cc=cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lrg-l0cyMroinI0@public.gmane.org \
    --cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
    --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.