From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Benoît Cousson" <bcousson@baylibre.com>,
"Tony Lindgren" <tony@atomide.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Adam Ford" <aford173@gmail.com>,
"André Roth" <neolynx@gmail.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
linux-omap@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
letux-kernel@openphoenux.org, kernel@pyra-handheld.com
Subject: Re: [RFC 4/5] ARM: dts: omap3-n950-n9: remove opp-v1 table
Date: Tue, 3 Sep 2019 08:23:51 +0200 [thread overview]
Message-ID: <6B7B0EDB-8A60-48A0-AFAB-8A266358300C@goldelico.com> (raw)
In-Reply-To: <20190903061403.k3d333f54gj2kuxi@vireshk-i7>
> Am 03.09.2019 um 08:14 schrieb Viresh Kumar <viresh.kumar@linaro.org>:
>
> On 03-09-19, 08:01, H. Nikolaus Schaller wrote:
>>
>>> Am 03.09.2019 um 04:36 schrieb Viresh Kumar <viresh.kumar@linaro.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@goldelico.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.
>
>> 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?
BR and thanks,
Nikolaus
next prev parent reply other threads:[~2019-09-03 6:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-02 10:55 [RFC 0/5] OMAP3: convert opp-v1 to opp-v2 and read speed binned / 720MHz grade bits H. Nikolaus Schaller
2019-09-02 10:55 ` [RFC 1/5] cpufreq: ti-cpufreq: add support for omap34xx and omap36xx H. Nikolaus Schaller
2019-09-02 10:55 ` [RFC 2/5] ARM: dts: add support for opp-v2 " H. Nikolaus Schaller
2019-09-03 2:38 ` Viresh Kumar
2019-09-03 2:39 ` Viresh Kumar
2019-09-03 5:58 ` H. Nikolaus Schaller
2019-09-02 10:55 ` [RFC 3/5] ARM: dts: omap3-evm-37xx: fix compatible from omap3630 to omap36xx H. Nikolaus Schaller
2019-09-02 10:55 ` [RFC 4/5] ARM: dts: omap3-n950-n9: remove opp-v1 table H. Nikolaus Schaller
2019-09-03 2:36 ` Viresh Kumar
2019-09-03 6:01 ` H. Nikolaus Schaller
2019-09-03 6:14 ` Viresh Kumar
2019-09-03 6:23 ` H. Nikolaus Schaller [this message]
2019-09-03 6:28 ` Viresh Kumar
2019-09-03 6:34 ` H. Nikolaus Schaller
2019-09-02 10:55 ` [RFC 5/5] ARM: dts: omap3-beagle: make explicitly compatible to ti,omap34xx H. Nikolaus Schaller
2019-09-03 13:40 ` Tony Lindgren
2019-09-04 8:47 ` H. Nikolaus Schaller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6B7B0EDB-8A60-48A0-AFAB-8A266358300C@goldelico.com \
--to=hns@goldelico.com \
--cc=aford173@gmail.com \
--cc=bcousson@baylibre.com \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pyra-handheld.com \
--cc=letux-kernel@openphoenux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=neolynx@gmail.com \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=tony@atomide.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.