[PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[Hugh Cole-Baker]

FriendlyELEC offers an optional heatsink and fan addon for the NanoPC-T6
and T6 LTS. Add an overlay which can be applied if the fan is fitted and
configures the fan as an active cooling device for the SoC package.

Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com>
---
FriendlyELEC heatsink with fan addon:
https://www.friendlyelec.com/index.php?route=product/product&product_id=305
Vendor DT with trip points and PWM duty cycle values:
https://github.com/friendlyarm/kernel-rockchip/blob/4944602540b62f5aad139fe602a76cf7c3176128/arch/arm64/boot/dts/rockchip/rk3588-nanopi6-rev01.dts#L75-L90

 arch/arm64/boot/dts/rockchip/Makefile         |  9 +++
 .../dts/rockchip/rk3588-nanopc-t6-fan.dtso    | 78 +++++++++++++++++++
 2 files changed, 87 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6-fan.dtso

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 4cd8ef607f55c..7a67b68a6bb03 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -178,6 +178,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-jaguar-ethernet-switch.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-jaguar-pre-ict-tester.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-mnt-reform2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-nanopc-t6.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-nanopc-t6-fan.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-nanopc-t6-lts.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-ok3588-c.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-orangepi-5-max.dtb
@@ -271,6 +272,14 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-jaguar-pre-ict-tester.dtb
 rk3588-jaguar-pre-ict-tester-dtbs := rk3588-jaguar.dtb \
 	rk3588-jaguar-pre-ict-tester.dtbo
 
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-nanopc-t6-with-fan.dtb
+rk3588-nanopc-t6-with-fan-dtbs := rk3588-nanopc-t6.dtb \
+	rk3588-nanopc-t6-fan.dtbo
+
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-nanopc-t6-lts-with-fan.dtb
+rk3588-nanopc-t6-lts-with-fan-dtbs := rk3588-nanopc-t6-lts.dtb \
+	rk3588-nanopc-t6-fan.dtbo
+
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-pcie-ep.dtb
 rk3588-rock-5b-pcie-ep-dtbs := rk3588-rock-5b.dtb \
 	rk3588-rock-5b-pcie-ep.dtbo
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6-fan.dtso b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6-fan.dtso
new file mode 100644
index 0000000000000..08c4782fb4148
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6-fan.dtso
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/thermal/thermal.h>
+
+&{/} {
+	fan: pwm-fan {
+		compatible = "pwm-fan";
+		cooling-levels = <0 35 64 100 150 255>;
+		fan-supply = <&vcc5v0_sys>;
+		pwms = <&pwm1 0 50000 0>;
+		#cooling-cells = <2>;
+	};
+};
+
+&package_thermal {
+	polling-delay = <1000>;
+
+	trips {
+		package_fan0: package-fan0 {
+			temperature = <50000>;
+			hysteresis = <2000>;
+			type = "active";
+		};
+
+		package_fan1: package-fan1 {
+			temperature = <55000>;
+			hysteresis = <2000>;
+			type = "active";
+		};
+
+		package_fan2: package-fan2 {
+			temperature = <60000>;
+			hysteresis = <2000>;
+			type = "active";
+		};
+
+		package_fan3: package-fan3 {
+			temperature = <65000>;
+			hysteresis = <2000>;
+			type = "active";
+		};
+
+		package_fan4: package-fan4 {
+			temperature = <70000>;
+			hysteresis = <2000>;
+			type = "active";
+		};
+	};
+
+	cooling-maps {
+		map0 {
+			trip = <&package_fan0>;
+			cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+		};
+
+		map1 {
+			trip = <&package_fan1>;
+			cooling-device = <&fan 2 3>;
+		};
+
+		map2 {
+			trip = <&package_fan2>;
+			cooling-device = <&fan 3 4>;
+		};
+
+		map3 {
+			trip = <&package_fan3>;
+			cooling-device = <&fan 4 5>;
+		};
+
+		map4 {
+			trip = <&package_fan4>;
+			cooling-device = <&fan 5 THERMAL_NO_LIMIT>;
+		};
+	};
+};
-- 
2.50.1 (Apple Git-155)


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[Alexey Charkov]

Hi Hugh,

On Mon, Oct 27, 2025 at 1:09 PM Hugh Cole-Baker <sigmaris@gmail.com> wrote:
>
> FriendlyELEC offers an optional heatsink and fan addon for the NanoPC-T6
> and T6 LTS. Add an overlay which can be applied if the fan is fitted and
> configures the fan as an active cooling device for the SoC package.
>
> Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com>
> ---
> FriendlyELEC heatsink with fan addon:
> https://www.friendlyelec.com/index.php?route=product/product&product_id=305
> Vendor DT with trip points and PWM duty cycle values:
> https://github.com/friendlyarm/kernel-rockchip/blob/4944602540b62f5aad139fe602a76cf7c3176128/arch/arm64/boot/dts/rockchip/rk3588-nanopi6-rev01.dts#L75-L90

Is there any downside to enabling this unconditionally in the board
.dts? Overlays require more user configuration, and not all
bootloaders support them directly (e.g. systemd-boot users would
struggle). Compiling with overlays enabled also makes .dtb's a lot
larger due to added symbols information.

Best regards,
Alexey

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[Hugh Cole-Baker]

On 27/10/2025 09:14, Alexey Charkov wrote:
> Hi Hugh,
> 
> On Mon, Oct 27, 2025 at 1:09 PM Hugh Cole-Baker <sigmaris@gmail.com> wrote:
>>
>> FriendlyELEC offers an optional heatsink and fan addon for the NanoPC-T6
>> and T6 LTS. Add an overlay which can be applied if the fan is fitted and
>> configures the fan as an active cooling device for the SoC package.
>>
>> Signed-off-by: Hugh Cole-Baker <sigmaris@gmail.com>
>> ---
>> FriendlyELEC heatsink with fan addon:
>> https://www.friendlyelec.com/index.php?route=product/product&product_id=305
>> Vendor DT with trip points and PWM duty cycle values:
>> https://github.com/friendlyarm/kernel-rockchip/blob/4944602540b62f5aad139fe602a76cf7c3176128/arch/arm64/boot/dts/rockchip/rk3588-nanopi6-rev01.dts#L75-L90

Hi Alexey,

> Is there any downside to enabling this unconditionally in the board
> .dts?

Only that it goes against the principle that the DT should describe the
hardware; the board .dts would describe a cooling device that doesn't
actually exist on the base board.

I guess then in theory, an OS might allow the SoC to reach undesirably high
temperatures if it's relying on the nonexistent fan to cool it down. But I
don't think this would be an issue on Linux, at least, in practice.

> Overlays require more user configuration, and not all
> bootloaders support them directly (e.g. systemd-boot users would
> struggle). Compiling with overlays enabled also makes .dtb's a lot
> larger due to added symbols information.

Nowadays (on Debian at least) using overlays is pretty easy, I'm using the
u-boot-menu package in Debian, I just copy the overlay(s) to /boot/dtbo/ and
it detects them automatically and adds them to extlinux.conf for u-boot to
apply.

Couldn't systemd-boot users just use rk3588-nanopc-t6-(lts-)with-fan.dtb as
their single DT to load, if it doesn't support applying overlays and they
want to use the fan addon?

FWIW, I haven't noticed any problems with having a larger .dtb (using mainline
U-Boot to load it) and several other RK3588 boards are also compiled with
symbols enabled already, and I haven't seen any issues reported with them.

