From: Viresh Kumar <viresh.kumar@linaro.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Georgi Djakov <georgi.djakov@linaro.org>,
Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Sibi Sankar <sibis@codeaurora.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Jordan Crouse <jcrouse@codeaurora.org>,
Evan Green <evgreen@chromium.org>,
Linux PM <linux-pm@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 6/7] OPP: Update the bandwidth on OPP frequency changes
Date: Thu, 30 Apr 2020 13:23:56 +0530 [thread overview]
Message-ID: <20200430075356.rjtctfuenirvhxgn@vireshk-i7> (raw)
In-Reply-To: <CAGETcx_zH_KJ7_A7Ofc2M5GfHKX_J__URJB127MSMcTeaqyzjw@mail.gmail.com>
On 30-04-20, 00:35, Saravana Kannan wrote:
> On Wed, Apr 29, 2020 at 11:09 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >
> > On 24-04-20, 14:18, Saravana Kannan wrote:
> > > My only comment is -- can we drop this patch please? I'd like to use
> > > devfreq governors for voting on bandwidth and this will effectively
> > > override whatever bandwidth decisions are made by the devfreq
> > > governor.
> >
> > And why would that be better ? FWIW, that will have the same problem
> > which cpufreq governors had since ages, i.e. they were not proactive
> > and were always too late.
> >
> > The bw should get updated right with frequency, why shouldn't it ?
>
> I didn't say the bw would be voted based on just CPUfreq. It can also
> be based on CPU busy time and other stats. Having said that, this is
> not just about CPUfreq. Having the bw be force changed every time a
> device has it's OPP is changed is very inflexible. Please don't do it.
So, the vote based on the requirements of cpufreq driver should come
directly from the cpufreq side itself, but no one stops the others
layers to aggregate the requests and then act on them. This is how it
is done for other frameworks like clk, regulator, genpd, etc.
You guys need to figure out who aggregates the requests from all users
or input providers for a certain path. This was pushed into the genpd
core in case of performance state for example.
--
viresh
next prev parent reply other threads:[~2020-04-30 7:54 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-24 15:53 [PATCH v7 0/7] Introduce OPP bandwidth bindings Georgi Djakov
2020-04-24 15:53 ` [PATCH v7 1/7] dt-bindings: opp: Introduce opp-peak-kBps and opp-avg-kBps bindings Georgi Djakov
2020-04-30 5:09 ` Viresh Kumar
2020-05-04 20:31 ` Sibi Sankar
2020-05-11 21:51 ` Rob Herring
2020-04-24 15:53 ` [PATCH v7 2/7] OPP: Add helpers for reading the binding properties Georgi Djakov
2020-04-24 17:30 ` Matthias Kaehlcke
2020-04-30 5:21 ` Viresh Kumar
2020-05-04 20:40 ` Sibi Sankar
2020-04-24 15:54 ` [PATCH v7 3/7] interconnect: Add of_icc_get_by_index() helper function Georgi Djakov
2020-04-24 18:02 ` Matthias Kaehlcke
2020-05-04 20:58 ` Sibi Sankar
2020-04-24 15:54 ` [PATCH v7 4/7] OPP: Add support for parsing interconnect bandwidth Georgi Djakov
2020-04-24 19:20 ` Matthias Kaehlcke
2020-04-28 16:21 ` Georgi Djakov
2020-04-30 5:28 ` Viresh Kumar
2020-05-04 21:03 ` Sibi Sankar
2020-04-24 15:54 ` [PATCH v7 5/7] OPP: Add sanity checks in _read_opp_key() Georgi Djakov
2020-04-24 19:26 ` Matthias Kaehlcke
2020-05-04 20:47 ` Sibi Sankar
2020-04-24 15:54 ` [PATCH v7 6/7] OPP: Update the bandwidth on OPP frequency changes Georgi Djakov
2020-04-24 19:36 ` Matthias Kaehlcke
2020-04-24 21:18 ` Saravana Kannan
2020-04-30 6:09 ` Viresh Kumar
2020-04-30 7:35 ` Saravana Kannan
2020-04-30 7:53 ` Viresh Kumar [this message]
2020-04-30 16:32 ` Saravana Kannan
2020-05-04 5:00 ` Viresh Kumar
2020-05-04 21:01 ` Saravana Kannan
2020-05-05 3:38 ` Viresh Kumar
2020-05-04 20:54 ` Sibi Sankar
2020-04-24 15:54 ` [PATCH v7 7/7] cpufreq: dt: Add support for interconnect bandwidth scaling Georgi Djakov
2020-04-24 19:41 ` Matthias Kaehlcke
2020-05-04 20:50 ` Sibi Sankar
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=20200430075356.rjtctfuenirvhxgn@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=evgreen@chromium.org \
--cc=georgi.djakov@linaro.org \
--cc=jcrouse@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nm@ti.com \
--cc=rjw@rjwysocki.net \
--cc=rnayak@codeaurora.org \
--cc=robh+dt@kernel.org \
--cc=saravanak@google.com \
--cc=sboyd@kernel.org \
--cc=sibis@codeaurora.org \
--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 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.