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

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

[Andrejs Cainikovs]

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Andrejs Cainikovs]

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.

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

[Frieder Schrempf]

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.1979-1-tharvey@gateworks.com/

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

[Frieder Schrempf]

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.1979-1-tharvey@gateworks.com/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: 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@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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: 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@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

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

[Peng Fan (OSS)]

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.1979-1-tharvey@gateworks.com/
> 

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

[Peng Fan (OSS)]

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.1979-1-tharvey@gateworks.com/
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: 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@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.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

Re: 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@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.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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Andrejs Cainikovs]

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.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

Thanks everyone for your feedback. I'll see what I can do about 
implementing this on U-Boot side.

Best regards,
Andrejs.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Andrejs Cainikovs]

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.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

Thanks everyone for your feedback. I'll see what I can do about 
implementing this on U-Boot side.

Best regards,
Andrejs.