| Message ID | 1312780773-23142-1-git-send-email-Baohua.Song@csr.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Aug 07, 2011 at 10:19:33PM -0700, Barry Song wrote: > Now there are many different implementations for GPIO pull configuration, for > example: > s3c_gpio_setpull() > tegra_pinmux_set_pullupdown() > chipcHw_setPinPullup() > gpio_pullup() > s3c2410_gpio_pullup() > > This patch adds a new generic gpio_set_pull API so that all SoCs can have unified > codes. > > Signed-off-by: Barry Song <Baohua.Song@csr.com> For arch/arm/mach-shmobile we also have gpio_pull_up() for board-g4evm.c and gpio_pull_down() for board-mackerel.c. Both of these would benefit from this sort of an API addition.
On Mon, Aug 8, 2011 at 2:15 AM, Paul Mundt <lethal@linux-sh.org> wrote: > On Sun, Aug 07, 2011 at 10:19:33PM -0700, Barry Song wrote: >> Now there are many different implementations for GPIO pull configuration, for >> example: >> s3c_gpio_setpull() >> tegra_pinmux_set_pullupdown() >> chipcHw_setPinPullup() >> gpio_pullup() >> s3c2410_gpio_pullup() >> >> This patch adds a new generic gpio_set_pull API so that all SoCs can have unified >> codes. >> >> Signed-off-by: Barry Song <Baohua.Song@csr.com> > > For arch/arm/mach-shmobile we also have gpio_pull_up() for board-g4evm.c > and gpio_pull_down() for board-mackerel.c. Both of these would benefit > from this sort of an API addition. I think I'm okay with this API change. Linus, what say you? How does this interact with your plans for pinctrl? g.
On Tue, Aug 9, 2011 at 3:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote: > On Mon, Aug 8, 2011 at 2:15 AM, Paul Mundt <lethal@linux-sh.org> wrote: >> On Sun, Aug 07, 2011 at 10:19:33PM -0700, Barry Song wrote: >>> Now there are many different implementations for GPIO pull configuration, for >>> example: >>> s3c_gpio_setpull() >>> tegra_pinmux_set_pullupdown() >>> chipcHw_setPinPullup() >>> gpio_pullup() >>> s3c2410_gpio_pullup() >>> >>> This patch adds a new generic gpio_set_pull API so that all SoCs can have unified >>> codes. >>> >>> Signed-off-by: Barry Song <Baohua.Song@csr.com> >> >> For arch/arm/mach-shmobile we also have gpio_pull_up() for board-g4evm.c >> and gpio_pull_down() for board-mackerel.c. Both of these would benefit >> from this sort of an API addition. > > I think I'm okay with this API change. Linus, what say you? How does > this interact with your plans for pinctrl? If gpiolib accept the pullup control. gpiolib is better place to control gpio config. then remains are the gpio driver strength, and power down mode control. powerdown pull-up/down, powerdown in/out at samsung gpios. Thank you, Kyungmin Park > > g. > > -- > Grant Likely, B.Sc., P.Eng. > Secret Lab Technologies Ltd. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >
On 8/8/2011 3:57 PM, Kyungmin Park wrote: > On Tue, Aug 9, 2011 at 3:24 AM, Grant Likely<grant.likely@secretlab.ca> wrote: >> On Mon, Aug 8, 2011 at 2:15 AM, Paul Mundt<lethal@linux-sh.org> wrote: >>> On Sun, Aug 07, 2011 at 10:19:33PM -0700, Barry Song wrote: >>>> Now there are many different implementations for GPIO pull configuration, for >>>> example: >>>> s3c_gpio_setpull() >>>> tegra_pinmux_set_pullupdown() >>>> chipcHw_setPinPullup() >>>> gpio_pullup() >>>> s3c2410_gpio_pullup() >>>> >>>> This patch adds a new generic gpio_set_pull API so that all SoCs can have unified >>>> codes. >>>> >>>> Signed-off-by: Barry Song<Baohua.Song@csr.com> >>> For arch/arm/mach-shmobile we also have gpio_pull_up() for board-g4evm.c >>> and gpio_pull_down() for board-mackerel.c. Both of these would benefit >>> from this sort of an API addition. >> I think I'm okay with this API change. Linus, what say you? How does >> this interact with your plans for pinctrl? > If gpiolib accept the pullup control. gpiolib is better place to > control gpio config. > then remains are the gpio driver strength, and power down mode > control. powerdown pull-up/down, powerdown in/out at samsung gpios. If we add this API - the remaining gpio controls like drive strength and function select could also be added, which eats into the pinmux domain. Linus W. had a patch earlier which added an API for a gpio config to be specified through gpiolib. " gpio: add a custom configuration mechanism to gpiolib" which is sort of an extensible model of this API. Thanks, Rohit > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ Thanks, Rohit Vaswani
2011/8/9 Rohit Vaswani <rvaswani@codeaurora.org>: > On 8/8/2011 3:57 PM, Kyungmin Park wrote: >> >> On Tue, Aug 9, 2011 at 3:24 AM, Grant Likely<grant.likely@secretlab.ca> >> wrote: >>> >>> On Mon, Aug 8, 2011 at 2:15 AM, Paul Mundt<lethal@linux-sh.org> wrote: >>>> >>>> On Sun, Aug 07, 2011 at 10:19:33PM -0700, Barry Song wrote: >>>>> >>>>> Now there are many different implementations for GPIO pull >>>>> configuration, for >>>>> example: >>>>> s3c_gpio_setpull() >>>>> tegra_pinmux_set_pullupdown() >>>>> chipcHw_setPinPullup() >>>>> gpio_pullup() >>>>> s3c2410_gpio_pullup() >>>>> >>>>> This patch adds a new generic gpio_set_pull API so that all SoCs can >>>>> have unified >>>>> codes. >>>>> >>>>> Signed-off-by: Barry Song<Baohua.Song@csr.com> >>>> >>>> For arch/arm/mach-shmobile we also have gpio_pull_up() for board-g4evm.c >>>> and gpio_pull_down() for board-mackerel.c. Both of these would benefit >>>> from this sort of an API addition. >>> >>> I think I'm okay with this API change. Linus, what say you? How does >>> this interact with your plans for pinctrl? >> >> If gpiolib accept the pullup control. gpiolib is better place to >> control gpio config. >> then remains are the gpio driver strength, and power down mode >> control. powerdown pull-up/down, powerdown in/out at samsung gpios. > > If we add this API - the remaining gpio controls like drive strength and > function select could also be added, which eats into the pinmux domain. > Linus W. had a patch earlier which added an API for a gpio config to be > specified through gpiolib. " gpio: add a custom configuration mechanism to > gpiolib" which is sort of an extensible model of this API. gpio_config() from Linus W. is an interface with multiple functions or a function for multiple purpose. Its actions seem to be ambiguous, then mean diffiicult to use or diffirent subsystems still result in many differences after using it. pullup/down/none is something very common and much frequently used to all SoCs, i guess it can have individual, simple and direct API. I don't oppose gpiolib cover more GPIO configurations, for example OC, OD and powerdown. but we might keep APIs as simple and clear as possible. > > Thanks, > Rohit
On Mon, Aug 8, 2011 at 8:24 PM, Grant Likely <grant.likely@secretlab.ca> wrote: > On Mon, Aug 8, 2011 at 2:15 AM, Paul Mundt <lethal@linux-sh.org> wrote: >> On Sun, Aug 07, 2011 at 10:19:33PM -0700, Barry Song wrote: >>> Now there are many different implementations for GPIO pull configuration, for >>> example: >>> s3c_gpio_setpull() >>> tegra_pinmux_set_pullupdown() >>> chipcHw_setPinPullup() >>> gpio_pullup() >>> s3c2410_gpio_pullup() >>> >>> This patch adds a new generic gpio_set_pull API so that all SoCs can have unified >>> codes. >>> >>> Signed-off-by: Barry Song <Baohua.Song@csr.com> >> >> For arch/arm/mach-shmobile we also have gpio_pull_up() for board-g4evm.c >> and gpio_pull_down() for board-mackerel.c. Both of these would benefit >> from this sort of an API addition. > > I think I'm okay with this API change. Linus, what say you? How does > this interact with your plans for pinctrl? I have already proposed a similar mechanism in the past, so let's recap: 1.First I proposed to expose gpio_to_chip() so each driver could provide any custom functions using foo_gpio_set_foo() or so by dereferencing the struct gpio_chip. NIXED: due to bad experience with doing exactly this for IRQ chips (Grant) 2. Second I added a sort-of generic control function; gpio_config() which would sit in gpiolib and take an enum for each operation, if one of these would be GPIO_SET_PULL, and a second argument would be whether to pull it up or down or open collector or open drain or schmitt-trigger or whatever. As you see the problem is not limited to up/down. This is equal to the proposed patch but with two arguments and broader scope, can also be used for drive strength etc. 3. Alan Cox suggested that we use a more generic control function instead so I wrapped it to an ioctl()- like operation with an opaque argument instead. This is especially good when you need to pass data *out* of the function, not just *in*. 4. After talks with Grant I submitted (1) again. I'm basically happy with anything as long as there is some progress, right now we're only bikeshedding, so I'm, resting my case. Linus Walleij
On Tue, Aug 9, 2011 at 12:57 AM, Kyungmin Park <kmpark@infradead.org> wrote: > If gpiolib accept the pullup control. gpiolib is better place to > control gpio config. > then remains are the gpio driver strength, and power down mode > control. powerdown pull-up/down, powerdown in/out at samsung gpios. I agree. And this is what I need to move the U300 and Nomadik GPIO drivers over to struct gpio_chip. Yours, Linus Walleij
On Tue, Aug 9, 2011 at 3:45 AM, Rohit Vaswani <rvaswani@codeaurora.org> wrote: > If we add this API - the remaining gpio controls like drive strength and > function select could also be added, I agree. > which eats into the pinmux domain. That's not so bad, since the pinctrl/pinmux subsystem is just a prototype people may want to wrap up their drivers into gpio_chip/gpiolib as they stand today to atleast get some isolation. Later on they can refactor and migrate to a pinctrl/pinmux subsystem. The latter will take some time to provide anyway, since I have been asked to restructure it so as not to use a global pin number space. > Linus W. had a patch earlier which added an API for a gpio config to be > specified through gpiolib. " gpio: add a custom configuration mechanism to > gpiolib" which is sort of an extensible model of this API. Yes I think I have already suggested a bunch of ways to skin this cat but somehow none of them seem to win general approval. Yours, Linus Walleij
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index a971e3d..a2afa95 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1620,6 +1620,23 @@ int __gpio_to_irq(unsigned gpio) } EXPORT_SYMBOL_GPL(__gpio_to_irq); +/** + * __gpio_set_pull() - set pull up, pull down or no pull for a gpio + * @gpio: gpio which will be configurated + * @mode: one of GPIO_PULL_NONE, GPIO_PULL_UP and GPIO_PULL_DOWN + * Context: any + * + * This is used directly or indirectly to implement gpio_set_pull(). + */ +void __gpio_set_pull(unsigned gpio, unsigned mode) +{ + struct gpio_chip *chip; + + chip = gpio_to_chip(gpio); + + chip->pull(chip, gpio, mode); +} +EXPORT_SYMBOL_GPL(__gpio_set_pull); /* There's no value in making it easy to inline GPIO calls that may sleep. diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h index d494001..f953835 100644 --- a/include/asm-generic/gpio.h +++ b/include/asm-generic/gpio.h @@ -112,6 +112,9 @@ struct gpio_chip { int (*to_irq)(struct gpio_chip *chip, unsigned offset); + void (*pull)(struct gpio_chip *chip, + unsigned offset, unsigned mode); + void (*dbg_show)(struct seq_file *s, struct gpio_chip *chip); int base; diff --git a/include/linux/gpio.h b/include/linux/gpio.h index 17b5a0d..ac48166 100644 --- a/include/linux/gpio.h +++ b/include/linux/gpio.h @@ -14,6 +14,10 @@ #define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW) #define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH) +#define GPIO_PULL_NONE 0 +#define GPIO_PULL_UP 1 +#define GPIO_PULL_DOWN 2 + #ifdef CONFIG_GENERIC_GPIO #include <asm/gpio.h>
Now there are many different implementations for GPIO pull configuration, for example: s3c_gpio_setpull() tegra_pinmux_set_pullupdown() chipcHw_setPinPullup() gpio_pullup() s3c2410_gpio_pullup() This patch adds a new generic gpio_set_pull API so that all SoCs can have unified codes. Signed-off-by: Barry Song <Baohua.Song@csr.com> --- drivers/gpio/gpiolib.c | 17 +++++++++++++++++ include/asm-generic/gpio.h | 3 +++ include/linux/gpio.h | 4 ++++ 3 files changed, 24 insertions(+), 0 deletions(-)