public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Zhang Rui <rui.zhang@intel.com>,
	Lukasz Luba <lukasz.luba@arm.com>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Heiko Stuebner <heiko@sntech.de>, Jonas Karlman <jonas@kwiboo.se>,
	Ye Zhang <ye.zhang@rock-chips.com>,
	devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	kernel@collabora.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 0/7] RK3576 thermal sensor support, including OTP trim adjustments
Date: Wed, 16 Jul 2025 22:07:38 +0200	[thread overview]
Message-ID: <aHgGiojM3nnNg8Bk@mai.linaro.org> (raw)
In-Reply-To: <20250425-rk3576-tsadc-upstream-v5-0-0c840b99c30e@collabora.com>

On Fri, Apr 25, 2025 at 09:34:34PM +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.

Applied patches 1-5

Thanks
  -- Daniel

-- 

 <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


      parent reply	other threads:[~2025-07-16 21:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-25 19:34 [PATCH v5 0/7] RK3576 thermal sensor support, including OTP trim adjustments Nicolas Frattaroli
2025-04-25 19:34 ` [PATCH v5 1/7] thermal: rockchip: rename rk_tsadcv3_tshut_mode Nicolas Frattaroli
2025-04-25 19:34 ` [PATCH v5 2/7] dt-bindings: rockchip-thermal: Add RK3576 compatible Nicolas Frattaroli
2025-04-25 19:34 ` [PATCH v5 3/7] thermal: rockchip: Support RK3576 SoC in the thermal driver Nicolas Frattaroli
2025-04-25 19:34 ` [PATCH v5 4/7] dt-bindings: thermal: rockchip: document otp thermal trim Nicolas Frattaroli
2025-04-25 19:34 ` [PATCH v5 5/7] thermal: rockchip: support reading trim values from OTP Nicolas Frattaroli
2025-04-26  9:49   ` Diederik de Haas
2025-04-26 20:57     ` Nicolas Frattaroli
2025-04-25 19:34 ` [PATCH v5 6/7] arm64: dts: rockchip: Add thermal nodes to RK3576 Nicolas Frattaroli
2025-06-05 19:19   ` Alexey Charkov
2025-06-06  8:31     ` Nicolas Frattaroli
2025-04-25 19:34 ` [PATCH v5 7/7] arm64: dts: rockchip: Add thermal trim OTP and tsadc nodes Nicolas Frattaroli
2025-07-16 20:07 ` Daniel Lezcano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aHgGiojM3nnNg8Bk@mai.linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=jonas@kwiboo.se \
    --cc=kernel@collabora.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=lukasz.luba@arm.com \
    --cc=nicolas.frattaroli@collabora.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=sebastian.reichel@collabora.com \
    --cc=ye.zhang@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox