Pinmux bindings proposal

[Tony Lindgren]

* Thomas Abraham <thomas.abraham at linaro.org> [120120 16:45]:
> On 20 January 2012 15:35, Tony Lindgren <tony at atomide.com> wrote:
> > * Thomas Abraham <thomas.abraham at linaro.org> [120119 10:05]:
> >> On 19 January 2012 23:50, Tony Lindgren <tony at atomide.com> wrote:
> >>
> >> I would like to understand the need for populating the
> >> pinmux/pingroups tables from dt. The question here is when we have
> >> something like
> >>
> >> pins = <&pinctrl0 0x0030 0x15 0x15 0x7>;
> >>
> >> which specifies the values that need to be written to the hardware
> >> registers, would populating pinmux/pingroup tables from dt required.
> >> The SoC specific pinctrl driver can provide a way (with the help of
> >> pinctrl core) to translate these values and write to corresponding
> >> hardware registers. Is there any particular reason for populating the
> >> pinmux/pingroups tables from dt?
> >
> > Hmm I see. Yes it's still needed as we only want to parse the DT once
> > because it's slower unless it was one time only configuration during
> > init.
> 
> Ok. The time spent on searching for the pin-config property can be
> reduced by having the device driver (say, i2c) keep a pointer to all
> the pinconfig properties in its node. The next time a driver needs to
> reconfigure the pins, the search time can be reduced. The time to
> parse the property values though would still be applicable. But I
> would still not opt to build pinmux/pinconfig/pindesc tables from dt.

Hmm that's something to consider to save memory as the node will stay
there. This would allow making all the pinctrl framework data __initdata
in some cases. You'd probably want to copy the data into the driver in
some pinctrl framework struct so you could still use pinctrl framework
functions with this data and not have to parse the node again.

For building the tables from dt, what I have currently is building
the tables without any specific knowledge about the pinmux functions.
I'm thinking that any further knowledge for debugging etc can be done
later on using user space tools to avoid storing the data in kernel.

Regards,

Tony