Pinmux bindings proposal V2

On Mon, Jan 30, 2012 at 09:20:42AM -0800, Tony Lindgren wrote:

* Shawn Guo [off-list ref] [120129 17:13]:

quoted

On Fri, Jan 27, 2012 at 09:05:45AM -0800, Tony Lindgren wrote:

...

quoted

quoted

Wouldn't it be cleaner to just clk_get esdhc_clk during init, then
do clk_set_rate on it to toggle the rates?
 

It's not an init-time switch but run-time one.  That said,
sdhci_ops.set_clock will be called during run-time.

Right, basically you don't want to do clk_get or pinmux_get during
runtime, you do that once one during init. Then do clk_set_rate or
whaterver during runtime.

Is there anything stopping from implementing sdhci_ops.set_rate
using clock framework and clk_set_rate in this case BTW?
 

We are doing this exactly for clk, and trying to figure out how to
handle pinctrl here.  I do not see how we can do pinmux_get at
init-time and pinmux_set_whatever at run-time.  The pinmux API does
not work that way.

quoted

quoted

quoted

quoted

So I'd rather stay out of random named states for
the pins coming from device tree; If we still need them, they should
be common bindings rather than things like "xyz_clock_hack".

The binding defines the syntax, and I do not see the necessity to
force the particular state name, which is really pinctrl client
device specific.

Do you have some other custom pin state example other than the
clock rate change example above?

I have another case PM related.  To aggressively save power, the pins
configured for particular function during active mode need to be
muxed on gpio mode and output 0 in low-power mode.

OK, but basically only a small subset of pins of the total pins?

Actually, all pins used by the block.

-- 
Regards,
Shawn