RFC: Updating i.MX8M CPU thermal trip-point at runtime

[Peng Fan (OSS)]

On 2022/4/14 16:37, Frieder Schrempf wrote:
> Hi Andrejs,
> 
> +Cc: Jacky Bai
> 
> Am 13.04.22 um 14:24 schrieb Andrejs Cainikovs:
>> [Sie erhalten nicht oft E-Mail von "andrejs.cainikovs at toradex.com".
>> Weitere Informationen, warum dies wichtig ist, finden Sie unter
>> "http://aka.ms/LearnAboutSenderIdentification".]
>>
>> Hi everyone,
>>
>> Recent issue that I had to deal with sparkled a discussion within my
>> team, and seems like we are not sure what would be a proper way to go,
>> even if there are multiple ways to do it. We decided to ask this
>> question to open-source community, in case someone has thoughts about it.
>>
>> At Toradex we have multiple computer on modules, each of those has few
>> variants - different memory sizes, with or without WiFi/BT, etc. One of
>> the options is also a temperature grade - IT and non-IT. Obviously, we
>> want to keep number of device trees as minimal as possible, since number
>> of device trees grows exponentially if we add a new option via device
>> tree, i.e. imx8mm-verdin-it-wifi-dev.dts +
>> imx8mm-verdin-nonit-wifi-dev.dts.
>>
>> Hence, we are working on a change that would update trips temperatures
>> in Linux device tree on the fly, setting them to whatever is read from
>> CPU fuses. Now, the question is - where would be the best place to do
>> it? So far we were thinking about following options:
>>
>> - Patching U-Boot thermal driver so that it would propagate max
>> temperature to Linux device tree.
>> - Patching U-Boot board files to update Linux device tree via
>> ft_board_setup(). This, however, will result in a duplicate code among
>> different boards within same SoC family.
>> - Anything else not listed here.
>>
>> I would appreciate any comments or thoughts regarding this topic. Thanks,
> 
> Thanks for bringing up the topic. We've been discussing this previously
> here: [1].
> 
> The bootloader doesn't really benefit from the information about the
> temperature grading, does it? Therefore I would rather think about a
> solution where the kernel itself, or more specifically the TMU driver
> reads the grading from the fuses and sets the trip points accordingly.
> So we don't create another dependency between bootloader and kernel.
> 
> Anyway, if you rather want to handle this in the bootloader and pass it
> via device tree, I guess this would also be ok. In this case the code
> should be added to the thermal driver or the platform code and not in
> any board specific files to avoid duplication, as you already mentioned.

I would prefer let bootloader handle this, that would be simple.

Regards,
Peng.

> 
> Best regards
> Frieder
> 
> [1]
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210601174917.1979-1-tharvey@gateworks.com/
>