linux-kernel - Re: [PATCH v7 4/4] thermal: mediatek: add another get

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8d9c51c8-8271-51de-a02c-4e44668be692@baylibre.com>
Date:   Wed, 25 Jan 2023 11:27:33 +0100
From:   Amjad Ouled-Ameur <aouledameur@...libre.com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Amit Kucheria <amitk@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Zhang Rui <rui.zhang@...el.com>
Cc:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Fabien Parent <fparent@...libre.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Markus Schneider-Pargmann <msp@...libre.com>,
        linux-pm@...r.kernel.org, Rob Herring <robh@...nel.org>,
        Michael Kao <michael.kao@...iatek.com>,
        linux-kernel@...r.kernel.org, Hsin-Yi Wang <hsinyi@...omium.org>,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v7 4/4] thermal: mediatek: add another get_temp ops for
 thermal sensors


On 1/25/23 11:02, Daniel Lezcano wrote:
> On 24/01/2023 23:27, Amjad Ouled-Ameur wrote:
>>
>> On 1/24/23 18:55, Daniel Lezcano wrote:
>>> On 24/01/2023 18:46, Amjad Ouled-Ameur wrote:
>>>>
>>>> On 1/24/23 17:54, Daniel Lezcano wrote:
>>>>>
>>>>> Hi Amjad,
>>>>>
>>>>> On 24/01/2023 11:08, Amjad Ouled-Ameur wrote:
>>>>>
>>>>> [ ... ]
>>>>>
>>>>>>>>
>>>>>>>> IIUC, there is a sensor per couple of cores. 1 x 2Bigs, 1 x 2Bigs, 1 x 4 Little, right ?
>>>>>>>
>>>>>>> MT8365 SoC has 4 x A53 CPUs. The SoC has 4 thermal zones per sensor. Thermal zone 0 corresponds
>>>>>>>
>>>>>>> to all 4 x A53 CPUs, the other thermal zones (1, 2 and 3) has nothing to do with CPUs. The cooling device type
>>>>>>>
>>>>>>> used for CPUs is passive. FYI, thermal zones 1, 2 and 3 are present in the SoC for debug-purpose only, they are not supposed
>>>>>>>
>>>>>>> to be used for production.
>>>>>>>
>>>>>> After reconsidering the fact that zones 1, 2 and 3 are only used for dev/debug, it might be best to avo >
>>>>>> aggregation as you suggested, and keep only support for zone 0 in this driver. Thus I suggest I send a V8
>>>>>>
>>>>>> where I keep only below fixes for this patch if that's okay with you:
>>>>>>
>>>>>> - Define "raw_to_mcelsius" function pointer for "struct thermal_bank_cfg".
>>>>>>
>>>>>> - Fix "mtk_thermal" variable in mtk_read_temp().
>>>>>>
>>>>>> - Set "mt->raw_to_mcelsius" in probe().
>>>>>>
>>>>>>
>>>>>> For zones 1, 2 and 3 we can later add a different driver specific for dev/debug to probe them to
>>>>>>
>>>>>> avoid confusion.
>>>>>
>>>>> You can add them in the driver and in the device tree, but just add the cooling device for the thermal zone 0.
>>>>
>>>> Thermal zone 0 uses CPU{0..3} for passive cooling, in this case we should register cooling device with
>>>>
>>>> cpufreq_cooling_register() for each CPU right ?
>>>
>>> No, the OF code device tree does already that. You just have to register the different thermal zones.
>>>
>>> Do you have a pointer to a device tree for this board and the thermal setup ?
>>
>> Sure, here is a dtsi for MT8365 SoC which contains thermal nodes [0].
>
> From my POV, there are two different setup with the DT but only one implementation with the driver.
>
> The driver should register all the thermal zones for each CPUs. For that, make things nice with the defines for the dt-bindings like [1].
>
> Then the device tree:
>
> setup1:
>
> Describe all the thermal zones in the DT which will be similar to [2]. Each CPU has a thermal zone, trip points and the same cooling device.
>
> The first thermal zone reaching the trip temperature threshold will start the mitigation. The thermal framework takes care of multiple thermal zones sharing the same cooling device.
>
> The result will be the same as the max temperature aggregation you did previously.
>
> setup2:
>
> Describe all the thermal zones in the DT [3], but add the cooling device only on the sensor you are interested in mitigating.
>
>
> And finally, if the sensors should be used to describe a kind of temperature gradient, a linear equation could be used but that is not implemented yet in the thermal framework.
>
> Hope that helps
>
Thank you Daniel for the thorough insights.

FYI, MT8195 SoC you referred to has a different thermal architecture and sensor mapping than on MT8365. The latter has only one

useful thermal zone corresponding to 4 CPUs at once. The other 3 thermal zones have no real purpose and will probably

not be defined in dtsi. Thus I sent a V8 of this series to keep only support for thermal zone 0 of interest.

Kindly,

Amjad

>   -- Daniel
>
> [1] https://lore.kernel.org/linux-arm-kernel/5dd5c795-5e67-146d-7132-30fc90171d4c@collabora.com/T/#Z2e.:..:20230124131717.128660-3-bchihi::40baylibre.com:1include:dt-bindings:thermal:mediatek-lvts.h
>
> [2] https://lore.kernel.org/linux-arm-kernel/5dd5c795-5e67-146d-7132-30fc90171d4c@collabora.com/T/#m303240c4da71f6f37831e5d1b6f3da771ae8dd90
>
> [3] https://lore.kernel.org/linux-arm-kernel/5dd5c795-5e67-146d-7132-30fc90171d4c@collabora.com/T/#Z2e.:..:20230124131717.128660-6-bchihi::40baylibre.com:1arch:arm64:boot:dts:mediatek:mt8195.dtsi
>
>