From: Thara Gopinath <email@example.com> To: Zhang Rui <firstname.lastname@example.org>, Daniel Lezcano <email@example.com>, firstname.lastname@example.org Cc: email@example.com, firstname.lastname@example.org, email@example.com 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: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> 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. :) >> >> > https://elinux.org/images/f/f7/ELC-2020-Thara-Ram-Linux-Kernel-Thermal-Warming.pdf >> >> 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 Thara
prev parent 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: 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RFC PATCH 0/4] thermal: Introduce support for monitoring falling temperature' \ /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
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).