[Discussion] Performance levels of power domains

[Discussion] Performance levels of power domains

[Viresh Kumar]

Hi Guys,

I wanted to involve you guys to get a discussion going
for a problem we want to solve, and so this mail.


Platform details:

Some of the Qualcom SoCs have the option to configure
the performance level of their Power Domains. The performance
levels are identified by integer values (lets say 0-9, 0 being the lowest).

Another M3 core handles the *real* voltage scaling based on the input
received (from software) in terms of these performance levels. The M3
core translates the levels into a range of voltages (corners) and selects
the right one by itself.

Software needs to provide the performance level for the entire domain
to the M3 core and so software also needs to handle performance requests
from all the devices that lie in the domain X and find a Performance Level P,
which can satisfy all the devices (normally the highest requrested level).


Problem statement:

As we aren't dealing with Voltages here, we can't really get the benefits
of the Regulators framework. The regulators are managed internally
by the M3 core. All we need is a way for software to comeout with inputs
for the M3 core.

The OPP framework can be used to include performance levels for
each OPP (frequency) entry.

But what framework can be used to select performance level of power
domains ?

By name, power-domain or genpd looks to be the right choice, but until
now it is only managing power-on and power-off of devices and domains.

Should we extend that (along with runtime PM), or do something else?

Qualcomm guys, please correct my understanding of the hardware in
case, something wasn't explained correctly.

--
viresh

Re: [Discussion] Performance levels of power domains

[Sudeep Holla]

On 26/10/16 11:52, Viresh Kumar wrote:
> Hi Guys,
>
> I wanted to involve you guys to get a discussion going
> for a problem we want to solve, and so this mail.
>
>
> Platform details:
>
> Some of the Qualcom SoCs have the option to configure
> the performance level of their Power Domains. The performance
> levels are identified by integer values (lets say 0-9, 0 being the lowest).
>
> Another M3 core handles the *real* voltage scaling based on the input
> received (from software) in terms of these performance levels. The M3
> core translates the levels into a range of voltages (corners) and selects
> the right one by itself.
>

Just out of curiosity, what's the protocol used to communicate with this
M3. This is what we already have on Vexpress TC2 and Juno. Currently M3
provides the information of voltage and frequency for each OPP, but that
may change as it's not always constant.

> Software needs to provide the performance level for the entire domain
> to the M3 core and so software also needs to handle performance requests
> from all the devices that lie in the domain X and find a Performance Level P,
> which can satisfy all the devices (normally the highest requrested level).
>

That's interesting and this is where it's different and gets complex
than what we have today. Do you have more details on this ?

I am mainly interested as there are efforts to standardize these
communication with M3 and there's WIP protocol development[1]. It would
be good to see if this user-case is also considered. And yes I am
interested in the problem you have explained below but just can't my
head around it as I can't fully visualize such systems.

-- 
Regards,
Sudeep

[1] 
http://s3.amazonaws.com/connect.linaro.org/las16/Presentations/Tuesday/LAS16-200%20--%20%20SCMI%20-%20System%20Management%20and%20Control%20Interface.pdf

Re: [Discussion] Performance levels of power domains

[Viresh Kumar]

On 26-10-16, 12:09, Sudeep Holla wrote:
> Just out of curiosity, what's the protocol used to communicate with this
> M3.

I will let Qcom guys answer this :)

> This is what we already have on Vexpress TC2 and Juno. Currently M3
> provides the information of voltage and frequency for each OPP, but that
> may change as it's not always constant.

Yeah, I do remember that. But it was always in terms of voltages and
so this thing is different here.

> That's interesting and this is where it's different and gets complex
> than what we have today. Do you have more details on this ?

I have written everything that I knew about it :)

> I am mainly interested as there are efforts to standardize these
> communication with M3 and there's WIP protocol development[1]. It would
> be good to see if this user-case is also considered.

What do you mean by that ?

