archive mirror
 help / color / mirror / Atom feed
From: Thara Gopinath <>
To: Zhang Rui <>,
	Daniel Lezcano <>,
Subject: Re: [RFC PATCH 0/4] thermal: Introduce support for monitoring falling temperature
Date: Wed, 15 Jul 2020 19:10:43 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 7/15/20 4:27 AM, Zhang Rui wrote:
> Hi, Thara,
> On Tue, 2020-07-14 at 17:39 -0400, Thara Gopinath wrote:
>>> For example, to support this, we can
>>> either
>>> introduce both "cold" trip points and "warming devices", and
>>> introduce
>>> new logic in thermal framework and governors to handle them,
>>> Or
>>> introduce "cold" trip point and "warming" device, but only
>>> semantically, and treat them just like normal trip points and
>>> cooling
>>> devices. And strictly define cooling state 0 as the state that
>>> generates most heat, and define max cooling state as the state that
>>> generates least heat. Then, say, we have a trip point at -10C, the
>>> "warming" device is set to cooling state 0 when the temperature is
>>> lower than -10C, and in most cases, this thermal zone is always in
>>> a
>>> "overheating" state (temperature higher than -10C), and the
>>> "warming"
>>> device for this thermal zone is "throttled" to generate as least
>>> heat
>>> as possible. And this is pretty much what the current code has
>>> always
>>> been doing, right?
>> IMHO, thermal framework should move to a direction where the term
>> "mitigation" is used rather than cooling or warming. In this case
>> "cooling dev" and "warming dev" should will become
>> "temp-mitigating-dev". So going by this, I think what you mention as
>> option 1 is more suitable where new logic is introduced into the
>> framework and governors to handle the trip points marked as "cold".
>> Also in the current set of requirements, we have a few power domain
>> rails and other resources that are used exclusively in the thermal
>> framework for warming alone as in they are not used ever for cooling
>> down a zone. But then one of the requirements we have discussed is
>> for cpufreq and gpu scaling to be behave as warming devices where
>> the minimum operating point/ voltage of the relevant cpu/gpu is
>> restricted.
>> So in this case, Daniel had this suggestion of introducing negative
>> states for presently what is defined as cooling devices. So cooling
>> dev
>> / temp-mitigation-dev states can range from say -3 to 5 with 0 as
>> the
>> good state where no mitigation is happening. This is an interesting
>> idea
>> though I have not proto-typed it yet.
> Agreed. If some devices support both "cooling" and "warning", we should
> have only one "temp-mitigating-dev" instead.
>>> I can not say which one is better for now as I don't have the
>>> background of this requirement. It's nice that Thara sent this RFC
>>> series for discussion, but from upstream point of view, I'd prefer
>>> to
>>> see a full stack solution, before taking any code.
>> We had done a session at ELC on this requirement. Here is the link
>> to
>> the presentation. Hopefully it gives you some back ground on this.
> yes, it helps. :)
>> I have sent across some patches for introducing a generic power
>> domain
>> warming device which is under review by Daniel.
>> So how do you want to proceed on this? Can you elaborate a bit more
>> on
>> what you mean by a full stack solution.
> I mean, the patches, and the idea look good to me, just with some minor
> comments. But applying this patch series, alone, does not bring us
> anything because we don't have a thermal zone driver that supports cold
> trip point, right?
> I'd like to see this patch series together with the support in
> thermal_core/governors and real users like updated/new thermal
> zone/cdev drivers that supports the cold trip point and warming
> actions.
> Or else I've the concern that this piece of code may be changed back
> and forth when prototyping the rest of the support.

Got it! I will try to include more pieces in the next version.

> thanks,
> rui

Warm Regards

      reply	other threads:[~2020-07-15 23:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10 13:51 Thara Gopinath
2020-07-10 13:51 ` [RFC PATCH 1/4] dt-bindings:thermal:Add cold trip point type Thara Gopinath
2020-07-13 15:05   ` Daniel Lezcano
2020-07-13 17:01     ` Thara Gopinath
2020-07-13 17:03       ` Daniel Lezcano
2020-07-10 13:51 ` [RFC PATCH 2/4] thermal: Add support for cold trip point Thara Gopinath
2020-07-10 13:51 ` [RFC PATCH 3/4] thermal:core:Add genetlink notifications for monitoring falling temperature Thara Gopinath
2020-07-15  8:46   ` Zhang Rui
2020-07-15 23:15     ` Thara Gopinath
2020-07-10 13:51 ` [RFC PATCH 4/4] thermal: Modify thermal governors to do nothing for "cold" trip points Thara Gopinath
2020-07-15  8:35   ` Zhang Rui
2020-07-15 23:13     ` Thara Gopinath
2020-07-13 15:03 ` [RFC PATCH 0/4] thermal: Introduce support for monitoring falling temperature Daniel Lezcano
2020-07-14 13:49   ` Zhang Rui
2020-07-14 21:39     ` Thara Gopinath
2020-07-15  8:27       ` Zhang Rui
2020-07-15 23:10         ` Thara Gopinath [this message]

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:

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

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [RFC PATCH 0/4] thermal: Introduce support for monitoring falling temperature' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).