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
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.
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.
:)
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.
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.
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.
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
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.
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
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.
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
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
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
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?
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
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
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.
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.
"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
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 ?
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
linaro-kernel@lists.linaro.org
-
Kevin Hilman -
Rafael J. Wysocki -
Stephen Boyd -
Sudeep Holla -
Sudeep K N -
Ulf Hansson -
Vincent Guittot -
Viresh Kumar