More pinmux feedback, and GPIO vs. pinmux interaction
Stephen Warren
swarren at nvidia.com
Wed Jun 15 17:48:02 EDT 2011
Linus (W),
Some more thoughts on pinmux:
========== GPIO/pinmux API interactions
I'd like to understand how the gpio and pinmux subsystems are intended
to interact.
Quoting from Documentation/gpio.txt:
Note that requesting a GPIO does NOT cause it to be configured in any
way; it just marks that GPIO as in use. Separate code must handle any
pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown).
Due to this, the current Tegra GPIO driver contains additional non-
standard functions:
void tegra_gpio_enable(int gpio);
void tegra_gpio_disable(int gpio);
In some cases, those functions are called by board files at boot time,
and in other cases by drivers themselves, right before gpio_request().
Is it your intention that such custom functions be replaced by
pinmux_request_gpio(), and the Tegra pinmux driver's gpio_request_enable
op should call tegra_gpio_enable?
That seems like the right idea to me.
========== pinmux calling GPIO or vice-versa?
Having pinmux call gpio appears to conflict with a couple of things from
your recent pinmux patchset:
> diff --git a/drivers/Kconfig b/drivers/Kconfig
> +# pinctrl before gpio - gpio drivers may need it
> +
> +source "drivers/pinctrl/Kconfig"
> +
> source "drivers/gpio/Kconfig"
>
> diff --git a/drivers/Makefile b/drivers/Makefile
>...
> +# GPIO must come after pinctrl as gpios may need to mux pins etc
> +obj-y += pinctrl/
Don't those patches imply that the GPIO controller code is calling into
the pinmux code to perform muxing, not the other way around?
========== When pins get marked as in-used
There seems to be a discrepancy in the way the client APIs work: For
special functions, the client calls pinmux_get, then later pinmux_enable,
whereas for GPIOs, the client just calls pinmux_request_gpio. I'm not
sure of the benefit of having separate pinmux_get and pinmux_enable
calls; I thought the idea was that a client could:
a = pinmux_get(dev, "funca");
b = pinmux_get(dev, "funcb");
pinmux_enable(a);
...
pinmux_disable(a);
pinmux_enable(b);
...
pinmux_disable(b);
pinmux_put(b);
pinmux_put(a);
However, since the pins are marked as reserved/in-use when pinmux_get
is called rather than pinmux_enable, the code above won't work; it'd
need to be:
a = pinmux_get(dev, "funca");
pinmux_enable(a);
...
pinmux_disable(a);
pinmux_put(a);
b = pinmux_get(dev, "funcb");
pinmux_enable(b);
...
pinmux_disable(b);
pinmux_put(b);
Perhaps pin usage marking should be moved into enable/disable?
========== Matched request/free calls for GPIOs
A couple more comments on your recent pinmux patches in light of this:
More information about the linux-arm-kernel
mailing list