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

[Andrejs Cainikovs]

On 14/04/2022 17:04, Tim Harvey wrote:
> On Thu, Apr 14, 2022 at 3:58 AM Peng Fan (OSS) <peng.fan at oss.nxp.com> wrote:
>>
>>
>>
>> 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/
>>>
> 
> If you want to do it within the bootloader, dynamic during
> ft_board_setup look at: f8a792e51d17 ("board: gateworks: venice:
> update thermal temp thresholds per cpu grade")
> 
> I see no reason why this eventually couldn't be moved to somewhere
> imx8m specific. I do agree the kernel should be doing this on its own
> but as mentioned in the discussion it's not as simple.
> 
> Best Regards,
> 
> Tim

Thanks everyone for your feedback. I'll see what I can do about 
implementing this on U-Boot side.

Best regards,
Andrejs.