Best regards,
Hugh

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[Dragan Simic]

Hello Hugh and Alexey,

On Mon, Oct 27, 2025 at 7:08 PM Hugh Cole-Baker <sigmaris@gmail.com> wrote:
> On 27/10/2025 09:14, Alexey Charkov wrote:
>
>> Is there any downside to enabling this unconditionally in the board
>> .dts?
>
> Only that it goes against the principle that the DT should describe the
> hardware; the board .dts would describe a cooling device that doesn't
> actually exist on the base board.

Having a separate DT overlay is perfectly fine if we want to
describe a board absolutely correctly: if the fan actually isn't
present, the operating system shouldn't be made to think it is
there, especially if there's no fan RPM feedback, which is the
case on almost all Rockchip boards that support a fan.

Preventing the kernel from managing a non-existent fan might even
save some CPU cycles, ending up producing a bit less heat, which
can only help in passively cooled setups.

However, the practice so far has been to describe the fans in the
main board dts files, if the board provides fan support, regardless
of the fan being present in a particular board setup or not.

> I guess then in theory, an OS might allow the SoC to reach undesirably high
> temperatures if it's relying on the nonexistent fan to cool it down. But I
> don't think this would be an issue on Linux, at least, in practice.

We're safe, a thermal runaway isn't going to happen when the fan is
defined in a board DT but actually isn't present.  Thermal CPU and
GPU throttling will prevent the overheating from happening.

>> Overlays require more user configuration, and not all
>> bootloaders support them directly (e.g. systemd-boot users would
>> struggle). Compiling with overlays enabled also makes .dtb's a lot
>> larger due to added symbols information.
>
> Nowadays (on Debian at least) using overlays is pretty easy, I'm using the
> u-boot-menu package in Debian, I just copy the overlay(s) to /boot/dtbo/ and
> it detects them automatically and adds them to extlinux.conf for u-boot to
> apply.
>
> Couldn't systemd-boot users just use rk3588-nanopc-t6-(lts-)with-fan.dtb as
> their single DT to load, if it doesn't support applying overlays and they
> want to use the fan addon?

Yes, that's an option.  However, that in general doesn't resolve
the issues arising from systemd-boot users wanting to apply more
than a single DT overlay.

> FWIW, I haven't noticed any problems with having a larger .dtb (using mainline
> U-Boot to load it) and several other RK3588 boards are also compiled with
> symbols enabled already, and I haven't seen any issues reported with them.

