* Thomas Abraham [off-list ref] [120120 16:45]:

On 20 January 2012 15:35, Tony Lindgren [off-list ref] wrote:

quoted

* Thomas Abraham [off-list ref] [120119 10:05]:

quoted

On 19 January 2012 23:50, Tony Lindgren [off-list ref] 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