* Linus Walleij <[email protected]> [111130 05:00]: > On Tue, Nov 29, 2011 at 6:55 PM, Stephen Warren <[email protected]> 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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
