Am 06.09.2019 um 19:08 schrieb H. Nikolaus Schaller hns@goldelico.com:
Hi Tony,
Am 06.09.2019 um 17:47 schrieb Tony Lindgren tony@atomide.com:
- H. Nikolaus Schaller hns@goldelico.com [190906 07:53]:
Am 05.09.2019 um 16:27 schrieb Tony Lindgren tony@atomide.com: compatible = "ti,omap3-ldp", "ti,omap3430", "ti,omap34xx", "ti,omap3";
After thinking a little about the whole topic the main rule of this change must be:
do not break any existing in-tree DTS => only *add* to compatible what we need to distinguish between omap34 and omap36
additions shall only follow new scheme => we only add "ti,omap34xx" or "ti,omap36xx" but neither "ti,omap3630" nor "ti,omap3430"
Sorry I don't follow you on this one.. We should always add "ti,omap3630" where "ti,omap36xx" is currently used so we can eventually get rid of "ti,omap36xx". And the same for 34xx.
Ah, ok now I see.
You want to make the "ti,omap3630" the official one and "ti,omap36xx" legacy. It is probably an arbitrary choice if we want to get rid of the xx or the 30.
I had thought to do it the other way round because I had done this statistics:
for i in 3430 34xx 3630 36xx; do echo $i $(fgrep '"'ti,omap$i'"' arch/arm/boot/dts/*.dts* | wc -l); done
3430 12 34xx 28 3630 3 36xx 23
sorry, here is the correct result. I had some .bak files sitting around:
3430 12 34xx 5 3630 3 36xx 23
which would indicate that 34xx and 36xx are more common.
- cover some out-of-tree DTS => make the ti-cpufreq driver still match "ti,omap3430" or "ti,omap3630" even if this duplicates compatibility
This would mean that the logicpd-som-lv-37xx-devkit.dts gets the additional "ti,omap36xx" while the omap3-ldp.dts would only get an "ti,omap34xx" but no "ti,omap3430" (since we do not use it anywhere).
Could you agree on this approach?
Yeah sounds like logicpd-som-lv-37xx-devkit.dts currently still needs "ti,omap36xx" for now.
If modifying omap3-ldp.dts, also add "ti,omap3430" in additon to "ti,omap34xx" that it already has.
So basically let's assume the following:
"ti,omap3430" == "ti,omap34xx" "ti,omap3630" == "ti,omap36xx"
This means code needs to parse both.
Yes, it already does everywhere.
BTW there is also some code that does special SoC detection based on soc_device_match(), mainly in omapdrm/dss.
If we were to use this mechanism in the ti-cpufreq driver we could match it to ti,omap3 and could avoid all these changes.
But make it less maintainable and code more complex.
And eventually we just drop the "xx" variants.
So while patching compatibles, let's also update for this to avoid multiple patches churning the same compatibles over and over.
Ok. I'll rework the patch so that we never add "ti,34xx" or "ti,36xx" but add "ti,3430" or "ti,3630" if missing.
I'll also take a look at omap.txt bindings since that likely needs an update as well to better describe what the official ones are and which are legacy.
BR and thanks, Nikolaus