> And yes I am
> interested in the problem you have explained below but just can't my
> head around it as I can't fully visualize such systems.

:)

-- 
viresh

Re: [Discussion] Performance levels of power domains

[Sudeep Holla]

On 26/10/16 12:16, Viresh Kumar wrote:
> On 26-10-16, 12:09, Sudeep Holla wrote:

[...]

>> I am mainly interested as there are efforts to standardize these
>> communication with M3 and there's WIP protocol development[1]. It would
>> be good to see if this user-case is also considered.
>
> What do you mean by that ?

Basically I wanted to know more details so that such system are also
considered(I agree it may not have any impact on the protocol at all,
but still good to consider them) when designing this new SCMI protocol.

-- 
Regards,
Sudeep

Re: [Discussion] Performance levels of power domains

[Kevin Hilman]

Viresh Kumar <viresh.kumar@linaro.org> writes:

> Hi Guys,
>
> I wanted to involve you guys to get a discussion going
> for a problem we want to solve, and so this mail.
>
>
> Platform details:
>
> Some of the Qualcom SoCs have the option to configure
> the performance level of their Power Domains. The performance
> levels are identified by integer values (lets say 0-9, 0 being the lowest).
>
> Another M3 core handles the *real* voltage scaling based on the input
> received (from software) in terms of these performance levels. The M3
> core translates the levels into a range of voltages (corners) and selects
> the right one by itself.
>
> Software needs to provide the performance level for the entire domain
> to the M3 core and so software also needs to handle performance requests
> from all the devices that lie in the domain X and find a Performance Level P,
> which can satisfy all the devices (normally the highest requrested level).
>
>
> Problem statement:
>
> As we aren't dealing with Voltages here, we can't really get the benefits
> of the Regulators framework. The regulators are managed internally
> by the M3 core. All we need is a way for software to comeout with inputs
> for the M3 core.
>
> The OPP framework can be used to include performance levels for
> each OPP (frequency) entry.
>
> But what framework can be used to select performance level of power
> domains ?
>
> By name, power-domain or genpd looks to be the right choice, but until
> now it is only managing power-on and power-off of devices and domains.

genpd has also recently been extended to support multiple states, though
those are still idle states, not active (performance) states.

> Should we extend that (along with runtime PM), or do something else?

Yes.  As I've suggested to qcom/linaro folks (off-list discussions), I
think extending genpd to handle performance states is a logical
extension.  Otherwise, you will be (re)inventing something that looks an
awful lot like genpd anyways.

The other related framework is per-device PM QoS which could be used to
set constraints on specific devices, and the genpd governors would then
be responsible for looking at the constraints and changing states as
needed.

Kevin

Re: [Discussion] Performance levels of power domains

[Viresh Kumar]

On 26-10-16, 12:00, Kevin Hilman wrote:
> Yes.  As I've suggested to qcom/linaro folks (off-list discussions), I

No one told me this story :)

> think extending genpd to handle performance states is a logical
> extension.  Otherwise, you will be (re)inventing something that looks an
> awful lot like genpd anyways.

I completely agree. Runtime PM and genpd look to be the perfect
placeholder for such stuff. I actually tried to convince Ulf yesterday
on this and he wasn't sure if it will ever get accepted upstream and
that's when I started this thread :)

> The other related framework is per-device PM QoS which could be used to
> set constraints on specific devices, and the genpd governors would then
> be responsible for looking at the constraints and changing states as
> needed.

I am not sure if genpd governors are also background governors like
cpufreq, but we need to make sure that the voltage is raised after the
function requesting a change returns, so that the clk rate can be
increased then.

-- 
viresh

Re: [Discussion] Performance levels of power domains

[Vincent Guittot]

On 26 October 2016 at 21:00, Kevin Hilman <khilman@baylibre.com> wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
>
>> Hi Guys,
>>
>> I wanted to involve you guys to get a discussion going
>> for a problem we want to solve, and so this mail.
>>
>>
>> Platform details:
>>
>> Some of the Qualcom SoCs have the option to configure
>> the performance level of their Power Domains. The performance
>> levels are identified by integer values (lets say 0-9, 0 being the lowest).
>>
>> Another M3 core handles the *real* voltage scaling based on the input
>> received (from software) in terms of these performance levels. The M3
>> core translates the levels into a range of voltages (corners) and selects
>> the right one by itself.
>>
>> Software needs to provide the performance level for the entire domain
>> to the M3 core and so software also needs to handle performance requests
>> from all the devices that lie in the domain X and find a Performance Level P,
>> which can satisfy all the devices (normally the highest requrested level).
>>
>>
>> Problem statement:
>>
>> As we aren't dealing with Voltages here, we can't really get the benefits
>> of the Regulators framework. The regulators are managed internally
>> by the M3 core. All we need is a way for software to comeout with inputs
>> for the M3 core.
>>
>> The OPP framework can be used to include performance levels for
>> each OPP (frequency) entry.
>>
>> But what framework can be used to select performance level of power
>> domains ?
>>
>> By name, power-domain or genpd looks to be the right choice, but until
>> now it is only managing power-on and power-off of devices and domains.
>
> genpd has also recently been extended to support multiple states, though
> those are still idle states, not active (performance) states.
>
>> Should we extend that (along with runtime PM), or do something else?
>
> Yes.  As I've suggested to qcom/linaro folks (off-list discussions), I
> think extending genpd to handle performance states is a logical
> extension.  Otherwise, you will be (re)inventing something that looks an
> awful lot like genpd anyways.

I think that we are mixing 2 different topics. This one is about
setting the voltage of shared voltage domain whereas the scaling bus
topic, that we also discuss with Kevin, includes path, throughput and
routing aspects, which are the intricate part of the discussion

That being said, I agreed that generic power domain could be a natural
place to select running level and not only the idle one.

>
> The other related framework is per-device PM QoS which could be used to
> set constraints on specific devices, and the genpd governors would then
> be responsible for looking at the constraints and changing states as
> needed.
>
> Kevin

Re: [Discussion] Performance levels of power domains

[Vincent Guittot]

On 27 October 2016 at 05:46, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 26-10-16, 12:00, Kevin Hilman wrote:
>> Yes.  As I've suggested to qcom/linaro folks (off-list discussions), I
>
> No one told me this story :)
>
>> think extending genpd to handle performance states is a logical
>> extension.  Otherwise, you will be (re)inventing something that looks an
>> awful lot like genpd anyways.
>
> I completely agree. Runtime PM and genpd look to be the perfect
> placeholder for such stuff. I actually tried to convince Ulf yesterday
> on this and he wasn't sure if it will ever get accepted upstream and
> that's when I started this thread :)
>
>> The other related framework is per-device PM QoS which could be used to
>> set constraints on specific devices, and the genpd governors would then
>> be responsible for looking at the constraints and changing states as
>> needed.
>
> I am not sure if genpd governors are also background governors like
> cpufreq, but we need to make sure that the voltage is raised after the
> function requesting a change returns, so that the clk rate can be
> increased then.

The M3 core takes only care of the voltage but not the clock ?

Just to be sure to understand the problem:
-There is no real voltage value but instead an opaque index that has
to be used with frequency instead of a voltage.
-This index is used by the M3 core to set voltages but M3 core doesn't
set the clock which is managed by Linux.
-The M3 core takes only one index input for the whole voltage domain
and Linux must aggregate the constraints (with probably a max policy)
of all devices that belong this domain

Am i missing something ?

Vincent
>
> --
> viresh

Re: [Discussion] Performance levels of power domains

[Viresh Kumar]

On 27-10-16, 09:17, Vincent Guittot wrote:
> The M3 core takes only care of the voltage but not the clock ?

Yes. The is handled normally.

> Just to be sure to understand the problem:
> -There is no real voltage value but instead an opaque index that has
> to be used with frequency instead of a voltage.
> -This index is used by the M3 core to set voltages but M3 core doesn't
> set the clock which is managed by Linux.
> -The M3 core takes only one index input for the whole voltage domain
> and Linux must aggregate the constraints (with probably a max policy)
> of all devices that belong this domain
> 
> Am i missing something ?

No. All matches to my understanding of the problem.

-- 
viresh

Re: [Discussion] Performance levels of power domains

[Rafael J. Wysocki]

On Wed, Oct 26, 2016 at 9:00 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
>
>> Hi Guys,
>>
>> I wanted to involve you guys to get a discussion going
>> for a problem we want to solve, and so this mail.
>>
>>
>> Platform details:
>>
>> Some of the Qualcom SoCs have the option to configure
>> the performance level of their Power Domains. The performance
>> levels are identified by integer values (lets say 0-9, 0 being the lowest).
>>
>> Another M3 core handles the *real* voltage scaling based on the input
>> received (from software) in terms of these performance levels. The M3
>> core translates the levels into a range of voltages (corners) and selects
>> the right one by itself.
>>
>> Software needs to provide the performance level for the entire domain
>> to the M3 core and so software also needs to handle performance requests
>> from all the devices that lie in the domain X and find a Performance Level P,
>> which can satisfy all the devices (normally the highest requrested level).
>>
>>
>> Problem statement:
>>
>> As we aren't dealing with Voltages here, we can't really get the benefits
>> of the Regulators framework. The regulators are managed internally
>> by the M3 core. All we need is a way for software to comeout with inputs
>> for the M3 core.
>>
>> The OPP framework can be used to include performance levels for
>> each OPP (frequency) entry.
>>
>> But what framework can be used to select performance level of power
>> domains ?
>>
>> By name, power-domain or genpd looks to be the right choice, but until
>> now it is only managing power-on and power-off of devices and domains.
>
> genpd has also recently been extended to support multiple states, though
> those are still idle states, not active (performance) states.
>
>> Should we extend that (along with runtime PM), or do something else?
>
> Yes.  As I've suggested to qcom/linaro folks (off-list discussions), I
> think extending genpd to handle performance states is a logical
> extension.  Otherwise, you will be (re)inventing something that looks an
> awful lot like genpd anyways.

On the Intel side we also have a mechanism to tell the processor about
the power/performance preference and it would be good to have a common
way to do it on all platforms and genpd doesn't look like a
particularly good place for that.

> The other related framework is per-device PM QoS which could be used to
> set constraints on specific devices, and the genpd governors would then
> be responsible for looking at the constraints and changing states as
> needed.

Right.

Let's talk about this at the LPC.

Thanks,
Rafael

Re: [Discussion] Performance levels of power domains

[Rafael J. Wysocki]

On Thu, Oct 27, 2016 at 5:46 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 26-10-16, 12:00, Kevin Hilman wrote:
>> Yes.  As I've suggested to qcom/linaro folks (off-list discussions), I
>
> No one told me this story :)
>
>> think extending genpd to handle performance states is a logical
>> extension.  Otherwise, you will be (re)inventing something that looks an
>> awful lot like genpd anyways.
>
> I completely agree. Runtime PM and genpd look to be the perfect
> placeholder for such stuff. I actually tried to convince Ulf yesterday
> on this and he wasn't sure if it will ever get accepted upstream and
> that's when I started this thread :)
>
>> The other related framework is per-device PM QoS which could be used to
>> set constraints on specific devices, and the genpd governors would then
>> be responsible for looking at the constraints and changing states as
>> needed.
>
> I am not sure if genpd governors are also background governors like
> cpufreq, but we need to make sure that the voltage is raised after the
> function requesting a change returns, so that the clk rate can be
> increased then.

