[Letux-kernel] thermal madness

[H. Nikolaus Schaller]

FYI: I have opened an "Issue": http://projects.goldelico.com/p/gta04-kernel/issues/928/

> Am 14.09.2019 um 21:02 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 
>> 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):
> 
> It looks as if TI_BANDGAP_FEATURE_MODE_CONFIG
> 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().

I had tried to enable TI_BANDGAP_FEATURE_MODE_CONFIG but then the bandgap
sensor doesn't report reasonable values.

> 
> 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.
> 
> BR,
> Nikolaus
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel