Pin control mappings for DT

[Tony Lindgren]

* Stephen Warren <swarren at nvidia.com> [111130 09:10]:
> 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?

It's the same IP block used across omap2/3/4 where the register can be
hooked to a different logical function within the SoC. So the differences
can be quite big.
 
> 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.

Yes we are using the die internal signal names. So for example, omap3
has the following die pad options for uart3 rx:

mux_register.mux_function	balls depending on the package
uart3_rx_irrx.uart3_rx_irrx	h24, b24 or h20
dss_data4.uart3_rx_irrx		ad23, ad21 or ag24
dss_data8.uart3_rx_irrx		h24, e24 or f27
hsusb0_data1.uart3_rx_irrx	y20, t23 or u28

So for selecting the function, the ball name does not matter.

> 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.

Yes we have currently 4 completely different supersets, then the rest 5
are diffs to these, usually subsets, but can have new functions added too.

Regards,

Tony