[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190725030712.lx3cjogo5r7kc262@vireshk-i7>
Date: Thu, 25 Jul 2019 08:37:12 +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>,
Sibi Sankar <sibis@...eaurora.org>, kernel-team@...roid.com,
linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/5] OPP: Improve require-opps linking
On 23-07-19, 07:47, Saravana Kannan wrote:
> On Tue, Jul 23, 2019, 3:28 AM Viresh Kumar <viresh.kumar@...aro.org> wrote:
>
> > $subject doesn't have correct property name.
> >
> > On 17-07-19, 15:23, Saravana Kannan wrote:
> > > Currently, the linking of required-opps fails silently if the
> > > destination OPP table hasn't been added before the source OPP table is
> > > added. This puts an unnecessary requirement that the destination table
> > > be added before the source table is added.
> > >
> > > In reality, the destination table is needed only when we try to
> > > translate from source OPP to destination OPP. So, instead of
> > > completely failing, retry linking the tables when the translation is
> > > attempted.
> > >
> > > Signed-off-by: Saravana Kannan <saravanak@...gle.com>
> > > ---
> > > drivers/opp/core.c | 32 +++++++++++-----
> > > drivers/opp/of.c | 91 ++++++++++++++++++++++------------------------
> > > drivers/opp/opp.h | 5 +++
> > > 3 files changed, 71 insertions(+), 57 deletions(-)
> >
> > Here is the general feedback and requirements I have:
> >
> > - We shouldn't do it from _set_required_opps() but way earlier, it
> > shouldn't affect the fast path (where we change the frequency).
> >
>
> I don't think there's any other intermediate OPP call where we can try to
> link the tables. Also if there tables are already fully linked, this is
> just checking for not NULL for a few elements in the array.
We should be doing this whenever a new OPP table is created, and see
if someone else was waiting for this OPP table to come alive. Also we
must make sure that we do this linking only if the new OPP table has
its own required-opps links fixed, otherwise delay further.
> I don't think
> this is really going to allow down the fast path in anyway.
> If you have other ideas, I'm willing to look at it. But as it is right now
> seems the best to me.
>
Even then I don't want to add these checks to those places. For the
opp-set-rate routine, add another flag to the OPP table which
indicates if we are ready to do dvfs or not and mark it true only
after the required-opps are all set.
--
viresh
Powered by blists - more mailing lists