linux-kernel - Re: [PATCH v4 0/5] Add LVTS support for mt8192

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <59c7c90c-50f2-5a77-af12-b266c6e6e0b1@linaro.org>
Date:   Thu, 8 Jun 2023 11:39:27 +0200
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>, Chen-Yu Tsai <wenst@...omium.org>
Cc:     Bernhard Rosenkränzer <bero@...libre.com>,
        angelogioacchino.delregno@...labora.com, rafael@...nel.org,
        amitk@...nel.org, rui.zhang@...el.com, matthias.bgg@...il.com,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        rdunlap@...radead.org, ye.xingchen@....com.cn,
        p.zabel@...gutronix.de, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, devicetree@...r.kernel.org,
        james.lo@...iatek.com, rex-bc.chen@...iatek.com,
        abailon@...libre.com, amergnat@...libre.com, khilman@...libre.com
Subject: Re: [PATCH v4 0/5] Add LVTS support for mt8192

On 01/06/2023 19:09, Nícolas F. R. A. Prado wrote:
> On Wed, May 31, 2023 at 12:49:43PM +0800, Chen-Yu Tsai wrote:
>> On Wed, May 31, 2023 at 3:51 AM Bernhard Rosenkränzer <bero@...libre.com> wrote:
>>>
>>> From: Balsam CHIHI <bchihi@...libre.com>
>>>
>>> Add full LVTS support (MCU thermal domain + AP thermal domain) to MediaTek MT8192 SoC.
>>> Also, add Suspend and Resume support to LVTS Driver (all SoCs),
>>> and update the documentation that describes the Calibration Data Offsets.
>>>
>>> Changelog:
>>>      v4 :
>>>          - Shrink the lvts_ap thermal sensor I/O range to 0xc00 to make
>>>            room for SVS support, pointed out by
>>>            AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
>>>
>>>      v3 :
>>>          - Rebased :
>>>              base-commit: 6a3d37b4d885129561e1cef361216f00472f7d2e
>>>          - Fix issues in v2 pointed out by Nícolas F. R. A. Prado <nfraprado@...labora.com>:
>>>            Use filtered mode to make sure threshold interrupts are triggered,
>>
>> I'm seeing sensor readout (either through sysfs/thermal/<x>/temp or hwmon)
>> fail frequently on MT8192. If I run `sensors` (lm-sensors), at least a couple
>> of the LVTS sensors would be N/A. Not sure if this is related to this change.
> 
> Yes, it is. Filtered mode has some delay associated with reading, meaning most
> of the time the value isn't ready, while immediate mode is, well, pretty much
> immediate and the read always succeeds.
> 
> For temperature monitoring, filtered mode should be used. It supports triggering
> interrupts when crossing the thresholds. Immediate mode is meant for one-off
> readings of the temperature. This is why I suggested using filtered mode.
> 
> As far as the thermal framework goes, it's ok that filtered mode doesn't always
> return a value, as it will keep the old one. But of course, having the
> temperature readout always work would be a desired improvement.
> 
> As for ways to achieve that, I think the intended way would be to enable the
> interrupts that signal data ready on filtered mode (bits 19, 20, 21, 28), read
> the temperature and cache it so it is always available when the get_temp()
> callback is called. The issue with this is that it would cause *a lot* of
> interrupts, which doesn't seem worth it.
> 
> Another option that comes to mind would be to enable immediate mode only during
> the get_temp() callback, to immediately read a value, and return to filtered
> mode at the end. That might work, but I haven't tried yet.

Why not understand why the filtered mode is unable to return temperature 
values most of the time?

I tried with the filtered mode and I can see 90% of the time it is not 
possible to read the temperature.

IIUC there are timings which can be setup, may be understand how to set 
them up in order to read the temperature correctly?

Caching values, switching the mode or whatever is hackish :/

-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog