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] [day] [month] [year] [list]

Message-ID: <caf10e4e-c688-cdb7-7d0d-7a030923a194@linaro.org>
Date:   Wed, 18 Sep 2019 11:37:47 +0200
From:   Daniel Lezcano <daniel.lezcano@...aro.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Adam Ford <aford173@...il.com>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        "H. Nikolaus Schaller" <hns@...delico.com>,
        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

On 18/09/2019 11:24, Viresh Kumar wrote:
> 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 :)

The solution of preventing running above the 90°C by changing the OPPs
is fine and works. It is a way of workaround the spec.

But AFAIU, the specs of the board say the OPPs 800MHz and 1GHz are only
permitted during an amount of time above 90°C which makes the constraint
inverted and recall somehow the 'turbo-mode' description:

"
- turbo-mode: Marks the OPP to be used only for turbo modes. Turbo mode
is available on some platforms, where the device can run over its
operating frequency for a short duration of time limited by the device's
power, current and thermal limits.
"

This is where I thought you can give an input.


-- 
 <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog