Messages in this thread |  | | Date | Tue, 31 Jan 2012 09:07:11 +0800 | From | Shawn Guo <> | Subject | Re: Pinmux bindings proposal V2 |
| |
On Mon, Jan 30, 2012 at 09:43:23AM -0800, Tony Lindgren wrote: > * Shawn Guo <shawn.guo@linaro.org> [120129 17:27]: > > On Fri, Jan 27, 2012 at 09:16:53AM -0800, Tony Lindgren wrote: > > ... > > > 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. >
|  |