All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Daniel Lezcano" <daniel.lezcano@linaro.org>,
	"Adam Ford" <aford173@gmail.com>,
	Linux-OMAP <linux-omap@vger.kernel.org>,
	"Tony Lindgren" <tony@atomide.com>,
	"André Roth" <neolynx@gmail.com>,
	"Discussions about the Letux Kernel"
	<letux-kernel@openphoenux.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Andreas Kemnade" <andreas@kemnade.info>,
	"Nishanth Menon" <nm@ti.com>, "Adam Ford" <adam.ford@logicpd.com>
Subject: Re: [RFC] ARM: dts: omap36xx: Enable thermal throttling
Date: Wed, 18 Sep 2019 11:36:26 +0200	[thread overview]
Message-ID: <6B087285-DFAF-45AD-8D32-6A1264252342@goldelico.com> (raw)
In-Reply-To: <20190918092418.que4c5jpcn2dcavx@vireshk-mac-ubuntu>

Hi,

> Am 18.09.2019 um 11:24 schrieb Viresh Kumar <viresh.kumar@linaro.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@linaro.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


  reply	other threads:[~2019-09-18  9:36 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-12 18:30 [RFC] ARM: dts: omap36xx: Enable thermal throttling Adam Ford
2019-09-12 21:12 ` Daniel Lezcano
2019-09-12 21:19   ` Adam Ford
2019-09-12 22:33     ` Daniel Lezcano
2019-09-18  9:24       ` Viresh Kumar
2019-09-18  9:36         ` H. Nikolaus Schaller [this message]
2019-09-18  9:37         ` Daniel Lezcano
2019-09-13  6:55 ` H. Nikolaus Schaller
2019-09-13 11:07   ` Adam Ford
2019-09-13 13:28     ` Adam Ford
2019-09-13 13:32     ` H. Nikolaus Schaller
2019-09-13 14:05       ` Adam Ford
2019-09-13 14:24         ` H. Nikolaus Schaller
2019-09-13 15:01           ` Adam Ford
2019-09-13 15:09             ` H. Nikolaus Schaller
2019-09-13 16:35               ` Adam Ford
2019-09-13 16:42                 ` Adam Ford
2019-09-13 16:51                   ` H. Nikolaus Schaller
2019-09-13 17:18                     ` Daniel Lezcano
2019-09-13 18:46                       ` Adam Ford
2019-09-13 20:01                         ` Adam Ford
2019-09-13 20:11                         ` Daniel Lezcano
2019-09-13 20:34                           ` H. Nikolaus Schaller
2019-09-13 20:34                             ` H. Nikolaus Schaller
2019-09-13 21:01                             ` Adam Ford
2019-09-14  9:53                             ` Daniel Lezcano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6B087285-DFAF-45AD-8D32-6A1264252342@goldelico.com \
    --to=hns@goldelico.com \
    --cc=adam.ford@logicpd.com \
    --cc=aford173@gmail.com \
    --cc=andreas@kemnade.info \
    --cc=daniel.lezcano@linaro.org \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=neolynx@gmail.com \
    --cc=nm@ti.com \
    --cc=tony@atomide.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.