[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2128c09a-0656-0878-c4e7-c327007021c7@arm.com>
Date: Tue, 18 Apr 2017 17:03:11 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: Sudeep Holla <sudeep.holla@....com>,
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 17/04/17 06:33, Viresh Kumar wrote:
> On 13-04-17, 14:43, Sudeep Holla wrote:
>> Interesting. My understand of power domain and in particular power
>> domain performance was that it would control both. The abstract number
>> you introduce would hide clocks and regulators.
>>
>> But if the concept treats it just as yet another regulator, we do we
>> need these at all. Why don't we relate this performance to regulator
>> values and be done with it ?
>>
>> Sorry if I am missing to understand something here. I would look this as
>> replacement for both clocks and regulators, something similar to ACPI
>> CPPC. If not, it looks unnecessary to me with the information I have got
>> so far.
>
> I kind of answered that in the other email.
>
> Some background may be good here. So Qcom tried to solve all this with virtual
> regulators, but the problem was that they need to talk in terms of integer
> values (1, 2, 3..) and not voltages and so they can't use the regulator
> framework straight away. And so we are doing all this.
>
Was it posted externally ? Was there any objections for that approach ?
IMO that's better approach but if I am late to the party, I would like
to read through the discussions that happened on it(if any)
--
Regards,
Sudeep
Powered by blists - more mailing lists