[Letux-kernel] thermal madness

H. Nikolaus Schaller hns at goldelico.com
Sat Sep 14 21:02:00 CEST 2019

> Am 14.09.2019 um 14:02 schrieb Andreas Kemnade <andreas at kemnade.info>:
> On Sat, 14 Sep 2019 12:28:06 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>> Am 14.09.2019 um 12:23 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> On Fri, 13 Sep 2019 22:27:11 +0200
>>> Andreas Kemnade <andreas at kemnade.info> wrote:
>>>> some more testing here:
>>>> root@(none):/# 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
>>>> CPUs which need to have their frequency coordinated by software: 0
>>>> maximum transition latency: 300 us.
>>>> hardware limits: 300 MHz - 1000 MHz
>>>> available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz
>>>> available cpufreq governors: conservative, userspace, powersave, ondemand, performance
>>>> current policy: frequency should be within 300 MHz and 1000 MHz.
>>>>                 The governor "ondemand" may decide which speed to use
>>>>                 within this range.
>>>> current CPU frequency is 600 MHz (asserted by call to hardware).
>>>> cpufreq stats: 300 MHz:94.86%, 600 MHz:2.49%, 800 MHz:0.92%, 1000 MHz:1.73%  (51)  
>>> should this be 1000Mhz: 0%? If not enabled the boost switch.  
>> I had it enabled... 
> Well, at least all these patches seem not to have any influence on
> idle-behavior. 

Fine. But I didn't expect it...

>> And we can remove the turbo-mode; tag anyways as soon as thermal throttling works.
> well, do we have the watchdog running? So if kernel does infinite
> busy-waiting, we will not overheat?

Good question. I don't know.

But I have a first finding by studying the bandgap driver code (drivers/thermal/ti-soc-thermal):

is not set for omap34xx and omap36xx although it could be.

This would allow to switch to continuous measuerements avoiding
to start - wait - read.

If it is not available, every call to ti_bandgap_read_temperature()
does a ti_bandgap_force_single_read() and then ti_bandgap_read_temp().

But I am still trying to understand ti_bandgap_force_single_read()
because according to my theory this is where something would go wrong
(start conversion but return previous value).

It sets SOC=1, then waits for EOCZ becoming 1 which I think means "conversion is running".
Then it sets SOC=0 and waits for EOCZ becoming 0.

There are counters for spin-loop timeouts. Hm. is the value 1000 too short?
So that we read before conversion is really finished? How long is this timeout???
It depends on OPP...

After doing that it will read the temp in spin-locked context, but on omap3
it is mostly just reading the result register.

Ok, let's wait for fresh ideas.


More information about the Letux-kernel mailing list