Received-SPF: pass (google.com: domain of linux-kernel+bounces-32433-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240106222357.23835-1-alchark@gmail.com> <e0302da12345e5539583b2c96d747592@manjaro.org>
 <CABjd4Yw5wTLyK5OPw2S-ipPVCw7RTUeF2J0RgH-Vyis-ng8rTw@mail.gmail.com>
 <d7f2f25071a4d7c72bd286b11836dce7@manjaro.org> <CABjd4Yz11D8ThcT-oCWsQf9jL2idChFYSRYVVu3KNnzwoOwkKQ@mail.gmail.com>
 <f5c05015e042b11a51a9af26c35f18ed@manjaro.org> <CABjd4Yy91MAd2wALp4KQiEub9OyxU+MR+ti5KA_c+yvZT5xaqQ@mail.gmail.com>
 <81a5410c3dbedbd4fe9ce60ab236700c@manjaro.org>
In-Reply-To: <81a5410c3dbedbd4fe9ce60ab236700c@manjaro.org>
From: Alexey Charkov <alchark@gmail.com>
Date: Mon, 22 Jan 2024 11:36:50 +0400
Message-ID: <CABjd4YwxoPrKRPmjn-eWsU1N5fXCjAbnRwfKD9DLKgeL2=vHrA@mail.gmail.com>
Subject: Re: [PATCH] arm64: dts: rockchip: enable built-in thermal monitoring
 on rk3588
To: Dragan Simic <dsimic@manjaro.org>
Cc: Rob Herring <robh+dt@kernel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, 
	Heiko Stuebner <heiko@sntech.de>, Sebastian Reichel <sebastian.reichel@collabora.com>, 
	Cristian Ciocaltea <cristian.ciocaltea@collabora.com>, 
	Christopher Obbard <chris.obbard@collabora.com>, =?UTF-8?B?VGFtw6FzIFN6xbFjcw==?= <szucst@iit.uni-miskolc.hu>, 
	Shreeya Patel <shreeya.patel@collabora.com>, Kever Yang <kever.yang@rock-chips.com>, 
	Chris Morgan <macromorgan@hotmail.com>, devicetree@vger.kernel.org, 
	linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 22, 2024 at 10:22=E2=80=AFAM Dragan Simic <dsimic@manjaro.org> =
wrote:
>
> On 2024-01-22 07:03, Alexey Charkov wrote:
> > On Mon, Jan 22, 2024 at 8:55=E2=80=AFAM Dragan Simic <dsimic@manjaro.or=
g>
> > wrote:
> >> On 2024-01-21 19:56, Alexey Charkov wrote:
> >> > On Thu, Jan 18, 2024 at 10:48=E2=80=AFPM Dragan Simic <dsimic@manjar=
o.org> wrote:
> >> >> On 2024-01-08 14:41, Alexey Charkov wrote:
> >> >> > On Sun, Jan 7, 2024 at 2:54=E2=80=AFAM Dragan Simic <dsimic@manja=
ro.org> wrote:
> >> >> >> On 2024-01-06 23:23, Alexey Charkov wrote:
> >> >> >> > Include thermal zones information in device tree for rk3588 va=
riants
> >> >> >> > and enable the built-in thermal sensing ADC on RADXA Rock 5B
> >> >> >> >
> >> >> >> > Signed-off-by: Alexey Charkov <alchark@gmail.com>
> >> >> >> > ---
> >> >> >> > +                     trips {
> >> >> >> > +                             threshold: trip-point-0 {
> >> >> >>
> >> >> >> It should be better to name it cpu_alert0 instead, because that'=
s what
> >> >> >> other newer dtsi files already use.
> >> >> >
> >> >> > Reflecting on your comments here and below, I'm thinking that may=
be it
> >> >> > would be better to define only the critical trip point for the So=
C
> >> >> > overall, and then have alerts along with the respective cooling m=
aps
> >> >> > separately for A76-0,1, A76-2,3, A55-0,1,2,3? After all, given th=
at we
> >> >> > have more granular temperature measurement here than in previous =
RK
> >> >> > chipsets it might be better to only throttle the "offending" core=
s,
> >> >> > not the full package.
> >> >> >
> >> >> > What do you think?
> >> >> >
> >> >> > Downstream DT doesn't follow this approach though, so maybe there=
's
> >> >> > something I'm missing here.
> >> >>
> >> >> I agree, it's better to fully utilize the higher measurement
> >> >> granularity
> >> >> made possible by having multiple temperature sensors available.
> >> >>
> >> >> I also agree that we should have only the critical trip defined for
> >> >> the
> >> >> package-level temperature sensor.  Let's have the separate temperat=
ure
> >> >> measurements for the CPU (sub)clusters do the thermal throttling, a=
nd
> >> >> let's keep the package-level measurement for the critical shutdowns
> >> >> only.  IIRC, some MediaTek SoC dtsi already does exactly that.
> >> >>
> >> >> Of course, there are no reasons not to have the critical trips defi=
ned
> >> >> for the CPU (sub)clusters as well.
> >> >
> >> > I think I'll also add a board-specific active cooling mechanism on t=
he
> >> > package level in the next iteration, given that Rock 5B has a PWM fa=
n
> >> > defined as a cooling device. That will go in the separate patch that
> >> > updates rk3588-rock-5b.dts (your feedback to v2 of this patch is als=
o
> >> > duly noted, thank you!)
> >>
> >> Great, thanks.  Sure, making use of the Rock 5B's support for
> >> attaching
> >> a PWM-controlled cooling fan is the way to go.
> >>
> >> Just to reiterate a bit, any "active" trip points belong to the board
> >> dts file(s), because having a cooling fan is a board-specific feature.
> >> As a note, you may also want to have a look at the RockPro64 dts(i)
> >> files, for example;  the RockPro64 also comes with a cooling fan
> >> connector and the associated PWM fan control logic.
> >
> > Thanks for the pointer! There is also a helpful doc within devicetree
> > bindings descriptions, although it sits under hwmon which was a bit
> > confusing to me. I've already tested it locally (by adding to the
> > board dts), and it spins up and down quite nicely, and even modulates
> > the fan speed swiftly when the load changes - yay!
>
> Nice!  Also, isn't it like magic? :)  To me, turning LEDs on/off and
> controlling fans acts as some kind of a "bridge" between the virtual
> and the real world. :)

Oh yes! I also keep admiring how one can add just a couple of lines of
text here and there that's not even real code, and the whole kernel
machinery starts crunching numbers, analyzing temperatures, running
PID loops, etc etc so that I could enjoy the satisfying whistle of a
small fan when I type `make -j8` :-D

> As a suggestion, it would be good to test with a couple of different
> fans, to make sure that the PWM values work well for more that one fan
> model.  The Rock 5B requires a 5 V fan, if I'm not mistaken?

It is 5V, yes. I only have one fan to try though, and I simply relied
on the PWM values that are already defined in the upstream
rk3588-rock-5b.dts. They don't look ideal for my particular fan,
because the lowest non-zero cooling state currently uses a PWM value
of 95, which doesn't always make it spin up. But in the end it doesn't
seem to matter that much, because that tiny fan needs to spin at full
255 whenever all eight cores are loaded (and even then it can only
balance the temperature at around 60.5=D0=A1), and when the load is lighter
(such as during various ./configure runs) it just switches off
completely as the temperature goes down to 46C even with the fan not
spinning.

I don't currently use the GPU/NPU/VPU though - maybe those would
produce more moderate load which could benefit from spinning the fan
at medium speeds.

Best regards,
Alexey