Pinmux bindings proposal V2
Tony Lindgren
tony at atomide.com
Fri Jan 27 12:42:32 EST 2012
* Stephen Warren <swarren at nvidia.com> [120127 09:05]:
> Tony Lindgren wrote at Thursday, January 26, 2012 7:09 PM:
> ...
> > I don't think we should try to pass the different possible states from
> > device tree. The pinmux/pinconf driver should know how to deal with that,
>
> Somehow, the pinctrl driver needs to know how to implement each state. In
> general, I believe this will be board-specific.
>
> Do you disagree with this assertion?
>
> If the data is board-specific, I don't see how it can be represented
> anywhere but the device tree.
Agreed, for board specific things device tree is the place to put it.
> > and the driver using the mux should be able to communicate what it wants
> > to the pinmux/pinconf driver. If people really want to be able to pass
> > alternative mux states from device tree, they should be standard bindings
> > for things like active/idle/suspend/off.
>
> As I've mentioned before, people have asked for driver-specific states to
> handle the case where e.g. drive strength must be adjusted based on clock
> rates of the interface. Again, I believe that's board-specific data since
> the actual values to use may be derived during board calibration, not
> SoC design.
>
> Do you disagree that this data may be board specific?
Right, but for the dynamic mux cases I've seen the alternative states
are usually specific to the driver using the mux. That's why I'm
suspicious of the board specific custom alternative states :)
Anyways, do you think the pinctrl-static + pinctrl-dynamic binding
I just posted as a reply to Simon's email would work for you?
Regards,
Tony
More information about the linux-arm-kernel
mailing list