After thinking a bit about it, I'd support the extraction of fan
definitions into separate DT overlays.  As I wrote above already,
not managing the non-existent fan might actually help a bit with
passively cooled board setups, which is a good enough reason for
me to support separate DT overlays.

If we end up agreeing to accept this DT overlay, I'll have some
comments on the way cooling maps are defined.  I think there's
quite a bit of redundancy there.


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[Alexey Charkov]

On Tue, Oct 28, 2025 at 12:02 AM Dragan Simic <dsimic@manjaro.org> wrote:
>
> Hello Hugh and Alexey,
>
> On Mon, Oct 27, 2025 at 7:08 PM Hugh Cole-Baker <sigmaris@gmail.com> wrote:
> > On 27/10/2025 09:14, Alexey Charkov wrote:
> >
> >> Is there any downside to enabling this unconditionally in the board
> >> .dts?
> >
> > Only that it goes against the principle that the DT should describe the
> > hardware; the board .dts would describe a cooling device that doesn't
> > actually exist on the base board.
>
> Having a separate DT overlay is perfectly fine if we want to
> describe a board absolutely correctly: if the fan actually isn't
> present, the operating system shouldn't be made to think it is
> there, especially if there's no fan RPM feedback, which is the
> case on almost all Rockchip boards that support a fan.
>
> Preventing the kernel from managing a non-existent fan might even
> save some CPU cycles, ending up producing a bit less heat, which
> can only help in passively cooled setups.

Sounds like an overcomplication without real benefit. It's one thing
with overlays for functionality that can be software-incompatible
depending on whether an external attachment is connected or depending
on the type of attachment connected. Here we are looking at a plain
2-pin fan which cannot be software incompatible to anything really
(it's not like one could repurpose the fan connector for anything
meaningful if a fan is not in use, and noone gets hurt if a PWM output
is left running without load).

The CPU cycles spent parsing a slightly larger DTB at boot are likely
comparable to those spent activating a PWM output needlessly upon
hitting the active cooling trip point, and both are negligible for any
practical purpose.

> However, the practice so far has been to describe the fans in the
> main board dts files, if the board provides fan support, regardless
> of the fan being present in a particular board setup or not.
>
> > I guess then in theory, an OS might allow the SoC to reach undesirably high
> > temperatures if it's relying on the nonexistent fan to cool it down. But I
> > don't think this would be an issue on Linux, at least, in practice.
>
> We're safe, a thermal runaway isn't going to happen when the fan is
> defined in a board DT but actually isn't present.  Thermal CPU and
> GPU throttling will prevent the overheating from happening.
>
> >> Overlays require more user configuration, and not all
> >> bootloaders support them directly (e.g. systemd-boot users would
> >> struggle). Compiling with overlays enabled also makes .dtb's a lot
> >> larger due to added symbols information.
> >
> > Nowadays (on Debian at least) using overlays is pretty easy, I'm using the
> > u-boot-menu package in Debian, I just copy the overlay(s) to /boot/dtbo/ and
> > it detects them automatically and adds them to extlinux.conf for u-boot to
> > apply.
> >
> > Couldn't systemd-boot users just use rk3588-nanopc-t6-(lts-)with-fan.dtb as
> > their single DT to load, if it doesn't support applying overlays and they
> > want to use the fan addon?

Sure, but it's a manual configuration step, where otherwise the kernel
would just default to the correct dtb for the board that the firmware
told it about. The fan is not discoverable, so the firmware won't ever
offer the "-with-fan" variant, meaning users would need to supply it
manually in every instance.

> Yes, that's an option.  However, that in general doesn't resolve
> the issues arising from systemd-boot users wanting to apply more
> than a single DT overlay.
>
> > FWIW, I haven't noticed any problems with having a larger .dtb (using mainline
> > U-Boot to load it) and several other RK3588 boards are also compiled with
> > symbols enabled already, and I haven't seen any issues reported with them.
>
> After thinking a bit about it, I'd support the extraction of fan
> definitions into separate DT overlays.  As I wrote above already,
> not managing the non-existent fan might actually help a bit with
> passively cooled board setups, which is a good enough reason for
> me to support separate DT overlays.

Practical benefits sound far fetched here, while forcing users to
manually configure something that would have otherwise just worked.
Let's see what Heiko thinks.

> If we end up agreeing to accept this DT overlay, I'll have some
> comments on the way cooling maps are defined.  I think there's
> quite a bit of redundancy there.

Agree. Thermal governors can figure out the fan speed ramp-up without
specifying each and every temperature threshold manually. Two trips
seem to be enough for everyone (c) - as we've done e.g. on Rock 5B and
others.

Best regards,
Alexey

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[Dragan Simic]

Hello Alexey,

