Am 13.09.2019 um 22:43 schrieb H. Nikolaus Schaller hns@goldelico.com:
Am 13.09.2019 um 22:40 schrieb H. Nikolaus Schaller hns@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@goldelico.com Betreff: 1.5GHz operation surprise Datum: 25. Februar 2017 um 17:28:48 MEZ An: kernel@pyra-handheld.com
Hi all, here is a very surprising result which needs independent confirmation.
root@letux:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@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@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@letux:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@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@letux:~#
What I have changed was to apply Matthijs' impedance calibration patch
http://git.goldelico.com/?p=gta04-uboot.git;a=commit;h=918c4c46104714a3cfede...
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@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel
Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel