[Letux-kernel] 1.5GHz operation surprise

H. Nikolaus Schaller hns at goldelico.com
Fri Sep 13 22:43:47 CEST 2019


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

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



More information about the Letux-kernel mailing list