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

[Tim Harvey]

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