Pin control mappings for DT

[Stephen Warren]

Tony Lindgren wrote at Wednesday, November 30, 2011 9:54 AM:
> * Linus Walleij <linus.walleij at linaro.org> [111130 06:39]:
> > On Tue, Nov 29, 2011 at 8:59 PM, Tony Lindgren <tony at atomide.com> wrote:
...
> Just to give some idea of the scope of problem it solves, we already
> have static data for 9 packages in arch/arm/mach-omap2/mux*4*.c with
> omap3 three alone having 4 packages.. Even with that being incremental
> data that's marked __initdata, it's still not a scalable way of doing
> things as there will be more and more packages.

Are these purely packaging options for the same silicon, such that any
pin ID in the pinmux controller always represents the same pad on the
die, it's just that some may not actually be bonded out to actual pins
or balls on the package (or some mux functions might select controllers
that are "not present" in the die)? Or, is this the same IP block used
in multiple SoCs, where the use of each pin ID in the pinmux controller,
and the meaning of each mux function value for each pin ID, are actually
hooked up to different logical functions within the SoC?

For the former case (pure bonding options), the pinctrl documentation
recommends having the pinctrl driver expose the die pads, rather than
the package pins/balls. That way, there's a pinctrl single data set that
works across all the n package variations. The only issue here is that
when constructing the pinctrl mapping table, you need to only actually
use pins/functions that are valid for the particular SoC you know you're
using, but that's true anyway irrespective of whether the pinctrl driver
actually defines the unusable options or not.

Tegra20 is in the same situation; there are at least 2 packaging options
for it. The Tegra20 pinctrl driver has been written with 1 dataset
representing what's on the die, rather than 2 datasets fully representing
which subsets actually make it out to the package.

-- 
nvpublic