> From: Kurt Miller <li...@intricatesoftware.com> > Date: Wed, 22 Dec 2021 12:30:57 -0500 > > On Mon, 2021-12-20 at 19:10 +0100, Christopher Zimmermann wrote: > > Hi, > > > > to me it seems the thermal zone fan control model (see > > https://www.kernel.org/doc/Documentation/devicetree/bindings/thermal/thermal.txt) > > > > is inappropriate in many cases. > > This model relies on a `cooling-levels` property of the fan being > > present, which is then referenced by a thermal zone trip-point. > > > > `cooling-levels` is essentially a map of 0-n fan power to 0-255 fan > > power. It is probably meant to be used to make a power-cooling relation > > more linear and cut off low-power setting which won't suffice to spin up > > the fan ?!? > > > > This setting can obviously only be configured for a specific fan. And to > > do so one needs to recompile and install a device tree for the specific > > fan. > > > > To test the fan I added a fall-back code path to pwmfan.c, so the fan > > doesn't depend on a `cooling-levels` setting (patch attached). > > > > Now knowing that the 80mm fan does actually work and at what level it > > will relieably spin up I could work out a sensible thermal-zone > > configuration which I then added to the device tree (patch attached). > > > > This diff won't help anybody with a different fan since other fans will > > need more or less power to spin up. > > > > What I would maybe like to add is a sysctl knob with which one can set > > the cooling-levels map as a uint8_t cooling-levels[255]. That way the > > fan could be controlled from userspace by setting the whole array to the > > same value or the map can be used to adapt a given fan to the thermal > > zones configuration of the device tree. > > > > I'm not sure where to put it. Since this whole thermal-zone and > > cooling-levels stuff is only an abstraction it should maybe be moved to > > ofw_thermal.c and a generic "cooling-device" knob be added there. > > Cooling devices would then need to pass their fdt_attach_args to > > ofw_thermal so that ofw_thermal could then read the cooling-levels. > > > > Does this make any sense? Is it a reasonable design? > > > > I put fan control into our u-boot port with settings that match the > rockpro64 NAS case: > > https://github.com/openbsd/ports/blob/master/sysutils/u-boot/patches/patch-arch_arm_dts_rk3399-rockpro64_dtsi > https://github.com/openbsd/ports/commit/3f3e0ce642390535672516f81257087d01f2391e#diff-469080868d3929ce1e4aae8f1e9984183c > 80764da94fa8bda82542a4cee10bcf > > It works well for me. When the system is idle no fan is engaged. > At cpu_warm the fan is on but silent. At cpu_med the fan is audible > but sufficient to keep the cpu at or around 60 deg for most loads. > With these settings its pretty hard to get the cpu temp to 65 deg. > Of course these settings are only tuned to the fan that comes with > the NAS case but that seem like a reasonable place to work from. > > We should probably sync the dtb port to match these settings, > including the PCIe gen2 setting.
So the "proper" way to customize the devicetree to match the customization of your board is probably through devicetree overlays. This is how things are done for the Raspberry Pi. There you can modify the config.txt to have the Raspberry Pi firmware apply certain overlays. But U-Boot is supposed to be able to apply overlays as well. Devicetree overlays have the benefit that they continue to apply when you install a new version of U-Boot that comes with an updated devicetree.
