Message-ID: <5a667361-940e-4653-ac3e-ae26a70255a2@gmail.com>
Date:   Tue, 19 Oct 2021 17:52:05 +0200
From:   Alex Bee <knaerzche@...il.com>
To:     Nicolas Frattaroli <frattaroli.nicolas@...il.com>,
        linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org
Cc:     Rob Herring <robh+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
        Johan Jonker <jbx6244@...il.com>, Chen-Yu Tsai <wens@...e.org>,
        David Wu <david.wu@...k-chips.com>,
        Ezequiel Garcia <ezequiel@...labora.com>,
        Cameron Nemo <cnemo@...anota.com>,
        Robin Murphy <robin.murphy@....com>,
        Elaine Zhang <zhangqing@...k-chips.com>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "moderated list:ARM/Rockchip SoC support" 
        <linux-arm-kernel@...ts.infradead.org>,
        Trevor Woerner <twoerner@...il.com>
Subject: Re: [PATCH 1/2] arm64: dts: rk3328: add gpu opp table

Am 18.10.21 um 18:49 schrieb Nicolas Frattaroli:
> On Samstag, 16. Oktober 2021 17:45:44 CEST 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@...il.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@...00000 {
>>   		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 {
>> +		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>;
>> +		};
>>   	};
>>
>>   	h265e_mmu: iommu@...30200 {
> 
> 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@...il.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.
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]

[1] 
https://github.com/rockchip-linux/kernel/blob/develop-4.4/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L750-L751

[2] 
https://github.com/rockchip-linux/kernel/blob/develop-4.4/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L840-L867

Alex

> [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-rockchip mailing list
> Linux-rockchip@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
> 

Powered by blists - more mailing lists