[Letux-kernel] Fwd: 1.5GHz operation surprise

H. Nikolaus Schaller hns at goldelico.com
Fri Sep 13 22:40:04 CEST 2019


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)

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



More information about the Letux-kernel mailing list