R36 PLUS cannot adjust the GPU frequency normally

[umifly]

Recently, while I was researching how to overclock the R36PLUS, I discovered a strange situation. The GPU was always running at the lowest frequency of 400 MHz as configured in the device tree, even though the device tree also included two other frequencies of 480 MHz and 520 MHz. I attempted to modify the scheduler to high performance, but the GPU still ran at the lowest frequency.
So I checked the logs about the GPU

ark@rg351mp:~$ dmesg | grep mali
[ 0.609533] mali ff400000.gpu: Looking up mali-supply from device tree
[ 0.609568] mali ff400000.gpu: Failed to get regulator
[ 0.614736] mali ff400000.gpu: Power control initialization failed
[ 0.916301] mali ff400000.gpu: Looking up mali-supply from device tree
[ 0.916663] mali ff400000.gpu: Failed to get leakage
[ 0.921682] mali ff400000.gpu: Looking up mali-supply from device tree
[ 0.921928] mali ff400000.gpu: pvtm-volt-sel=2
[ 0.922240] mali ff400000.gpu: avs=0
[ 0.922294] W : [File] : drivers/gpu/arm/bifrost_for_linux/platform/rk/mali_kbase_config_rk.c; [Line] : 113; [Func] : kbase_platform_rk_init(); power-off-delay-ms not available.
[ 0.922875] mali ff400000.gpu: GPU identified as 0x3 arch 7.0.9 r0p0 status 0
[ 0.923523] mali ff400000.gpu: l=0 h=2147483647 hyst=5000 l_limit=0 h_limit=0
[ 0.923704] mali ff400000.gpu: Using configured power model mali-simple-power-model, and fallback mali-simple-power-model
[ 0.924530] mali ff400000.gpu: Probed as mali0

I noticed this line

[ 0.609568] mali ff400000.gpu: Failed to get regulator

So I checked the dtb , found gpu@ff400000 node references a regulator named vdd_logic through mali-supply. Generally, the GPU should have a dedicated regulator vdd_gpu, so I looked up the technical manual of rk3326

It seems that the logic core and GPU share this regulator , So I attempted to directly delete the mali-supply property in the GPU node

Then, it worked , after I change the governor to performance in the advanced Settings, the GPU successfully reached 520Mhz

ark@rg351mp:~$ dmesg | grep mali
[ 0.607145] mali ff400000.gpu: Looking up mali-supply from device tree
[ 0.607171] mali ff400000.gpu: Looking up mali-supply property in node /gpu@ff400000 failed
[ 0.607193] mali ff400000.gpu: Continuing without Mali regulator control
[ 0.607269] mali ff400000.gpu: Failed to get leakage
[ 0.612287] mali ff400000.gpu: Looking up mali-supply from device tree
[ 0.612312] mali ff400000.gpu: Looking up mali-supply property in node /gpu@ff400000 failed
[ 0.612334] mali ff400000.gpu: Failed to get reg
[ 0.612822] mali ff400000.gpu: avs=0
[ 0.612889] W : [File] : drivers/gpu/arm/bifrost_for_linux/platform/rk/mali_kbase_config_rk.c; [Line] : 113; [Func] : kbase_platform_rk_init(); power-off-delay-ms not available.
[ 0.613173] W : [File] : drivers/gpu/arm/bifrost_for_linux/platform/rk/mali_kbase_config_rk.c; [Line] : 285; [Func] : rk_pm_enable_regulator(); no mali regulator control, no need to enable.
[ 0.613613] mali ff400000.gpu: GPU identified as 0x3 arch 7.0.9 r0p0 status 0
[ 0.614861] mali ff400000.gpu: l=0 h=2147483647 hyst=5000 l_limit=480000000 h_limit=0
[ 0.614913] mali ff400000.gpu: failed to read out thermal zone (-22)
[ 0.621542] mali ff400000.gpu: Using configured power model mali-simple-power-model, and fallback mali-simple-power-model
[ 0.622681] mali ff400000.gpu: Probed as mali0

ark@rg351mp:/sys/class/devfreq/ff400000.gpu$ cat cur_freq
520000000

[AeolusUX]

Great work unlocking 520 MHz on the GPU! The 400 MHz limit was intentional to save battery, especially for devices like the R36S Plus with its 720x720 screen. That 1:1 display has ~68% more pixels than the R36S’s 640x480, so it chews through power faster. Sticking to 400 MHz keeps the Mali-G31 MP2 efficient and avoids overloading the shared vdd_logic regulator. Your tweak boosts PSP/N64 performance, but how’s the battery life holding up with the higher-res screen?

[umifly]

Great work unlocking 520 MHz on the GPU! The 400 MHz limit was intentional to save battery, especially for devices like the R36S Plus with its 720x720 screen. That 1:1 display has ~68% more pixels than the R36S’s 640x480, so it chews through power faster. Sticking to 400 MHz keeps the Mali-G31 MP2 efficient and avoids overloading the shared vdd_logic regulator. Your tweak boosts PSP/N64 performance, but how’s the battery life holding up with the higher-res screen?

It will still take some time to assess the impact of overclocking on the battery. Considering that most simulators are not well optimized for multi-core, I am accustomed to turning off one logic core to save power.
It is worth mentioning that I found two additional GPU frequencies in the original dtb of the R36PLUS, which might reduce power consumption when running some games that do not require excessive performance.

	opp-200000000 {
		opp-hz = <0x00 0xbebc200>;
		opp-microvolt = <0xe7ef0>;
		opp-microvolt-L0 = <0xe7ef0>;
		opp-microvolt-L1 = <0xe7ef0>;
		opp-microvolt-L2 = <0xe7ef0>;
		opp-microvolt-L3 = <0xe7ef0>;
	};

	opp-300000000 {
		opp-hz = <0x00 0x11e1a300>;
		opp-microvolt = <0xee098>;
		opp-microvolt-L0 = <0xee098>;
		opp-microvolt-L1 = <0xe7ef0>;
		opp-microvolt-L2 = <0xe7ef0>;
		opp-microvolt-L3 = <0xe7ef0>;
	};

[umifly]

The simple_ondemand governor still seems to have some issues. It will always be scheduled at the lowest frequency and will not adjust the frequency according to the load

[umifly]

I attempted to write a simple script to adjust the maximum frequency of the gpu, in order to alleviate the bug where the governor cannot adjust the frequency.

https://github.com/umifly/R36PLUS-Script/blob/main/GPUController.sh

[HelicopterKlutzy]

What happened to this script?

[bmdhacks]

My testing shows 520mhz to induce severe lag periods possibly due to thermal throttling. 480mhz gives a nice result.