On Mon, Feb 13, 2017 at 1:38 PM, Anand Moon [off-list ref] wrote:

Hi Krzysztof,



On 12 February 2017 at 01:44, Krzysztof Kozlowski [off-list ref] wrote:

quoted

In Odroid XU3 Lite board, the temperature levels reported for thermal
zone 0 were weird. In warm room:
        /sys/class/thermal/thermal_zone0/temp:32000
        /sys/class/thermal/thermal_zone1/temp:51000
        /sys/class/thermal/thermal_zone2/temp:55000
        /sys/class/thermal/thermal_zone3/temp:54000
        /sys/class/thermal/thermal_zone4/temp:51000

Sometimes after booting the value was even equal to ambient temperature
which is highly unlikely to be a real temperature of sensor in SoC.

The thermal sensor's calibration (trimming) is based on fused values.
In case of the board above, the fused values are: 35, 52, 43, 58 and 43
(corresponding to each TMU device).  However driver defined a minimum value
for fused data as 40 and for smaller values it was using a hard-coded 55
instead.  This lead to mapping data from sensor to wrong temperatures
for thermal zone 0.

Various vendor 3.10 trees (Hardkernel's based on Samsung LSI, Artik 10)
do not impose any limits on fused values.  Since we do not have any
knowledge about these limits, use 0 as a minimum accepted fused value.
This should essentially allow accepting any reasonable fused value thus
behaving like vendor driver.

On HK following values are define in drivers/thermal/exynos_thermal.c

#define EFUSE_MIN_VALUE                         40
#define EFUSE_MAX_VALUE                         100

Are they being used?

Best regards,
Krzysztof