Well, as I've just written in a message to Kevin, there are reasons
why genpd may not be the best place for that.

Thanks,
Rafael

Re: [Discussion] Performance levels of power domains

[Viresh Kumar]

On 27-10-16, 12:11, Rafael J. Wysocki wrote:
> On the Intel side we also have a mechanism to tell the processor about
> the power/performance preference and it would be good to have a common
> way to do it on all platforms and genpd doesn't look like a
> particularly good place for that.
> 
> Let's talk about this at the LPC.

Thanks for your feedback Rafael.

As I wouldn't be attending the LPC (though would try to get some
information from the guys who are going to attend it), will it be
possible for you to summarize why you think genpd is not the right
choice here?

-- 
viresh

Re: [Discussion] Performance levels of power domains

[Rafael J. Wysocki]

On Thu, Oct 27, 2016 at 12:23 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 27-10-16, 12:11, Rafael J. Wysocki wrote:
>> On the Intel side we also have a mechanism to tell the processor about
>> the power/performance preference and it would be good to have a common
>> way to do it on all platforms and genpd doesn't look like a
>> particularly good place for that.
>>
>> Let's talk about this at the LPC.
>
> Thanks for your feedback Rafael.
>
> As I wouldn't be attending the LPC (though would try to get some
> information from the guys who are going to attend it), will it be
> possible for you to summarize why you think genpd is not the right
> choice here?

There is a mechanism to tell the processor about power/performance
preferences on the Intel side and it is not related to genpd in any
way.

Thanks,
Rafael

Re: [Discussion] Performance levels of power domains

[Ulf Hansson]

On 27 October 2016 at 12:11, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Wed, Oct 26, 2016 at 9:00 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> Viresh Kumar <viresh.kumar@linaro.org> writes:
>>
>>> Hi Guys,
>>>
>>> I wanted to involve you guys to get a discussion going
>>> for a problem we want to solve, and so this mail.
>>>
>>>
>>> Platform details:
>>>
>>> Some of the Qualcom SoCs have the option to configure
>>> the performance level of their Power Domains. The performance
>>> levels are identified by integer values (lets say 0-9, 0 being the lowest).
>>>
>>> Another M3 core handles the *real* voltage scaling based on the input
>>> received (from software) in terms of these performance levels. The M3
>>> core translates the levels into a range of voltages (corners) and selects
>>> the right one by itself.
>>>
>>> Software needs to provide the performance level for the entire domain
>>> to the M3 core and so software also needs to handle performance requests
>>> from all the devices that lie in the domain X and find a Performance Level P,
>>> which can satisfy all the devices (normally the highest requrested level).
>>>
>>>
>>> Problem statement:
>>>
>>> As we aren't dealing with Voltages here, we can't really get the benefits
>>> of the Regulators framework. The regulators are managed internally
>>> by the M3 core. All we need is a way for software to comeout with inputs
>>> for the M3 core.
>>>
>>> The OPP framework can be used to include performance levels for
>>> each OPP (frequency) entry.
>>>
>>> But what framework can be used to select performance level of power
>>> domains ?
>>>
>>> By name, power-domain or genpd looks to be the right choice, but until
>>> now it is only managing power-on and power-off of devices and domains.
>>
>> genpd has also recently been extended to support multiple states, though
>> those are still idle states, not active (performance) states.
>>
>>> Should we extend that (along with runtime PM), or do something else?
>>
>> Yes.  As I've suggested to qcom/linaro folks (off-list discussions), I
>> think extending genpd to handle performance states is a logical
>> extension.  Otherwise, you will be (re)inventing something that looks an
>> awful lot like genpd anyways.
>
> On the Intel side we also have a mechanism to tell the processor about
> the power/performance preference and it would be good to have a common
> way to do it on all platforms and genpd doesn't look like a
> particularly good place for that.

