Pin control mappings for DT

[Tony Lindgren]

* Linus Walleij <linus.walleij at linaro.org> [111130 05:00]:
> On Tue, Nov 29, 2011 at 6:55 PM, Stephen Warren <swarren at nvidia.com> wrote:
> > Linus Walleij wrote at Tuesday, November 29, 2011 12:42 AM:
> 
> >> 1) Per-driver info, includes the pin controller base, its pins, their
> >>  (optional) names and their specific presets like bias etc.
> >
> > I'm still planning on putting this all into the driver source code; I
> > don't really see any advantage of putting this almost static data into
> > DT just to parse it back out into the same tables that could be written
> > straight into the driver anyway. (only almost static rather than static
> > since we'll need new tables for each SoC)
> 
> I think OMAP already have a few different SoCs using the same
> pinmux HW block, so for them it makes more sense.
> 
> Maybe when you have your Tegra 7 chips using the same
> controller as Tegra { 3, 4, 5, 6 } with yet another pin list
> it will make sense :-)
> 
> Besides - doing it one way does not exclude the other.

Yeah we should be pretty easily able to support any combination
of the following data sources:

- Static maps passed from board/machine
- Mux data being loaded dynamically from loadable pinmux modules
- Mux data and maps being loaded dynamically from DT
 
> If the tables gets large I will have Torvalds on my tail for
> putting nonsensical lists into the kernel that'd better been
> kept outside it.

Yeah the problem is that data will just grow and grow because
packages change with shrinkage and need to support non-POP and
POP chips. So no matter where you stuff this data, the amount
of if will just grow. Passing the mux data from DT has the
advantage of only passing only one single instance of hopefully
correct data.

So probably some combination of static data, loading data from
loadable modules, and passing some from DT will be the optimal
solution.

Regards,

Tony