Tony Lindgren wrote at Wednesday, November 30, 2011 9:54 AM: > * Linus Walleij <[email protected]> [111130 06:39]: > > On Tue, Nov 29, 2011 at 8:59 PM, Tony Lindgren <[email protected]> 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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
