[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABjd4YzWJie91kcbHom_Zso=QQR9gPmAVvJb1vbqa0Qwu5egKg@mail.gmail.com>
Date: Thu, 25 Jan 2024 14:17:21 +0400
From: Alexey Charkov <alchark@...il.com>
To: Daniel Lezcano <daniel.lezcano@...aro.org>
Cc: Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
Heiko Stuebner <heiko@...ech.de>, Dragan Simic <dsimic@...jaro.org>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
linux-kernel@...r.kernel.org, Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [PATCH 4/4] arm64: dts: rockchip: Add OPP data for CPU cores on RK3588
On Thu, Jan 25, 2024 at 1:30 PM Daniel Lezcano
<daniel.lezcano@...aro.org> wrote:
>
>
> Hi Alexey,
>
> Adding Viresh
>
> On 24/01/2024 21:30, Alexey Charkov wrote:
> > By default the CPUs on RK3588 start up in a conservative performance
> > mode. Add frequency and voltage mappings to the device tree to enable
> > dynamic scaling via cpufreq
> >
> > Signed-off-by: Alexey Charkov <alchark@...il.com>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 209 ++++++++++++++++++++++++++++++
> > 1 file changed, 209 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> > index 131b9eb21398..e605be531a0f 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> > @@ -97,6 +97,7 @@ cpu_l0: cpu@0 {
> > clocks = <&scmi_clk SCMI_CLK_CPUL>;
> > assigned-clocks = <&scmi_clk SCMI_CLK_CPUL>;
> > assigned-clock-rates = <816000000>;
> > + operating-points-v2 = <&cluster0_opp_table>;
> > cpu-idle-states = <&CPU_SLEEP>;
> > i-cache-size = <32768>;
> > i-cache-line-size = <64>;
> > @@ -116,6 +117,7 @@ cpu_l1: cpu@100 {
> > enable-method = "psci";
> > capacity-dmips-mhz = <530>;
> > clocks = <&scmi_clk SCMI_CLK_CPUL>;
> > + operating-points-v2 = <&cluster0_opp_table>;
> > cpu-idle-states = <&CPU_SLEEP>;
> > i-cache-size = <32768>;
> > i-cache-line-size = <64>;
> > @@ -135,6 +137,7 @@ cpu_l2: cpu@200 {
> > enable-method = "psci";
> > capacity-dmips-mhz = <530>;
> > clocks = <&scmi_clk SCMI_CLK_CPUL>;
> > + operating-points-v2 = <&cluster0_opp_table>;
> > cpu-idle-states = <&CPU_SLEEP>;
> > i-cache-size = <32768>;
> > i-cache-line-size = <64>;
> > @@ -154,6 +157,7 @@ cpu_l3: cpu@300 {
> > enable-method = "psci";
> > capacity-dmips-mhz = <530>;
> > clocks = <&scmi_clk SCMI_CLK_CPUL>;
> > + operating-points-v2 = <&cluster0_opp_table>;
> > cpu-idle-states = <&CPU_SLEEP>;
> > i-cache-size = <32768>;
> > i-cache-line-size = <64>;
> > @@ -175,6 +179,7 @@ cpu_b0: cpu@400 {
> > clocks = <&scmi_clk SCMI_CLK_CPUB01>;
> > assigned-clocks = <&scmi_clk SCMI_CLK_CPUB01>;
> > assigned-clock-rates = <816000000>;
> > + operating-points-v2 = <&cluster1_opp_table>;
> > cpu-idle-states = <&CPU_SLEEP>;
> > i-cache-size = <65536>;
> > i-cache-line-size = <64>;
> > @@ -194,6 +199,7 @@ cpu_b1: cpu@500 {
> > enable-method = "psci";
> > capacity-dmips-mhz = <1024>;
> > clocks = <&scmi_clk SCMI_CLK_CPUB01>;
> > + operating-points-v2 = <&cluster1_opp_table>;
> > cpu-idle-states = <&CPU_SLEEP>;
> > i-cache-size = <65536>;
> > i-cache-line-size = <64>;
> > @@ -215,6 +221,7 @@ cpu_b2: cpu@600 {
> > clocks = <&scmi_clk SCMI_CLK_CPUB23>;
> > assigned-clocks = <&scmi_clk SCMI_CLK_CPUB23>;
> > assigned-clock-rates = <816000000>;
> > + operating-points-v2 = <&cluster2_opp_table>;
> > cpu-idle-states = <&CPU_SLEEP>;
> > i-cache-size = <65536>;
> > i-cache-line-size = <64>;
> > @@ -234,6 +241,7 @@ cpu_b3: cpu@700 {
> > enable-method = "psci";
> > capacity-dmips-mhz = <1024>;
> > clocks = <&scmi_clk SCMI_CLK_CPUB23>;
> > + operating-points-v2 = <&cluster2_opp_table>;
> > cpu-idle-states = <&CPU_SLEEP>;
> > i-cache-size = <65536>;
> > i-cache-line-size = <64>;
> > @@ -348,6 +356,207 @@ l3_cache: l3-cache {
> > };
> > };
> >
> > + cluster0_opp_table: opp-table-cluster0 {
> > + compatible = "operating-points-v2";
> > + opp-shared;
> > +
> > + opp-408000000 {
> > + opp-hz = /bits/ 64 <408000000>;
> > + opp-microvolt = <675000 675000 950000>;
> > + clock-latency-ns = <40000>;
> > + };
> > + opp-600000000 {
> > + opp-hz = /bits/ 64 <600000000>;
> > + opp-microvolt = <675000 675000 950000>;
> > + clock-latency-ns = <40000>;
> > + };
> > + opp-816000000 {
> > + opp-hz = /bits/ 64 <816000000>;
> > + opp-microvolt = <675000 675000 950000>;
> > + clock-latency-ns = <40000>;
> > + };
> > + opp-1008000000 {
> > + opp-hz = /bits/ 64 <1008000000>;
> > + opp-microvolt = <675000 675000 950000>;
> > + clock-latency-ns = <40000>;
> > + };
>
> It is not useful to introduce OPP with the same voltage. There is no
> gain in terms of energy efficiency as the compute capacity is linearly
> tied with power consumption (P=CxFxV²) in this case.
>
> For example, opp-408 consumes 2 bogoWatts and opp-816 consumes 4
> bogoWatts (because of the same voltage).
>
> For a workload, opp-408 takes 10 sec and opp-816 takes 5 sec because it
> is twice faster.
>
> The energy consumption is:
>
> opp-408 = 10 x 2 = 20 BogoJoules
> opp-816 = 5 x 4 = 20 BogoJoules
I see, thank you. Will drop all "lower frequency - same voltage"
instances and resubmit in the next iteration.
Best regards,
Alexey
Powered by blists - more mailing lists