On Tue, 12 Mar 2019 at 13:09, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Mar 12, 2019 at 12:56:22PM +0100, Krzysztof Kozlowski wrote: > > commit 28928a3ce142b2e4e5a7a0f067cefb41a3d2c3f9 upstream. > > > > 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. > > > > The exynos5420-tmu-sensor-conf.dtsi is copied directly from existing > > exynos4412 with one change - the samsung,tmu_min_efuse_value. > > > > Signed-off-by: Krzysztof Kozlowski <krzk@xxxxxxxxxx> > > Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@xxxxxxxxxxx> > > Acked-by: Eduardo Valentin <edubezval@xxxxxxxxx> > > Reviewed-by: Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx> > > Tested-by: Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx> > > Reviewed-by: Anand Moon <linux.amoon@xxxxxxxxx> > > Tested-by: Anand Moon <linux.amoon@xxxxxxxxx> > > --- > > arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi | 25 +++++++++++++++++++++++ > > arch/arm/boot/dts/exynos5420.dtsi | 10 ++++----- > > 2 files changed, 30 insertions(+), 5 deletions(-) > > create mode 100644 arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi > > this backport does not apply to 4.9.y, but only 4.4.y. Can you also > send a 4.9.y backport so that someone moving from 4.4.y to 4.9.y does > not get a regression? v4.9 should also get it and you can apply directly the upstream commit: 28928a3ce142b2e4e5a7a0f067cefb41a3d2c3f9 (v4.4 required indentation adjustment) Shall I send a version for v4.9 or can you apply the upstream directly? Best regards, Krzysztof
