[PATCH v2] leds: leds-gpio: adopt pinctrl support
AnilKumar, Chimata
anilkumar at ti.com
Wed Oct 3 06:52:32 EDT 2012
On Tue, Oct 02, 2012 at 01:29:37, Linus Walleij wrote:
> On Mon, Oct 1, 2012 at 5:44 PM, Tony Lindgren <tony at atomide.com> wrote:
>
> >> OK that is typical pinctrl driver implementation work.
> >> I hope Tony can advice on this?
> >
> > I think we're best off to just stick to alternative named modes
> > passed from device tree. For example, for GPIO wake-ups you can
> > have named modes such as "default", "enabled" and "idle" where
> > "idle" muxes things for GPIO wake-ups for the duration of idle.
> >
In this case we need to add three different values according
to three modes (default, enabled, idle) and for each node.
> > It seems that should also work for leds-gpio. And you can
> > define more named modes as needed.
If we want to implement pinctrl_gpio functionality we have to
separate "function-mask" bits to
1. pinmux-mask
2. pinconf-mask, to make it generic we need following bit masks
a. receiver enable/disable bit
b. slew rate fast/slow bit
c. pull-up/down bit
....
I have gone through nvidia pinctrl dt data (tegra20-seaboard.dts,
node drive_sdio1) which has different pinconfig values, those
are mapping to pinconf values.
With the above bit masks and function-mask we can identify
pull-up/down, slow/high speed slew rate and direction in/out.
(or)
Named modes:-
Are you saying named modes like this?
default-input-up
default-input-down
default-output-up
default-output-down
This 1, 2 and 2.a or named modes are required to implement
pinctrl_gpio_direction_input/output and
pinctrl_request/free_gpio.
>
>
> This is what we're doing for ux500 and should be a good model.
I have looked into this, but not seen any named modes.
Thanks
AnilKumar
More information about the linux-arm-kernel
mailing list