[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170420095248.GJ5436@vireshk-i7>
Date: Thu, 20 Apr 2017 15:22:48 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Rafael Wysocki <rjw@...ysocki.net>, ulf.hansson@...aro.org,
Kevin Hilman <khilman@...aro.org>,
Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
Stephen Boyd <sboyd@...eaurora.org>,
linaro-kernel@...ts.linaro.org, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
robh+dt@...nel.org, lina.iyer@...aro.org, rnayak@...eaurora.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH V4 1/9] PM / OPP: Allow OPP table to be used for
power-domains
On 20-04-17, 10:43, Sudeep Holla wrote:
> Just that the term performance is closely related to frequency, it needs
> to be explicit on what *exactly* it means. As it stands now,
> it can be used for OPP as I explain which controls both but as you
> clarify that's not what it's designed for.
We are talking about active states of a power domain here and
*performance* is the best word I got. And yes we can still have
frequency as a configurable here, just that current platforms don't
have it.
> I am not sure if choosing highest performance point makes it difficult
> to fit it in regulator framework. It could be some configuration.
I was just pointing out a difference :)
> Also IIUC the actual programming is done in the firmware in this case
> and I fail to see how that adds lot of platform code.
Oh I meant that for converting general regulator only cases to OPP. No
firmware was involved there.
--
viresh
Powered by blists - more mailing lists