[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171102090033.GZ4240@vireshk-i7>
Date: Thu, 2 Nov 2017 14:30:33 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Stephen Boyd <sboyd@...eaurora.org>
Cc: Rob Herring <robh+dt@...nel.org>,
Ulf Hansson <ulf.hansson@...aro.org>,
Kevin Hilman <khilman@...nel.org>,
Viresh Kumar <vireshk@...nel.org>, Nishanth Menon <nm@...com>,
Rafael Wysocki <rjw@...ysocki.net>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Rajendra Nayak <rnayak@...eaurora.org>,
Sudeep Holla <sudeep.holla@....com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain
magic values
On 02-11-17, 00:15, Stephen Boyd wrote:
> Sorry I'm not following. We're going to need to have platform
> specific code that understands platform specific bindings that
> aren't shoved into the generic OPP bindings.
At least I am not targeting any platform specific binding right now.
The way I see this to work is:
- We will reuse earlier bindings and allow opp-hz and opp-microvolt to
contain special values (this patch).
- Platform specific DT entries will put corner numbers in opp-hz (or
opp-microvolt) fields.
- Some platform specific driver (in OPP or genpd) will be used to
convert OPP into a performance state (corner) value. Now that can
simply read opp-hz (or opp-microvolt) and return its value.
- OPP core will request for a performance state (code is already
merged for that).
And so there is no platform specific binding here. Do you want to do
this differently ?
--
viresh
Powered by blists - more mailing lists