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

[Frieder Schrempf]

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.

Best regards
Frieder

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