[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190626063240.kgdiy7xsz4mahrdr@vireshk-i7>
Date: Wed, 26 Jun 2019 12:02:40 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Saravana Kannan <saravanak@...gle.com>
Cc: MyungJoo Ham <myungjoo.ham@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
Stephen Boyd <sboyd@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Android Kernel Team <kernel-team@...roid.com>,
Linux PM <linux-pm@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 0/3] Add required-opps support to devfreq passive gov
On 24-06-19, 22:29, Saravana Kannan wrote:
> No, the CPUs will be the "parent" and the cache will be the "child".
> CPU is a special case when it comes to the actual software (not DT) as
> we'll need the devfreq governor to look at all the CPUfreq policies to
> decide the cache frequency (max of all their requirements).
>
> I think "master" and "slave" would have been a better term as the
> master device determines its frequency using whatever means and the
> "slave" device just "follows" the master device.
Okay, so to confirm again this is what we will have:
- CPUs are called masters and Caches are slaves.
- The devfreq governor we are talking about takes care of changing
frequency of caches (slaves) and chooses a target frequency for
caches based on what the masters are running at.
- The CPUs OPP nodes will have required-opps property and will be
pointing to the caches OPP nodes. The CPUs may already be using
required-opps node for PM domain performance state thing.
Now the problem is "required-opp" means something really *required*
and it is not optional. Like a specific voltage level before we can
switch to a particular frequency. And this is how I have though of it
until now. And this shouldn't be handled asynchronously, i.e. required
OPPs must be set while configuring OPP of a device.
So, when a CPU changes frequency, we must change the performance state
of PM domain and change frequency/bw of the cache synchronously. And
in such a case "required-opps" can be a very good fit for this use
case.
But with what you are trying to do it is no longer required-opp but
good-to-have-opp. And that worries me.
--
viresh
Powered by blists - more mailing lists