linux-kernel - Re: [PATCH v3] arm64: dts: rockchip: add thermal fan control to rockpro64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <893701da-ea17-00ab-5e31-c745051ac9b9@arm.com>
Date:   Fri, 13 Aug 2021 14:51:54 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        Peter Geis <pgwipeout@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Heiko Stuebner <heiko@...ech.de>
Cc:     devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] arm64: dts: rockchip: add thermal fan control to
 rockpro64

On 2021-08-13 13:59, Daniel Lezcano wrote:
> On 30/07/2021 17:17, Peter Geis wrote:
>> The rockpro64 had a fan node since
>> commit 5882d65c1691 ("arm64: dts: rockchip: Add PWM fan for RockPro64")
>> however it was never tied into the thermal driver for automatic control.
>>
>> Add the links to the thermal node to permit the kernel to handle this
>> automatically.
>> Borrowed from the (rk3399-khadas-edge.dtsi).
>>
>> Signed-off-by: Peter Geis <pgwipeout@...il.com>
>> ---
>>
>> Changelog:
>> v3:
>> Removed the gpu nodes to prevent in-fighting (thanks Robin!)
>>
>> v2:
>> Adjusted fan setpoints for less noise
>>
>>   .../boot/dts/rockchip/rk3399-rockpro64.dtsi   | 29 +++++++++++++++++++
>>   1 file changed, 29 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
>> index 6bff8db7d33e..83db4ca67334 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
>> @@ -69,6 +69,7 @@ diy_led: led-1 {
>>   
>>   	fan: pwm-fan {
>>   		compatible = "pwm-fan";
>> +		cooling-levels = <0 100 150 200 255>;
>>   		#cooling-cells = <2>;
>>   		fan-supply = <&vcc12v_dcin>;
>>   		pwms = <&pwm1 0 50000 0>;
>> @@ -245,6 +246,34 @@ &cpu_b1 {
>>   	cpu-supply = <&vdd_cpu_b>;
>>   };
>>   
>> +&cpu_thermal {
>> +	trips {
>> +		cpu_warm: cpu_warm {
>> +			temperature = <55000>;
>> +			hysteresis = <2000>;
>> +			type = "active";
>> +		};
>> +
>> +		cpu_hot: cpu_hot {
>> +			temperature = <65000>;
>> +			hysteresis = <2000>;
>> +			type = "active";
>> +		};
>> +	};
>> +
> 
> Why two trip points ?
> 
> Why not one functioning temperature and no lower / upper limits for the
> cooling maps ?

Certainly when I first did this for NanoPC-T4, IIRC it was to avoid the 
fan ramping up too eagerly, since level 1 for my fan is effectively 
silent but still cools enough to let a moderate load eventually settle 
to a steady state below the second trip.

Robin.

>> +	cooling-maps {
>> +		map2 {
>> +			trip = <&cpu_warm>;
>> +			cooling-device = <&fan THERMAL_NO_LIMIT 1>;
>> +		};
>> +
>> +		map3 {
>> +			trip = <&cpu_hot>;
>> +			cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
>> +		};
>> +	};
>> +};
>> +
>>   &emmc_phy {
>>   	status = "okay";
>>   };
>>
> 
>