Hi Adam,
Am 13.09.2019 um 13:07 schrieb Adam Ford aford173@gmail.com:
cpu_cooling_maps: cooling-maps {map0 {trip = <&cpu_alert0>;/* Only allow OPP50 and OPP100 */cooling-device = <&cpu 0 1>;omap4-cpu-thermal.dtsi uses THERMAL_NO_LIMIT constants but I do not understand their meaning (and how it relates to the opp list).
I read through the documentation, but it wasn't completely clear to me. AFAICT, the numbers after &cpu represent the min and max index in the OPP table when the condition is hit.
Ok. It seems to use "cooling state" for those and the first is minimum and the last is maximum. Using THERMAL_NO_LIMIT (-1UL) means to have no limits.
Since here we use the &cpu node it is likely that the "cooling state" is the same as the OPP index currently in use.
I have looked through the .dts which use cpu_crit and the picture is not unique...
omap4 seems to only define it am57xx has two different grade dtsi files dra7 overwrites critical temperature value am57xx-beagle defines a gpio to control a fan
The fan is only a map0 for the board_alert0 starting to do something at 40°C and above but there is nothing for the "critical" point. But throttling is working on omap5...
Could there be some automatic handling by the govenors for the "critical" trip points? So that we do not need to define any cooling-maps for "critical"?
Even for the exynos54xx where the crical trip point is only defined.
};};Seems to make sense when comparing to omap4-cpu-thermal.dtsi...
Maybe we can add the trip points to omap3-cpu-thermal.dtsi because they seem to be the same for all omap3 variants and just have a SoC variant specific cooling map for omap36xx.dtsi.
The OPP's for OMAP3530 show that OPP5 and OPP6 are capable of operating at 105C. AM3517 is a little different also, so I didn't want to make a generic omap3 throttling table. Since my goal was to try to remove the need for the turbo option from the newly supported 1GHz omap3630/3730, I was hoping to get this pushed first. From there, we can tweak the 34xx.dtsi and 3517.dtsi for their respective thermal information.
My observation is that all omap3 have commercial range 0°C .. 90°C extended -40°C .. 105°C
So there is no difference in defining these as trip points and my proposal would be to have these in omap3.dtsi.
Only disabling OPPs differs. Which would make only the mapping go to omap36xx.
+};
/* OMAP3630 needs dss_96m_fck for VENC */ &venc { clocks = <&dss_tv_fck>, <&dss_96m_fck>; -- 2.17.1
The question is how we can test that. Heating up the omap36xx to 90°C or even 105°C isn't that easy like with omap5...
Maybe we can modify the millicelsius values for testing purposes to something in reachable range, e.g. 60°C and 70°C and watch what happens?
I have access to a thermal chamber at work, but the guy who knows how to use it is out for the rest of the week. My plan was do as you suggested and change the milicelsius values, but I wanted to get some buy-in from TI people and/or Tony. This also means enabling the omap3 thermal stuff which clearly throws a message that it's inaccurate.
Basically we need two different types of test: 1. is the DTS setup correct so that the bandgap sensor is read and triggers correct actions 2. is the bandgap sensor correct enough to that the data sheet limits are really met
I don't know how much it's inaccurate, so we may have to make the 90C value lower to compensate.
Hm. If the bandgap sensor is inaccurate, we should make sure it reports the maximum value, just to be on the safe side. So that the real temperature is guaranteed to be lower than what is reported.
Then we can use the data sheet limits of 90°C and 105°C in the trip point table (which should not be tweaked for sensor inaccuracy).
BR, Nikolaus
On Fri, Sep 13, 2019 at 8:32 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Adam,
Am 13.09.2019 um 13:07 schrieb Adam Ford aford173@gmail.com:
cpu_cooling_maps: cooling-maps {map0 {trip = <&cpu_alert0>;/* Only allow OPP50 and OPP100 */cooling-device = <&cpu 0 1>;omap4-cpu-thermal.dtsi uses THERMAL_NO_LIMIT constants but I do not understand their meaning (and how it relates to the opp list).
I read through the documentation, but it wasn't completely clear to me. AFAICT, the numbers after &cpu represent the min and max index in the OPP table when the condition is hit.
Ok. It seems to use "cooling state" for those and the first is minimum and the last is maximum. Using THERMAL_NO_LIMIT (-1UL) means to have no limits.
Since here we use the &cpu node it is likely that the "cooling state" is the same as the OPP index currently in use.
I have looked through the .dts which use cpu_crit and the picture is not unique...
omap4 seems to only define it am57xx has two different grade dtsi files dra7 overwrites critical temperature value am57xx-beagle defines a gpio to control a fan
Checkout rk3288-veyron-mickey.dts
They have almost_warm, warm, almost_hot, hot, hotter, very_hot, and critical for trips, and they have as many corresponding cooling maps which appear to limit the CPU speeds, but their index references are still confusing to me.
For that device, Warm and no limit first, then 4: coolling-device = <&cpu0 THERMAL_NO_LIMIT 4> ... very_hot uses a number then no limit: cooling-device = <&cpu0 8 THERMAL_NO_LIMIT>
This makes me wonder if the min and max are switched or the index values go backwards.
The fan is only a map0 for the board_alert0 starting to do something at 40°C and above but there is nothing for the "critical" point. But throttling is working on omap5...
Could there be some automatic handling by the govenors for the "critical" trip points? So that we do not need to define any cooling-maps for "critical"?
Even for the exynos54xx where the crical trip point is only defined.
};};Seems to make sense when comparing to omap4-cpu-thermal.dtsi...
Maybe we can add the trip points to omap3-cpu-thermal.dtsi because they seem to be the same for all omap3 variants and just have a SoC variant specific cooling map for omap36xx.dtsi.
The OPP's for OMAP3530 show that OPP5 and OPP6 are capable of operating at 105C. AM3517 is a little different also, so I didn't want to make a generic omap3 throttling table. Since my goal was to try to remove the need for the turbo option from the newly supported 1GHz omap3630/3730, I was hoping to get this pushed first. From there, we can tweak the 34xx.dtsi and 3517.dtsi for their respective thermal information.
My observation is that all omap3 have commercial range 0°C .. 90°C extended -40°C .. 105°C
So there is no difference in defining these as trip points and my proposal would be to have these in omap3.dtsi.
I can do that. I'll copy-paste the omap4 stuff using 90 and 105 as limits without any mapping. I'll then keep the mapping in omap3630
Only disabling OPPs differs. Which would make only the mapping go to omap36xx.
+};
/* OMAP3630 needs dss_96m_fck for VENC */ &venc { clocks = <&dss_tv_fck>, <&dss_96m_fck>; -- 2.17.1
The question is how we can test that. Heating up the omap36xx to 90°C or even 105°C isn't that easy like with omap5...
Maybe we can modify the millicelsius values for testing purposes to something in reachable range, e.g. 60°C and 70°C and watch what happens?
I have access to a thermal chamber at work, but the guy who knows how to use it is out for the rest of the week. My plan was do as you suggested and change the milicelsius values, but I wanted to get some buy-in from TI people and/or Tony. This also means enabling the omap3 thermal stuff which clearly throws a message that it's inaccurate.
Basically we need two different types of test:
- is the DTS setup correct so that the bandgap sensor is read and triggers correct actions
- is the bandgap sensor correct enough to that the data sheet limits are really met
I don't know how much it's inaccurate, so we may have to make the 90C value lower to compensate.
Hm. If the bandgap sensor is inaccurate, we should make sure it reports the maximum value, just to be on the safe side. So that the real temperature is guaranteed to be lower than what is reported.
Then we can use the data sheet limits of 90°C and 105°C in the trip point table (which should not be tweaked for sensor inaccuracy).
I can see not compensating if it reads high, but if the temp reads low, shouldn't compensate so we don't over temp the processor?
adam
BR, Nikolaus
Am 13.09.2019 um 16:05 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 8:32 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Adam,
Am 13.09.2019 um 13:07 schrieb Adam Ford aford173@gmail.com:
cpu_cooling_maps: cooling-maps {map0 {trip = <&cpu_alert0>;/* Only allow OPP50 and OPP100 */cooling-device = <&cpu 0 1>;omap4-cpu-thermal.dtsi uses THERMAL_NO_LIMIT constants but I do not understand their meaning (and how it relates to the opp list).
I read through the documentation, but it wasn't completely clear to me. AFAICT, the numbers after &cpu represent the min and max index in the OPP table when the condition is hit.
Ok. It seems to use "cooling state" for those and the first is minimum and the last is maximum. Using THERMAL_NO_LIMIT (-1UL) means to have no limits.
Since here we use the &cpu node it is likely that the "cooling state" is the same as the OPP index currently in use.
I have looked through the .dts which use cpu_crit and the picture is not unique...
omap4 seems to only define it am57xx has two different grade dtsi files dra7 overwrites critical temperature value am57xx-beagle defines a gpio to control a fan
Checkout rk3288-veyron-mickey.dts
They have almost_warm, warm, almost_hot, hot, hotter, very_hot, and critical for trips, and they have as many corresponding cooling maps which appear to limit the CPU speeds, but their index references are still confusing to me.
Seems to be quite sophistcated.
The arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi also has a lot of trip points. So there may be very different needs...
But it has potentially helpful comments...
/* * When reaching cpu0_alert3, reduce CPU * by 2 steps. On Exynos5422/5800 that would * be: 1600 MHz and 1100 MHz. */ map3 { trip = <&cpu0_alert3>; cooling-device = <&cpu0 0 2>; }; map4 { trip = <&cpu0_alert3>; cooling-device = <&cpu4 0 2>; }; /* * When reaching cpu0_alert4, reduce CPU * further, down to 600 MHz (12 steps for big, * 7 steps for LITTLE). */ map5 { trip = <&cpu0_alert4>; cooling-device = <&cpu0 3 7>; }; map6 { trip = <&cpu0_alert4>; cooling-device = <&cpu4 3 12>; };
That would mean the second integer is something about how many steps to reduce.
But the first is not explained.
BTW: this also demonstrates how a single trip point can map to multiple cooling-device actions (something we likely do not need).
For that device, Warm and no limit first, then 4: coolling-device = <&cpu0 THERMAL_NO_LIMIT 4> ... very_hot uses a number then no limit: cooling-device = <&cpu0 8 THERMAL_NO_LIMIT>
This makes me wonder if the min and max are switched or the index values go backwards.
It may depend on the specific cpu driver? Maybe even omap rk and exynos have different interpretation in code?
Then we can use the data sheet limits of 90°C and 105°C in the trip point table (which should not be tweaked for sensor inaccuracy).
I can see not compensating if it reads high, but if the temp reads low, shouldn't compensate so we don't over temp the processor?
I just mean that we must ensure that the TJ is <= 90° if the bandgap ever reports 90°. So it may report 10 or 20 or even 30 degrees more than the real temperature but never less (reaching the critical temperature too early but not too late).
We can achieve that by adding bias or changing slope etc. in the bandgap sensor driver.
If I find some time I am curious enough to look into the code and the data sheets to understand why it is said to be inaccurate... Maybe there is jitter from some LDO and it needs a median filter?
And why it seems to add a bias of ca. 10° as soon as I read it more than for the first time. And how well temperature correlates to ambient temperature (it definitively correlates to cpufreq-set -f).
But we should not modify the trip temperatures by 10 or 20 or 30 degrees. IMHO they should have the values defined by the data sheet.
BR, Nikolaus
On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Am 13.09.2019 um 16:05 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 8:32 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Adam,
Am 13.09.2019 um 13:07 schrieb Adam Ford aford173@gmail.com:
cpu_cooling_maps: cooling-maps {map0 {trip = <&cpu_alert0>;/* Only allow OPP50 and OPP100 */cooling-device = <&cpu 0 1>;omap4-cpu-thermal.dtsi uses THERMAL_NO_LIMIT constants but I do not understand their meaning (and how it relates to the opp list).
I read through the documentation, but it wasn't completely clear to me. AFAICT, the numbers after &cpu represent the min and max index in the OPP table when the condition is hit.
Ok. It seems to use "cooling state" for those and the first is minimum and the last is maximum. Using THERMAL_NO_LIMIT (-1UL) means to have no limits.
Since here we use the &cpu node it is likely that the "cooling state" is the same as the OPP index currently in use.
I have looked through the .dts which use cpu_crit and the picture is not unique...
omap4 seems to only define it am57xx has two different grade dtsi files dra7 overwrites critical temperature value am57xx-beagle defines a gpio to control a fan
I am going to push a separate but related RFC with 2 patches in the series. This new one will setup the alerts and maps without any throttling for all omap3's in the first patch. The second patch will consolidate the thermal references to omap3.dtsi so omap34, omap36 and am35 can all use them without having to duplicate the entries.
It will make the omap36xx changes simpler to manage, because we can just modify a portion of the entries instead of having the whole table.
Once this parallel RFC gets comments/feedback, I'll re-integrate the omap36xx throttling.
adam
Checkout rk3288-veyron-mickey.dts
They have almost_warm, warm, almost_hot, hot, hotter, very_hot, and critical for trips, and they have as many corresponding cooling maps which appear to limit the CPU speeds, but their index references are still confusing to me.
Seems to be quite sophistcated.
The arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi also has a lot of trip points. So there may be very different needs...
But it has potentially helpful comments...
/* * When reaching cpu0_alert3, reduce CPU * by 2 steps. On Exynos5422/5800 that would * be: 1600 MHz and 1100 MHz. */ map3 { trip = <&cpu0_alert3>; cooling-device = <&cpu0 0 2>; }; map4 { trip = <&cpu0_alert3>; cooling-device = <&cpu4 0 2>; }; /* * When reaching cpu0_alert4, reduce CPU * further, down to 600 MHz (12 steps for big, * 7 steps for LITTLE). */ map5 { trip = <&cpu0_alert4>; cooling-device = <&cpu0 3 7>; }; map6 { trip = <&cpu0_alert4>; cooling-device = <&cpu4 3 12>; };That would mean the second integer is something about how many steps to reduce.
But the first is not explained.
BTW: this also demonstrates how a single trip point can map to multiple cooling-device actions (something we likely do not need).
For that device, Warm and no limit first, then 4: coolling-device = <&cpu0 THERMAL_NO_LIMIT 4> ... very_hot uses a number then no limit: cooling-device = <&cpu0 8 THERMAL_NO_LIMIT>
This makes me wonder if the min and max are switched or the index values go backwards.
It may depend on the specific cpu driver? Maybe even omap rk and exynos have different interpretation in code?
Then we can use the data sheet limits of 90°C and 105°C in the trip point table (which should not be tweaked for sensor inaccuracy).
I can see not compensating if it reads high, but if the temp reads low, shouldn't compensate so we don't over temp the processor?
I just mean that we must ensure that the TJ is <= 90° if the bandgap ever reports 90°. So it may report 10 or 20 or even 30 degrees more than the real temperature but never less (reaching the critical temperature too early but not too late).
We can achieve that by adding bias or changing slope etc. in the bandgap sensor driver.
If I find some time I am curious enough to look into the code and the data sheets to understand why it is said to be inaccurate... Maybe there is jitter from some LDO and it needs a median filter?
And why it seems to add a bias of ca. 10° as soon as I read it more than for the first time. And how well temperature correlates to ambient temperature (it definitively correlates to cpufreq-set -f).
But we should not modify the trip temperatures by 10 or 20 or 30 degrees. IMHO they should have the values defined by the data sheet.
BR, Nikolaus
Am 13.09.2019 um 17:01 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Am 13.09.2019 um 16:05 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 8:32 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Adam,
Am 13.09.2019 um 13:07 schrieb Adam Ford aford173@gmail.com:
> + cpu_cooling_maps: cooling-maps { > + map0 { > + trip = <&cpu_alert0>; > + /* Only allow OPP50 and OPP100 */ > + cooling-device = <&cpu 0 1>;
omap4-cpu-thermal.dtsi uses THERMAL_NO_LIMIT constants but I do not understand their meaning (and how it relates to the opp list).
I read through the documentation, but it wasn't completely clear to me. AFAICT, the numbers after &cpu represent the min and max index in the OPP table when the condition is hit.
Ok. It seems to use "cooling state" for those and the first is minimum and the last is maximum. Using THERMAL_NO_LIMIT (-1UL) means to have no limits.
Since here we use the &cpu node it is likely that the "cooling state" is the same as the OPP index currently in use.
I have looked through the .dts which use cpu_crit and the picture is not unique...
omap4 seems to only define it am57xx has two different grade dtsi files dra7 overwrites critical temperature value am57xx-beagle defines a gpio to control a fan
I am going to push a separate but related RFC with 2 patches in the series. This new one will setup the alerts and maps without any throttling for all omap3's in the first patch. The second patch will consolidate the thermal references to omap3.dtsi so omap34, omap36 and am35 can all use them without having to duplicate the entries.
It will make the omap36xx changes simpler to manage, because we can just modify a portion of the entries instead of having the whole table.
Once this parallel RFC gets comments/feedback, I'll re-integrate the omap36xx throttling.
Good idea. I have looked over them and they seem to be ok.
adam
BR and thanks, Nikolaus
On Fri, Sep 13, 2019 at 10:09 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Am 13.09.2019 um 17:01 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Am 13.09.2019 um 16:05 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 8:32 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Adam,
Am 13.09.2019 um 13:07 schrieb Adam Ford aford173@gmail.com:
>> + cpu_cooling_maps: cooling-maps { >> + map0 { >> + trip = <&cpu_alert0>; >> + /* Only allow OPP50 and OPP100 */ >> + cooling-device = <&cpu 0 1>; > > omap4-cpu-thermal.dtsi uses THERMAL_NO_LIMIT constants but I do not > understand their meaning (and how it relates to the opp list).
I read through the documentation, but it wasn't completely clear to me. AFAICT, the numbers after &cpu represent the min and max index in the OPP table when the condition is hit.
Ok. It seems to use "cooling state" for those and the first is minimum and the last is maximum. Using THERMAL_NO_LIMIT (-1UL) means to have no limits.
Since here we use the &cpu node it is likely that the "cooling state" is the same as the OPP index currently in use.
I have looked through the .dts which use cpu_crit and the picture is not unique...
omap4 seems to only define it am57xx has two different grade dtsi files dra7 overwrites critical temperature value am57xx-beagle defines a gpio to control a fan
I am going to push a separate but related RFC with 2 patches in the series. This new one will setup the alerts and maps without any throttling for all omap3's in the first patch. The second patch will consolidate the thermal references to omap3.dtsi so omap34, omap36 and am35 can all use them without having to duplicate the entries.
It will make the omap36xx changes simpler to manage, because we can just modify a portion of the entries instead of having the whole table.
Once this parallel RFC gets comments/feedback, I'll re-integrate the omap36xx throttling.
Good idea. I have looked over them and they seem to be ok.
Rebasing my omap36xx throttling after the v2 RFC I pushed moving the omap3-cpu thermal stuff, I modified the omap36xx accordingly to try and force the alert condition:
&cpu_alert0 { temperature = <55000>; /* millicelsius */ };
&cpu_cooling_maps { map0 { /* OPP130 and OPP1G are not available above 90C */ cooling-device = <&cpu 0 2>; }; };
I would expect that with the temperature set for 55C, it would have done something, but it doesn't appear to be working as I would expect.
# cat /sys/devices/virtual/thermal/thermal_zone0/temp 58500
# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 300000 600000 800000 #
:-(
adam
BR and thanks, Nikolaus
On Fri, Sep 13, 2019 at 11:35 AM Adam Ford aford173@gmail.com wrote:
On Fri, Sep 13, 2019 at 10:09 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Am 13.09.2019 um 17:01 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Am 13.09.2019 um 16:05 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 8:32 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Adam,
> Am 13.09.2019 um 13:07 schrieb Adam Ford aford173@gmail.com:
>>> + cpu_cooling_maps: cooling-maps { >>> + map0 { >>> + trip = <&cpu_alert0>; >>> + /* Only allow OPP50 and OPP100 */ >>> + cooling-device = <&cpu 0 1>; >> >> omap4-cpu-thermal.dtsi uses THERMAL_NO_LIMIT constants but I do not >> understand their meaning (and how it relates to the opp list). > > I read through the documentation, but it wasn't completely clear to > me. AFAICT, the numbers after &cpu represent the min and max index in > the OPP table when the condition is hit.
Ok. It seems to use "cooling state" for those and the first is minimum and the last is maximum. Using THERMAL_NO_LIMIT (-1UL) means to have no limits.
Since here we use the &cpu node it is likely that the "cooling state" is the same as the OPP index currently in use.
I have looked through the .dts which use cpu_crit and the picture is not unique...
omap4 seems to only define it am57xx has two different grade dtsi files dra7 overwrites critical temperature value am57xx-beagle defines a gpio to control a fan
I am going to push a separate but related RFC with 2 patches in the series. This new one will setup the alerts and maps without any throttling for all omap3's in the first patch. The second patch will consolidate the thermal references to omap3.dtsi so omap34, omap36 and am35 can all use them without having to duplicate the entries.
It will make the omap36xx changes simpler to manage, because we can just modify a portion of the entries instead of having the whole table.
Once this parallel RFC gets comments/feedback, I'll re-integrate the omap36xx throttling.
Good idea. I have looked over them and they seem to be ok.
Rebasing my omap36xx throttling after the v2 RFC I pushed moving the omap3-cpu thermal stuff, I modified the omap36xx accordingly to try and force the alert condition:
&cpu_alert0 { temperature = <55000>; /* millicelsius */ };
&cpu_cooling_maps { map0 { /* OPP130 and OPP1G are not available above 90C */ cooling-device = <&cpu 0 2>; }; };
I would expect that with the temperature set for 55C, it would have done something, but it doesn't appear to be working as I would expect.
# cat /sys/devices/virtual/thermal/thermal_zone0/temp 58500
# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 300000 600000 800000 #
:-(
Good news (I think)
With cooling-device = <&cpu 1 2> setup, I was able to ask the max frequency and it returned 600MHz.
# cat /sys/devices/virtual/thermal/thermal_zone0/temp 58500 # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 300000 600000 800000 # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_m scaling_max_freq scaling_min_freq # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 600000
adam
adam
BR and thanks, Nikolaus
Am 13.09.2019 um 18:42 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 11:35 AM Adam Ford aford173@gmail.com wrote:
On Fri, Sep 13, 2019 at 10:09 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Am 13.09.2019 um 17:01 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 9:24 AM H. Nikolaus Schaller hns@goldelico.com wrote:
Am 13.09.2019 um 16:05 schrieb Adam Ford aford173@gmail.com:
On Fri, Sep 13, 2019 at 8:32 AM H. Nikolaus Schaller hns@goldelico.com wrote: > > Hi Adam, > >> Am 13.09.2019 um 13:07 schrieb Adam Ford aford173@gmail.com: > >>>> + cpu_cooling_maps: cooling-maps { >>>> + map0 { >>>> + trip = <&cpu_alert0>; >>>> + /* Only allow OPP50 and OPP100 */ >>>> + cooling-device = <&cpu 0 1>; >>> >>> omap4-cpu-thermal.dtsi uses THERMAL_NO_LIMIT constants but I do not >>> understand their meaning (and how it relates to the opp list). >> >> I read through the documentation, but it wasn't completely clear to >> me. AFAICT, the numbers after &cpu represent the min and max index in >> the OPP table when the condition is hit. > > Ok. It seems to use "cooling state" for those and the first is minimum > and the last is maximum. Using THERMAL_NO_LIMIT (-1UL) means to have > no limits. > > Since here we use the &cpu node it is likely that the "cooling state" > is the same as the OPP index currently in use. > > I have looked through the .dts which use cpu_crit and the picture is > not unique... > > omap4 seems to only define it > am57xx has two different grade dtsi files > dra7 overwrites critical temperature value > am57xx-beagle defines a gpio to control a fan
I am going to push a separate but related RFC with 2 patches in the series. This new one will setup the alerts and maps without any throttling for all omap3's in the first patch. The second patch will consolidate the thermal references to omap3.dtsi so omap34, omap36 and am35 can all use them without having to duplicate the entries.
It will make the omap36xx changes simpler to manage, because we can just modify a portion of the entries instead of having the whole table.
Once this parallel RFC gets comments/feedback, I'll re-integrate the omap36xx throttling.
Good idea. I have looked over them and they seem to be ok.
Rebasing my omap36xx throttling after the v2 RFC I pushed moving the omap3-cpu thermal stuff, I modified the omap36xx accordingly to try and force the alert condition:
&cpu_alert0 { temperature = <55000>; /* millicelsius */ };
&cpu_cooling_maps { map0 { /* OPP130 and OPP1G are not available above 90C */ cooling-device = <&cpu 0 2>; }; };
I would expect that with the temperature set for 55C, it would have done something, but it doesn't appear to be working as I would expect.
# cat /sys/devices/virtual/thermal/thermal_zone0/temp 58500
# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 300000 600000 800000 #
:-(
Good news (I think)
With cooling-device = <&cpu 1 2> setup, I was able to ask the max frequency and it returned 600MHz.
# cat /sys/devices/virtual/thermal/thermal_zone0/temp 58500 # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 300000 600000 800000 # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_m scaling_max_freq scaling_min_freq # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 600000
looks good! But we have to understand what the <&cpu 1 2> exactly means...
Hopefully someone reading your RFCv2 can answer...
What happens with trip point 60000? (unfortunately one has to reboot in between or can you kexec between two kernel/dtb versions?)
BR, Nikolaus
On 13/09/2019 18:51, H. Nikolaus Schaller wrote:
[ ... ]
Good news (I think)
With cooling-device = <&cpu 1 2> setup, I was able to ask the max frequency and it returned 600MHz.
# cat /sys/devices/virtual/thermal/thermal_zone0/temp 58500 # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 300000 600000 800000 # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_m scaling_max_freq scaling_min_freq # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 600000
looks good! But we have to understand what the <&cpu 1 2> exactly means...
Hopefully someone reading your RFCv2 can answer...
I may have missed the question :)
These are the states allowed for the cooling device (the one you can see in the /sys/class/thermal/cooling_device0/max_state. As the logic is inverted for cpufreq, that can be confusing.
If it was a fan with, let's say 5 speeds, you would use <&fan 0 5>, so when the mitigation begins the cooling device state is 0 and then the thermal governor increase the state until it sees a cooling effect.
If <&fan 0 2> is set, the governor won't set a state above 2 even if the temperature increases.
When the cooling driver is able to return the number of states it supports, it is safe to set the states to THERMAL_NO_LIMIT and let the governor to find the balance point.
Now if the cooling device is cpufreq, the state order is inverted, because the cooling effects happens when decreasing the OPP.
If the boards support 7 OPPs, the state 0 is 7 - 0, so no mitigation, if the state is 1, the cpufreq is throttle to the 6th OPP, 2 to the 5th OPP etc.
Now the different combinations:
<&cpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT> the governor will use the state 0 to 7.
<&cpu THERMAL_NO_LIMIT 2> the governor will use the state 0 to 2
<&cpu 1 2> the governor will use the state 1 and 2. That means there is always the cooling effect as the governor won't set it to zero thus stopping the mitigation.
Does it clarify the DT spec?
What happens with trip point 60000? (unfortunately one has to reboot in between or can you kexec between two kernel/dtb versions?)
BR, Nikolaus
On Fri, Sep 13, 2019 at 12:18 PM Daniel Lezcano daniel.lezcano@linaro.org wrote:
On 13/09/2019 18:51, H. Nikolaus Schaller wrote:
[ ... ]
Good news (I think)
With cooling-device = <&cpu 1 2> setup, I was able to ask the max frequency and it returned 600MHz.
# cat /sys/devices/virtual/thermal/thermal_zone0/temp 58500 # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 300000 600000 800000 # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_m scaling_max_freq scaling_min_freq # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 600000
looks good! But we have to understand what the <&cpu 1 2> exactly means...
Hopefully someone reading your RFCv2 can answer...
Daniel,
Thank you for replying.
I may have missed the question :)
These are the states allowed for the cooling device (the one you can see in the /sys/class/thermal/cooling_device0/max_state. As the logic is inverted for cpufreq, that can be confusing.
I think that's what has be confused.
If it was a fan with, let's say 5 speeds, you would use <&fan 0 5>, so when the mitigation begins the cooling device state is 0 and then the thermal governor increase the state until it sees a cooling effect.
If <&fan 0 2> is set, the governor won't set a state above 2 even if the temperature increases.
I am not sure I know what you mean by 'state' in this context.
When the cooling driver is able to return the number of states it supports, it is safe to set the states to THERMAL_NO_LIMIT and let the governor to find the balance point.
If the cooling driver is using cpufreq, is the number of supported states equal to the number of operating points given to cpufreq?
Now if the cooling device is cpufreq, the state order is inverted, because the cooling effects happens when decreasing the OPP.
If the boards support 7 OPPs, the state 0 is 7 - 0, so no mitigation, if the state is 1, the cpufreq is throttle to the 6th OPP, 2 to the 5th OPP etc.
I am not sure how the state would be set to 2.
Now the different combinations:
<&cpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT> the governor will use the state 0 to 7.
<&cpu THERMAL_NO_LIMIT 2> the governor will use the state 0 to 2
What would be the difference between <&cpu THERMAL_NO_LIMIT 2> and <&cpu 0 2> ? (if there is any)
<&cpu 1 2> the governor will use the state 1 and 2. That means there is always the cooling effect as the governor won't set it to zero thus stopping the mitigation.
For the purposes of the board in question, we have 4 operating points, 300MHz, 600MHz, 800MHz and 1GHz. Once the board reaches 90C, we need them to cease operation at 800MHz and 1GHz and only permit operation at 300MHz and 600MHz. I am going under the assumption that the cpu index[0] would be for 300MHz, index[1] = 600MHz, etc.
If I am interpreting your comment correctly, I should set <&cpu THERMAL_NO_LIMIT 2> which would allow it to either not cool and run up to 600MHz and not exceed, is that correct?
Does it clarify the DT spec?
I think your reply to my inquiry might. If possible, it would be nice to get this documented into the bindings doc for others in the future. I can do it, but someone with a better understanding of the concept maybe more qualified. I can totally understand why some may want to integrate this into their SoC device trees to slow the processor when hot.
Thank you for taking the time to review this. I appreciate it.
adam
What happens with trip point 60000? (unfortunately one has to reboot in between or can you kexec between two kernel/dtb versions?)
BR, Nikolaus
-- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog
On Fri, Sep 13, 2019 at 1:46 PM Adam Ford aford173@gmail.com wrote:
On Fri, Sep 13, 2019 at 12:18 PM Daniel Lezcano daniel.lezcano@linaro.org wrote:
On 13/09/2019 18:51, H. Nikolaus Schaller wrote:
[ ... ]
Good news (I think)
With cooling-device = <&cpu 1 2> setup, I was able to ask the max frequency and it returned 600MHz.
# cat /sys/devices/virtual/thermal/thermal_zone0/temp 58500 # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies 300000 600000 800000 # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_m scaling_max_freq scaling_min_freq # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 600000
looks good! But we have to understand what the <&cpu 1 2> exactly means...
Hopefully someone reading your RFCv2 can answer...
Daniel,
Thank you for replying.
I may have missed the question :)
These are the states allowed for the cooling device (the one you can see in the /sys/class/thermal/cooling_device0/max_state. As the logic is inverted for cpufreq, that can be confusing.
I think that's what has be confused.
If it was a fan with, let's say 5 speeds, you would use <&fan 0 5>, so when the mitigation begins the cooling device state is 0 and then the thermal governor increase the state until it sees a cooling effect.
If <&fan 0 2> is set, the governor won't set a state above 2 even if the temperature increases.
I am not sure I know what you mean by 'state' in this context.
When the cooling driver is able to return the number of states it supports, it is safe to set the states to THERMAL_NO_LIMIT and let the governor to find the balance point.
If the cooling driver is using cpufreq, is the number of supported states equal to the number of operating points given to cpufreq?
Now if the cooling device is cpufreq, the state order is inverted, because the cooling effects happens when decreasing the OPP.
If the boards support 7 OPPs, the state 0 is 7 - 0, so no mitigation, if the state is 1, the cpufreq is throttle to the 6th OPP, 2 to the 5th OPP etc.
I am not sure how the state would be set to 2.
Now the different combinations:
<&cpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT> the governor will use the state 0 to 7.
<&cpu THERMAL_NO_LIMIT 2> the governor will use the state 0 to 2
What would be the difference between <&cpu THERMAL_NO_LIMIT 2> and <&cpu 0 2> ? (if there is any)
<&cpu 1 2> the governor will use the state 1 and 2. That means there is always the cooling effect as the governor won't set it to zero thus stopping the mitigation.
For the purposes of the board in question, we have 4 operating points, 300MHz, 600MHz, 800MHz and 1GHz. Once the board reaches 90C, we need them to cease operation at 800MHz and 1GHz and only permit operation at 300MHz and 600MHz. I am going under the assumption that the cpu index[0] would be for 300MHz, index[1] = 600MHz, etc.
If I am interpreting your comment correctly, I should set <&cpu THERMAL_NO_LIMIT 2> which would allow it to either not cool and run up to 600MHz and not exceed, is that correct?
Does it clarify the DT spec?
I think your reply to my inquiry might. If possible, it would be nice to get this documented into the bindings doc for others in the future. I can do it, but someone with a better understanding of the concept maybe more qualified. I can totally understand why some may want to integrate this into their SoC device trees to slow the processor when hot.
Thank you for taking the time to review this. I appreciate it.
adam
What happens with trip point 60000? (unfortunately one has to reboot in between or can you kexec between two kernel/dtb versions?)
I set the trip point just above the ambient temp. I then tried to run some benchmarks in the background while constantly polling the max frequency and it changes, but it needs to skip the 800MHz point and jump right to the 600 MHz point (or lower)
# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 800000
# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 600000
Loops: 80000, Iterations: 1, Duration: 12 sec. C Converted Double Precision Whetstones: 666.7 MIPS # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 800000
[1]+ Done whetstone 80000
# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 800000
# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq 1000000
BR, Nikolaus
-- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog
-
Adam Ford -
Daniel Lezcano -
H. Nikolaus Schaller