[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4BC39938-D63E-4BDC-BA28-5132F77F602D@goldelico.com>
Date: Fri, 6 Sep 2019 09:53:01 +0200
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Tony Lindgren <tony@...mide.com>,
Viresh Kumar <viresh.kumar@...aro.org>
Cc: Benoît Cousson <bcousson@...libre.com>,
Rob Herring <robh+dt@...nel.org>,
Adam Ford <aford173@...il.com>,
André Roth <neolynx@...il.com>,
Mark Rutland <mark.rutland@....com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Linux-OMAP <linux-omap@...r.kernel.org>,
devicetree <devicetree@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-pm@...r.kernel.org,
Discussions about the Letux Kernel
<letux-kernel@...nphoenux.org>, kernel@...a-handheld.com
Subject: Re: [RFC v2 3/3] ARM: dts: omap3: bulk convert compatible to be explicitly ti,omap3430 or ti,omap36xx
Hi,
I am preparing the next PATCH version now. Incl. updating the commit
messages to carry more documentation about the opp-supported-hw bit
definitions.
So please do not merge yet.
> Am 05.09.2019 um 16:27 schrieb Tony Lindgren <tony@...mide.com>:
>
> Hi,
>
> * H. Nikolaus Schaller <hns@...delico.com> [190904 08:54]:
>> According to omap.txt bindings documentation, matching the ti-cpufreq driver needs
>> to specify explicitly if a board uses an omap3430 or omap36xx chip.
>>
>> This needs to add ti,omap3430 to most omap34xx boards and replace ti,omap3630
>> by ti,omap36xx for some omap36xx boards (most others already have done it right).
>>
>> We also clean up some instances of missing ti,am3517 so that we can rely on
>> seeing either one of:
>>
>> ti,am3517
>> ti,omap34xx
>> ti,omap36xx
>>
>> in addition to ti,omap3.
>
> Please set up things to use ti,omap3630 in addition to ti,omap36xx
> for compatible to avoid churning the same files later.
>
>> diff --git a/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts b/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
>> --- a/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
>> +++ b/arch/arm/boot/dts/logicpd-som-lv-37xx-devkit.dts
>> @@ -9,5 +9,5 @@
>>
>> / {
>> model = "LogicPD Zoom DM3730 SOM-LV Development Kit";
>> - compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3630", "ti,omap3";
>> + compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap36xx", "ti,omap3";
>> };
>
> So just make this:
>
> compatible = "logicpd,dm3730-som-lv-devkit", "ti,omap3630", "ti,omap36xx", "ti,omap3";
Do we really need both? The clock driver already checks for both variants and the
ti-cpufreq will as well. So it suffices to have either "ti,omap3630" or "ti,omap36xx".
But yes, there may be user-space code that reads sysfs. So we should keep the
"ti,omap3630" and add "ti,omap36xx".
>
> And so on. It's fine to use ti,omap3630 for 37xx too as they're the same.
>
>> diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
>> index 9a5fde2d9bce..9947574bd0f8 100644
>> --- a/arch/arm/boot/dts/omap3-ldp.dts
>> +++ b/arch/arm/boot/dts/omap3-ldp.dts
>> @@ -10,7 +10,7 @@
>>
>> / {
>> model = "TI OMAP3430 LDP (Zoom1 Labrador)";
>> - compatible = "ti,omap3-ldp", "ti,omap3";
>> + compatible = "ti,omap3-ldp", "ti,omap34xx, "ti,omap3";
>
> This fails to compile, it's missing a '"' for ti,omap34xx. And here too,
> please update to use:
Ah yes. I missed that (and my build script did not build all DTB).
>
> 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"
* 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?
>
> And again it's fine to add "ti,omap3430" for 3530 variants.
Yes, sure.
BR,
Nikolaus
Powered by blists - more mailing lists