On Monday, October 27, 2025 21:56 CET, Alexey Charkov <alchark@gmail.com> wrote:
> On Tue, Oct 28, 2025 at 12:02 AM Dragan Simic <dsimic@manjaro.org> wrote:
> > On Mon, Oct 27, 2025 at 7:08 PM Hugh Cole-Baker <sigmaris@gmail.com> wrote:
> > > On 27/10/2025 09:14, Alexey Charkov wrote:
> > >
> > >> Is there any downside to enabling this unconditionally in the board
> > >> .dts?
> > >
> > > Only that it goes against the principle that the DT should describe the
> > > hardware; the board .dts would describe a cooling device that doesn't
> > > actually exist on the base board.
> >
> > Having a separate DT overlay is perfectly fine if we want to
> > describe a board absolutely correctly: if the fan actually isn't
> > present, the operating system shouldn't be made to think it is
> > there, especially if there's no fan RPM feedback, which is the
> > case on almost all Rockchip boards that support a fan.
> >
> > Preventing the kernel from managing a non-existent fan might even
> > save some CPU cycles, ending up producing a bit less heat, which
> > can only help in passively cooled setups.
> 
> Sounds like an overcomplication without real benefit. It's one thing
> with overlays for functionality that can be software-incompatible
> depending on whether an external attachment is connected or depending
> on the type of attachment connected. Here we are looking at a plain
> 2-pin fan which cannot be software incompatible to anything really
> (it's not like one could repurpose the fan connector for anything
> meaningful if a fan is not in use, and noone gets hurt if a PWM output
> is left running without load).
> 
> The CPU cycles spent parsing a slightly larger DTB at boot are likely
> comparable to those spent activating a PWM output needlessly upon
> hitting the active cooling trip point, and both are negligible for any
> practical purpose.

Hmm, right, I forgot for a moment that the PWM output is generated
by dedicated hardware, so not many CPU cycles would be wasted.

BTW, with a fan PWM signal generated by a soft-GPIO output, much
more CPU cycles would've been saved by omitting the fan definition
if it isn't present, but that isn't the case here.

> > However, the practice so far has been to describe the fans in the
> > main board dts files, if the board provides fan support, regardless
> > of the fan being present in a particular board setup or not.
> >
> > > I guess then in theory, an OS might allow the SoC to reach undesirably high
> > > temperatures if it's relying on the nonexistent fan to cool it down. But I
> > > don't think this would be an issue on Linux, at least, in practice.
> >
> > We're safe, a thermal runaway isn't going to happen when the fan is
> > defined in a board DT but actually isn't present.  Thermal CPU and
> > GPU throttling will prevent the overheating from happening.
> >
> > >> Overlays require more user configuration, and not all
> > >> bootloaders support them directly (e.g. systemd-boot users would
> > >> struggle). Compiling with overlays enabled also makes .dtb's a lot
> > >> larger due to added symbols information.
> > >
> > > Nowadays (on Debian at least) using overlays is pretty easy, I'm using the
> > > u-boot-menu package in Debian, I just copy the overlay(s) to /boot/dtbo/ and
> > > it detects them automatically and adds them to extlinux.conf for u-boot to
> > > apply.
> > >
> > > Couldn't systemd-boot users just use rk3588-nanopc-t6-(lts-)with-fan.dtb as
> > > their single DT to load, if it doesn't support applying overlays and they
> > > want to use the fan addon?
> 
> Sure, but it's a manual configuration step, where otherwise the kernel
> would just default to the correct dtb for the board that the firmware
> told it about. The fan is not discoverable, so the firmware won't ever
> offer the "-with-fan" variant, meaning users would need to supply it
> manually in every instance.

FWIW, the most user-friendly SBC family in the world, Raspberry
Pi, :) requires manual enabling of the fan on Raspberry Pi 4.
I haven't researched what's the background for that, perhaps the
need to keep the GPIO expansion header completely unoccupied by
default, because the fan attaches to the GPIO header, instead of
to some dedicated fan connector.

> > Yes, that's an option.  However, that in general doesn't resolve
> > the issues arising from systemd-boot users wanting to apply more
> > than a single DT overlay.
> >
> > > FWIW, I haven't noticed any problems with having a larger .dtb (using mainline
> > > U-Boot to load it) and several other RK3588 boards are also compiled with
> > > symbols enabled already, and I haven't seen any issues reported with them.
> >
> > After thinking a bit about it, I'd support the extraction of fan
> > definitions into separate DT overlays.  As I wrote above already,
> > not managing the non-existent fan might actually help a bit with
> > passively cooled board setups, which is a good enough reason for
> > me to support separate DT overlays.
> 
> Practical benefits sound far fetched here, while forcing users to
> manually configure something that would have otherwise just worked.
> Let's see what Heiko thinks.

Yeah, I forgot for a moment that the PWM signal is generated
by hardware, which means that the resulting overheads when no
fan is present are rather small.

> > If we end up agreeing to accept this DT overlay, I'll have some
> > comments on the way cooling maps are defined.  I think there's
> > quite a bit of redundancy there.
> 
> Agree. Thermal governors can figure out the fan speed ramp-up without
> specifying each and every temperature threshold manually. Two trips
> seem to be enough for everyone (c) - as we've done e.g. on Rock 5B and
> others.

