[PATCH v4 2/3] thermal: exynos_tmu: Support new hardware and update TMU interface

Mon Sep 22 17:53:53 PDT 2025

Hello Henrik Grimler

> -----Original Message-----
> From: Henrik Grimler [mailto:henrik at grimler.se]
> Sent: Tuesday, September 23, 2025 5:05 AM
> To: Shin Son <shin.son at samsung.com>
> Cc: Bartlomiej Zolnierkiewicz <bzolnier at gmail.com>; Krzysztof Kozlowski
> <krzk at kernel.org>; Rafael J . Wysocki <rafael at kernel.org>; Daniel Lezcano
> <daniel.lezcano at linaro.org>; Zhang Rui <rui.zhang at intel.com>; Lukasz Luba
> <lukasz.luba at arm.com>; Rob Herring <robh at kernel.org>; Conor Dooley
> <conor+dt at kernel.org>; Alim Akhtar <alim.akhtar at samsung.com>; linux-
> pm at vger.kernel.org; linux-samsung-soc at vger.kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH v4 2/3] thermal: exynos_tmu: Support new hardware and
> update TMU interface
> 
> Hi Shin,
> 
> On Mon, Sep 22, 2025 at 01:18:56PM +0900, Shin Son wrote:
> > The Exynos tmu driver's private data structure has been extended to
> > support the exynosautov920 hardware, which requires per-sensor
> > interrupt enablement and multiple-zone handling:
> >
> > - Add 'slope_comp' : compensation parameter below 25 degrees.
> > - Add 'calib_temp' : stores the fused calibaration temperature.
> > - Add 'sensor_count' : reflects the maximum sensor numbers.
> > - Rename 'tzd' -> 'tzd_array' to register multiple thermal zones.
> >
> > Since splitting this patch causes runtime errors during temperature
> > emulation or problems where the read temperature feature fails to
> > retrieve values, I have submitted it as a single commit. To add
> > support for the exynosautov920 to the exisiting TMU interface, the
> > following changes are included:
> >
> > 1. Simplify "temp_to_code" and "code_to_temp" to one computation path
> >    by normalizing calib_temp.
> > 2. Loop over 'sensor_count' in critical-point setup.
> > 3. Introduce 'update_con_reg' for exynosautov920 control-register
> updates.
> > 4. Add exynosautov920-specific branch in 'exynos_tmu_update_temp'
> function.
> > 5. Skip high & low temperature threshold setup in exynosautov920.
> > 6. Enable interrupts via sensor_count in exynosautov920.
> > 7. Initialize all new members during 'exynosautov920_tmu_initialize'.
> > 8. Clear IRQs by iterating the sensor_count in exynosautov920.
> > 9. Register each zone with 'devm_thermal_of_zone_register()'
> >    based on 'sensor_count'.
> >
> > Signed-off-by: Shin Son <shin.son at samsung.com>
> > ---
> >  drivers/thermal/samsung/exynos_tmu.c | 322
> > ++++++++++++++++++++++++---
> >  1 file changed, 285 insertions(+), 37 deletions(-)
> >
> > diff --git a/drivers/thermal/samsung/exynos_tmu.c
> > b/drivers/thermal/samsung/exynos_tmu.c
> > index 47a99b3c5395..ebcc38f3fff6 100644
> > --- a/drivers/thermal/samsung/exynos_tmu.c
> > +++ b/drivers/thermal/samsung/exynos_tmu.c
> > @@ -121,8 +121,51 @@
> >
> >  #define EXYNOS_NOISE_CANCEL_MODE		4
> >
> > +/* ExynosAutov920 specific registers */
> > +#define EXYNOSAUTOV920_SLOPE_COMP		25
> > +#define EXYNOSAUTOV920_SLOPE_COMP_MASK		0xf
> > +#define EXYNOSAUTOV920_CALIB_SEL_TEMP		30
> > +#define EXYNOSAUTOV920_CALIB_SEL_TEMP_MASK	0x2
> > +
> > +#define EXYNOSAUTOV920_SENSOR0_TRIM_INFO	0x10
> > +#define EXYNOSAUTOV920_TRIM_MASK		0x1ff
> > +#define EXYNOSAUTOV920_TRIMINFO_25_SHIFT	0
> > +#define EXYNOSAUTOV920_TRIMINFO_85_SHIFT	9
> > +
> > +#define EXYNOSAUTOV920_TMU_REG_TRIMINFO2	0x04
> > +
> > +#define EXYNOSAUTOV920_TMU_REG_THRESHOLD(p)	(((p)) * 0x50 +
0x00d0)
> > +#define EXYNOSAUTOV920_TMU_REG_INTEN(p)		(((p)) * 0x50 +
> 0x00f0)
> > +#define EXYNOSAUTOV920_TMU_REG_INT_PEND(p)	(((p)) * 0x50 + 0x00f8)
> > +
> > +#define EXYNOSAUTOV920_CURRENT_TEMP_P1_P0	0x084
> > +#define EXYNOSAUTOV920_TMU_REG_EMUL_CON		0x0b0
> > +
> > +#define EXYNOSAUTOV920_TMU_REG_CONTROL		0x50
> > +#define EXYNOSAUTOV920_TMU_REG_CONTROL1		0x54
> > +#define EXYNOSAUTOV920_TMU_REG_AVG_CONTROL	0x58
> > +#define EXYNOSAUTOV920_TMU_SAMPLING_INTERVAL	0x70
> > +#define EXYNOSAUTOV920_TMU_REG_COUNTER_VALUE0	0x74
> > +#define EXYNOSAUTOV920_TMU_REG_COUNTER_VALUE1	0x78
> > +
> > +#define EXYNOSAUTOV920_TMU_T_BUF_VREF_SEL_SHIFT		8
> > +#define EXYNOSAUTOV920_TMU_T_BUF_VREF_SEL_MASK		0x1f
> > +#define EXYNOSAUTOV920_TMU_T_BUF_SLOPE_SEL_SHIFT	3
> > +#define EXYNOSAUTOV920_TMU_T_BUF_SLOPE_SEL_MASK		0xf
> > +#define EXYNOSAUTOV920_TMU_NUM_PROBE_MASK		0xf
> > +#define EXYNOSAUTOV920_TMU_NUM_PROBE_SHIFT		16
> > +#define EXYNOSAUTOV920_TMU_LPI_MODE_MASK		1
> > +#define EXYNOSAUTOV920_TMU_LPI_MODE_SHIFT		10
> > +
> > +#define EXYNOSAUTOV920_TMU_AVG_CON_UPDATE		0x0008011a
> > +#define EXYNOSAUTOV920_TMU_COUNTER_VALUE0_UPDATE	0x030003c0
> > +#define EXYNOSAUTOV920_TMU_COUNTER_VALUE1_UPDATE	0x03c0004d
> > +
> >  #define MCELSIUS	1000
> >
> > +#define EXYNOS_DEFAULT_SENSOR_COUNT			1
> > +#define EXYNOS_MAX_SENSOR_COUNT				16
> 
> In patch 1, sensor count is described as a value 0 <= sensor_count <= 15,
> but here max sensor count value is set to 16. Shouldn't max value be the
> same in these two places, what is the maximum number of thermal sensors
> that the hardware can have?

