On Tue, Oct 02, 2012 at 01:29:37, Linus Walleij wrote: > On Mon, Oct 1, 2012 at 5:44 PM, Tony Lindgren <tony@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