Indeed, and if there are actually measurable/audible benefits
from having those manually defined thresholds/maps, then we
should start thinking about improving the already existing
fan-driving logic instead.


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[Diederik de Haas]

On Mon Oct 27, 2025 at 10:15 PM CET, Dragan Simic wrote:
> FWIW, the most user-friendly SBC family in the world, Raspberry
> Pi, :) requires manual enabling of the fan on Raspberry Pi 4.
> I haven't researched what's the background for that, perhaps the

RPi's have been using DT overlays basically from their start (ie way
before it became practically usable on the upstream kernel).


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[Heiko Stuebner]

Am Montag, 27. Oktober 2025, 22:15:05 Mitteleuropäische Normalzeit schrieb Dragan Simic:
> Hello Alexey,
> 
> On Monday, October 27, 2025 21:56 CET, Alexey Charkov <alchark@gmail.com> wrote:
> > On Tue, Oct 28, 2025 at 12:02 AM Dragan Simic <dsimic@manjaro.org> wrote:
> > > On Mon, Oct 27, 2025 at 7:08 PM Hugh Cole-Baker <sigmaris@gmail.com> wrote:
> > > > On 27/10/2025 09:14, Alexey Charkov wrote:
> > > >
> > > >> Is there any downside to enabling this unconditionally in the board
> > > >> .dts?
> > > >
> > > > Only that it goes against the principle that the DT should describe the
> > > > hardware; the board .dts would describe a cooling device that doesn't
> > > > actually exist on the base board.
> > >
> > > Having a separate DT overlay is perfectly fine if we want to
> > > describe a board absolutely correctly: if the fan actually isn't
> > > present, the operating system shouldn't be made to think it is
> > > there, especially if there's no fan RPM feedback, which is the
> > > case on almost all Rockchip boards that support a fan.
> > >
> > > Preventing the kernel from managing a non-existent fan might even
> > > save some CPU cycles, ending up producing a bit less heat, which
> > > can only help in passively cooled setups.
> > 
> > Sounds like an overcomplication without real benefit. It's one thing
> > with overlays for functionality that can be software-incompatible
> > depending on whether an external attachment is connected or depending
> > on the type of attachment connected. Here we are looking at a plain
> > 2-pin fan which cannot be software incompatible to anything really
> > (it's not like one could repurpose the fan connector for anything
> > meaningful if a fan is not in use, and noone gets hurt if a PWM output
> > is left running without load).
> > 
> > The CPU cycles spent parsing a slightly larger DTB at boot are likely
> > comparable to those spent activating a PWM output needlessly upon
> > hitting the active cooling trip point, and both are negligible for any
> > practical purpose.
> 
> Hmm, right, I forgot for a moment that the PWM output is generated
> by dedicated hardware, so not many CPU cycles would be wasted.
> 
> BTW, with a fan PWM signal generated by a soft-GPIO output, much
> more CPU cycles would've been saved by omitting the fan definition
> if it isn't present, but that isn't the case here.
> 
> > > However, the practice so far has been to describe the fans in the
> > > main board dts files, if the board provides fan support, regardless
> > > of the fan being present in a particular board setup or not.
> > >
> > > > I guess then in theory, an OS might allow the SoC to reach undesirably high
> > > > temperatures if it's relying on the nonexistent fan to cool it down. But I
> > > > don't think this would be an issue on Linux, at least, in practice.
> > >
> > > We're safe, a thermal runaway isn't going to happen when the fan is
> > > defined in a board DT but actually isn't present.  Thermal CPU and
> > > GPU throttling will prevent the overheating from happening.
> > >
> > > >> Overlays require more user configuration, and not all
> > > >> bootloaders support them directly (e.g. systemd-boot users would
> > > >> struggle). Compiling with overlays enabled also makes .dtb's a lot
> > > >> larger due to added symbols information.
> > > >
> > > > Nowadays (on Debian at least) using overlays is pretty easy, I'm using the
> > > > u-boot-menu package in Debian, I just copy the overlay(s) to /boot/dtbo/ and
> > > > it detects them automatically and adds them to extlinux.conf for u-boot to
> > > > apply.
> > > >
> > > > Couldn't systemd-boot users just use rk3588-nanopc-t6-(lts-)with-fan.dtb as
> > > > their single DT to load, if it doesn't support applying overlays and they
> > > > want to use the fan addon?
> > 
> > Sure, but it's a manual configuration step, where otherwise the kernel
> > would just default to the correct dtb for the board that the firmware
> > told it about. The fan is not discoverable, so the firmware won't ever
> > offer the "-with-fan" variant, meaning users would need to supply it
> > manually in every instance.
> 
> FWIW, the most user-friendly SBC family in the world, Raspberry
> Pi, :) requires manual enabling of the fan on Raspberry Pi 4.
> I haven't researched what's the background for that, perhaps the
> need to keep the GPIO expansion header completely unoccupied by
> default, because the fan attaches to the GPIO header, instead of
> to some dedicated fan connector.
> 
> > > Yes, that's an option.  However, that in general doesn't resolve
> > > the issues arising from systemd-boot users wanting to apply more
> > > than a single DT overlay.
> > >
> > > > FWIW, I haven't noticed any problems with having a larger .dtb (using mainline
> > > > U-Boot to load it) and several other RK3588 boards are also compiled with
> > > > symbols enabled already, and I haven't seen any issues reported with them.
> > >
> > > After thinking a bit about it, I'd support the extraction of fan
> > > definitions into separate DT overlays.  As I wrote above already,
> > > not managing the non-existent fan might actually help a bit with
> > > passively cooled board setups, which is a good enough reason for
> > > me to support separate DT overlays.
> > 
> > Practical benefits sound far fetched here, while forcing users to
> > manually configure something that would have otherwise just worked.
> > Let's see what Heiko thinks.

