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 <redacted>
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 26 +++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
Add a regulator for the GPU in order to properly make use of the newly added
operations-table.
Signed-off-by: Trevor Woerner <redacted>
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 4 ++++
1 file changed, 4 insertions(+)
From: Johan Jonker <hidden> Date: 2021-10-16 20:45:16
On 10/16/21 5:45 PM, Trevor Woerner wrote:
quoted hunk
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 <redacted>
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 26 +++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
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
On Sat 2021-10-16 @ 10:45:04 PM, Johan Jonker wrote:
On 10/16/21 5:45 PM, Trevor Woerner wrote:
quoted
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 <redacted>
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 26 +++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
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
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
From: Robin Murphy <robin.murphy@arm.com> Date: 2021-10-18 18:09:40
On 2021-10-17 16:29, Trevor Woerner wrote:
On Sat 2021-10-16 @ 10:45:04 PM, Johan Jonker wrote:
quoted
On 10/16/21 5:45 PM, Trevor Woerner wrote:
quoted
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 <redacted>
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 26 +++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
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
No, that's just the default voltage that BUCK1 itself starts up at -
looks like that table is an unfinished attempt to summarise the Power
Sequence section from the RK805 datasheet.
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?
FWIW the usual culprit for clocks not changing is inadvertently not
having devfreq and/or the simple_ondemand governor enabled. However, I
do seem to recall that devfreq doesn't explicitly fix up an out-of-spec
clock to a known OPP on startup like cpufreq does - I think it only
actually touches the clocks and regulators when transitioning between
OPPs, so if it only has one it might possibly end up in a pathological
state where that effectively never happens; I don't remember exactly.
Unfortunately all my boards are out of action for various reasons at the
moment so I can't readily check how I was running mine, but from memory
I think I ended up with slightly tweaked voltages based on a survey of
several other BSP kernels, and the 200-300MHz points just disabled to
avoid undervolting the memory controller once lima voltage scaling was
working properly.
Cheers,
Robin.
I'll investigate whether I can prove or disprove the scaling is actually
occurring?
Best regards,
Trevor
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Date: 2021-10-18 16:49:21
On Samstag, 16. Oktober 2021 17:45:44 CEST Trevor Woerner wrote:
quoted hunk
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 <redacted>
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 26 +++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
As for whether this works as described on a ROCK64 for glmark2-es2-wayland:
Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
There is some stuff worth noting that LibreELEC does on this SoC[1]:
1. they use 1.05V for all OPPs up to and including 400 MHz
2. they run 500 MHz at 1.15V instead (though 1.10V seemed to work for both of
us)
3. they disable 500 MHz because 1.15V was apparently too high for rkvdec.
3 is currently not very relevant because mainline Linux has no rkvdec node in
the rk3328 dtsi, and we're not running at 1.15V.
I've decided to add their rkvdec dtsi patch[2] on top anyway, and saw no
complaints from the rkvdec module while glmark2-es2-drm was running. However,
it's not like I tried to actually hardware decode video while it was running
because the userspace situation still won't let me without compiling entirely
too much stuff from git. Though the rkvdec module was loaded and present.
[1]: https://github.com/LibreELEC/LibreELEC.tv/commit/
9a6be0d36ba7ff3c3d5df798682d47a1de594ac0
[2]: https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Rockchip/
patches/linux/default/linux-1001-v4l2-rockchip.patch#L860-L935
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Samstag, 16. Oktober 2021 17:45:44 CEST Trevor Woerner wrote:
quoted
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 <redacted>
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 26 +++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
As for whether this works as described on a ROCK64 for glmark2-es2-wayland:
The probably most "convenient" and also future-proof solution upstream
for that is to define voltage ranges á la
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <950000 950000 1150000>;
};
and so on.
And then adapt the regulator-min-microvolt of the logic regulator like
vdd_logic: DCDC_REG1 {
regulator-name = "vdd_logic";
regulator-min-microvolt = <1050000>;
...
};
That way all opp-points will be taken, but its ensured, that vdd_log
never goes below 1.05 V
Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
There is some stuff worth noting that LibreELEC does on this SoC[1]:
1. they use 1.05V for all OPPs up to and including 400 MHz
2. they run 500 MHz at 1.15V instead (though 1.10V seemed to work for both of
us)
That might be true for your boards, but note that the required voltage
is per "leakage level" defined in efuse bits - something we do not
support for Rockchip upstream currently - see [1]
3. they disable 500 MHz because 1.15V was apparently too high for rkvdec.
3 is currently not very relevant because mainline Linux has no rkvdec node in
the rk3328 dtsi, and we're not running at 1.15V.
I've decided to add their rkvdec dtsi patch[2] on top anyway, and saw no
complaints from the rkvdec module while glmark2-es2-drm was running. However,
it's not like I tried to actually hardware decode video while it was running
because the userspace situation still won't let me without compiling entirely
too much stuff from git. Though the rkvdec module was loaded and present.
From: Nicolas Frattaroli <frattaroli.nicolas@gmail.com> Date: 2021-10-19 16:19:15
On Dienstag, 19. Oktober 2021 17:52:05 CEST Alex Bee wrote:
Am 18.10.21 um 18:49 schrieb Nicolas Frattaroli:
quoted
On Samstag, 16. Oktober 2021 17:45:44 CEST Trevor Woerner wrote:
quoted
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 <redacted>
---
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 26 +++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
As for whether this works as described on a ROCK64 for glmark2-es2-wayland:
The probably most "convenient" and also future-proof solution upstream
for that is to define voltage ranges á la
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <950000 950000 1150000>;
};
and so on.
And then adapt the regulator-min-microvolt of the logic regulator like
vdd_logic: DCDC_REG1 {
regulator-name = "vdd_logic";
regulator-min-microvolt = <1050000>;
...
};
That way all opp-points will be taken, but its ensured, that vdd_log
never goes below 1.05 V
quoted
Tested-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
There is some stuff worth noting that LibreELEC does on this SoC[1]:
1. they use 1.05V for all OPPs up to and including 400 MHz
2. they run 500 MHz at 1.15V instead (though 1.10V seemed to work for both of
us)
That might be true for your boards, but note that the required voltage
is per "leakage level" defined in efuse bits - something we do not
support for Rockchip upstream currently - see [1]
Thank you for the insight.
If we had the efuse bits, is there an already existing mechanism to only
enable the 500 MHz OPP if the chip happens to be one of those able to do
it at 1.10V?
Something like only having opp-microvolt-L1 defined and having the opp
be ignored if we're not an L1 chip.
quoted
3. they disable 500 MHz because 1.15V was apparently too high for rkvdec.
3 is currently not very relevant because mainline Linux has no rkvdec node in
the rk3328 dtsi, and we're not running at 1.15V.
I've decided to add their rkvdec dtsi patch[2] on top anyway, and saw no
complaints from the rkvdec module while glmark2-es2-drm was running. However,
it's not like I tried to actually hardware decode video while it was running
because the userspace situation still won't let me without compiling entirely
too much stuff from git. Though the rkvdec module was loaded and present.
You will see no complaints from the module , but you will see the SoC
crashing if both is running at the same time - see rkvdec-opp-table
downstream [2]
I did end up finding an old arm64 build I had of a patched ffmpeg that works
for the current kernel, and
ffmpeg -hwaccel drm -i file -f null -
was running stably with glmark2-es2-drm running at the same time, though I
also did not have an rkvdec OPP table.
Either way, thank you for clearing things up. I guess the easiest way to
get more useful clocks on mainline right now is to disable the 500 MHz
OPP and define them all in the way you've suggested.
Regards,
Nicolas Frattaroli