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

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

 



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@xxxxxxxxxxxx> wrote:

From: Balsam CHIHI <bchihi@xxxxxxxxxxxx>

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@xxxxxxxxxxxxx>

     v3 :
         - Rebased :
             base-commit: 6a3d37b4d885129561e1cef361216f00472f7d2e
         - Fix issues in v2 pointed out by Nícolas F. R. A. Prado <nfraprado@xxxxxxxxxxxxx>:
           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.

Why?

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.

It is not by design but just the code not returning the error when updating the thermal zone as it should so the side effect is giving the illusion everything is all right.

But of course, having the
temperature readout always work would be a desired improvement.

More than a desired improvement, it is mandatory. How can the thermal framework protect and mitigate the temperature with a twisted vision of the thermal situation?

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.

It sounds very strange how the filtered mode is working. We setup the filtered mode, then we shall receive an interrupt telling the data is ready so we can read it?

The issue with this is that it would cause *a lot* of
interrupts, which doesn't seem worth it.

Why not use the immediate mode + interrupts ?


--
<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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux