[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=Vng40b05F2_i7qqXC+yN=ZBgRXsio-86sBA+QdoMMGaw@mail.gmail.com>
Date: Tue, 4 May 2021 13:02:28 -0700
From: Doug Anderson <dianders@...omium.org>
To: Sibi Sankar <sibis@...eaurora.org>
Cc: Bjorn Andersson <bjorn.andersson@...aro.org>,
Matthias Kaehlcke <mka@...omium.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Stephen Boyd <sboyd@...nel.org>,
Andy Gross <agross@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
Linux PM <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] arm64: dts: qcom: sc7280: Add cpu OPP tables
Hi,
On Mon, May 3, 2021 at 11:59 PM Sibi Sankar <sibis@...eaurora.org> wrote:
>
> + cpu0_opp_table: cpu0_opp_table {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + cpu0_opp1: opp-300000000 {
It seems like it might be nicer to give the node labels a less
arbitrary name. How about?
cpu0_opp_300mhz: opp-300000000
That has advantes:
* If, for some reason, you have to mess with some operating point in
another dts it'll be less fragile.
* It'll make diffing easier between SoCs.
* If you end up putting a new operating point in the middle you don't
need to rename everything below.
Other than that, I can't say that I'm a huge expert on the
interconnect stuff and whether those make sense, but I'm still OK
with:
Reviewed-by: Douglas Anderson <dianders@...omium.org>
Powered by blists - more mailing lists