One thing that would be interesting to know is where the
power/performance preference "voting" can be done. Is that in also in
the separate processor or is that a job for the kernel?

>
>> The other related framework is per-device PM QoS which could be used to
>> set constraints on specific devices, and the genpd governors would then
>> be responsible for looking at the constraints and changing states as
>> needed.

I guess dev PM QoS could be extended to cover performance preferences
as well, but at the same time that framework is about dealing with
idle - not performance.

Perhaps the OPP framework might be better place? One could also think
of extending this to support "OPP PM domains"...

>
> Right.
>
> Let's talk about this at the LPC.

Yes, count me in!

>
> Thanks,
> Rafael

Kind regards
Uffe

Re: [Discussion] Performance levels of power domains

[Sudeep K N]

On Thu, Oct 27, 2016 at 11:11 AM, Rafael J. Wysocki <rafael@kernel.org> wrote:

[...]

> Let's talk about this at the LPC.
>

I am interested too.

-- 
Regards,
Sudeep

Re: [Discussion] Performance levels of power domains

[Kevin Hilman]

"Rafael J. Wysocki" <rafael@kernel.org> writes:

> On Wed, Oct 26, 2016 at 9:00 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> Viresh Kumar <viresh.kumar@linaro.org> writes:
>>
>>> Hi Guys,
>>>
>>> I wanted to involve you guys to get a discussion going
>>> for a problem we want to solve, and so this mail.
>>>
>>>
>>> Platform details:
>>>
>>> Some of the Qualcom SoCs have the option to configure
>>> the performance level of their Power Domains. The performance
>>> levels are identified by integer values (lets say 0-9, 0 being the lowest).
>>>
>>> Another M3 core handles the *real* voltage scaling based on the input
>>> received (from software) in terms of these performance levels. The M3
>>> core translates the levels into a range of voltages (corners) and selects
>>> the right one by itself.
>>>
>>> Software needs to provide the performance level for the entire domain
>>> to the M3 core and so software also needs to handle performance requests
>>> from all the devices that lie in the domain X and find a Performance Level P,
>>> which can satisfy all the devices (normally the highest requrested level).
>>>
>>>
>>> Problem statement:
>>>
>>> As we aren't dealing with Voltages here, we can't really get the benefits
>>> of the Regulators framework. The regulators are managed internally
>>> by the M3 core. All we need is a way for software to comeout with inputs
>>> for the M3 core.
>>>
>>> The OPP framework can be used to include performance levels for
>>> each OPP (frequency) entry.
>>>
>>> But what framework can be used to select performance level of power
>>> domains ?
>>>
>>> By name, power-domain or genpd looks to be the right choice, but until
>>> now it is only managing power-on and power-off of devices and domains.
>>
>> genpd has also recently been extended to support multiple states, though
>> those are still idle states, not active (performance) states.
>>
>>> Should we extend that (along with runtime PM), or do something else?
>>
>> Yes.  As I've suggested to qcom/linaro folks (off-list discussions), I
>> think extending genpd to handle performance states is a logical
>> extension.  Otherwise, you will be (re)inventing something that looks an
>> awful lot like genpd anyways.
>
> On the Intel side we also have a mechanism to tell the processor about
> the power/performance preference and it would be good to have a common
> way to do it on all platforms and genpd doesn't look like a
> particularly good place for that.
>
>> The other related framework is per-device PM QoS which could be used to
>> set constraints on specific devices, and the genpd governors would then
>> be responsible for looking at the constraints and changing states as
>> needed.
>
> Right.
>
> Let's talk about this at the LPC.

Sounds good.

Kevin

Re: [Discussion] Performance levels of power domains

[Stephen Boyd]