Personally, I'm more on the less complication side.

I.e. if there is an actual fan-connector on the board we should describe
it as such.

Overlays I see for things where you attach hats to generic pin headers
to create specific functionality on top of a generic interface.

But if the board itself has an actual fan header, it should be described
as such. Because that then _is_ the standard use of that.


Heiko



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[Hugh Cole-Baker]

On 01/11/2025 11:44, Heiko Stuebner wrote:
> Am Montag, 27. Oktober 2025, 22:15:05 Mitteleuropäische Normalzeit schrieb Dragan Simic:
>> Hello Alexey,
>>
>> On Monday, October 27, 2025 21:56 CET, Alexey Charkov <alchark@gmail.com> wrote:
>>> On Tue, Oct 28, 2025 at 12:02 AM Dragan Simic <dsimic@manjaro.org> wrote:
>>>> On Mon, Oct 27, 2025 at 7:08 PM Hugh Cole-Baker <sigmaris@gmail.com> wrote:
>>>>> On 27/10/2025 09:14, Alexey Charkov wrote:
>>>>>
>>>>>> Is there any downside to enabling this unconditionally in the board
>>>>>> .dts?
>>>>>
>>>>> Only that it goes against the principle that the DT should describe the
>>>>> hardware; the board .dts would describe a cooling device that doesn't
>>>>> actually exist on the base board.
>>>>
>>>> Having a separate DT overlay is perfectly fine if we want to
>>>> describe a board absolutely correctly: if the fan actually isn't
>>>> present, the operating system shouldn't be made to think it is
>>>> there, especially if there's no fan RPM feedback, which is the
>>>> case on almost all Rockchip boards that support a fan.
>>>>
>>>> Preventing the kernel from managing a non-existent fan might even
>>>> save some CPU cycles, ending up producing a bit less heat, which
>>>> can only help in passively cooled setups.
>>>
>>> Sounds like an overcomplication without real benefit. It's one thing
>>> with overlays for functionality that can be software-incompatible
>>> depending on whether an external attachment is connected or depending
>>> on the type of attachment connected. Here we are looking at a plain
>>> 2-pin fan which cannot be software incompatible to anything really
>>> (it's not like one could repurpose the fan connector for anything
>>> meaningful if a fan is not in use, and noone gets hurt if a PWM output
>>> is left running without load).
>>>
>>> The CPU cycles spent parsing a slightly larger DTB at boot are likely
>>> comparable to those spent activating a PWM output needlessly upon
>>> hitting the active cooling trip point, and both are negligible for any
>>> practical purpose.
>>
>> Hmm, right, I forgot for a moment that the PWM output is generated
>> by dedicated hardware, so not many CPU cycles would be wasted.
>>
>> BTW, with a fan PWM signal generated by a soft-GPIO output, much
>> more CPU cycles would've been saved by omitting the fan definition
>> if it isn't present, but that isn't the case here.
>>
>>>> However, the practice so far has been to describe the fans in the
>>>> main board dts files, if the board provides fan support, regardless
>>>> of the fan being present in a particular board setup or not.
>>>>
>>>>> I guess then in theory, an OS might allow the SoC to reach undesirably high
>>>>> temperatures if it's relying on the nonexistent fan to cool it down. But I
>>>>> don't think this would be an issue on Linux, at least, in practice.
>>>>
>>>> We're safe, a thermal runaway isn't going to happen when the fan is
>>>> defined in a board DT but actually isn't present.  Thermal CPU and
>>>> GPU throttling will prevent the overheating from happening.
>>>>
>>>>>> Overlays require more user configuration, and not all
>>>>>> bootloaders support them directly (e.g. systemd-boot users would
>>>>>> struggle). Compiling with overlays enabled also makes .dtb's a lot
>>>>>> larger due to added symbols information.
>>>>>
>>>>> Nowadays (on Debian at least) using overlays is pretty easy, I'm using the
>>>>> u-boot-menu package in Debian, I just copy the overlay(s) to /boot/dtbo/ and
>>>>> it detects them automatically and adds them to extlinux.conf for u-boot to
>>>>> apply.
>>>>>
>>>>> Couldn't systemd-boot users just use rk3588-nanopc-t6-(lts-)with-fan.dtb as
>>>>> their single DT to load, if it doesn't support applying overlays and they
>>>>> want to use the fan addon?
>>>
>>> Sure, but it's a manual configuration step, where otherwise the kernel
>>> would just default to the correct dtb for the board that the firmware
>>> told it about. The fan is not discoverable, so the firmware won't ever
>>> offer the "-with-fan" variant, meaning users would need to supply it
>>> manually in every instance.
>>
>> FWIW, the most user-friendly SBC family in the world, Raspberry
>> Pi, :) requires manual enabling of the fan on Raspberry Pi 4.
>> I haven't researched what's the background for that, perhaps the
>> need to keep the GPIO expansion header completely unoccupied by
>> default, because the fan attaches to the GPIO header, instead of
>> to some dedicated fan connector.
>>
>>>> Yes, that's an option.  However, that in general doesn't resolve
>>>> the issues arising from systemd-boot users wanting to apply more
>>>> than a single DT overlay.
>>>>
>>>>> FWIW, I haven't noticed any problems with having a larger .dtb (using mainline
>>>>> U-Boot to load it) and several other RK3588 boards are also compiled with
>>>>> symbols enabled already, and I haven't seen any issues reported with them.
>>>>
>>>> After thinking a bit about it, I'd support the extraction of fan
>>>> definitions into separate DT overlays.  As I wrote above already,
>>>> not managing the non-existent fan might actually help a bit with
>>>> passively cooled board setups, which is a good enough reason for
>>>> me to support separate DT overlays.
>>>
>>> Practical benefits sound far fetched here, while forcing users to
>>> manually configure something that would have otherwise just worked.
>>> Let's see what Heiko thinks.
> 
> Personally, I'm more on the less complication side.
> 
> I.e. if there is an actual fan-connector on the board we should describe
> it as such.
> 
> Overlays I see for things where you attach hats to generic pin headers
> to create specific functionality on top of a generic interface.
> 
> But if the board itself has an actual fan header, it should be described
> as such. Because that then _is_ the standard use of that.

