[PATCH v2] leds: leds-gpio: adopt pinctrl support

AnilKumar, Chimata anilkumar at ti.com
Wed Oct 3 20:52:32 EST 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 devicetree-discuss mailing list