Thread (49 messages) flat view 49 messages, 5 authors, 2012-02-13

Re: Pinmux bindings proposal V2

From: Shawn Guo <hidden>
Date: 2012-01-31 00:54:58
Also in: linux-arm-kernel, lkml

On Mon, Jan 30, 2012 at 09:43:23AM -0800, Tony Lindgren wrote:
* Shawn Guo [off-list ref] [120129 17:27]:
quoted
On Fri, Jan 27, 2012 at 09:16:53AM -0800, Tony Lindgren wrote:
...
quoted
I guess the analog we should follow here is clk_get and clk_set_rate,
except we would have pinconf_set_state with predefined states.
It seems working for cases that we only change pinconf but never pinmux
for different configuration states.  But how would that work for cases
that require mux change for different configuration states?
I don't see why we should not allow changing the mux state with pinconf
too, after all it's the mux/pin that's locked, not the functionality of
the pin.
My point is I do not see how we can use the current pinmux APIs design
to change mux in the way how clk_get and clk_set_rate work.  Or you
have a pinmux APIs reconstruction on your mind?

Regards,
Shawn
An example of this would be remuxing a shared UART line between rx and
tx. Those kind of cases could be defined as PMX_DIRECTION_INPUT and
PMX_DIRECTION_OUTPUT so driver could call Linux generic functions for
those if implemented.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help