Re: [RFC v2 3/3] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap36xx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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
> 





[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux