On Mon, Jan 30, 2012 at 09:43:23AM -0800, Tony Lindgren wrote: > * Shawn Guo <[email protected]> [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. > _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
