[PATCH] rockchip: rockpro64: Set cooling levels for pwm-fan
The cooling levels are tuned to the fan that comes with the rockpro64 NAS case. A gpu_thermal zone was not added because having two active cooling maps control one physical fan causes them to compete for the fan speed which results in erratic fan behavior.
Signed-off-by: Kurt Miller kurt@intricatesoftware.com ---
arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 43 +++++++++++++++++++++++ 1 file changed, 43 insertions(+)
diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi index deaa3efd39..c0e0396758 100644 --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi @@ -13,6 +13,49 @@ chosen { u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci; }; + + fan: pwm-fan { + cooling-levels = <0 40 80 255>; + }; +}; + +&cpu_thermal { + trips { + cpu_warm: cpu_warm { + temperature = <50000>; + hysteresis = <2000>; + type = "active"; + }; + + cpu_med: cpu_med { + temperature = <60000>; + hysteresis = <2000>; + type = "active"; + }; + + cpu_hot: cpu_hot { + temperature = <65000>; + hysteresis = <2000>; + type = "active"; + }; + }; + + cooling-maps { + map2 { + trip = <&cpu_warm>; + cooling-device = <&fan THERMAL_NO_LIMIT 1>; + }; + + map3 { + trip = <&cpu_med>; + cooling-device = <&fan THERMAL_NO_LIMIT 2>; + }; + + map4 { + trip = <&cpu_hot>; + cooling-device = <&fan 2 THERMAL_NO_LIMIT>; + }; + }; };
&vdd_center {
On Thu, May 28, 2020 at 8:32 PM Kurt Miller kurt@intricatesoftware.com wrote:
The cooling levels are tuned to the fan that comes with the rockpro64 NAS case. A gpu_thermal zone was not added because having two active cooling maps control one physical fan causes them to compete for the fan speed which results in erratic fan behavior.
Is there any reason this shouldn't go to the linux kernel first and then be synced back to the standard rk3399-rockpro64.dtsi?
Signed-off-by: Kurt Miller kurt@intricatesoftware.com
arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 43 +++++++++++++++++++++++ 1 file changed, 43 insertions(+)
diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi index deaa3efd39..c0e0396758 100644 --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi @@ -13,6 +13,49 @@ chosen { u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci; };
fan: pwm-fan {cooling-levels = <0 40 80 255>;};+};
+&cpu_thermal {
trips {cpu_warm: cpu_warm {temperature = <50000>;hysteresis = <2000>;type = "active";};cpu_med: cpu_med {temperature = <60000>;hysteresis = <2000>;type = "active";};cpu_hot: cpu_hot {temperature = <65000>;hysteresis = <2000>;type = "active";};};cooling-maps {map2 {trip = <&cpu_warm>;cooling-device = <&fan THERMAL_NO_LIMIT 1>;};map3 {trip = <&cpu_med>;cooling-device = <&fan THERMAL_NO_LIMIT 2>;};map4 {trip = <&cpu_hot>;cooling-device = <&fan 2 THERMAL_NO_LIMIT>;};};};
&vdd_center {
2.26.2
On Fri, 2020-05-29 at 09:27 +0100, Peter Robinson wrote:
On Thu, May 28, 2020 at 8:32 PM Kurt Miller kurt@intricatesoftware.com wrote:
The cooling levels are tuned to the fan that comes with the rockpro64 NAS case. A gpu_thermal zone was not added because having two active cooling maps control one physical fan causes them to compete for the fan speed which results in erratic fan behavior.
Is there any reason this shouldn't go to the linux kernel first and then be synced back to the standard rk3399-rockpro64.dtsi?
Is that a requirement? I do my primary development on OpenBSD and while I use Linux for work tasks, I don't have available time right now to push these changes to Linux kernel first.
Signed-off-by: Kurt Miller kurt@intricatesoftware.com
arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 43 +++++++++++++++++++++++ 1 file changed, 43 insertions(+)
diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi index deaa3efd39..c0e0396758 100644 --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi @@ -13,6 +13,49 @@ chosen { u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci; };
+ fan: pwm-fan { + cooling-levels = <0 40 80 255>; + }; +};
+&cpu_thermal { + trips { + cpu_warm: cpu_warm { + temperature = <50000>; + hysteresis = <2000>; + type = "active"; + };
+ cpu_med: cpu_med { + temperature = <60000>; + hysteresis = <2000>; + type = "active"; + };
+ cpu_hot: cpu_hot { + temperature = <65000>; + hysteresis = <2000>; + type = "active"; + }; + };
+ cooling-maps { + map2 { + trip = <&cpu_warm>; + cooling-device = <&fan THERMAL_NO_LIMIT 1>; + };
+ map3 { + trip = <&cpu_med>; + cooling-device = <&fan THERMAL_NO_LIMIT 2>; + };
+ map4 { + trip = <&cpu_hot>; + cooling-device = <&fan 2 THERMAL_NO_LIMIT>; + }; + }; };
&vdd_center {
2.26.2
Hi Kurt,
On Fri, 29 May 2020 at 06:42, Kurt Miller kurt@intricatesoftware.com wrote:
On Fri, 2020-05-29 at 09:27 +0100, Peter Robinson wrote:
On Thu, May 28, 2020 at 8:32 PM Kurt Miller kurt@intricatesoftware.com wrote:
The cooling levels are tuned to the fan that comes with the rockpro64 NAS case. A gpu_thermal zone was not added because having two active cooling maps control one physical fan causes them to compete for the fan speed which results in erratic fan behavior.
Is there any reason this shouldn't go to the linux kernel first and then be synced back to the standard rk3399-rockpro64.dtsi?
Is that a requirement? I do my primary development on OpenBSD and while I use Linux for work tasks, I don't have available time right now to push these changes to Linux kernel first.
The problem is that we need to keep Linux and U-Boot in sync. If a DT change is submitted only to one then it isn't clear who is taking on the task of syncing them up.
You don't actually need to be using Linux to send a DT change - just clone Linux, apply your patch and send to devicetree@vger.kernel.org. I wonder if it would be good enough to cc that group and the Linux maintainer on these patches, assuming the files are currently in sync? But probably a new patch is needed.
Regards, Simon
On Fri, 2020-05-29 at 13:00 -0600, Simon Glass wrote:
Hi Kurt,
On Fri, 29 May 2020 at 06:42, Kurt Miller kurt@intricatesoftware.com wrote:
On Fri, 2020-05-29 at 09:27 +0100, Peter Robinson wrote:
On Thu, May 28, 2020 at 8:32 PM Kurt Miller kurt@intricatesoftware.com wrote:
The cooling levels are tuned to the fan that comes with the rockpro64 NAS case. A gpu_thermal zone was not added because having two active cooling maps control one physical fan causes them to compete for the fan speed which results in erratic fan behavior.
Is there any reason this shouldn't go to the linux kernel first and then be synced back to the standard rk3399-rockpro64.dtsi?
Is that a requirement? I do my primary development on OpenBSD and while I use Linux for work tasks, I don't have available time right now to push these changes to Linux kernel first.
The problem is that we need to keep Linux and U-Boot in sync. If a DT change is submitted only to one then it isn't clear who is taking on the task of syncing them up.
You don't actually need to be using Linux to send a DT change - just clone Linux, apply your patch and send to devicetree@vger.kernel.org. I wonder if it would be good enough to cc that group and the Linux maintainer on these patches, assuming the files are currently in sync? But probably a new patch is needed.
Thank you for the pointers. I'll give that a try.
Best, -Kurt
participants (3)
-
Kurt Miller -
Peter Robinson -
Simon Glass