Message-ID: <14c91ee4-3a09-4ec9-966f-0d563d7c8966@linaro.org>
Date: Thu, 17 Jul 2025 10:20:35 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Heiko Stübner <heiko@...ech.de>,
 Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: Alexey Charkov <alchark@...il.com>, "Rafael J. Wysocki"
 <rafael@...nel.org>, Zhang Rui <rui.zhang@...el.com>,
 Lukasz Luba <lukasz.luba@....com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Jonas Karlman <jonas@...boo.se>,
 Sebastian Reichel <sebastian.reichel@...labora.com>, kernel@...labora.com,
 linux-pm@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org, Ye Zhang <ye.zhang@...k-chips.com>
Subject: Re: [PATCH v6 0/7] RK3576 thermal sensor support, including OTP trim
 adjustments

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


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

Powered by blists - more mailing lists