Re: [PATCH stable v4.4+] ARM: dts: exynos: Do not ignore real-world fuse values for thermal zone 0 on Exynos5420

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux