[Letux-kernel] 1.5GHz operation surprise

H. Nikolaus Schaller hns at goldelico.com
Fri Sep 13 22:48:39 CEST 2019


> Am 13.09.2019 um 22:43 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> Am 13.09.2019 um 22:40 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> Hi,
>> I have digged out an old mail describing OMAP5 temperature throttling experiments
>> (using some 4.x kernel):
>> 
>> It looks as if throttling starts at 100°C and may go downwards by
>> multiple OPPs (I had additional ones at 750, 500, 250 MHz).
>> 
>> Since TJ cools down quickly (<1 second) the clock rate goes up
>> almost immediately to the highest OPP again.
>> 
>> I now think we do not need to do it differently for OMAP3, just different
>> temperature.
>> 
>> So in total it may be simpler as we thought:
>> * just add a 90° trip point (and 125°C "critcial" but no mapping)
>> * map it to <&cpu THERMAL_NO_LIMIT THERMAL_NO_LIMIT>
>> * if >90° it will go from OPP1G (state 3) -> OPP130 (state 2)
>> * if this is not enough it will go OPP130 -> OPP100 (state 1)
>> * if this is not enough it will go OPP100 -> OPP50 (state 0)
> 
> So we just need simlar to omap4-cpu-thermal.dtsi:
> 
> cpu_thermal: cpu_thermal {
> 	polling-delay-passive = <250>; /* milliseconds */
> 	polling-delay = <1000>; /* milliseconds */
> 
> 			/* sensor       ID */
>        thermal-sensors = <&bandgap     0>;
> 
> 	cpu_trips: trips {
>                cpu_alert0: cpu_alert {
>                        temperature = <90000>; /* millicelsius */
>                        hysteresis = <2000>; /* millicelsius */
>                        type = "passive";
>                };
>                cpu_crit: cpu_crit {
>                        temperature = <105000>; /* millicelsius */
>                        hysteresis = <2000>; /* millicelsius */
>                        type = "critical";
>                };
>        };
> 
> 	cpu_cooling_maps: cooling-maps {
> 		map0 {
> 			trip = <&cpu_alert0>;
> 			cooling-device =
> 				<&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> 		};
> 	};
> };
> 
> And contrary to my thinking that we should do that only for omap36xx
> we can simply do it for any OMAP3. This makes sure that none overheats...

Well, no OMAP3 will then use the not explicitly forbidden temperature
range of 90° .. 105° at lower OPPs. But IMHO this is unlikely than anyone
is missing such system operation states.

