linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Lukasz Luba <lukasz.luba@arm.com>
Cc: vincent.guittot@linaro.org, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, vireshk@kernel.org,
	robh+dt@kernel.org, sboyd@kernel.org, nm@ti.com,
	rafael@kernel.org, sudeep.holla@arm.com,
	daniel.lezcano@linaro.org, Dietmar.Eggemann@arm.com
Subject: Re: [PATCH 0/4] Add sustainable OPP concept
Date: Fri, 30 Oct 2020 13:59:37 +0530	[thread overview]
Message-ID: <20201030082937.xgjmko2ohwhkt6f5@vireshk-i7> (raw)
In-Reply-To: <228fa1b3-bbd3-6941-fd4b-06581016d839@arm.com>

On 29-10-20, 09:56, Lukasz Luba wrote:
> There were discussions about Energy Model (EM), scale of values (mW or
> abstract scale) and relation to EAS and IPA. You can find quite long
> discussion below v2 [1] (there is also v3 send after agreement [2]).
> We have in thermal DT binding: 'sustainable-power' expressed in mW,
> which is used by IPA, but it would not support bogoWatts.

Why so ? (I am sorry, can't dig into such long threads without knowing
which message I am looking for :( ). Lets assume if that same property
can be used for bogoWatts, will that be sufficient for you ? Or you
will still need this patch set ?

> The sustainable power is used for estimation of internal coefficients
> (also for power budget), which I am trying to change to work with
> 'abstract scale' [3][4].
> 
> This would allow to estimate sustainable power of the system based on
> CPUs, GPU opp-sustainable points, where we don't have
> 'sustainable-power' or devices using bogoWatts.

Then maybe we should ahve sustainable-power in those cases too instead
of adding a meaningless (IMHO) binding.

Honestly speaking, as Nishanth said, there is nothing like a
sustainable OPP in reality. Moreover, the DT needs to describe the
hardware as it is (and in some cases the behavior of the firmware).
And what you are trying to add here is none of them and so it should
not go in DT as such. There are too many factors which play a part
here, ambient temperature is one of the biggest ones, and the software
needs to find the sustainable OPP by itself based on the current
situation.

So I don't really see a good reason why such a property should be
added here.

Coming to properties like suspend-opp, it made sense for some of the
platforms as the last configured frequency of the CPU plays a part in
deciding the power consumed by the SoC even when the system is
suspended. And finding an optimal OPP (normally the lowest) there
would make sense and so was that property added.

-- 
viresh

  reply	other threads:[~2020-10-30  8:29 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-28 14:08 [PATCH 0/4] Add sustainable OPP concept Lukasz Luba
2020-10-28 14:08 ` [PATCH 1/4] dt-bindings: opp: Introduce opp-sustainable bindings Lukasz Luba
2020-10-28 21:47   ` Nishanth Menon
2020-10-29 10:04     ` Lukasz Luba
2020-10-29 12:59       ` Nishanth Menon
2020-10-29 13:33         ` Lukasz Luba
2020-10-29 13:49           ` Nishanth Menon
2020-10-29 14:20             ` Lukasz Luba
2020-10-30 19:34   ` Rob Herring
2020-11-02  8:40     ` Lukasz Luba
2020-10-28 14:08 ` [PATCH 2/4] OPP: Add support for parsing the 'opp-sustainable' property Lukasz Luba
2020-10-30 11:47   ` Quentin Perret
2020-10-30 12:53     ` Lukasz Luba
2020-10-28 14:08 ` [PATCH 3/4] OPP: Add dev_pm_opp_set_sustainable_opp_freq() Lukasz Luba
2020-10-28 14:08 ` [PATCH 4/4] firmware: arm_scmi/perf: Mark sustainable OPP Lukasz Luba
2020-10-29  7:40 ` [PATCH 0/4] Add sustainable OPP concept Viresh Kumar
2020-10-29  7:53   ` Viresh Kumar
2020-10-29  9:56     ` Lukasz Luba
2020-10-30  8:29       ` Viresh Kumar [this message]
2020-10-30  9:19         ` Lukasz Luba
2020-10-30  9:52           ` Viresh Kumar
2020-10-30 10:56             ` Lukasz Luba
2020-10-30 11:17               ` Viresh Kumar
2020-10-30 12:40                 ` Lukasz Luba

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=20201030082937.xgjmko2ohwhkt6f5@vireshk-i7 \
    --to=viresh.kumar@linaro.org \
    --cc=Dietmar.Eggemann@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=nm@ti.com \
    --cc=rafael@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vireshk@kernel.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 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).