On Tue, 12 Mar 2019 at 13:17, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Mar 12, 2019 at 01:14:00PM +0100, Krzysztof Kozlowski wrote: > > 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? > > The upstream version does not apply directly at all: > > checking file arch/arm/boot/dts/exynos5420-tmu-sensor-conf.dtsi > checking file arch/arm/boot/dts/exynos5420.dtsi > Hunk #1 succeeded at 703 with fuzz 1 (offset 4 lines). > Hunk #2 FAILED at 708. > Hunk #3 succeeded at 712 with fuzz 1 (offset -5 lines). > Hunk #4 succeeded at 721 with fuzz 1 (offset -5 lines). > Hunk #5 succeeded at 730 with fuzz 1 (offset -5 lines). > 1 out of 5 hunks FAILED > > so yes, a backport is needed :) Ah, it seems that differences were solvable for cherry-pick but not for apply. Sure, let me send a backport. Best regards, Krzysztof