The board does have a fan connector, just no fan by default. But anyway,
since it sounds like the preferred approach I'll send a v2 which puts the
fan into the base board .dts.

Dragan, you mentioned there's no need for more than 2 trip points - if
I remove the trip points between "SoC is warm, start fan at slow speed"
and "SoC is v. hot, run fan at full speed" is the OS/kernel expected to
interpolate between those 2 trip points (if you have a link to docs or
code about this it'd be interesting, I couldn't find anything in the
dt-bindings)?

Best regards, Hugh

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[Dragan Simic]

Hello Hugh,

On Saturday, November 01, 2025 14:14 CET, Hugh Cole-Baker <sigmaris@gmail.com> wrote:
> On 01/11/2025 11:44, Heiko Stuebner wrote:
> > Personally, I'm more on the less complication side.
> > 
> > I.e. if there is an actual fan-connector on the board we should describe
> > it as such.
> > 
> > Overlays I see for things where you attach hats to generic pin headers
> > to create specific functionality on top of a generic interface.
> > 
> > But if the board itself has an actual fan header, it should be described
> > as such. Because that then _is_ the standard use of that.
> 
> The board does have a fan connector, just no fan by default. But anyway,
> since it sounds like the preferred approach I'll send a v2 which puts the
> fan into the base board .dts.
> 
> Dragan, you mentioned there's no need for more than 2 trip points - if
> I remove the trip points between "SoC is warm, start fan at slow speed"
> and "SoC is v. hot, run fan at full speed" is the OS/kernel expected to
> interpolate between those 2 trip points (if you have a link to docs or
> code about this it'd be interesting, I couldn't find anything in the
> dt-bindings)?

True, that isn't described in the bindings, because it basically
doesn't belong there.  Thus, the most specific description of the
associated cooling stuff, as provided by the bindings, is the
following excerpt from Documentation/devicetree/bindings/thermal/
thermal-zones.yaml:

  209 cooling-device:
  210   $ref: /schemas/types.yaml#/definitions/phandle-array
  211   description:
  212     A list of cooling device phandles along with the minimum
  213     and maximum cooling state specifiers for each cooling
  214     device. Using the THERMAL_NO_LIMIT (-1UL) constant in the
  215     cooling-device phandle limit specifier lets the framework
  216     use the minimum and maximum cooling state for that cooling
  217     device automatically.

That's where the cooling hardware description ends, so that's also
where the associated binding ends.  Everything else belongs to the
thermal governors, because they actually decide on how to best use
the available cooling features.

