Re: RFC: Updating i.MX8M CPU thermal trip-point at runtime
On 14/04/2022 17:04, Tim Harvey wrote:
On Thu, Apr 14, 2022 at 3:58 AM Peng Fan (OSS) 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
Thanks everyone for your feedback. I'll see what I can do about
implementing this on U-Boot side.
Best regards,
Andrejs.
Re: RFC: Updating i.MX8M CPU thermal trip-point at runtime
On Thu, Apr 14, 2022 at 3:58 AM Peng Fan (OSS) 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
RE: RFC: Updating i.MX8M CPU thermal trip-point at runtime
> 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.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. > 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%2Fdata=04%7C01%7Cping.bai%40 > nxp.com%7Cb78589a916204ec81fb508da1df20c7a%7C686ea1d3bc2b4c6fa9 > 2cd99c5c301635%7C0%7C0%7C637855222675274340%7CUnknown%7CTW > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > CI6Mn0%3D%7C3000sdata=jkqzw1TBRvDA1FelABQUnZFTrCxG3sNZFTiu > P33p3EY%3Dreserved=0
Re: RFC: Updating i.MX8M CPU thermal trip-point at runtime
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/
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.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. Best regards Frieder [1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210601174917.1979-1-thar...@gateworks.com/