On 10/26, Sudeep Holla wrote:
> 
> 
> On 26/10/16 12:16, Viresh Kumar wrote:
> >On 26-10-16, 12:09, Sudeep Holla wrote:
> 
> [...]
> 
> >>I am mainly interested as there are efforts to standardize these
> >>communication with M3 and there's WIP protocol development[1]. It would
> >>be good to see if this user-case is also considered.
> >
> >What do you mean by that ?
> 
> Basically I wanted to know more details so that such system are also
> considered(I agree it may not have any impact on the protocol at all,
> but still good to consider them) when designing this new SCMI protocol.
> 

There are a couple different wire protocols used to communicate
with the RPM on these platforms. The first one is at
drivers/mfd/qcom_rpm.c, and the second one is at
drivers/soc/qcom/smd-rpm.c. Bjorn upstreamed these drivers based
on the codeaurora sources.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [Discussion] Performance levels of power domains

[Viresh Kumar]

On 27-10-16, 13:46, Ulf Hansson wrote:
> One thing that would be interesting to know is where the
> power/performance preference "voting" can be done. Is that in also in
> the separate processor or is that a job for the kernel?

In our case it is required to be done by the kernel.

> Perhaps the OPP framework might be better place? One could also think
> of extending this to support "OPP PM domains"...

OPP framework will surely get some updates for this, as it needs to
relate the frequencies with power levels for the domains.

-- 
viresh

Re: [Discussion] Performance levels of power domains

[Sudeep Holla]

On 28/10/16 01:22, Stephen Boyd wrote:
> On 10/26, Sudeep Holla wrote:
>>
>>
>> On 26/10/16 12:16, Viresh Kumar wrote:
>>> On 26-10-16, 12:09, Sudeep Holla wrote:
>>
>> [...]
>>
>>>> I am mainly interested as there are efforts to standardize these
>>>> communication with M3 and there's WIP protocol development[1]. It would
>>>> be good to see if this user-case is also considered.
>>>
>>> What do you mean by that ?
>>
>> Basically I wanted to know more details so that such system are also
>> considered(I agree it may not have any impact on the protocol at all,
>> but still good to consider them) when designing this new SCMI protocol.
>>
>
> There are a couple different wire protocols used to communicate
> with the RPM on these platforms. The first one is at
> drivers/mfd/qcom_rpm.c, and the second one is at
> drivers/soc/qcom/smd-rpm.c. Bjorn upstreamed these drivers based
> on the codeaurora sources.
>

Thanks for information Stephen, I will have a look.

-- 
Regards,
Sudeep

Re: [Discussion] Performance levels of power domains

[Viresh Kumar]

On 27 October 2016 at 15:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Wed, Oct 26, 2016 at 9:00 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> Viresh Kumar <viresh.kumar@linaro.org> writes:
>>
>>> Hi Guys,
>>>
>>> I wanted to involve you guys to get a discussion going
>>> for a problem we want to solve, and so this mail.
>>>
>>>
>>> Platform details:
>>>
>>> Some of the Qualcom SoCs have the option to configure
>>> the performance level of their Power Domains. The performance
>>> levels are identified by integer values (lets say 0-9, 0 being the lowest).
>>>
>>> Another M3 core handles the *real* voltage scaling based on the input
>>> received (from software) in terms of these performance levels. The M3
>>> core translates the levels into a range of voltages (corners) and selects
>>> the right one by itself.
>>>
>>> Software needs to provide the performance level for the entire domain
>>> to the M3 core and so software also needs to handle performance requests
>>> from all the devices that lie in the domain X and find a Performance Level P,
>>> which can satisfy all the devices (normally the highest requrested level).
>>>
>>>
>>> Problem statement:
>>>
>>> As we aren't dealing with Voltages here, we can't really get the benefits
>>> of the Regulators framework. The regulators are managed internally
>>> by the M3 core. All we need is a way for software to comeout with inputs
>>> for the M3 core.
>>>
>>> The OPP framework can be used to include performance levels for
>>> each OPP (frequency) entry.
>>>
>>> But what framework can be used to select performance level of power
>>> domains ?
>>>
>>> By name, power-domain or genpd looks to be the right choice, but until
>>> now it is only managing power-on and power-off of devices and domains.
>>
>> genpd has also recently been extended to support multiple states, though
>> those are still idle states, not active (performance) states.
>>
>>> Should we extend that (along with runtime PM), or do something else?
>>
>> Yes.  As I've suggested to qcom/linaro folks (off-list discussions), I
>> think extending genpd to handle performance states is a logical
>> extension.  Otherwise, you will be (re)inventing something that looks an
>> awful lot like genpd anyways.
>
> On the Intel side we also have a mechanism to tell the processor about
> the power/performance preference and it would be good to have a common
> way to do it on all platforms and genpd doesn't look like a
> particularly good place for that.
>
>> The other related framework is per-device PM QoS which could be used to
>> set constraints on specific devices, and the genpd governors would then
>> be responsible for looking at the constraints and changing states as
>> needed.
>
> Right.
>
> Let's talk about this at the LPC.

