Re: [RFC 1/3] pinctrl: add a driver for NVIDIA Tegra

[Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>]

* Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> [111209 08:56]:
> Linus Walleij wrote at Friday, December 09, 2011 7:01 AM:
> > 
> > What we could worry about is the amount of hard-coded chip data
> > which sort of correlates with the discussion with Tony on how to
> > provide DT info for pin control drivers.
> 
> My thinking here is that irrespective of whether the data in future chips
> is the same or different to the current chips, it's better in the driver.
> 
> For a given SoC, the data is static; it can never ever change.
> 
> Hence, there's no point parsing it from device tree; we end up with exactly
> the same data in the driver, yet have spent a bunch of time parsing it out
> from device tree instead of just embedding it into the kernel binary.
> 
> If parts of Tegra X and Tegra Y are similar, it should be possible to have
> them co-ordinate together and share the common data, and do whatever it
> takes to create the appropriate completed view before passing it back from
> tegraX_pinctrl_init() to the core. You could perhaps do it using /include/
> in the .dtsi file too, but I think allowing the SoC init code to unify the
> tables gives more flexibility; in your example below of the same data with
> different pin names, that'd be implementable with code without too much
> difficulty, but probably impossible with dtc since it has no macro/define
> support at present.
> 
> Also, the representation of the data in a .c file will likely be far
> smaller than in the .dtsi file, so this way saves space. Admittedly with
> a multi-SoC binary, you end up with all the large per-SoC data in the
> binary initially, so the space-savings aren't exactly seen, but it's
> all init data, so does get dumped soon after boot.
> 
> Another point here: I don't have to maintain a DT binding for the Tegra
> pinctrl driver this way, so if the next Tegra's pinmux HW is different,
> all I need to do is edit the driver, not be shackled by a need to keep
> the DT binding for it backwards-compatible. Although that said, I
> /think/ even an obvious DT binding derived from struct
> tegra_pinctrl_soc_data would be flexible enough for most things, perhaps
> with the addition of allowing config param field definitions for pins
> as well as groups.

What you're describing should be supported for sure.

IMHO the key issue here from pinctrl fwk point of view is: We want to
allow multiple data sources for describing the pinmux functions.

The data sources supported should be any combination of static platform_data,
DT data, loadable modules, and /lib/firmware. Then it's just a question of
using the most suitable method for each SoC.

Regards,

Tony