[PATCH] GPIOLIB: add generic gpio_set_pull API

Linus Walleij linus.walleij at linaro.org
Tue Aug 9 06:04:06 EDT 2011


On Mon, Aug 8, 2011 at 8:24 PM, Grant Likely <grant.likely at secretlab.ca> wrote:
> On Mon, Aug 8, 2011 at 2:15 AM, Paul Mundt <lethal at 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 at 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



More information about the linux-arm-kernel mailing list