> 
> BR,
> Nikolaus
> 
> 
>> 
>> BR,
>> Nikolaus
>> 
>>> Anfang der weitergeleiteten Nachricht:
>>> 
>>> Von: "H. Nikolaus Schaller" <hns at goldelico.com>
>>> Betreff: 1.5GHz operation surprise
>>> Datum: 25. Februar 2017 um 17:28:48 MEZ
>>> An: kernel at pyra-handheld.com
>>> 
>>> Hi all,
>>> here is a very surprising result which needs independent confirmation.
>>> 
>>> root at letux:~# cpufreq-info 
>>> cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
>>> Report errors and bugs to cpufreq at vger.kernel.org, please.
>>> analyzing CPU 0:
>>> driver: cpufreq-dt
>>> CPUs which run at the same hardware frequency: 0 1
>>> CPUs which need to have their frequency coordinated by software: 0 1
>>> maximum transition latency: 400 us.
>>> hardware limits: 250 MHz - 1.50 GHz
>>> available frequency steps: 250 MHz, 500 MHz, 750 MHz, 1000 MHz, 1.25 GHz, 1.50 GHz
>>> available cpufreq governors: conservative, userspace, powersave, ondemand, performance
>>> current policy: frequency should be within 250 MHz and 1.50 GHz.
>>>                The governor "ondemand" may decide which speed to use
>>>                within this range.
>>> current CPU frequency is 250 MHz (asserted by call to hardware).
>>> cpufreq stats: 250 MHz:10.27%, 500 MHz:37.39%, 750 MHz:9.76%, 1000 MHz:24.02%, 1.25 GHz:6.92%, 1.50 GHz:11.64%  (60)
>>> analyzing CPU 1:
>>> driver: cpufreq-dt
>>> CPUs which run at the same hardware frequency: 0 1
>>> CPUs which need to have their frequency coordinated by software: 0 1
>>> maximum transition latency: 400 us.
>>> hardware limits: 250 MHz - 1.50 GHz
>>> available frequency steps: 250 MHz, 500 MHz, 750 MHz, 1000 MHz, 1.25 GHz, 1.50 GHz
>>> available cpufreq governors: conservative, userspace, powersave, ondemand, performance
>>> current policy: frequency should be within 250 MHz and 1.50 GHz.
>>>                The governor "ondemand" may decide which speed to use
>>>                within this range.
>>> current CPU frequency is 250 MHz (asserted by call to hardware).
>>> cpufreq stats: 250 MHz:10.29%, 500 MHz:37.38%, 750 MHz:9.76%, 1000 MHz:24.01%, 1.25 GHz:6.92%, 1.50 GHz:11.63%  (60)
>>> root at letux:~# ./high-load -n
>>> 100% load stress test for 2 cores
>>> Sat Jan 1 04:52:17 UTC 2000 51° 52° 49° 36° 4002mV 1000MHz
>>> Sat Jan 1 04:52:17 UTC 2000 51° 52° 49° 36° 3991mV 1500MHz
>>> Sat Jan 1 04:52:18 UTC 2000 52° 53° 51° 36° 3854mV 1500MHz
>>> Sat Jan 1 04:52:20 UTC 2000 64° 54° 53° 36° 3876mV 1500MHz
>>> Sat Jan 1 04:52:21 UTC 2000 76° 62° 61° 36° 3855mV 1500MHz
>>> Sat Jan 1 04:52:23 UTC 2000 81° 69° 66° 37° 3852mV 1500MHz
>>> Sat Jan 1 04:52:24 UTC 2000 85° 71° 71° 37° 3832mV 1500MHz
>>> Sat Jan 1 04:52:26 UTC 2000 90° 75° 74° 37° 3829mV 1500MHz
>>> Sat Jan 1 04:52:27 UTC 2000 90° 75° 77° 37° 3824mV 1500MHz
>>> Sat Jan 1 04:52:29 UTC 2000 92° 78° 77° 38° 3843mV 1500MHz
>>> Sat Jan 1 04:52:30 UTC 2000 95° 81° 79° 38° 3813mV 1500MHz
>>> Sat Jan 1 04:52:31 UTC 2000 97° 84° 82° 38° 3825mV 1500MHz
>>> Sat Jan 1 04:52:33 UTC 2000 101° 86° 83° 38° 4021mV 500MHz
>>> Sat Jan 1 04:52:35 UTC 2000 102° 87° 84° 37° 4023mV 500MHz
>>> Sat Jan 1 04:52:37 UTC 2000 82° 84° 79° 37° 3848mV 1500MHz
>>> Sat Jan 1 04:52:38 UTC 2000 77° 79° 73° 37° 3813mV 1500MHz
>>> Sat Jan 1 04:52:40 UTC 2000 90° 78° 75° 37° 3836mV 1500MHz
>>> Sat Jan 1 04:52:41 UTC 2000 97° 84° 80° 38° 3822mV 1500MHz
>>> Sat Jan 1 04:52:43 UTC 2000 101° 86° 84° 38° 3964mV 750MHz
>>> Sat Jan 1 04:52:44 UTC 2000 104° 89° 86° 38° 4019mV 250MHz
>>> Sat Jan 1 04:52:47 UTC 2000 85° 86° 81° 37° 3820mV 1500MHz
>>> Sat Jan 1 04:52:48 UTC 2000 78° 81° 75° 37° 3832mV 1500MHz
>>> Sat Jan 1 04:52:50 UTC 2000 93° 81° 78° 37° 3797mV 1500MHz
>>> Sat Jan 1 04:52:51 UTC 2000 100° 86° 83° 37° 4029mV 250MHz
>>> Sat Jan 1 04:52:53 UTC 2000 104° 89° 86° 37° 3986mV 750MHz
>>> Sat Jan 1 04:52:55 UTC 2000 83° 84° 79° 37° 3815mV 1500MHz
>>> Sat Jan 1 04:52:57 UTC 2000 78° 80° 75° 37° 3824mV 1500MHz
>>> Sat Jan 1 04:52:58 UTC 2000 94° 82° 78° 37° 3799mV 1500MHz
>>> Sat Jan 1 04:53:00 UTC 2000 100° 87° 84° 39° 4056mV 500MHz
>>> Sat Jan 1 04:53:01 UTC 2000 105° 90° 87° 39° 4004mV 500MHz
>>> Sat Jan 1 04:53:04 UTC 2000 87° 88° 83° 39° 3816mV 1500MHz
>>> Sat Jan 1 04:53:05 UTC 2000 81° 83° 77° 38° 3797mV 1500MHz
>>> Sat Jan 1 04:53:07 UTC 2000 95° 83° 79° 38° 3824mV 1500MHz
>>> Sat Jan 1 04:53:08 UTC 2000 103° 88° 85° 38° 4106mV 250MHz
>>> ^Ckill 2653 2654
>>> 
>>> root at letux:~# cpufreq-info 
>>> cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
>>> Report errors and bugs to cpufreq at vger.kernel.org, please.
>>> analyzing CPU 0:
>>> driver: cpufreq-dt
>>> CPUs which run at the same hardware frequency: 0 1
>>> CPUs which need to have their frequency coordinated by software: 0 1
>>> maximum transition latency: 400 us.
>>> hardware limits: 250 MHz - 1.50 GHz
>>> available frequency steps: 250 MHz, 500 MHz, 750 MHz, 1000 MHz, 1.25 GHz, 1.50 GHz
>>> available cpufreq governors: conservative, userspace, powersave, ondemand, performance
>>> current policy: frequency should be within 250 MHz and 1.50 GHz.
>>>                The governor "ondemand" may decide which speed to use
>>>                within this range.
>>> current CPU frequency is 500 MHz (asserted by call to hardware).
>>> cpufreq stats: 250 MHz:24.54%, 500 MHz:21.39%, 750 MHz:5.83%, 1000 MHz:11.23%, 1.25 GHz:4.45%, 1.50 GHz:32.56%  (142)
>>> analyzing CPU 1:
>>> driver: cpufreq-dt
>>> CPUs which run at the same hardware frequency: 0 1
>>> CPUs which need to have their frequency coordinated by software: 0 1
>>> maximum transition latency: 400 us.
>>> hardware limits: 250 MHz - 1.50 GHz
>>> available frequency steps: 250 MHz, 500 MHz, 750 MHz, 1000 MHz, 1.25 GHz, 1.50 GHz
>>> available cpufreq governors: conservative, userspace, powersave, ondemand, performance
>>> current policy: frequency should be within 250 MHz and 1.50 GHz.
>>>                The governor "ondemand" may decide which speed to use
>>>                within this range.
>>> current CPU frequency is 500 MHz (asserted by call to hardware).
>>> cpufreq stats: 250 MHz:24.54%, 500 MHz:21.39%, 750 MHz:5.83%, 1000 MHz:11.23%, 1.25 GHz:4.45%, 1.50 GHz:32.56%  (142)
>>> root at letux:~# 
>>> 
>>> What I have changed was to apply Matthijs' impedance calibration patch 
>>> 
>>> http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=918c4c46104714a3cfede004a8880a9d04e3153a
>>> 
>>> and enabling the 1.5GHz OPP in DT. Plus recompile u-boot and kernel and then boot.
>>> 
>>> I always said it could be a software bug but nobody believed that it could be one.
>>> And I never believed that changing 1 bit in U-Boot could be sufficient (I thought we
>>> need to patch the kernel).
>>> 
>>> A realistic explanation is that our DDR3 is a little more sensitive to
>>> noise by 1.5GHz operation than the EVM and hence we get the problems
>>> but don't see them on the EVM if it is more robust.
>>> 
>>> At least my prototype was now running for 5 minutes @ 200% load @ 1.5GHz
>>> (cycling between 1.5GHz and 250MHz and 80°C and 110°C with a period of
>>> ca. 10 seconds) until I got
>>> 
>>> thermal thermal_zone0: critical temperature reached(125 C),shutting down
>>> 
>>> We should evaluate this further!
>>> 
>>> BR and please cross-check,
>>> Nikolaus
>>> 
>>> _______________________________________________
>>> Kernel mailing list
>>> Kernel at pyra-handheld.com
>>> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
>> 
>> _______________________________________________
>> Kernel mailing list
>> Kernel at pyra-handheld.com
>> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
> 
> _______________________________________________
> Kernel mailing list
> Kernel at pyra-handheld.com
> http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel



More information about the Letux-kernel mailing list