Re: Pin control mappings for DT

* Linus Walleij [off-list ref] [111130 05:00]:

On Tue, Nov 29, 2011 at 6:55 PM, Stephen Warren [off-list ref] wrote:

quoted

Linus Walleij wrote at Tuesday, November 29, 2011 12:42 AM:

quoted

quoted

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
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss