[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMdYzYpXwWdddVFFFQ=0MY0zCOR++n3gurkg-q7Jtrr7X_icQA@mail.gmail.com>
Date: Fri, 30 Jul 2021 11:12:39 -0400
From: Peter Geis <pgwipeout@...il.com>
To: Robin Murphy <robin.murphy@....com>
Cc: Rob Herring <robh+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
devicetree@...r.kernel.org,
arm-mail-list <linux-arm-kernel@...ts.infradead.org>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] arm64: dts: rockchip: add thermal fan control to rockpro64
On Fri, Jul 30, 2021 at 10:33 AM Robin Murphy <robin.murphy@....com> wrote:
>
> Hi Peter,
>
> On 2021-07-30 15:02, Peter Geis wrote:
> > The rockpro64 had a fan node since
> > commit 5882d65c1691 ("arm64: dts: rockchip: Add PWM fan for RockPro64")
> > however it was never tied into the thermal driver for automatic control.
> >
> > Add the links to the thermal node to permit the kernel to handle this
> > automatically.
> > Borrowed from the (rk3399-khadas-edge.dtsi).
> >
> > Signed-off-by: Peter Geis <pgwipeout@...il.com>
> > ---
> >
> > Changelog:
> > v2:
> > Adjusted fan setpoints for less noise
> >
> > .../boot/dts/rockchip/rk3399-rockpro64.dtsi | 57 +++++++++++++++++++
> > 1 file changed, 57 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> > index 6bff8db7d33e..0d79e6ae1c3a 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi
> > @@ -69,6 +69,7 @@ diy_led: led-1 {
> >
> > fan: pwm-fan {
> > compatible = "pwm-fan";
> > + cooling-levels = <0 100 150 200 255>;
> > #cooling-cells = <2>;
> > fan-supply = <&vcc12v_dcin>;
> > pwms = <&pwm1 0 50000 0>;
> > @@ -245,6 +246,34 @@ &cpu_b1 {
> > cpu-supply = <&vdd_cpu_b>;
> > };
> >
> > +&cpu_thermal {
> > + trips {
> > + cpu_warm: cpu_warm {
> > + temperature = <55000>;
> > + hysteresis = <2000>;
> > + type = "active";
> > + };
>
> (Heh, it still tickles me to see these points I arbitrarily made up
> being faithfully copied around - I guess that means I got them right!)
On the rockpro64 these points work quite nicely, I compile the kernel
natively so I hit the first one easily.
>
> > +
> > + cpu_hot: cpu_hot {
> > + temperature = <65000>;
> > + hysteresis = <2000>;
> > + type = "active";
> > + };
> > + };
> > +
> > + cooling-maps {
> > + map2 {
> > + trip = <&cpu_warm>;
> > + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> > + };
> > +
> > + map3 {
> > + trip = <&cpu_hot>;
> > + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> > + };
> > + };
> > +};
> > +
> > &emmc_phy {
> > status = "okay";
> > };
> > @@ -281,6 +310,34 @@ &gpu {
> > status = "okay";
> > };
> >
> > +&gpu_thermal {
> > + trips {
> > + gpu_warm: gpu_warm {
> > + temperature = <55000>;
> > + hysteresis = <2000>;
> > + type = "active";
> > + };
> > +
> > + gpu_hot: gpu_hot {
> > + temperature = <65000>;
> > + hysteresis = <2000>;
> > + type = "active";
> > + };
> > + };
> > +
> > + cooling-maps {
> > + map1 {
> > + trip = <&gpu_warm>;
> > + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> > + };
> > +
> > + map2 {
> > + trip = <&gpu_hot>;
> > + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> > + };
> > + };
> > +};
>
> Unless something's changed since commit a793e19c15f2 ("arm64: dts:
> rockchip: Fix NanoPC-T4 cooling maps"), multiple cooling maps don't
> actually share a singe cooling device properly[1]. The Khadas Edge DT
> dates from right around the same time so I guess it crossed over with
> that discussion and never got fixed.
>
> In hindsight, I do seem to remember my fan being a bit more jumpy around
> the trip points than it is today, which may well have been the two maps
> fighting each other...
>
> Robin.
>
> [1]
> https://lore.kernel.org/linux-rockchip/55b9018e-672e-522b-d0a0-c5655be0f353@linaro.org/
Interesting, so instead of "or-ing" the signals to the fan, the
thermal just fights with itself?
That explains interesting states where it can't decide if it wants to
run or not.
I'll pull the gpu portion and submit a v3, thanks!
>
> > +
> > &i2c0 {
> > clock-frequency = <400000>;
> > i2c-scl-rising-time-ns = <168>;
> >
Powered by blists - more mailing lists