# Re: \[PATCH 1/4\] arm64: dts: imx8mm-venice-gw700x: override thermal cfg for industrial temp

- From: Frieder Schrempf \<hidden\>
- Date: 2021-06-07 08:34:51 
- List: linux-arm-kernel
- Page: https://ratatoskr.run/linux-arm-kernel/2021/06/8191837
- Thread: https://ratatoskr.run/linux-devicetree/2021/06/8191673/t.md

```text
On 07.06.21 10:00, Jacky Bai wrote:
>> Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override
>> thermal cfg for industrial temp
>>
>> On 07.06.21 09:30, Jacky Bai wrote:
>>>> Subject: Re: [PATCH 1/4] arm64: dts: imx8mm-venice-gw700x: override
>>>> thermal cfg for industrial temp
>>>>
>>>> On 04.06.21 17:42, Tim Harvey wrote:
>>>>> On Wed, Jun 2, 2021 at 12:11 AM Frieder Schrempf
>>>>> [ref] wrote:
>>>>>>
>>>>>> On 01.06.21 19:49, Tim Harvey wrote:
>>>>>>> Override the default temperature alert/crit for Industrial temp
>>>>>>> IMX8M Mini.
>>>>>>>
>>>>>>> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
>>>>>>> ---
>>>>>>>  .../boot/dts/freescale/imx8mm-venice-gw700x.dtsi     | 12
>>>> ++++++++++++
>>>>>>>  1 file changed, 12 insertions(+)
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
>>>>>>> b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
>>>>>>> index c769fadbd008..512b76cd7c3b 100644
>>>>>>> --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
>>>>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw700x.dtsi
>>>>>>> @@ -493,3 +493,15 @@
>>>>>>>               >;
>>>>>>>       };
>>>>>>>  };
>>>>>>> +
>>>>>>> +&cpu_alert0 {
>>>>>>> +     temperature = <95000>;
>>>>>>> +     hysteresis = <2000>;
>>>>>>> +     type = "passive";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&cpu_crit0 {
>>>>>>> +     temperature = <105000>;
>>>>>>> +     hysteresis = <2000>;
>>>>>>> +     type = "critical";
>>>>>>> +};
>>>>>>
>>>>>> As this is not really board-specific, I think the proper way to
>>>>>> handle this for
>>>> all boards is to let the thermal driver read the temperature grading
>>>> from the OTP fuses and set the trip-points accordingly, similar to
>>>> what is done on i.MX6 [1].
>>>>>>
>>> ...
>>>>>
>>>>> Frieder,
>>>>>
>>>>> Yes, I thought about adding that kind of support to imx8mm_thermal.c
>>>>> but the difference is that imx8mm has alerts defined by dt and imx6
>>>>> does not so is it right to override dt alerts on imx8m? What if
>>>>> someone designs a board that they specifically want a lower alert
>>>>> than the cpu grade they are using based on something else on the board?
>>>>>
>>>>> My approach to this was to eventually actually adjust the imx8m dt
>>>>> alerts in boot firmware based on some boot firmware setting or
>>>>> specific board support and leave the kernel alone.
>>>>
>>>> Allowing board-specific trip points sounds like a valid request, but
>>>> I still think we need a way to handle the temperature grading in the
>>>> driver if no board-specific trip-points are given.
>>>>
>>>> What if we just set the temperature property in the trip nodes in
>>>> imx8mm.dtsi to zero? The thermal driver would detect this and setup
>>>> the correct values according to the grading. If the dt already
>>>> provides non-zero temperature values (through the board dts) the
>>>> driver will just leave the values and disregard the grading.
>>>>
>>>> I think this solution would be covering all needs.
>>>
>>> I thought to add the grading check in the imx8mm_thermal.c to
>>> dynamically set the trip points temp, but it seems hard to do it due
>>> to the fact of_thermal is used, as no helper API is exported by of_thermal,
>> no better way to override the trip point temp.
>>>
>>> glad to see any good suggestions.
>>
>> Right, the driver doesn't handle the trip-points directly. This is all hidden in the
>> framework. So this might not be so easy to implement.
>>
>> What about this other approach: Adding all the possible trip-points for the
>> different gradings to the SoC-devicetree and then let the thermal driver
>> remove the trip nodes from the dt that are not valid for the detected grading,
>> just before the driver registers the sensor/zone.
> 
> It is more reasonable for the firmware/bootloader to handle this by checking the grading.

If possible, I would rather like to avoid creating another dependency on bootloader/firmware. I think the kernel should be able to detect the grading by itself and adjust its behavior accordingly. We also do this for the speed grading in cpufreq.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
```