From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: linuxppc-dev@ozlabs.org
Cc: David Brownell <david-b@pacbell.net>
Subject: [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine
Date: Sun, 3 Feb 2008 20:10:06 +0300 [thread overview]
Message-ID: <20080203171006.GD28024@localhost.localdomain> (raw)
In-Reply-To: <20080203170820.GA18520@localhost.localdomain>
This routine sets dedicated functions of the GPIO pin.
---
Hello David,
Yes, I did read Documentation/gpio.txt's last chapter. :-)
...that says:
One of the biggest things these conventions omit is pin multiplexing,
since this is highly chip-specific and nonportable.
Let me counter: "chip-specific" is a weak argument, IMO. Imagine some
GPIO controller that can't do inputs, or outputs. First one will be
still suitable for gpio_leds, second one will be suitable for gpio_keys.
Or... gpio_to_irq/irq_to_gpio. More than chip-specific, isn't it?
Some GPIO controllers might provide interrupt sources, some might
not.
Or let's put it completely different way: IRQs, they are
chip specific too, some of them can't do EDGE_FALLING or
EDGE_RISING. But these flags still exists for the IRQs,
and drivers use them.
The same for GPIO pin multiplexing: some drivers aren't aware of
GPIO multiplexing, but some are.
With the device tree/OpenFirmware environment it's quite easy
to pass "dedicated functions" flags to the drivers. Platform device
drivers also may accept functions via platform data (or better yet
via IORESOURCE_GPIO and its flags -- yet to be implemented, of course).
Today, there is a driver for the Freescale USB Host Controller, that
needs switching some pins to GPIOs for short period, and then back to
the dedicated functions...
So, down below is the proposal patch: gpio_set_dedicated() routine.
There are other options, tough. But I don't like them:
- Don't use GPIO API for that driver. Bad idea, this driver
completely fits in the current GPIO use cases, except
set_dedicated()...
- Export "gpio_chips", thus we can implement arch-specific functions.
Bad idea, we'll smear "GPIO LIB" across the whole kernel.
- Implement gpio_chip->free() and gpio_chip->request() callbacks,
so controllers could restore pin's functions in the ->free().
Then drivers could do:
gpio_request();
gpio_direction_...();
...do some GPIO work...
gpio_free(); /* and controller will restore dedicated function */
Well, this is viable option. But expensive and it isn't good
idea to release gpios when driver already probed (think someone
might request it meantime). Still viable for my case, though.
Oh, there is no way to pass "func" argument also.
- Another option?
Thanks!
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/gpio/gpiolib.c | 13 +++++++++++++
include/asm-generic/gpio.h | 3 +++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d8db2f8..de6e765 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -440,6 +440,19 @@ void gpio_set_value_cansleep(unsigned gpio, int value)
}
EXPORT_SYMBOL_GPL(gpio_set_value_cansleep);
+int gpio_set_dedicated(unsigned gpio, int func)
+{
+ struct gpio_chip *chip;
+
+ might_sleep_if(extra_checks);
+ chip = gpio_to_chip(gpio);
+ if (chip->set_dedicated)
+ return chip->set_dedicated(chip, gpio - chip->base, func);
+
+ return -ENOSYS;
+}
+EXPORT_SYMBOL_GPL(gpio_set_dedicated);
+
#ifdef CONFIG_DEBUG_FS
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 806b86c..cfbeea8 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -61,6 +61,8 @@ struct gpio_chip {
unsigned offset, int value);
void (*set)(struct gpio_chip *chip,
unsigned offset, int value);
+ int (*set_dedicated)(struct gpio_chip *chip,
+ unsigned offset, int func);
void (*dbg_show)(struct seq_file *s,
struct gpio_chip *chip);
int base;
@@ -88,6 +90,7 @@ extern int gpio_direction_output(unsigned gpio, int value);
extern int gpio_get_value_cansleep(unsigned gpio);
extern void gpio_set_value_cansleep(unsigned gpio, int value);
+extern int gpio_set_dedicated(unsigned gpio, int func);
/* A platform's <asm/gpio.h> code may want to inline the I/O calls when
* the GPIO is constant and refers to some always-present controller,
--
1.5.2.2
next prev parent reply other threads:[~2008-02-03 17:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-03 17:08 [RFC PATCH 0/11] Patches needed to support QE USB Host Controller Anton Vorontsov
2008-02-03 17:09 ` [PATCH 01/11] [POWERPC] Implement support for the GPIO LIB API Anton Vorontsov
2008-02-03 21:17 ` David Brownell
2008-02-04 13:19 ` Anton Vorontsov
2008-02-03 17:09 ` [PATCH 02/11] [POWERPC] QE: split par_io_config_pin() Anton Vorontsov
2008-02-03 17:10 ` [PATCH 03/11] [POWERPC] QE: implement GPIO LIB API Anton Vorontsov
2008-02-03 17:10 ` Anton Vorontsov [this message]
2008-02-03 21:22 ` [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine David Brownell
2008-02-03 23:32 ` Anton Vorontsov
2008-02-15 4:36 ` David Brownell
2008-02-15 11:40 ` Anton Vorontsov
2008-02-29 20:55 ` Anton Vorontsov
2008-02-03 17:10 ` [PATCH 05/11] [POWERPC] qe_lib: support for gpio_set_dedicated Anton Vorontsov
2008-02-04 17:38 ` Timur Tabi
2008-02-03 17:10 ` [PATCH 06/11] [POWERPC] qe_lib: implement qe_muram_offset Anton Vorontsov
2008-02-03 17:10 ` [PATCH 07/11] [POWERPC] qe_lib: export qe_get_brg_clk Anton Vorontsov
2008-02-03 17:10 ` [PATCH 08/11] [POWERPC] qe_lib: implement QE GTM support Anton Vorontsov
2008-02-04 20:30 ` Scott Wood
2008-02-04 20:56 ` Anton Vorontsov
2008-02-03 17:10 ` [PATCH 09/11] [POWERPC] qe_lib: add support for QE USB Anton Vorontsov
2008-02-03 17:10 ` [PATCH 10/11] [POWERPC] mpc8360erdk: add FHCI USB support Anton Vorontsov
2008-02-03 17:11 ` [PATCH 11/11] [RFC USB POWERPC] Freescale QUICC Engine USB Host Controller Anton Vorontsov
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=20080203171006.GD28024@localhost.localdomain \
--to=avorontsov@ru.mvista.com \
--cc=david-b@pacbell.net \
--cc=linuxppc-dev@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).