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

[Jacky Bai]

> Subject: Re: RFC: Updating i.MX8M CPU thermal trip-point at runtime
> 
> 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.
> 

On old i.MX6/7, the thermal driver is not based thermal_of framework, so it is easy to check the temperature grading fuse, then
update the trip point setting based on the fuse.

But for i.MX8M, the thermal driver is based on thermal_of, so it seems no easy way in linux kernel to update the trip point as on i.MX6/7.

Modifying the dts default trip point values base on grading fuse should be a feasible way.

BR
Jacky Bai

> Best regards
> Frieder
> 
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatchw
> ork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fpatch%2F20210601174917.
> 1979-1-tharvey%40gateworks.com%2F&data=04%7C01%7Cping.bai%40
> nxp.com%7Cb78589a916204ec81fb508da1df20c7a%7C686ea1d3bc2b4c6fa9
> 2cd99c5c301635%7C0%7C0%7C637855222675274340%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV
> CI6Mn0%3D%7C3000&sdata=jkqzw1TBRvDA1FelABQUnZFTrCxG3sNZFTiu
> P33p3EY%3D&reserved=0