From: ryan@bluewatersys.com (Ryan Mallon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleeping gpios)
Date: Thu, 24 Jun 2010 11:06:23 +1200 [thread overview]
Message-ID: <4C22936F.9050300@bluewatersys.com> (raw)
In-Reply-To: <20100623225345.GD7058@shareable.org>
On 06/24/2010 10:53 AM, Jamie Lokier wrote:
> Ryan Mallon wrote:
>> On 06/23/2010 04:37 PM, David Brownell wrote:
>> I'm not. Some gpios, such as those on io expanders, may sleep in their
>> implementations of the gpio_(set/get) functions.
>
> I'm having a hard time figuring out where some GPIOs I'm using fit
> into this picture.
>
> I have some hardware that is currently using a 2.4.26 kernel, but I
> look from time to time at forward-porting all the drivers to 2.6.recent.
>
> It has an I2C driven GPIO expander, with a watchdog reset chip hanging
> off the expander.
>
> The watchdog is kept alive off the back end of a timer BH, which means
> the I2C GPIO routines are written to be safe in BH context (which
> isn't sleepable), but they can't be used in IRQ context because the
> necessary spin_lock_irqsave() would turn off interrupts for too long
> for other subsystems to function properly.
Do the implementations of the get/set calls for the io expander gpios
sleep at all?
> How should I flag those GPIO routines in your scheme? They're safe to
> use in some non-sleeping contexts, but not safe in irq context.
The idea in my proposal is to use gpio_request in a driver if the
requested gpio can never sleep (ie because of the context it is used
in), and gpio_request_cansleep if the gpio is never used from non-sleep
safe context in a driver. I suggested stripping back the patch to just
add the gpio_request_cansleep function.
In the current code, if a driver ever calls gpio_(set/get)_value on a
gpio then you cannot pass a sleeping gpio to that driver. The request
will succeed, but you will get warnings with the get/get calls are made.
My idea is basically to move the denotation of whether a gpio will be
used in non-sleep safe context to the gpio request.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
WARNING: multiple messages have this Message-ID (diff)
From: Ryan Mallon <ryan@bluewatersys.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: "David Brownell" <david-b@pacbell.net>,
"David Brownell" <dbrownell@users.sourceforge.net>,
gregkh@suse.de, "linux kernel" <linux-kernel@vger.kernel.org>,
ext-jani.1.nikula@nokia.com,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Andrew Morton" <akpm@linux-foundation.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleeping gpios)
Date: Thu, 24 Jun 2010 11:06:23 +1200 [thread overview]
Message-ID: <4C22936F.9050300@bluewatersys.com> (raw)
In-Reply-To: <20100623225345.GD7058@shareable.org>
On 06/24/2010 10:53 AM, Jamie Lokier wrote:
> Ryan Mallon wrote:
>> On 06/23/2010 04:37 PM, David Brownell wrote:
>> I'm not. Some gpios, such as those on io expanders, may sleep in their
>> implementations of the gpio_(set/get) functions.
>
> I'm having a hard time figuring out where some GPIOs I'm using fit
> into this picture.
>
> I have some hardware that is currently using a 2.4.26 kernel, but I
> look from time to time at forward-porting all the drivers to 2.6.recent.
>
> It has an I2C driven GPIO expander, with a watchdog reset chip hanging
> off the expander.
>
> The watchdog is kept alive off the back end of a timer BH, which means
> the I2C GPIO routines are written to be safe in BH context (which
> isn't sleepable), but they can't be used in IRQ context because the
> necessary spin_lock_irqsave() would turn off interrupts for too long
> for other subsystems to function properly.
Do the implementations of the get/set calls for the io expander gpios
sleep at all?
> How should I flag those GPIO routines in your scheme? They're safe to
> use in some non-sleeping contexts, but not safe in irq context.
The idea in my proposal is to use gpio_request in a driver if the
requested gpio can never sleep (ie because of the context it is used
in), and gpio_request_cansleep if the gpio is never used from non-sleep
safe context in a driver. I suggested stripping back the patch to just
add the gpio_request_cansleep function.
In the current code, if a driver ever calls gpio_(set/get)_value on a
gpio then you cannot pass a sleeping gpio to that driver. The request
will succeed, but you will get warnings with the get/get calls are made.
My idea is basically to move the denotation of whether a gpio will be
used in non-sleep safe context to the gpio request.
~Ryan
--
Bluewater Systems Ltd - ARM Technology Solution Centre
Ryan Mallon 5 Amuri Park, 404 Barbadoes St
ryan@bluewatersys.com PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com New Zealand
Phone: +64 3 3779127 Freecall: Australia 1800 148 751
Fax: +64 3 3779135 USA 1800 261 2934
next prev parent reply other threads:[~2010-06-23 23:06 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-17 21:47 gpiolib and sleeping gpios Ryan Mallon
2010-06-17 21:47 ` Ryan Mallon
2010-06-18 5:27 ` Uwe Kleine-König
2010-06-18 5:27 ` Uwe Kleine-König
2010-06-18 6:16 ` David Brownell
2010-06-18 6:16 ` David Brownell
2010-06-18 22:01 ` Ryan Mallon
2010-06-18 22:01 ` Ryan Mallon
2010-06-19 6:21 ` David Brownell
2010-06-19 6:21 ` David Brownell
2010-06-20 21:31 ` Ryan Mallon
2010-06-20 21:31 ` Ryan Mallon
2010-06-21 2:40 ` David Brownell
2010-06-21 2:40 ` David Brownell
2010-06-21 5:09 ` Uwe Kleine-König
2010-06-21 5:09 ` Uwe Kleine-König
2010-06-23 1:59 ` [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleeping gpios) Ryan Mallon
2010-06-23 1:59 ` Ryan Mallon
2010-06-23 4:37 ` David Brownell
2010-06-23 4:37 ` David Brownell
2010-06-23 4:58 ` Eric Miao
2010-06-23 4:58 ` Eric Miao
2010-06-23 9:51 ` David Brownell
2010-06-23 9:51 ` David Brownell
2010-06-23 5:02 ` Ryan Mallon
2010-06-23 5:02 ` Ryan Mallon
2010-06-23 5:26 ` Eric Miao
2010-06-23 5:26 ` Eric Miao
2010-06-23 9:39 ` David Brownell
2010-06-23 9:39 ` David Brownell
2010-06-23 19:12 ` Ryan Mallon
2010-06-23 19:12 ` Ryan Mallon
2010-06-24 4:46 ` [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleepinggpios) Jon Povey
2010-06-24 4:46 ` Jon Povey
2010-06-24 8:20 ` Lars-Peter Clausen
2010-06-24 8:20 ` Lars-Peter Clausen
2010-06-24 8:29 ` Jani Nikula
2010-06-24 8:29 ` Jani Nikula
2010-06-24 10:31 ` Lars-Peter Clausen
2010-06-24 10:31 ` Lars-Peter Clausen
2010-06-24 6:41 ` [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleeping gpios) Uwe Kleine-König
2010-06-24 6:41 ` Uwe Kleine-König
2010-06-23 22:53 ` Jamie Lokier
2010-06-23 22:53 ` Jamie Lokier
2010-06-23 23:06 ` Ryan Mallon [this message]
2010-06-23 23:06 ` Ryan Mallon
2010-06-24 0:04 ` Jamie Lokier
2010-06-24 0:04 ` Jamie Lokier
2010-06-24 0:10 ` Ryan Mallon
2010-06-24 0:10 ` Ryan Mallon
2010-06-25 7:19 ` David Brownell
2010-06-25 7:19 ` David Brownell
2010-06-24 4:33 ` [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleepinggpios) Jon Povey
2010-06-24 4:33 ` Jon Povey
2010-06-29 8:29 ` gpiolib and sleeping gpios CoffBeta
2010-06-29 8:29 ` CoffBeta
2010-06-23 11:53 ` Jani Nikula
2010-06-23 11:53 ` Jani Nikula
2010-06-23 12:40 ` David Brownell
2010-06-23 12:40 ` David Brownell
2010-06-23 13:22 ` Jani Nikula
2010-06-23 13:22 ` Jani Nikula
2010-06-23 13:39 ` David Brownell
2010-06-23 13:39 ` David Brownell
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=4C22936F.9050300@bluewatersys.com \
--to=ryan@bluewatersys.com \
--cc=linux-arm-kernel@lists.infradead.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.