Any updates from LPC on this ?

Re: [Discussion] Performance levels of power domains

[Kevin Hilman]

Viresh Kumar <viresh.kumar@linaro.org> writes:

> On 27 October 2016 at 15:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
>> On Wed, Oct 26, 2016 at 9:00 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>>> Viresh Kumar <viresh.kumar@linaro.org> writes:
>>>
>>>> Hi Guys,
>>>>
>>>> I wanted to involve you guys to get a discussion going
>>>> for a problem we want to solve, and so this mail.
>>>>
>>>>
>>>> Platform details:
>>>>
>>>> Some of the Qualcom SoCs have the option to configure
>>>> the performance level of their Power Domains. The performance
>>>> levels are identified by integer values (lets say 0-9, 0 being the lowest).
>>>>
>>>> Another M3 core handles the *real* voltage scaling based on the input
>>>> received (from software) in terms of these performance levels. The M3
>>>> core translates the levels into a range of voltages (corners) and selects
>>>> the right one by itself.
>>>>
>>>> Software needs to provide the performance level for the entire domain
>>>> to the M3 core and so software also needs to handle performance requests
>>>> from all the devices that lie in the domain X and find a Performance Level P,
>>>> which can satisfy all the devices (normally the highest requrested level).
>>>>
>>>>
>>>> Problem statement:
>>>>
>>>> As we aren't dealing with Voltages here, we can't really get the benefits
>>>> of the Regulators framework. The regulators are managed internally
>>>> by the M3 core. All we need is a way for software to comeout with inputs
>>>> for the M3 core.
>>>>
>>>> The OPP framework can be used to include performance levels for
>>>> each OPP (frequency) entry.
>>>>
>>>> But what framework can be used to select performance level of power
>>>> domains ?
>>>>
>>>> By name, power-domain or genpd looks to be the right choice, but until
>>>> now it is only managing power-on and power-off of devices and domains.
>>>
>>> genpd has also recently been extended to support multiple states, though
>>> those are still idle states, not active (performance) states.
>>>
>>>> Should we extend that (along with runtime PM), or do something else?
>>>
>>> Yes.  As I've suggested to qcom/linaro folks (off-list discussions), I
>>> think extending genpd to handle performance states is a logical
>>> extension.  Otherwise, you will be (re)inventing something that looks an
>>> awful lot like genpd anyways.
>>
>> On the Intel side we also have a mechanism to tell the processor about
>> the power/performance preference and it would be good to have a common
>> way to do it on all platforms and genpd doesn't look like a
>> particularly good place for that.
>>
>>> The other related framework is per-device PM QoS which could be used to
>>> set constraints on specific devices, and the genpd governors would then
>>> be responsible for looking at the constraints and changing states as
>>> needed.
>>
>> Right.
>>
>> Let's talk about this at the LPC.
>
> Any updates from LPC on this ?

The short version: we agreed that extending genpd to support performance
states/levels is the right way to go.

Kevin