Sorry for the confusion. It actually refers to the maximum number of remote
sensors.
I'll change it to 15.

> 
> >  enum soc_type {
> >  	SOC_ARCH_EXYNOS3250 = 1,
> >  	SOC_ARCH_EXYNOS4210,
> > @@ -133,6 +176,7 @@ enum soc_type {
> >  	SOC_ARCH_EXYNOS5420_TRIMINFO,
> >  	SOC_ARCH_EXYNOS5433,
> >  	SOC_ARCH_EXYNOS7,
> > +	SOC_ARCH_EXYNOSAUTOV920,
> >  };
> >

...

> >  static int temp_to_code(struct exynos_tmu_data *data, u8 temp)  {
> > +	s32 temp_diff, code;
> > +
> >  	if (data->cal_type == TYPE_ONE_POINT_TRIMMING)
> >  		return temp + data->temp_error1 - EXYNOS_FIRST_POINT_TRIM;
> >
> > -	return (temp - EXYNOS_FIRST_POINT_TRIM) *
> > -		(data->temp_error2 - data->temp_error1) /
> > -		(EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) +
> > -		data->temp_error1;
> > +	temp_diff = temp - EXYNOS_FIRST_POINT_TRIM;
> > +
> > +	code = temp_diff * (data->temp_error2 - data->temp_error1) *
> MCELSIUS /
> > +	       (data->calib_temp - EXYNOS_FIRST_POINT_TRIM);
> > +
> > +	if (data->soc == SOC_ARCH_EXYNOSAUTOV920 && temp_diff < 0)
> > +		code = code * (57 + data->slope_comp) / 65;
> > +
> > +	return code / MCELSIUS + data->temp_error1;
> >  }
> >
> >  /*
> > @@ -220,13 +277,20 @@ static int temp_to_code(struct exynos_tmu_data
> *data, u8 temp)
> >   */
> >  static int code_to_temp(struct exynos_tmu_data *data, u16 temp_code)
> > {
> > +	s32 code_diff, temp;
> > +
> >  	if (data->cal_type == TYPE_ONE_POINT_TRIMMING)
> >  		return temp_code - data->temp_error1 +
> EXYNOS_FIRST_POINT_TRIM;
> >
> > -	return (temp_code - data->temp_error1) *
> > -		(EXYNOS_SECOND_POINT_TRIM - EXYNOS_FIRST_POINT_TRIM) /
> > -		(data->temp_error2 - data->temp_error1) +
> > -		EXYNOS_FIRST_POINT_TRIM;
> > +	code_diff = temp_code - data->temp_error1;
> > +
> > +	temp = code_diff * (data->calib_temp - EXYNOS_FIRST_POINT_TRIM) *
> MCELSIUS /
> > +	       (data->temp_error2 - data->temp_error1);
> > +
> > +	if (data->soc == SOC_ARCH_EXYNOSAUTOV920 && code_diff < 0)
> > +		temp = temp * 65 / (57 + data->slope_comp);
> > +
> > +	return temp / MCELSIUS + EXYNOS_FIRST_POINT_TRIM;
> >  }
> 
> Nice, these two functions looks much better compared to v2!

Thank you for your advice!

> 
> >  static void sanitize_temp_error(struct exynos_tmu_data *data, u32
> > trim_info) @@ -262,6 +326,9 @@ static int exynos_tmu_initialize(struct
> platform_device *pdev)

...

> > @@ -865,6 +1079,10 @@ static int exynos_map_dt_data(struct
> > platform_device *pdev)
> >
> >  	data->soc = (uintptr_t)of_device_get_match_data(&pdev->dev);
> >
> > +	data->sensor_count = EXYNOS_DEFAULT_SENSOR_COUNT;
> > +
> > +	data->calib_temp = EXYNOS_SECOND_POINT_TRIM;
> > +
> >  	switch (data->soc) {
> >  	case SOC_ARCH_EXYNOS4210:
> >  		data->tmu_set_low_temp = exynos4210_tmu_set_low_temp; @@ -
> 945,6
> > +1163,19 @@ static int exynos_map_dt_data(struct platform_device *pdev)
> >  		data->min_efuse_value = 15;
> >  		data->max_efuse_value = 100;
> >  		break;
> > +	case SOC_ARCH_EXYNOSAUTOV920:
> > +		data->tmu_set_low_temp = exynosautov920_tmu_set_low_temp;
> > +		data->tmu_set_high_temp = exynosautov920_tmu_set_high_temp;
> > +		data->tmu_disable_low = exynosautov920_tmu_disable_low;
> > +		data->tmu_disable_high = exynosautov920_tmu_disable_high;
> > +		data->tmu_set_crit_temp = exynosautov920_tmu_set_crit_temp;
> > +		data->tmu_initialize = exynosautov920_tmu_initialize;
> > +		data->tmu_control = exynosautov920_tmu_control;
> > +		data->tmu_read = exynosautov920_tmu_read;
> > +		data->tmu_set_emulation = exynos4412_tmu_set_emulation;
> > +		data->tmu_clear_irqs = exynosautov920_tmu_clear_irqs;
> > +		data->sensor_count = EXYNOS_MAX_SENSOR_COUNT;
> > +		break;
> >  	default:
> >  		dev_err(&pdev->dev, "Platform not supported\n");
> >  		return -EINVAL;
> > @@ -952,6 +1183,14 @@ static int exynos_map_dt_data(struct
> > platform_device *pdev)
> >
> >  	data->cal_type = TYPE_ONE_POINT_TRIMMING;
> >
> > +	if (data->soc == SOC_ARCH_EXYNOSAUTOV920) {
> > +		if (of_property_read_u32(pdev->dev.of_node,
> "samsung,sensors",
> > +					 &data->sensor_count)) {
> > +			dev_err(&pdev->dev, "failed to get sensor count\n");
> > +			return -ENODEV;
> > +		}
> > +	}
> 
> Do we really need the `if (data->soc == SOC_ARCH_EXYNOSAUTOV920)` here, I
> am sure there will be more socs that use samsung,sensors. Can't we simply
> read samsung,sensors for all socs and use EXYNOS_DEFAULT_SENSOR_COUNT if
> it fails, or would it be potentially dangerous if samsung,sensors is
> missing for autov920 dtb and default value of 1 is used?
> 
> Best regards,
> Henrik Grimler
> 

Yes. Incorrect remote-sensor settings can affect TMU operation. For
example, when the sensor count is set to 1,
The thermal zone doesn't function properly and the hardware trip doesn't
assert on the v920 variant.
I consider that configuration unsafe, so I added variant-specific handling
for that SoC.
Meanwhile, the other variant legitimately uses only a single sensor.