devicetree.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 15:22:48 +0530	[thread overview]
Message-ID: <20201030095248.abej6h5wphud2ihb@vireshk-i7> (raw)
In-Reply-To: <a0a6db69-fc3e-c39f-7586-5ac3227b746e@arm.com>

On 30-10-20, 09:19, Lukasz Luba wrote:
> How about dropping the DT binding, but just adding this new field into
> dev_pm_opp? There will be no DT parsing code, just the get/set
> functions, which will be used in SCMI patch 4/4 and in IPA?
> That would not require to change any DT bindings.
 
> I see. Just for your information SCMI supports 'Sustained Performance'
>  expressed in kHz.

Even that doesn't sound great (but then I don't have any background of
why that was added there). The problem is not about how do we get this
data into the kernel (from DT or firmware), but why is it even
required. I really feel that software can find the sustainable OPP by
itself (which can keep changing).

About moving it into the OPP core, I am open to getting something
added there if it is really useful and if the OPP core is the best
suited place to keep such data. Though I am not sure of that for this
field right now.

Is it ever going to be used by anyone else apart from IPA ? If not,
what about adding a helper in IPA to set sustainable-freq for a device
?

So only SCMI based platforms will be able to use this stuff ? That's
very limited, isn't it ? I think we should still try to make it better
for everyone by making the software smarter. It has so much data, the
OPPs, the power it will consume (based on microvolt property?), the
heat we produce from that (from thermal framework), etc. Perhaps
building this information continuously at runtime based on when and
how we hit the trip points ? So we know which is the right frequency
where we can refrain from hitting the trip points.

But may be I am asking too much :(

-- 
viresh

  reply	other threads:[~2020-10-30  9:52 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
2020-10-30  9:19         ` Lukasz Luba
2020-10-30  9:52           ` Viresh Kumar [this message]
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=20201030095248.abej6h5wphud2ihb@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).