* AnilKumar, Chimata <anilku...@ti.com> [121003 03:53]: > On Tue, Oct 02, 2012 at 01:29:37, Linus Walleij wrote: > > On Mon, Oct 1, 2012 at 5:44 PM, Tony Lindgren <t...@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.
Yes those make sense from the generic leds-gpio point of view for the platforms that implement pinctrl. > > > 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 > .... Yes those can be implemented, but the problem will always be that the driver will not know if the board is using external pulls. If you implement the board specific settings in the .dts file for default, enabled and idle, the leds-gpio does not need to care if the pull is internal or external. So that seems like a more generic way to do it. > 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 Hmm no, you want to implement named modes that make sense from the client driver point of view. It seems that default, enabled and idle should do here? Then for the enabled mode you can set the LED specific pins to whatever pull mode you want for the board, and then leds-gpio does the rest using the gpio framework. > This 1, 2 and 2.a or named modes are required to implement > pinctrl_gpio_direction_input/output and > pinctrl_request/free_gpio. I would just add the named modes to leds-gpio because 2a does not work for the case where you use external pulls. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
