pine64-rockpro64: add fancontrol

[samtinel]

Description of changes

Controls the fan so it doesn't spin at full force after installation.
rk3399's operating temps are -20 to 80°C. It has sensors for CPU and GPU. The MINSTART/-STOP values are a result of my own testing.
Tested my fork without any changes and with hardware.fancontrol.enable = false; to disable it.

Things done

• Tested the changes in your own NixOS Configuration
• Tested the changes end-to-end by using your fork of nixos-hardware and
  importing it via <nixos-hardware> or Flake input

[samtinel]

With these settings, the fan doesn't run in idle for me. With stress --cpu 6 the fan runs till ~90, which is still pretty quiet. I couldn't get it higher, and as soon as I end the stressing, it quickly calms comes down to a full stop.
It barely reached the "warm" stresshold configured in the kernel, so I think MINTEMP is set to an OK value.

[Mic92]

Thanks!

[tomfitzhenry]

It's great to see this, since I stopped using the fan since the lack of fancontrol was annoying.

To test this PR/functionality, I plugged a fan into my rockpro64, but the fan is continuously running, even when the CPU is idle.

fancontrol.service is unable to start:

$ journalctl -u fancontrol.service
[..]
Nov 07 18:18:38 rockpro64 systemd[1]: Started software fan control.
Nov 07 18:18:38 rockpro64 fancontrol[1769]: Loading configuration from /nix/store/23b8vza7s0yjrkrfc8gnrg43j1in6pd1-fancontrol.conf ...
Nov 07 18:18:38 rockpro64 fancontrol[1769]: Common settings:
Nov 07 18:18:38 rockpro64 fancontrol[1769]:   INTERVAL=3
Nov 07 18:18:38 rockpro64 fancontrol[1769]: Settings for hwmon3/pwm1:
Nov 07 18:18:38 rockpro64 fancontrol[1769]:   Depends on hwmon0/temp1_input
Nov 07 18:18:38 rockpro64 fancontrol[1769]:   Controls
Nov 07 18:18:38 rockpro64 fancontrol[1769]:   MINTEMP=40
Nov 07 18:18:38 rockpro64 fancontrol[1769]:   MAXTEMP=80
Nov 07 18:18:38 rockpro64 fancontrol[1769]:   MINSTART=35
Nov 07 18:18:38 rockpro64 fancontrol[1769]:   MINSTOP=30
Nov 07 18:18:38 rockpro64 fancontrol[1769]:   MINPWM=0
Nov 07 18:18:38 rockpro64 fancontrol[1769]:   MAXPWM=255
Nov 07 18:18:38 rockpro64 fancontrol[1769]:   AVERAGE=1
Nov 07 18:18:38 rockpro64 fancontrol[1769]: Device path of hwmon0 has changed
Nov 07 18:18:38 rockpro64 fancontrol[1769]: Device path of hwmon1 has changed
Nov 07 18:18:38 rockpro64 fancontrol[1769]: Device path of hwmon3 has changed
Nov 07 18:18:38 rockpro64 fancontrol[1769]: Device name of hwmon0 has changed
Nov 07 18:18:38 rockpro64 fancontrol[1769]: Device name of hwmon1 has changed
Nov 07 18:18:38 rockpro64 fancontrol[1769]: Device name of hwmon3 has changed
Nov 07 18:18:38 rockpro64 fancontrol[1769]: Configuration appears to be outdated, please run pwmconfig again
Nov 07 18:18:38 rockpro64 systemd[1]: fancontrol.service: Main process exited, code=exited, status=1/FAILURE
Nov 07 18:18:38 rockpro64 systemd[1]: fancontrol.service: Failed with result 'exit-code'.
Nov 07 18:18:38 rockpro64 systemd[1]: fancontrol.service: Triggering OnFailure= dependencies.
Nov 07 18:18:39 rockpro64 systemd[1]: fancontrol.service: Scheduled restart job, restart counter is at 5.

I'm not familiar with fancontrol, sadly!

@samtinel, thoughts?

[tomfitzhenry]

FYI:

$ ls -l /sys/class/hwmon/
total 0
lrwxrwxrwx 1 root root 0 Jul 28 09:27 hwmon0 -> ../../devices/platform/f8000000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/nvme/nvme0/hwmon0
lrwxrwxrwx 1 root root 0 Nov  7 18:18 hwmon1 -> ../../devices/virtual/thermal/thermal_zone0/hwmon1
lrwxrwxrwx 1 root root 0 Nov  8 02:00 hwmon2 -> ../../devices/virtual/thermal/thermal_zone1/hwmon2
lrwxrwxrwx 1 root root 0 Nov  7 18:18 hwmon3 -> ../../devices/platform/ff3d0000.i2c/i2c-4/4-0022/power_supply/tcpm-source-psy-4-0022/hwmon3
lrwxrwxrwx 1 root root 0 Nov  8 02:00 hwmon4 -> ../../devices/platform/pwm-fan/hwmon/hwmon4

