public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.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>,
	Diederik de Haas <didi.debian@cknow.org>
Cc: 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 5/7] thermal: rockchip: support reading trim values from OTP
Date: Sat, 26 Apr 2025 22:57:04 +0200	[thread overview]
Message-ID: <2891736.iZASKD2KPV@workhorse> (raw)
In-Reply-To: <D9GH5V09WW47.358SY1F7LJ9ZV@cknow.org>

On Saturday, 26 April 2025 11:49:13 Central European Summer Time Diederik de Haas wrote:
> Hi Nicolas,
> 
> On Fri Apr 25, 2025 at 9:34 PM CEST, Nicolas Frattaroli wrote:
> > Many of the Rockchip SoCs support storing trim values for the sensors in
> > factory programmable memory. These values specify a fixed offset from
> > the sensor's returned temperature to get a more accurate picture of what
> > temperature the silicon is actually at.
> >
> > The way this is implemented is with various OTP cells, which may be
> > absent. There may both be whole-TSADC trim values, as well as per-sensor
> > trim values.
> >
> > In the downstream driver, whole-chip trim values override the per-sensor
> > trim values. This rewrite of the functionality changes the semantics to
> > something I see as slightly more useful: allow the whole-chip trim
> > values to serve as a fallback for lacking per-sensor trim values,
> > instead of overriding already present sensor trim values.
> >
> > Additionally, the chip may specify an offset (trim_base, trim_base_frac)
> > in degrees celsius and degrees decicelsius respectively which defines
> > what the basis is from which the trim, if any, should be calculated
> > from. By default, this is 30 degrees Celsius, but the chip can once
> > again specify a different value through OTP cells.
> 
> Would it be useful to define all the values in the same unit?
> Having celsius and decicelsius and millicelsius sounds like a recipe for
> (future) off-by-10/-100/-1000 errors.

No. It is not possible to redefine the unit of these, because the values are 
factory programmed into these one-time programmable cells.

> And possibly define-ing the '30' so people don't need this commit
> message to figure out where that magic number comes from?

There is no constant of 30 in the code to define anywhere. This is what the
factory programmed values are referenced against.

> And also the '923' for ``.trim_slope``?

.trim_slope is an SoC specific value that does not need to be defined a second
time in a different place, it lives in the SoC data for that reason, much like
the code tables and which functions the driver should use for this chip. There
is nothing to be gained here from the indirection.

> 
> > The implementation of these trim calculations have been tested
> > extensively on an RK3576, where it was confirmed to get rid of pesky 1.8
> > degree Celsius offsets between certain sensors.
> >
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> >  drivers/thermal/rockchip_thermal.c | 221 +++++++++++++++++++++++++++++++++----
> >  1 file changed, 202 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c
> > index 89e3180667e2a8f0ef5542b0db4d9e19a21a24d3..3beff9b6fac3abe8948b56132b618ff1bed57217 100644
> > --- a/drivers/thermal/rockchip_thermal.c
> > +++ b/drivers/thermal/rockchip_thermal.c
> > @@ -9,6 +9,7 @@
> >  #include <linux/interrupt.h>
> >  #include <linux/io.h>
> >  #include <linux/module.h>
> > +#include <linux/nvmem-consumer.h>
> >  #include <linux/of.h>
> >  #include <linux/of_address.h>
> >  #include <linux/of_irq.h>
> > @@ -69,16 +70,18 @@ struct chip_tsadc_table {
> >   * struct rockchip_tsadc_chip - hold the private data of tsadc chip
> >   * @chn_offset: the channel offset of the first channel
> >   * @chn_num: the channel number of tsadc chip
> > - * @tshut_temp: the hardware-controlled shutdown temperature value
> > + * @trim_slope: used to convert the trim code to a temperature in millicelsius
> > + * @tshut_temp: the hardware-controlled shutdown temperature value, with no trim
> 
> Having the same units used everywhere would also avoid possible
> confusion here as ``trim_slope`` explicitly mentions millicelsius, but
> ``tshut_temp`` does not, but AFAIK it's also in millicelsius.

That seems like an additional change out of scope for this series, and does not
need to hold up this patch series for a v6.

> 
> Cheers,
>   Diederik
> 
> >   * @tshut_mode: the hardware-controlled shutdown mode (0:CRU 1:GPIO)
> >   * @tshut_polarity: the hardware-controlled active polarity (0:LOW 1:HIGH)
> >   * @initialize: SoC special initialize tsadc controller method
> >   * @irq_ack: clear the interrupt
> >   * @control: enable/disable method for the tsadc controller
> > - * @get_temp: get the temperature
> > + * @get_temp: get the raw temperature, unadjusted by trim
> >   * @set_alarm_temp: set the high temperature interrupt
> >   * @set_tshut_temp: set the hardware-controlled shutdown temperature
> >   * @set_tshut_mode: set the hardware-controlled shutdown mode
> > + * @get_trim_code: convert a hardware temperature code to one adjusted for by trim
> >   * @table: the chip-specific conversion table
> >   */
> >  struct rockchip_tsadc_chip {
> > @@ -86,6 +89,9 @@ struct rockchip_tsadc_chip {
> 






  reply	other threads:[~2025-04-26 20:59 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 [this message]
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 ` [PATCH v5 0/7] RK3576 thermal sensor support, including OTP trim adjustments Daniel Lezcano

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=2891736.iZASKD2KPV@workhorse \
    --to=nicolas.frattaroli@collabora.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=didi.debian@cknow.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=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