linux-kernel - Re: [RFC] ARM: dts: omap36xx: Enable thermal throttling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <6B087285-DFAF-45AD-8D32-6A1264252342@goldelico.com>
Date:   Wed, 18 Sep 2019 11:36:26 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        Adam Ford <aford173@...il.com>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        Tony Lindgren <tony@...mide.com>,
        André Roth <neolynx@...il.com>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andreas Kemnade <andreas@...nade.info>,
        Nishanth Menon <nm@...com>, Adam Ford <adam.ford@...icpd.com>
Subject: Re: [RFC] ARM: dts: omap36xx: Enable thermal throttling

Hi,

> Am 18.09.2019 um 11:24 schrieb Viresh Kumar <viresh.kumar@...aro.org>:
> 
> On 13-09-19, 00:33, Daniel Lezcano wrote:
>> 
>> Hi Adam,
>> 
>> On 12/09/2019 23:19, Adam Ford wrote:
>>> On Thu, Sep 12, 2019 at 4:12 PM Daniel Lezcano
>>> <daniel.lezcano@...aro.org> wrote:
>>>> 
>>>> On 12/09/2019 20:30, Adam Ford wrote:
>>>>> The thermal sensor in the omap3 family isn't accurate, but it's
>>>>> better than nothing.  The various OPP's enabled for the omap3630
>>>>> support up to OPP1G, however the datasheet for the DM3730 states
>>>>> that OPP130 and OPP1G are not available above TJ of 90C.
>>>>> 
>>>>> This patch configures the thermal throttling to limit the
>>>>> operating points of the omap3630 to Only OPP50 and OPP100 if
>>>>> the thermal sensor reads a value above 90C.
>> 
>> Oh, that's a very interesting use case.
>> 
>> AFAICT the thermal framework is not designed to deal with this
>> situation. I agree this setup may work (even if I'm not convinced about
>> the stability of the whole).
>> 
>> May be Viresh can help for the cpufreq side?
> 
> Sorry but I am not able to understand what's not supported by thermal framework
> here and what can I do to help :)

Well, it appears that it is not supported that the thermal
framework can enable/disable individual OPPs. Rather it disables
more and more of them from highest index to lowest (like a
fan spinning up in speed).

But it has turned out that we do not need that. It was only
a too verbatim interpretation of the data sheet which says
that certain OPPs (OPP130 and OPP1G) must not be enabled above
a thermal limit of 90°C while the others can be used above.

But just going down stepwise to lower frequency OPPs as long
as above thermal limit is fine for practical situations.

So instead of "limit the operating points of the omap3630 to
Only OPP50 and OPP100 if the thermal sensor reads a value above
90C" we can just "go down from OPP1G -> OPP130 -> OPP100 -> OPP50
until the thermal sensors reads a value below 90C". And
that is easily done with existing cpufreq and thermal framework
(as we have tested).

This will of course also exclude OPP100 and OPP50 above 90°C
where no thermal limit is given in the data sheet, but as far
as we know it is impossible (without running the board in a thermal
chamber) to get the chip above 90C in these low-frequency/voltage
OPPs.

Hope this clarifies.

BR and thanks,
Nikolaus