[samtinel]

Thanks for reaching out, @tomfitzhenry! It's good to see somebody else making use (or trying to :D) one's contribution.
Can you please post the content of:

/sys/class/hwmon/hwmon0/name
/sys/devices/virtual/thermal/thermal_zone0/temp*
/sys/class/hwmon/hwmon1/name
/sys/devices/virtual/thermal/thermal_zone1/temp*
/sys/class/hwmon/hwmon3/name
/sys/devices/platform/pwm-fan/pwm*

Could be wrong about the path of the last one, if it's incorrect I'll check this evening. Additionally if they exist:

/sys/class/hwmon/hwmon2/name
/sys/class/hwmon/hwmon4/name

Since they'll likely not match, what's your board revision (printed on the device afaik, newest is 2.1) and kernel? Do you use a different (i.e. not the default one) device tree?

[tomfitzhenry]

Thanks for looking into this! :)

[tom@rockpro64:~]$ cat /sys/class/hwmon/hwmon0/name
nvme

[tom@rockpro64:~]$ ls -lh /sys/devices/virtual/thermal/thermal_zone0/temp*
-r--r--r-- 1 root root 4.0K Nov  8 23:24 /sys/devices/virtual/thermal/thermal_zone0/temp

[tom@rockpro64:~]$ cat /sys/devices/virtual/thermal/thermal_zone0/temp*
26875

[tom@rockpro64:~]$ cat /sys/class/hwmon/hwmon1/name
cpu_thermal

[tom@rockpro64:~]$ ls -lh /sys/devices/virtual/thermal/thermal_zone1/temp*
-r--r--r-- 1 root root 4.0K Nov  8 23:25 /sys/devices/virtual/thermal/thermal_zone1/temp

[tom@rockpro64:~]$ cat /sys/devices/virtual/thermal/thermal_zone1/temp*
27500

[tom@rockpro64:~]$ cat /sys/class/hwmon/hwmon3/name
tcpm_source_psy_4_0022

[tom@rockpro64:~]$ cat /sys/devices/platform/pwm-fan/hwmon/hwmon4/pwm1
255

[tom@rockpro64:~]$ cat /sys/class/hwmon/hwmon2/name
gpu_thermal

[tom@rockpro64:~]$ cat /sys/class/hwmon/hwmon4/name
pwmfan

Board revision: RockPro64 V2.1 2018-07-02

Kernel is pkgs.linuxPackages_5_15 to avoid recent NVMe-on-boot issues I experience with later kernels. I've been meaning to report this upstream...

$ uname -a
Linux rockpro64 5.15.137 #1-NixOS SMP Wed Oct 25 09:59:04 UTC 2023 aarch64 GNU/Linux

I use Tow Boot on SPI flash, and the upstream kernel's DT.

[samtinel]

Since you have an nvme drive installed (which apparently has a thermal sensor), and that one is hwmon0, every other hwmon is increased by one. So if you wanted to get this to work, you'd just need to replace the following words in the fancontrol config: - hwmon0 -> hwmon1 - hwmon1 -> hwmon2 - hwmon3 -> hwmon4 It'd be nice if you could test that?

[samtinel]

There's an upstream issue about not being able to use better identifiers than the number: lm-sensors/lm-sensors#227 I don't know what's the best way forward, maybe a different package? I used fancontrol because that's what some other board in this repo used.

[tomfitzhenry]

So if you wanted to get this to work, you'd just need to replace the following words in the fancontrol config: - hwmon0 -> hwmon1 - hwmon1 -> hwmon2 - hwmon3 -> hwmon4 It'd be nice if you could test that?

This works perfectly, thanks! I observe the fan off while idle, and then on during a stress test.

There's an upstream issue about not being able to use better identifiers than the number:
lm-sensors/lm-sensors#227
I don't know what's the best way forward, maybe a different package? I used fancontrol because that's what some other board in this repo used.

Ah, that's a shame that lm-sensors seems so dependent on module load order. Thanks for looking into this.

I will keep my overridden hardware.fancontrol.config for now. When I get a chance, I'll look into this more, and maybe raise a PR to add options for specifying the sysfs paths for the CPU and fan. That way, the default (no NVMe) will work out-the-box, and NVMe users can override hwmon paths.