RFC: Updating i.MX8M CPU thermal trip-point at runtime
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,
Best regards, Andrejs Cainikovs.
Hi Andrejs,
+Cc: Jacky Bai
Am 13.04.22 um 14:24 schrieb Andrejs Cainikovs:
[Sie erhalten nicht oft E-Mail von "andrejs.cainikovs@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.1...
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@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
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@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.1...
On Thu, Apr 14, 2022 at 3:58 AM Peng Fan (OSS) peng.fan@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@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.1...
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
On 14/04/2022 17:04, Tim Harvey wrote:
On Thu, Apr 14, 2022 at 3:58 AM Peng Fan (OSS) peng.fan@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@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.1...
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.
participants (5)
-
Andrejs Cainikovs -
Frieder Schrempf -
Jacky Bai -
Peng Fan (OSS) -
Tim Harvey