Add PWM fan control to dietpi-config

[zumbiepig]

Adds GPIO fan control from raspi-config.

Will close #4003

raspi-config link: https://github.com/RPi-Distro/raspi-config/blob/master/raspi-config#L1308

I named the config option "GPIO fan control" because I don't think this affects the Active Cooler on rpi 5. but i dont have an rpi5 to test with.

Dependencies:

• Add pwm-fan overlay raspberrypi/linux#7594

[zumbiepig]

Generally, I'd probably prefer a more generic new script to allow configuring PWM fans via sysfs on all hardware, not an RPi-only extra config entry. But we are open to PRs either way, of course.

Before someone starts with the gpio-fan overlay, doesn't this actually work with the pwn-gpio-fan overlay on the Raspberry Pi 4 (and earlier), to assign multiple trip points? Or does this work on RPi 5 only?

I dont have a PWN fan or an rpi 5 so i cant test any of these. maybe someone with more knowledge can work on these features

[MichaIng]

I dont have a PWN fan or an rpi 5 so i cant test any of these. maybe someone with more knowledge can work on these features

Are you sure that this is not a PWM(-capable) fan? The pwm-gpio-fan overlay makes use of a software PWM to drive the fan speed in multiple temperature steps, without the need for 4th PWM pin AFAIU.

See the description here: https://github.com/herbingk/pwm-gpio-fan
As its README mentions, it is included in the RPi kernel package already, which that one's README shows as well: https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L4364

Hence, try to use dtoverlay=pwm-gpio-fan,fan_gpio=<GPIO>, in case with lower fan_temp[0-3]s to see it in action. If that works on RPi 4, it works on all RPis. But there might be fans which do not work well with the software PWM on a single pin only, but stutter or something like that instead of running smoothly slower.

[zumbiepig]

@MichaIng

I dont have a PWN fan or an rpi 5 so i cant test any of these. maybe someone with more knowledge can work on these features

Are you sure that this is not a PWM(-capable) fan? The pwm-gpio-fan overlay makes use of a software PWM to drive the fan speed in multiple temperature steps, without the need for 4th PWM pin AFAIU.

See the description here: https://github.com/herbingk/pwm-gpio-fan As its README mentions, it is included in the RPi kernel package already, which that one's README shows as well: https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L4364

Hence, try to use dtoverlay=pwm-gpio-fan,fan_gpio=<GPIO>, in case with lower fan_temp[0-3]s to see it in action. If that works on RPi 4, it works on all RPis. But there might be fans which do not work well with the software PWM on a single pin only, but stutter or something like that instead of running smoothly slower.

This is the fan I have: https://www.pishop.us/product/highpi-pro-5v-cooling-fan/
Ideally this PR should also be compatible with the Official rpi4 case fan (pretty similar to mine).

I don't know if these support PWM, could you tell me? And if we use PWM, is it backwards compatible with non-PWM fans? Or should we prompt the user to pick one?

EDIT: It looks like my fan does support PWM. Overall this seems like a good default replacement, but we should still ask the user if they want to enable it.

There are several PWM controlled cooling fans avaliable for the Raspberry Pis prior to the Pi 5, that are connected via the Pi's GPIO header. Examples are the Argon mini-fan, HighPi Pro Fan or Waveshare FAN-4020-PWM-5V.

What these fans have in common is, that they are using the +5V pin and GND pin from the Pi's GPIO header to supply power to the fan and an additional GPIO pin (mostly GPIO 18) to control the fan state to be either on or off.

EDIT 2: Should we include config options for fan_temp[1-3]? This would complicate the fan config a lot.

[MichaIng]

Great, and yes, this seems to be quite a successor. I'd hence implement this one only for now. If users report that it does not work well with a particular 3 pins fan, we can still add the simple on/off overlay as alternative.

EDIT 2: Should we include config options for fan_temp[1-3]? This would complicate the fan config a lot.

Consequently, this makes sense. For most, the defaults will be fine, though.

For completeness, here is the script I started years ago to configure PWM fan trip points and speeds via sysfs API: https://github.com/MichaIng/DietPi/blob/dev/.meta/dietpi-fan_control
But the API (at that time) turned out to be very inconsistent. It worked on the Odroid C2, but on almost no other SBC. Anyway, theoretically, it could be reused for Raspberry Pi, with its menu structure for trip points and respective fan speeds, where input is done as a space-separated list. Even a static speed would still be possible by setting the first trip point to 0°C and same speed on all trip points. But that feature is probably not reasonable at all, I just implemented it, since it was explicitly possible via sysfs API. The idea then was to run this at early boot like dietpi-fan_control 1. Nowadays I'd create udev rules instead.

[zumbiepig]

@MichaIng

Great, and yes, this seems to be quite a successor. I'd hence implement this one only for now. If users report that it does not work well with a particular 3 pins fan, we can still add the simple on/off overlay as alternative.

EDIT 2: Should we include config options for fan_temp[1-3]? This would complicate the fan config a lot.

Consequently, this makes sense. For most, the defaults will be fine, though.

For completeness, here is the script I started years ago to configure PWM fan trip points and speeds via sysfs API: https://github.com/MichaIng/DietPi/blob/dev/.meta/dietpi-fan_control But the API (at that time) turned out to be very inconsistent. It worked on the Odroid C2, but on almost no other SBC. Anyway, theoretically, it could be reused for Raspberry Pi, with its menu structure for trip points and respective fan speeds, where input is done as a space-separated list. Even a static speed would still be possible by setting the first trip point to 0°C and same speed on all trip points. But that feature is probably not reasonable at all, I just implemented it, since it was explicitly possible via sysfs API. The idea then was to run this at early boot like dietpi-fan_control 1. Nowadays I'd create udev rules instead.

I'm looking at the defaults for temp/speed in pwm-fan-overlay and they seem very reasonable. For now I don't want to over complicate it so Im leaving it as default. Please give me feedback on clarifying the config prompts though since I suck at UX.

[zumbiepig]

@MichaIng

I have the config done now. But I tested it (just putting it into config.txt manually) and it starts out quite noisy and gets quieter as the PWM speed goes up (louder at lower speed). ChatGPT says this is because it is using software PWM which outputs 50Hz and hardware PWM outputs 25kHz, and 25kHz is required for it to be inaudible.

Is there an easy way for DietPi to implement hardware PWM on GPIO 18 (the caveat is bad audio quality, but most people don't need audio for a headless setup)?

[zumbiepig]

this pr now depends on the merging of raspberrypi/linux#7594

[MichaIng]

What is the difference between pwm-fan and pem-gpio-fan?

EDIT: Ah got it, it uses a hardware PWM. It should be configurable here, IMO. Some people do use audio. Good is that parameters are the same.