Re: [PATCH v6 0/7] RK3576 thermal sensor support, including OTP trim adjustments

["Heiko Stübner" <heiko@sntech.de>]

Hey Alexey,

Am Donnerstag, 31. Juli 2025, 09:33:32 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> On Thu, Jul 17, 2025 at 12:20 PM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
> >
> > On 7/17/25 09:21, Heiko Stübner wrote:
> > > Hi Daniel,
> > >
> > > Am Mittwoch, 16. Juli 2025, 22:12:53 Mitteleuropäische Sommerzeit schrieb Daniel Lezcano:
> > >> On Tue, Jun 10, 2025 at 02:32:36PM +0200, Nicolas Frattaroli wrote:
> > >>> This series adds support for the RK3576's thermal sensor.
> > >>>
> > >>> The sensor has six channels, providing measurements for the package
> > >>> temperature, the temperature of the big cores, the temperature of the
> > >>> little cores, and the GPU, NPU and DDR controller.
> > >>>
> > >>> In addition to adding support for the sensor itself, the series also
> > >>> adds support for reading thermal trim values out of the device tree.
> > >>> Most of this functionality is not specific to this SoC, but needed to be
> > >>> implemented to make the sensors a little more accurate in order to
> > >>> investigate whether the TRM swapped GPU and DDR or downstream swapped
> > >>> GPU and DDR in terms of channel IDs, as downstream disagrees with what's
> > >>> in the TRM, and the difference is so small and hard to pin down with
> > >>> testing that the constant offset between the two sensors was a little
> > >>> annoying for me to deal with.
> > >>>
> > >>> I ended up going with the channel assignment the TRM lists, as I see the
> > >>> DDR sensor get a larger deviation from baseline temperatures during memory
> > >>> stress tests (stress-ng --memrate 8 --memrate-flush) than what the TRM
> > >>> claims is the GPU sensor but downstream claims is the DDR sensor. Input
> > >>> from Rockchip engineers on whether the TRM is right or wrong welcome.
> > >>>
> > >>> The trim functionality is only used by RK3576 at the moment. Code to
> > >>> handle other SoCs can rely on the shared otp reading and perhaps even
> > >>> the IP revision specific function, but may need its own IP revision
> > >>> specific functions added as well. Absent trim functionality in other
> > >>> SoCs should not interfere with the modified common code paths.
> > >>>
> > >>> Patch 1 is a cleanup patch for the rockchip thermal driver, where a
> > >>> function was confusingly named.
> > >>>
> > >>> Patch 2 adds the RK3576 compatible to the bindings.
> > >>>
> > >>> Patch 3 adds support for this SoC's thermal chip to the driver. It is a
> > >>> port of the downstream commit adding support for this.
> > >>>
> > >>> Patch 4 adds some documentation for imminent additional functionality to
> > >>> the binding, namely the trim value stuff.
> > >>>
> > >>> Patch 5 adds support for reading these OTP values in the
> > >>> rockchip_thermal driver, and makes use of them. The code is mostly new
> > >>> upstream code written by me, using downstream code as reference.
> > >>
> > >> Replaced previously applied version V5 with this V6 patches 1-5
> > >
> > > are these commits available somewhere?
> > >
> > > Because git.kernel.org reports that
> > >    https://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git
> > > has not seen activity in a while?
> > >
> >
> > I just pushed the bleeding-edge branch
> 
> Just wondering if patches 6-7 from this series are on your radar?
> Driver changes are in -next AFAICT, but not DTS. Can't wait to get the
> temperature monitoring working on RK3576 without out-of-tree patches
> ;-)

they are :-) .

Right now we're in the middle of the merge-window though, so everything
I apply now, I'd need to rebase onto -rc1 in slightly more than a week,
invalidating all those nice commit hashes that end up in the "applied" mails.

So I'm struggling with myself on every merge window about that.


Heiko