[Letux-kernel] 1.5GHz operation surprise

H. Nikolaus Schaller hns at goldelico.com
Fri Sep 13 23:01:22 CEST 2019


> Am 13.09.2019 um 22:50 schrieb Adam Ford <aford173 at gmail.com>:
> 
> On Fri, Sep 13, 2019 at 3:40 PM H. Nikolaus Schaller <hns at goldelico.com> wrote:
>> 
>> 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)
>> 
> 
> From what I can tell, this patch does this:
> 
> https://patchwork.kernel.org/patch/11144941/
> 
> The 2nd patch in the series associates it to all omap3 boards (34xx,
> 36xx, and 3517)
> https://patchwork.kernel.org/patch/11144939/
> 
> If there is anything you think that should be done differently, please
> let me know.

Ah, yes. The mails arrived in different order...

This patches above came before I received the "[RFC v2] ARM: dts: omap36xx: Enable thermal throttling"
with cooling-device = <&cpu 1 2>;

So in my current evaluation we simply can skip that omap36xx specific patch, because the
general omap3 patch should already do it right...

In other words, I think we are done :)

BR and thanks,
Nikolaus


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