[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <95aa4b97-4e1a-13bb-f4d8-982b778012ba@arm.com>
Date: Tue, 18 Apr 2017 17:01:03 +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:27, Viresh Kumar wrote:
> On 13-04-17, 14:42, Sudeep Holla wrote:
>> What I was referring is about power domain provider with multiple power
>> domains(simply #power-domain-cells=<1> case as explained in the
>> power-domain specification.
>
> I am not sure if we should be looking to target such a situation for now, as
> that would be like this:
>
> Device controlled by Domain A. Domain A itself is controlled by Domain B and
> Domain C.
>
No, may be I was not so clear. I am just referring a power controller
that provides say 3 different power domains and are indexed 0 - 2.
The consumer just passes the index along with the phandle for the power
domain info.
> Though we will end up converting the domain-performance-state property to an
> array if that is required in near future.
>
OK, better to document that so that we know how to extend it. We have
#power-domain-cells=<1> on Juno with SCPI.
>> Yes. To simplify what not we just have power-domain for a device and
>> change state of that domain to change the performance of that device.
>
> Consider this case to understand what I have in Mind.
>
> The power domain have its states as A, B, C, D. There can be multiple devices
> regulated by that domain and one of the devices have its power states as: A1,
> A2, A3, B1, B2, B3, C1, C2, C3, D1, D2, D3 and all these states have different
> frequency/voltages.
>
> IOW, the devices can have regulators as well and may want to fine tune within
> the domain performance-state.
>
Understood. I would incline towards reusing regulators we that's what is
changed behind the scene. Calling this operating performance point
is misleading and doesn't align well with existing specs/features.
>> Then put this in the hierarchy. Some thing similar to what we already
>> have with new domain-idle states. In that way, we can move any
>> performance control to the domain and abstract the clocks and regulators
>> from the devices as the first step and from the OSPM view if there's
>> firmware support.
>>
>> If we are looking this power-domains with performance as just some
>> *advanced regulators*, I don't like the complexity added.
>
> In the particular case I am trying to solve (Qcom), we have some sort of
> regulators which are only programmed by a M3 core. The M3 core needs integer
> numbers representing state we want the domain to be in and it will put the
> regulators (or whatever) in a particular state.
>
Understood. We have exactly same thing with SCPI but it controls both
frequency and voltage referred as operating points. In general, this OPP
terminology is used in SCPI/ACPI/SCMI specifications as both frequency
and voltage control. I am bit worried that this binding might introduce
confusions on the definitions. But it can be reworded/renamed easily if
required.
--
Regards,
Sudeep
Powered by blists - more mailing lists