For example, the chain of events may look like this:

  (1) The rockchip_thermal_alarm_irq_thread() function, defined in
      drivers/thermal/rockchip_thermal.c, gets triggered by TSADC
      within the parameters of DT-defined "active" trip types

  (2) It calls the thermal_zone_device_update() function defined
      in drivers/thermal/thermal_core.c

  (3) This ends up calling the step_wise_manage() function that's
      defined in drivers/thermal/gov_step_wise.c, which handles
      the previously triggered "active" trip

  (4) This calls the drivers/thermal/gov_step_wise.c's locally
      defined thermal_zone_trip_update() and get_target_state()
      functions, which end up ramping the fan speed up and down
      as needed, while respecting the upper and lower limits
      defined through the "cooling-device" DT map properties,
      which correspond to the "cooling-levels" defined in the
      DT fan property

Here's also an excerpt from drivers/thermal/gov_step_wise.c, which
confirms all this and explains it a bit further:

  113  /*
  114   * Throttling Logic: Use the trend of the thermal zone to throttle.
  115   * If the thermal zone is 'heating up', throttle all of the cooling
  116   * devices associated with each trip point by one step. If the zone
  117   * is 'cooling down', it brings back the performance of the devices
  118   * by one step.
  119   */

With all that in mind, the fan will ramp its speed up and down
nicely, according to the current temperature, with no need for
having multiple manually defined steps.

The intended benefit of having the two usual, distinct "active"
thermal trips and cooling maps is to lower the fan-induced noise
a bit while not affecting the cooling much.  This is all visible
in rk3399-rockpro64.dtsi, for example.


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH] arm64: dts: rockchip: pwm-fan overlay for NanoPC-T6

[Dragan Simic]

(Resending because the original message ended up on some spam lists,
seemingly as a result of some UTF-8 characters in the subject.)

Hello Hugh,

On Saturday, November 01, 2025 14:14 CET, Hugh Cole-Baker <sigmaris@gmail.com> wrote:
> On 01/11/2025 11:44, Heiko Stuebner wrote:
> > Personally, I'm more on the less complication side.
> > 
> > I.e. if there is an actual fan-connector on the board we should describe
> > it as such.
> > 
> > Overlays I see for things where you attach hats to generic pin headers
> > to create specific functionality on top of a generic interface.
> > 
> > But if the board itself has an actual fan header, it should be described
> > as such. Because that then _is_ the standard use of that.
> 
> The board does have a fan connector, just no fan by default. But anyway,
> since it sounds like the preferred approach I'll send a v2 which puts the
> fan into the base board .dts.
> 
> Dragan, you mentioned there's no need for more than 2 trip points - if
> I remove the trip points between "SoC is warm, start fan at slow speed"
> and "SoC is v. hot, run fan at full speed" is the OS/kernel expected to
> interpolate between those 2 trip points (if you have a link to docs or
> code about this it'd be interesting, I couldn't find anything in the
> dt-bindings)?

True, that isn't described in the bindings, because it basically
doesn't belong there.  Thus, the most specific description of the
associated cooling stuff, as provided by the bindings, is the
following excerpt from Documentation/devicetree/bindings/thermal/
thermal-zones.yaml:

  209 cooling-device:
  210   $ref: /schemas/types.yaml#/definitions/phandle-array
  211   description:
  212     A list of cooling device phandles along with the minimum
  213     and maximum cooling state specifiers for each cooling
  214     device. Using the THERMAL_NO_LIMIT (-1UL) constant in the
  215     cooling-device phandle limit specifier lets the framework
  216     use the minimum and maximum cooling state for that cooling
  217     device automatically.

That's where the cooling hardware description ends, so that's also
where the associated binding ends.  Everything else belongs to the
thermal governors, because they actually decide on how to best use
the available cooling features.

For example, the chain of events may look like this:

  (1) The rockchip_thermal_alarm_irq_thread() function, defined in
      drivers/thermal/rockchip_thermal.c, gets triggered by TSADC
      within the parameters of DT-defined "active" trip types

  (2) It calls the thermal_zone_device_update() function defined
      in drivers/thermal/thermal_core.c

  (3) This ends up calling the step_wise_manage() function that's
      defined in drivers/thermal/gov_step_wise.c, which handles
      the previously triggered "active" trip

  (4) This calls the drivers/thermal/gov_step_wise.c's locally
      defined thermal_zone_trip_update() and get_target_state()
      functions, which end up ramping the fan speed up and down
      as needed, while respecting the upper and lower limits
      defined through the "cooling-device" DT map properties,
      which correspond to the "cooling-levels" defined in the
      DT fan property

Here's also an excerpt from drivers/thermal/gov_step_wise.c, which
confirms all this and explains it a bit further:

  113  /*
  114   * Throttling Logic: Use the trend of the thermal zone to throttle.
  115   * If the thermal zone is 'heating up', throttle all of the cooling
  116   * devices associated with each trip point by one step. If the zone
  117   * is 'cooling down', it brings back the performance of the devices
  118   * by one step.
  119   */

With all that in mind, the fan will ramp its speed up and down
nicely, according to the current temperature, with no need for
having multiple manually defined steps.

The intended benefit of having the two usual, distinct "active"
thermal trips and cooling maps is to lower the fan-induced noise
a bit while not affecting the cooling much.  This is all visible
in rk3399-rockpro64.dtsi, for example.


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip