From: Trevor Woerner <twoerner@gmail.com>
To: Johan Jonker <jbx6244@gmail.com>
Cc: linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>, Chen-Yu Tsai <wens@csie.org>,
David Wu <david.wu@rock-chips.com>,
Ezequiel Garcia <ezequiel@collabora.com>,
Cameron Nemo <cnemo@tutanota.com>,
Robin Murphy <robin.murphy@arm.com>,
Elaine Zhang <zhangqing@rock-chips.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"moderated list:ARM/Rockchip SoC support"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Rockchip SoC support"
<linux-rockchip@lists.infradead.org>
Subject: Re: [PATCH 1/2] arm64: dts: rk3328: add gpu opp table
Date: Sun, 17 Oct 2021 11:29:41 -0400 [thread overview]
Message-ID: <20211017152941.GA33697@localhost> (raw)
In-Reply-To: <67c7c3c6-b946-a6bc-24fd-85f56bcec7f3@gmail.com>
On Sat 2021-10-16 @ 10:45:04 PM, Johan Jonker wrote:
> On 10/16/21 5:45 PM, Trevor Woerner wrote:
> > Add an operating-points table and cooling entry to the GPU on the
> > RK3328 SoC to improve its performance. According to its datasheet[1]
> > the maximum frequency of the Mali-450 MP2 GPU found on the RK3328 SoC
> > is 500MHz.
> >
> > On my rock64 device, under x11, glmark2-es2 performance increased from
> > around 60 to just over 100. Same device running glmark2-es2 under
> > wayland/weston improved from just over 100 to just over 200.
> >
> > [1] https://rockchip.fr/RK3328%20datasheet%20V1.2.pdf
> >
> > Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3328.dtsi | 26 +++++++++++++++++++++++-
> > 1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > index 8c821acb21ff..5e1dcf71e414 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > @@ -532,7 +532,8 @@ map0 {
> > cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > - <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > contribution = <4096>;
> > };
> > };
> > @@ -617,6 +618,29 @@ gpu: gpu@ff300000 {
> > clocks = <&cru ACLK_GPU>, <&cru ACLK_GPU>;
> > clock-names = "bus", "core";
> > resets = <&cru SRST_GPU_A>;
> > + operating-points-v2 = <&gpu_opp_table>;
> > + #cooling-cells = <2>;
> > + };
> > +
>
> > + gpu_opp_table: gpu-opp-table {
>
> After the conversion to YAML of the Operating Performance Points(OPP)
> binding the operating-points-v2 property expects the nodename to have
> the '^opp-table(-[a-z0-9]+)?$' format.
>
> make ARCH=arm64 dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/opp/opp-v2.yaml
Thanks, I wasn't aware.
> > + compatible = "operating-points-v2";
> > +
> > + opp-200000000 {
> > + opp-hz = /bits/ 64 <200000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > + opp-300000000 {
> > + opp-hz = /bits/ 64 <300000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > + opp-400000000 {
> > + opp-hz = /bits/ 64 <400000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > + opp-500000000 {
> > + opp-hz = /bits/ 64 <500000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > };
>
> opp-microvolt has the same value for every node vs. table below?
On page 1 of the schematic for the rock64
https://files.pine64.org/doc/rock64/ROCK64_Schematic_v3.0_20181105.pdf is a
table ("Power Timing") showing BUCK1 at 1.1V. I interpreted this to mean that
VDD_LOG should always be at 1.1V, regardless of frequency.
> See also previous discussion:
>
> https://lore.kernel.org/linux-rockchip/3c95c29b-6c07-5945-ac22-d683997e1ca0@arm.com/
>
> Is that now fixed/checked?
I wasn't aware of the previous/on-going discussion regarding a gpu opp table
for this SoC. Perhaps that explains my suspicions? I couldn't help wonder why
the frequency is always reported as 163840000 even when I have an opp table
that only has the 500MHz entry?
I'll investigate whether I can prove or disprove the scaling is actually
occurring?
Best regards,
Trevor
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Trevor Woerner <twoerner@gmail.com>
To: Johan Jonker <jbx6244@gmail.com>
Cc: linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>, Chen-Yu Tsai <wens@csie.org>,
David Wu <david.wu@rock-chips.com>,
Ezequiel Garcia <ezequiel@collabora.com>,
Cameron Nemo <cnemo@tutanota.com>,
Robin Murphy <robin.murphy@arm.com>,
Elaine Zhang <zhangqing@rock-chips.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"moderated list:ARM/Rockchip SoC support"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Rockchip SoC support"
<linux-rockchip@lists.infradead.org>
Subject: Re: [PATCH 1/2] arm64: dts: rk3328: add gpu opp table
Date: Sun, 17 Oct 2021 11:29:41 -0400 [thread overview]
Message-ID: <20211017152941.GA33697@localhost> (raw)
In-Reply-To: <67c7c3c6-b946-a6bc-24fd-85f56bcec7f3@gmail.com>
On Sat 2021-10-16 @ 10:45:04 PM, Johan Jonker wrote:
> On 10/16/21 5:45 PM, Trevor Woerner wrote:
> > Add an operating-points table and cooling entry to the GPU on the
> > RK3328 SoC to improve its performance. According to its datasheet[1]
> > the maximum frequency of the Mali-450 MP2 GPU found on the RK3328 SoC
> > is 500MHz.
> >
> > On my rock64 device, under x11, glmark2-es2 performance increased from
> > around 60 to just over 100. Same device running glmark2-es2 under
> > wayland/weston improved from just over 100 to just over 200.
> >
> > [1] https://rockchip.fr/RK3328%20datasheet%20V1.2.pdf
> >
> > Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3328.dtsi | 26 +++++++++++++++++++++++-
> > 1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > index 8c821acb21ff..5e1dcf71e414 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > @@ -532,7 +532,8 @@ map0 {
> > cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > - <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > contribution = <4096>;
> > };
> > };
> > @@ -617,6 +618,29 @@ gpu: gpu@ff300000 {
> > clocks = <&cru ACLK_GPU>, <&cru ACLK_GPU>;
> > clock-names = "bus", "core";
> > resets = <&cru SRST_GPU_A>;
> > + operating-points-v2 = <&gpu_opp_table>;
> > + #cooling-cells = <2>;
> > + };
> > +
>
> > + gpu_opp_table: gpu-opp-table {
>
> After the conversion to YAML of the Operating Performance Points(OPP)
> binding the operating-points-v2 property expects the nodename to have
> the '^opp-table(-[a-z0-9]+)?$' format.
>
> make ARCH=arm64 dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/opp/opp-v2.yaml
Thanks, I wasn't aware.
> > + compatible = "operating-points-v2";
> > +
> > + opp-200000000 {
> > + opp-hz = /bits/ 64 <200000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > + opp-300000000 {
> > + opp-hz = /bits/ 64 <300000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > + opp-400000000 {
> > + opp-hz = /bits/ 64 <400000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > + opp-500000000 {
> > + opp-hz = /bits/ 64 <500000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > };
>
> opp-microvolt has the same value for every node vs. table below?
On page 1 of the schematic for the rock64
https://files.pine64.org/doc/rock64/ROCK64_Schematic_v3.0_20181105.pdf is a
table ("Power Timing") showing BUCK1 at 1.1V. I interpreted this to mean that
VDD_LOG should always be at 1.1V, regardless of frequency.
> See also previous discussion:
>
> https://lore.kernel.org/linux-rockchip/3c95c29b-6c07-5945-ac22-d683997e1ca0@arm.com/
>
> Is that now fixed/checked?
I wasn't aware of the previous/on-going discussion regarding a gpu opp table
for this SoC. Perhaps that explains my suspicions? I couldn't help wonder why
the frequency is always reported as 163840000 even when I have an opp table
that only has the 500MHz entry?
I'll investigate whether I can prove or disprove the scaling is actually
occurring?
Best regards,
Trevor
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Trevor Woerner <twoerner@gmail.com>
To: Johan Jonker <jbx6244@gmail.com>
Cc: linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>, Chen-Yu Tsai <wens@csie.org>,
David Wu <david.wu@rock-chips.com>,
Ezequiel Garcia <ezequiel@collabora.com>,
Cameron Nemo <cnemo@tutanota.com>,
Robin Murphy <robin.murphy@arm.com>,
Elaine Zhang <zhangqing@rock-chips.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"moderated list:ARM/Rockchip SoC support"
<linux-arm-kernel@lists.infradead.org>,
"open list:ARM/Rockchip SoC support"
<linux-rockchip@lists.infradead.org>
Subject: Re: [PATCH 1/2] arm64: dts: rk3328: add gpu opp table
Date: Sun, 17 Oct 2021 11:29:41 -0400 [thread overview]
Message-ID: <20211017152941.GA33697@localhost> (raw)
In-Reply-To: <67c7c3c6-b946-a6bc-24fd-85f56bcec7f3@gmail.com>
On Sat 2021-10-16 @ 10:45:04 PM, Johan Jonker wrote:
> On 10/16/21 5:45 PM, Trevor Woerner wrote:
> > Add an operating-points table and cooling entry to the GPU on the
> > RK3328 SoC to improve its performance. According to its datasheet[1]
> > the maximum frequency of the Mali-450 MP2 GPU found on the RK3328 SoC
> > is 500MHz.
> >
> > On my rock64 device, under x11, glmark2-es2 performance increased from
> > around 60 to just over 100. Same device running glmark2-es2 under
> > wayland/weston improved from just over 100 to just over 200.
> >
> > [1] https://rockchip.fr/RK3328%20datasheet%20V1.2.pdf
> >
> > Signed-off-by: Trevor Woerner <twoerner@gmail.com>
> > ---
> > arch/arm64/boot/dts/rockchip/rk3328.dtsi | 26 +++++++++++++++++++++++-
> > 1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > index 8c821acb21ff..5e1dcf71e414 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> > @@ -532,7 +532,8 @@ map0 {
> > cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > - <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> > + <&gpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> > contribution = <4096>;
> > };
> > };
> > @@ -617,6 +618,29 @@ gpu: gpu@ff300000 {
> > clocks = <&cru ACLK_GPU>, <&cru ACLK_GPU>;
> > clock-names = "bus", "core";
> > resets = <&cru SRST_GPU_A>;
> > + operating-points-v2 = <&gpu_opp_table>;
> > + #cooling-cells = <2>;
> > + };
> > +
>
> > + gpu_opp_table: gpu-opp-table {
>
> After the conversion to YAML of the Operating Performance Points(OPP)
> binding the operating-points-v2 property expects the nodename to have
> the '^opp-table(-[a-z0-9]+)?$' format.
>
> make ARCH=arm64 dtbs_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/opp/opp-v2.yaml
Thanks, I wasn't aware.
> > + compatible = "operating-points-v2";
> > +
> > + opp-200000000 {
> > + opp-hz = /bits/ 64 <200000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > + opp-300000000 {
> > + opp-hz = /bits/ 64 <300000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > + opp-400000000 {
> > + opp-hz = /bits/ 64 <400000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > + opp-500000000 {
> > + opp-hz = /bits/ 64 <500000000>;
> > + opp-microvolt = <1100000>;
> > + };
> > };
>
> opp-microvolt has the same value for every node vs. table below?
On page 1 of the schematic for the rock64
https://files.pine64.org/doc/rock64/ROCK64_Schematic_v3.0_20181105.pdf is a
table ("Power Timing") showing BUCK1 at 1.1V. I interpreted this to mean that
VDD_LOG should always be at 1.1V, regardless of frequency.
> See also previous discussion:
>
> https://lore.kernel.org/linux-rockchip/3c95c29b-6c07-5945-ac22-d683997e1ca0@arm.com/
>
> Is that now fixed/checked?
I wasn't aware of the previous/on-going discussion regarding a gpu opp table
for this SoC. Perhaps that explains my suspicions? I couldn't help wonder why
the frequency is always reported as 163840000 even when I have an opp table
that only has the 500MHz entry?
I'll investigate whether I can prove or disprove the scaling is actually
occurring?
Best regards,
Trevor
next prev parent reply other threads:[~2021-10-17 15:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-16 15:45 [PATCH 1/2] arm64: dts: rk3328: add gpu opp table Trevor Woerner
2021-10-16 15:45 ` Trevor Woerner
2021-10-16 15:45 ` Trevor Woerner
2021-10-16 15:45 ` [PATCH 2/2] arm64: dts: rock64: add gpu regulator Trevor Woerner
2021-10-16 15:45 ` Trevor Woerner
2021-10-16 15:45 ` Trevor Woerner
2021-10-16 20:45 ` [PATCH 1/2] arm64: dts: rk3328: add gpu opp table Johan Jonker
2021-10-16 20:45 ` Johan Jonker
2021-10-16 20:45 ` Johan Jonker
2021-10-17 15:29 ` Trevor Woerner [this message]
2021-10-17 15:29 ` Trevor Woerner
2021-10-17 15:29 ` Trevor Woerner
2021-10-18 18:09 ` Robin Murphy
2021-10-18 18:09 ` Robin Murphy
2021-10-18 18:09 ` Robin Murphy
2021-10-18 16:49 ` Nicolas Frattaroli
2021-10-18 16:49 ` Nicolas Frattaroli
2021-10-18 16:49 ` Nicolas Frattaroli
2021-10-19 15:52 ` Alex Bee
2021-10-19 15:52 ` Alex Bee
2021-10-19 15:52 ` Alex Bee
2021-10-19 16:19 ` Nicolas Frattaroli
2021-10-19 16:19 ` Nicolas Frattaroli
2021-10-19 16:19 ` Nicolas Frattaroli
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=20211017152941.GA33697@localhost \
--to=twoerner@gmail.com \
--cc=cnemo@tutanota.com \
--cc=david.wu@rock-chips.com \
--cc=devicetree@vger.kernel.org \
--cc=ezequiel@collabora.com \
--cc=heiko@sntech.de \
--cc=jbx6244@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=wens@csie.org \
--cc=zhangqing@rock-chips.com \
/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.