From: ryan@bluewatersys.com (Ryan Mallon)
To: linux-arm-kernel@lists.infradead.org
Subject: gpiolib and sleeping gpios
Date: Fri, 18 Jun 2010 09:47:59 +1200 [thread overview]
Message-ID: <4C1A980F.8080908@bluewatersys.com> (raw)
Hi,
Currently implementors of gpiolib must provide implementations for
gpio_get_value, gpio_set_value and gpio_cansleep. Most of the
implementations just #define these to the double underscore prefixed
versions in drivers/gpio/gpiolib.c. A few implementations have a simple
wrapper function which provides a fast path for the SoC gpios, and calls
gpiolib for the any additional gpios, such as those added by an io expander.
Although gpio_chips know whether or not they may sleep, gpios which can
sleep need to call gpio_[set/get]_value_cansleep. The only difference
between __gpio_(set/get)_value and gpio_(set/get)_value_cansleep is that
the cansleep versions calls might_sleep_if. Most drivers call
gpio_(get/set)_value, rather than the cansleep variants. I haven't done
a full audit of all of the drivers (which is a reasonably involved
task), but I would hazard a guess that some of these could be replaced
by the cansleep versions.
Would it not be simpler to combine the calls and have something like this:
void __gpio_get_value(unsigned gpio, int value)
{
struct gpio_chip *chip;
chip = gpio_to_chip(gpio);
might_sleep_if(extra_checks && chip->can_sleep);
chip->set(chip, gpio - chip->base, value);
}
Then all drivers can just call gpio_(set/get)_value and any attempts to
use sleeping gpios from an non-sleeping context will be caught by the
might_sleep_if check. Is there something I am missing about this?
I can prepare a patch which combines the non-sleeping and sleeping
variants, but I wanted to check that I'm not missing something
fundamental first.
Thanks,
~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: linux kernel <linux-kernel@vger.kernel.org>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"David Brownell" <dbrownell@users.sourceforge.net>,
gregkh@suse.de,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
ext-jani.1.nikula@nokia.com
Subject: gpiolib and sleeping gpios
Date: Fri, 18 Jun 2010 09:47:59 +1200 [thread overview]
Message-ID: <4C1A980F.8080908@bluewatersys.com> (raw)
Hi,
Currently implementors of gpiolib must provide implementations for
gpio_get_value, gpio_set_value and gpio_cansleep. Most of the
implementations just #define these to the double underscore prefixed
versions in drivers/gpio/gpiolib.c. A few implementations have a simple
wrapper function which provides a fast path for the SoC gpios, and calls
gpiolib for the any additional gpios, such as those added by an io expander.
Although gpio_chips know whether or not they may sleep, gpios which can
sleep need to call gpio_[set/get]_value_cansleep. The only difference
between __gpio_(set/get)_value and gpio_(set/get)_value_cansleep is that
the cansleep versions calls might_sleep_if. Most drivers call
gpio_(get/set)_value, rather than the cansleep variants. I haven't done
a full audit of all of the drivers (which is a reasonably involved
task), but I would hazard a guess that some of these could be replaced
by the cansleep versions.
Would it not be simpler to combine the calls and have something like this:
void __gpio_get_value(unsigned gpio, int value)
{
struct gpio_chip *chip;
chip = gpio_to_chip(gpio);
might_sleep_if(extra_checks && chip->can_sleep);
chip->set(chip, gpio - chip->base, value);
}
Then all drivers can just call gpio_(set/get)_value and any attempts to
use sleeping gpios from an non-sleeping context will be caught by the
might_sleep_if check. Is there something I am missing about this?
I can prepare a patch which combines the non-sleeping and sleeping
variants, but I wanted to check that I'm not missing something
fundamental first.
Thanks,
~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 reply other threads:[~2010-06-17 21:47 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-17 21:47 Ryan Mallon [this message]
2010-06-17 21:47 ` gpiolib and sleeping gpios 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
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=4C1A980F.8080908@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.