Add pwm-fan overlay

[zumbiepig]

Why: the pwm-gpio-fan overlay that was added it really loud since it runs at 50hz (20ms cycle) and hardware pwm does 25khz (40ns cycle)

This uses hardware pwm so it runs quiet and the only downside is that you get worse audio quality. but many people dont use their raspberry pi with audio.

[pelwell]

Pros:

• I can see what you're trying to do.
• The goal is sensible.
• The fan settings look OK, but that's because you've copied them from Pi 5.

Cons:

• Although you allow a pin number to be chosen, in practice there is only one values that works - 18. The others need a different PWM channel or alt-function selector (or both):

  $ pinctrl -c bcm2835 funcs 0-27 | grep PWM
  12, GPIO12, PWM0, SD4, DPI_D8, AVEOUT_VID8, AVEIN_VID8, ARM_TMS
  13, GPIO13, PWM1, SD5, DPI_D9, AVEOUT_VID9, AVEIN_VID9, ARM_TCK
  18, GPIO18, PCM_CLK, SD10, DPI_D14, I2CSL_SDA_MOSI, SPI1_CE0_N, PWM0
  19, GPIO19, PCM_FS, SD11, DPI_D15, I2CSL_SCL_SCLK, SPI1_MISO, PWM1
  

  I think you should restrict this to GPIOs 12, 13, 18 and 19 and use dedicated overrides/parameters for each, something like (not tested):

  fan_gpio_12 = <&pwm_pins>,"brcm,pins:0=12",
                <&pwm_pins>,"brcm,function:0=4",
                <&fan>,"pwms:4=0";
  fan_gpio_13 = <&pwm_pins>,"brcm,pins:0=13",
                <&pwm_pins>,"brcm,function:0=4",
                <&fan>,"pwms:4=1";
  fan_gpio_18 = <&pwm_pins>,"brcm,pins:0=18",
                <&pwm_pins>,"brcm,function:0=2",
                <&fan>,"pwms:4=0";
  fan_gpio_19 = <&pwm_pins>,"brcm,pins:0=19",
                <&pwm_pins>,"brcm,function:0=2",
                <&fan>,"pwms:4=1";
  

• Have you developed this by editing files in the GitHub online editor? Having so many commits means lots of notifications. We'd have to squash them before merging. It's much better to clone the repo to your own computer (including a Pi), make the changes and commit them, then push them when you are ready.

[zumbiepig]

question: it says compatible = "brcm,bcm2835"; (pi zero), but will it also be compatible with bcm2711 (pi 4)? i dont know how to specify multiple

[pelwell]

Just leave it as brcm,bcm2835 - that has come to mean that is compatible with most of the Pi family, but nothing checks it apart from some of my automated checkers.

[zumbiepig]

I just tested the overlay on my Raspberry Pi 4B with all four PWM pins (12, 13, 18, 19) and a HighPi Pro Fan. Everything is fully functional on all four pins.

[pelwell]

Thanks - I'll merge once the auto-builds have completed.

[zumbiepig]

Thanks - I'll merge once the auto-builds have completed.

Thank you. They should build successfully since the only thing that changed since the last test was documentation and whitespace.

Btw, is there a better solution to this ugliness? (5000 is the only word on the second line)

And not being able to quickly copy and paste this?

I had to trim these because of the 100 char limit

[pelwell]

The 100 character limit is only a warning. We don't worry about it on things like overlays which will never be sent to the upstream kernel maintainers. Checkpatch failures are not necessarily blockers - that's why we call it the "Advisory checkpatch review".

However, one way to avoid the ugly wrapping of the in-overlay usage information is just to delete it - that's what the README is for.

[zumbiepig]

The 100 character limit is only a warning. We don't worry about it on things like overlays which will never be sent to the upstream kernel maintainers. Checkpatch failures are not necessarily blockers - that's why we call it the "Advisory checkpatch review".

However, one way to avoid the ugly wrapping of the in-overlay usage information is just to delete it - that's what the README is for.

Can I revert my commits then? The other thing that failed was "you should only use tabs for indenting" which leads to this spacing being very inconsistent (this would ideally be aligned with spaces to the above line)

And i guess i could remove the params from the overlay, its just i thought we were supposed to since all the other overlays did it. im new to this repo

[zumbiepig]

The 100 character limit is only a warning. We don't worry about it on things like overlays which will never be sent to the upstream kernel maintainers. Checkpatch failures are not necessarily blockers - that's why we call it the "Advisory checkpatch review".

Here is a screenshot that everything passed. im going to force push a commit now to make it not pass, but you can merge it anyways

[zumbiepig]

Force pushed from b4865fb...f3e3398. You can compare the changes here and merge it without waiting again since it will fail the check.

[zumbiepig]

Thank you. When can I expect to see this shipped to most Pis (that update their kernel ofc)?

[pelwell]

There's no fixed schedule, but the kernel apt packages get bumped around every 2-3 months, with new images being created more like every 6 months. However, there's nothing stopping you keeping the .dtbo as an extra file - it won't get deleted or overwritten until it gets a proper release. You will lose the README though.

[zumbiepig]

There's no fixed schedule, but the kernel apt packages get bumped around every 2-3 months, with new images being created more like every 6 months. However, there's nothing stopping you keeping the .dtbo as an extra file - it won't get deleted or overwritten until it gets a proper release. You will lose the README though.

Can I ship the same bcm2835 .dtbo file to all raspberry pis in DietPi? or does each chip require a rebuild? this is probably a stupid question

[pelwell]

It's not a stupid question (we don't believe in them), and the answer is yes - one overlay will work for all Pis without recompilation. To be a bit more precise:

• We only ship one build of each overlay.
• If it doesn't work on all Pis, rebuilding it won't change that.
• Where one overlay file is not enough for all Pis we use a model/family-specific suffix - ramoops-pi4, w1-gpio-pi5, etc. The overlay_map file allows the correct version to be selected.