* Stephen Warren <[email protected]> [111130 09:10]: > 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?
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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
