On Tue, Oct 02, 2012 at 01:29:37, Linus Walleij wrote:

On Mon, Oct 1, 2012 at 5:44 PM, Tony Lindgren [off-list ref] wrote:

quoted

quoted

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.

quoted

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