From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: Rob Herring <robh@kernel.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Zhang Rui <rui.zhang@intel.com>,
Lukasz Luba <lukasz.luba@arm.com>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Heiko Stuebner <heiko@sntech.de>,
Sebastian Reichel <sebastian.reichel@collabora.com>,
kernel@collabora.com, linux-pm@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/6] dt-bindings: thermal: rockchip: document otp thermal trim
Date: Fri, 21 Feb 2025 14:27:58 +0100 [thread overview]
Message-ID: <4631308.LvFx2qVVIh@workhorse> (raw)
In-Reply-To: <20250219231036.GA3137058-robh@kernel.org>
On Thursday, 20 February 2025 00:10:36 Central European Standard Time Rob
Herring wrote:
> On Sun, Feb 16, 2025 at 12:34:53AM +0100, Nicolas Frattaroli wrote:
> > Several Rockchip SoCs, such as the RK3576, can store calibration trim
> > data for thermal sensors in OTP cells. This capability should be
> > documented.
>
> Is several most or a minority as this change is enabled for everyone.
Downstream has trim_h/trim_l nodes for the following SoCs:
- RK3502
- RK3528
- RK3562
- RK3566
- RK3568
- RK3576
- RV1126
If you'd prefer I split the bindings or add a conditional to only enable this
on those specific compatibles, let me know. It is worth noting that all of
these SoCs are fairly new, so I assume this is the design that Rockchip is
using going forward.
Additionally, trim_base/trim_base_frac seem to only be set in downstream DTs
for RK3562, RK3566, RK3568 and RV1126, so while I'm at it I'd add those to a
separate conditional as well.
> > Such a rockchip thermal sensor may reference cell handles that store
> > both a chip-wide trim for all the sensors, as well as cell handles
> > for each individual sensor channel pointing to that specific sensor's
> > trim value.
> >
> > Additionally, the thermal sensor may optionally reference cells which
> > store the base in terms of degrees celsius and decicelsius that the trim
> > is relative to.
> >
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> >
> > .../bindings/thermal/rockchip-thermal.yaml | 44
> > ++++++++++++++++++++++ 1 file changed, 44 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml
> > b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml index
> > 49ceed68c92ce5a32ed8d4f39bd88fd052de0e80..8d27ddefcc64e29f0faab0598888058
> > 02c948b41 100644 ---
> > a/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml +++
> > b/Documentation/devicetree/bindings/thermal/rockchip-thermal.yaml>
> > @@ -40,6 +40,21 @@ properties:
> > - const: tsadc
> > - const: apb_pclk
> >
> > + nvmem-cells:
> > + items:
> > + - description: cell handle of the low byte of the chip fallback
> > trim value + - description: cell handle of the high byte of the chip
> > fallback trim value + - description: cell handle to where the trim's
> > base temperature is stored + - description:
> > + cell handle to where the trim's tenths of Celsius base value is
> > stored +
> > + nvmem-cell-names:
> > + enum:
> > + - trim_l
> > + - trim_h
> > + - trim_base
> > + - trim_base_frac
> > +
> >
> > resets:
> > minItems: 1
> > maxItems: 3
> >
> > @@ -51,6 +66,12 @@ properties:
> > - const: tsadc
> > - const: tsadc-phy
> >
> > + "#address-cells":
> > + const: 1
> > +
> > + "#size-cells":
> > + const: 0
> > +
> >
> > "#thermal-sensor-cells":
> > const: 1
> >
> > @@ -72,6 +93,29 @@ properties:
> > $ref: /schemas/types.yaml#/definitions/uint32
> > enum: [0, 1]
> >
> > +patternProperties:
>
> > + "^([a-z]+)@[0-9]+$":
> If each node is a sensor or channel, then make that the node name.
Will do in V2. Should the node name be something like e.g. `gpu` for the GPU
thermal sensor/channel? Maybe suffixed with e.g. `-tsadc` or something, to
disambiguate it from other mentions of the GPU, or is disambiguation
unnecessary noise because it's evident from it being a child of tsadc anyway,
much like cpu and codec aren't suffixed with anything in simple-audio-card's
dai-link?
>
> > + type: object
> > + properties:
> > + reg:
> > + maxItems: 1
> > + description: sensor ID, a.k.a. channel number
> > +
> > + nvmem-cells:
> > + items:
> > + - description: handle of cell containing low byte of
> > calibration data + - description: handle of cell containing high
> > byte of calibration data +
> > + nvmem-cell-names:
> > + items:
> > + - const: trim_l
> > + - const: trim_h
> > +
> > + required:
> > + - reg
> > +
> > + unevaluatedProperties: false
> > +
> >
> > required:
> > - compatible
> > - reg
next prev parent reply other threads:[~2025-02-21 13:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-15 23:34 [PATCH 0/6] RK3576 thermal sensor support, including OTP trim adjustments Nicolas Frattaroli
2025-02-15 23:34 ` [PATCH 1/6] dt-bindings: rockchip-thermal: Add RK3576 compatible Nicolas Frattaroli
2025-02-19 23:03 ` Rob Herring (Arm)
2025-02-15 23:34 ` [PATCH 2/6] arm64: dts: rockchip: Add thermal nodes to RK3576 Nicolas Frattaroli
2025-02-15 23:34 ` [PATCH 3/6] thermal: rockchip: Support RK3576 SoC in the thermal driver Nicolas Frattaroli
2025-02-15 23:34 ` [PATCH 4/6] dt-bindings: thermal: rockchip: document otp thermal trim Nicolas Frattaroli
2025-02-19 23:10 ` Rob Herring
2025-02-21 13:27 ` Nicolas Frattaroli [this message]
2025-02-15 23:34 ` [PATCH 5/6] arm64: dts: rockchip: Add thermal trim OTP and tsadc nodes Nicolas Frattaroli
2025-02-20 1:14 ` Sebastian Reichel
2025-02-15 23:34 ` [PATCH 6/6] thermal: rockchip: support reading trim values from OTP Nicolas Frattaroli
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=4631308.LvFx2qVVIh@workhorse \
--to=nicolas.frattaroli@collabora.com \
--cc=conor+dt@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--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=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rui.zhang@intel.com \
--cc=sebastian.reichel@collabora.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