> Am 06.09.2019 um 19:08 schrieb H. Nikolaus Schaller <hns@xxxxxxxxxxxxx>: > > Hi Tony, > >> Am 06.09.2019 um 17:47 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: >> >> * H. Nikolaus Schaller <hns@xxxxxxxxxxxxx> [190906 07:53]: >>>> Am 05.09.2019 um 16:27 schrieb Tony Lindgren <tony@xxxxxxxxxxx>: >>>> 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 >
