Linux-fslc temperature calibration in kernel driver imx_thermal.c

[ennebi]

Hi,

I'm using Linux-fslc with imx6ull.

I observed that the "i.MX 6ULL Applications Processor Reference Manual", at "Chapter 52 Temperature Monitor" specifies that temperature calibration is defined with 2 points:

- (N1, T1) = (ROOM_COUNT, 25.0)

- (N2, T2) = (HOT_COUNT, HOT_TEMP)

While the kernel driver imx_thermal.c (5.15 and 6.12 are the same), in imx_init_calib() considers only one calibration point: the OCOTP_ANA1[ROOM_COUNT] at 25°C as in the following code extract:

static int imx_init_calib(struct platform_device *pdev, u32 ocotp_ana1)
{
	struct imx_thermal_data *data = platform_get_drvdata(pdev);
	int n1;
	u64 temp64;

	if (ocotp_ana1 == 0 || ocotp_ana1 == ~0) {
		dev_err(&pdev->dev, "invalid sensor calibration data\n");
		return -EINVAL;
	}

	/*
	 * On i.MX7D, we only use the calibration data at 25C to get the temp,
	 * Tmeas = ( Nmeas - n1) + 25; n1 is the fuse value for 25C.
	 */
	if (data->socdata->version == TEMPMON_IMX7D) {
		data->c1 = (ocotp_ana1 >> 9) & 0x1ff;
		return 0;
	}

	/*
	 * The sensor is calibrated at 25 °C (aka T1) and the value measured
	 * (aka N1) at this temperature is provided in bits [31:20] in the
	 * i.MX's OCOTP value ANA1.
	 * To find the actual temperature T, the following formula has to be used
	 * when reading value n from the sensor:
	 *
	 * T = T1 + (N - N1) / (0.4148468 - 0.0015423 * N1) °C + 3.580661 °C
	 *   = [T1' - N1 / (0.4148468 - 0.0015423 * N1) °C] + N / (0.4148468 - 0.0015423 * N1) °C
	 *   = [T1' + N1 / (0.0015423 * N1 - 0.4148468) °C] - N / (0.0015423 * N1 - 0.4148468) °C
	 *   = c2 - c1 * N
	 *
	 * with
	 *
	 *  T1' = 28.580661 °C
	 *   c1 = 1 / (0.0015423 * N1 - 0.4297157) °C
	 *   c2 = T1' + N1 / (0.0015423 * N1 - 0.4148468) °C
	 *      = T1' + N1 * c1
	 */
	n1 = ocotp_ana1 >> 20;

	temp64 = 10000000; /* use 10^7 as fixed point constant for values in formula */
	temp64 *= 1000; /* to get result in °mC */
	do_div(temp64, 15423 * n1 - 4148468);
	data->c1 = temp64;
	data->c2 = n1 * data->c1 + 28581;

	return 0;
}

This line 'n1 = ocotp_ana1 >> 20', drops OCOTP_ANA1[HOT_COUNT] and OCOTP_ANA1[HOT_TEMP] and this leads to temperature inconsistencies.

To confirm this, I did some verifications on a board, by reading registers and calculating trip temperatures:

• Calibration register OCOTP_ANA1=0x50F4A269
  
  • ROOM_COUNT=0x50F = 1295
  • HOT_COUNT=0x4A2 = 1186
  • HOT_TEMP(°C)=0x69=105
• TEMPMON_TEMPSENSE0=0x4A551206
  • ALARM_VALUE=0x4A5=1189
• TEMPMON_TEMPSENSE2= 0x049D0FFF
  • PANIC_ALARM_VALUE=49D=1181

than I converted [ALARM_VALUE] and  [PANIC_ALARM_VALUE] to celsius temperature according to reference manual indication:

• Tmeas = HOT_TEMP - (Nmeas - HOT_COUNT) * ((HOT_TEMP - 25.0) /
  (ROOM_COUNT – HOT_COUNT))

so I got:

• Alarm/Passive temperature = 102,8°C
• Panic temperature = 108.7°C

those temperatures are greater than default trip temperature:

• Alarm/passive temperature = 95°C (10°c less than max temperature of 105°C)
• Panic temperature = 100°C (5°C less than max temperature of 105°C)

This looks like a potentially critical issue in the driver where the panic temperature is already above the maximum operating temperature from datasheet.

Can you confirm the issue?

[JorgeCas]

Hello,

Have you encountered any temperature measurement inaccuracies or trip temperature points are incorrect?

I have discussed the code with owner. It's an very old code and he though the algorithm should be okay.

Best regards.

[ennebi]

Hi Jorge,

as I reported in my initial post, I confirm you that trip temperature points are incorrect:

• actual Alarm/Passive temperature is 102,8°C instead of 95°C
• actual Panic temperature is 108.7°C instead of 100°C

This is a potentially critical issue, the panic temperature is above the maximum operating temperature of 105°C.