[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <98AF4586-C6FF-43A5-99B9-797145F50D07@goldelico.com>
Date: Tue, 3 Sep 2019 08:34:50 +0200
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Benoît Cousson <bcousson@...libre.com>,
Tony Lindgren <tony@...mide.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@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
letux-kernel@...nphoenux.org, kernel@...a-handheld.com
Subject: Re: [RFC 4/5] ARM: dts: omap3-n950-n9: remove opp-v1 table
> Am 03.09.2019 um 08:28 schrieb Viresh Kumar <viresh.kumar@...aro.org>:
>
> On 03-09-19, 08:23, H. Nikolaus Schaller wrote:
>>
>>> Am 03.09.2019 um 08:14 schrieb Viresh Kumar <viresh.kumar@...aro.org>:
>>>
>>> On 03-09-19, 08:01, H. Nikolaus Schaller wrote:
>>>>
>>>>> Am 03.09.2019 um 04:36 schrieb Viresh Kumar <viresh.kumar@...aro.org>:
>>>>>
>>>>> On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
>>>>>> With opp-v2 in omap36xx.dtsi and ti-cpufreq driver the
>>>>>> 1GHz capability is automatically detected.
>>>>>>
>>>>>> Signed-off-by: H. Nikolaus Schaller <hns@...delico.com>
>>>>>> ---
>>>>>> arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 -------
>>>>>> 1 file changed, 7 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi b/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>>>> index 5441e9ffdbb4..e98b0c615f19 100644
>>>>>> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>>>> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
>>>>>> @@ -11,13 +11,6 @@
>>>>>> cpus {
>>>>>> cpu@0 {
>>>>>> cpu0-supply = <&vcc>;
>>>>>> - operating-points = <
>>>>>> - /* kHz uV */
>>>>>> - 300000 1012500
>>>>>> - 600000 1200000
>>>>>> - 800000 1325000
>>>>>> - 1000000 1375000
>>>>>> - >;
>>>>>> };
>>>>>> };
>>>>>
>>>>> This should be merged with 2/5 ?
>>>>
>>>> Well, it bloats 2/5.
>>>
>>> It is logically the right place to do this as that's where we are
>>> adding opp-v2.
>>
>> Well, sometimes the philosophy of patches is to add something new
>> first and remove the old in a second separate patch if the system
>> can live with both. This makes it easier to digest single patches
>> (because they are smaller) and might also better pinpoint an issue
>> by bisect.
>
> Right, but you already removed some of the opp-v1 stuff in patch 2/5.
> Why leave this one out ?
>
>>>
>>>> What I hope (I can't test) is that this opp-v1 table
>>>> is ignored if an opp-v2 table exists. So that it can be
>>>> removed by a separate follow-up patch.
>>>
>>> It should work as that's what we are doing in OPP core, but I still
>>> feel this better get merged with 2/5.
>>
>> Ok, I see. Noted for RFCv2.
>>
>> There will also be a big batch of changes for the compatible record
>> (omap3530->omap35xx, add omap34xx where needed) of ca. 10 board definition
>> DTS files. Should this then also become part of the new 2/5?
>
> Compatible thing should be separate patch anyway, I was just talking
> about replacing opp-v1 with v2.
Ok, understood.
BR and thanks,
Nikolaus
Powered by blists - more mailing lists