[Letux-kernel] 1.5GHz operation surprise

Adam Ford aford173 at gmail.com
Fri Sep 13 22:50:24 CEST 2019


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.

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