On Thu, Apr 14, 2022 at 3:58 AM Peng Fan (OSS) <peng....@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.cainik...@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-thar...@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