All of lore.kernel.org
 help / color / mirror / Atom feed
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






WARNING: multiple messages have this Message-ID (diff)
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





_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2025-02-21 13:30 UTC|newest]

Thread overview: 22+ 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 ` Nicolas Frattaroli
2025-02-15 23:34 ` [PATCH 1/6] dt-bindings: rockchip-thermal: Add RK3576 compatible Nicolas Frattaroli
2025-02-15 23:34   ` Nicolas Frattaroli
2025-02-19 23:03   ` Rob Herring (Arm)
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   ` 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   ` Nicolas Frattaroli
2025-02-15 23:34 ` [PATCH 4/6] dt-bindings: thermal: rockchip: document otp thermal trim Nicolas Frattaroli
2025-02-15 23:34   ` Nicolas Frattaroli
2025-02-19 23:10   ` Rob Herring
2025-02-19 23:10     ` Rob Herring
2025-02-21 13:27     ` Nicolas Frattaroli [this message]
2025-02-21 13:27       ` Nicolas Frattaroli
2025-02-15 23:34 ` [PATCH 5/6] arm64: dts: rockchip: Add thermal trim OTP and tsadc nodes Nicolas Frattaroli
2025-02-15 23:34   ` Nicolas Frattaroli
2025-02-20  1:14   ` Sebastian Reichel
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
2025-02-15 23:34   ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.