Hi all,
This email intends to ask for potential interest in extending the support for the SCMI perf-domain protocol in the Linux kernel and in the firmware. Please, feel free to ignore this, while a short answer like "sounds interesting" would be sufficient information at this point. Some more details below.
Today, the current support in the Linux kernel for the SCMI perf-domain protocol, is limited to be used for CPU frequency scaling, through the cpufreq subsystem. However, the SCMI perf-domain protocol isn't really limited to CPUs, but fits well for other generic peripheral devices too. By extending the support, we can avoid the need for SoC specific protocols/interfaces, while scaling performance for non-CPU devices.
From the Linux kernel point of view, we already have generic support
for DVFS (Dynamic Voltage Frequency Scaling), through a mixture of subsystems/libraries. Without going into details, we should be able to tap into these existing infrastructures, to add support for the SCMI perf-protocol. In this way, the support would be generic and nicely abstracted from lower layer drivers/subsystems.
Thoughts?
Kind regards Ulf Hansson, Linaro Kernel Team
On Tue, Dec 07, 2021 at 11:27:06AM +0100, Ulf Hansson wrote:
Hi all,
This email intends to ask for potential interest in extending the support for the SCMI perf-domain protocol in the Linux kernel and in the firmware. Please, feel free to ignore this, while a short answer like "sounds interesting" would be sufficient information at this point. Some more details below.
Today, the current support in the Linux kernel for the SCMI perf-domain protocol, is limited to be used for CPU frequency scaling, through the cpufreq subsystem. However, the SCMI perf-domain protocol isn't really limited to CPUs, but fits well for other generic peripheral devices too. By extending the support, we can avoid the need for SoC specific protocols/interfaces, while scaling performance for non-CPU devices.
From the Linux kernel point of view, we already have generic support for DVFS (Dynamic Voltage Frequency Scaling), through a mixture of subsystems/libraries. Without going into details, we should be able to tap into these existing infrastructures, to add support for the SCMI perf-protocol. In this way, the support would be generic and nicely abstracted from lower layer drivers/subsystems.
Thoughts?
Definitely interested. As discussed in some other thread on the list, I am interested in more details on how this will look for CPUs. You did mention about creation of power domains to control these performance domains as one of the proposal. I would like to know what that means for CPUs with OSI cpuidle(as well as PC) which creates power domains already.
On Tue, 7 Dec 2021 at 11:46, Sudeep Holla sudeep.holla@arm.com wrote:
On Tue, Dec 07, 2021 at 11:27:06AM +0100, Ulf Hansson wrote:
Hi all,
This email intends to ask for potential interest in extending the support for the SCMI perf-domain protocol in the Linux kernel and in the firmware. Please, feel free to ignore this, while a short answer like "sounds interesting" would be sufficient information at this point. Some more details below.
Today, the current support in the Linux kernel for the SCMI perf-domain protocol, is limited to be used for CPU frequency scaling, through the cpufreq subsystem. However, the SCMI perf-domain protocol isn't really limited to CPUs, but fits well for other generic peripheral devices too. By extending the support, we can avoid the need for SoC specific protocols/interfaces, while scaling performance for non-CPU devices.
From the Linux kernel point of view, we already have generic support for DVFS (Dynamic Voltage Frequency Scaling), through a mixture of subsystems/libraries. Without going into details, we should be able to tap into these existing infrastructures, to add support for the SCMI perf-protocol. In this way, the support would be generic and nicely abstracted from lower layer drivers/subsystems.
Thoughts?
Definitely interested. As discussed in some other thread on the list, I am interested in more details on how this will look for CPUs. You did mention about creation of power domains to control these performance domains as one of the proposal. I would like to know what that means for CPUs with OSI cpuidle(as well as PC) which creates power domains already.
Sudeep, thanks for your reply! Good to hear that you are interested in this!
When it comes to the PSCI power domains (OSI or PC mode), controlled by the cpuidle driver - I believe it's probably a good idea to keep those decoupled from a potential SCMI perf "power-domain". A CPU can be part of multiple power domains, one for PSCI (idle) and one for SCMI (perf), for example.
However, I need to explore things more before I can make a formal proposal. At this point, it is mostly ideas floating around in my head.
One thing though, that is related to this, could be to explore a hierarchical power-domain layout, combining a PSCI power domain with an SCMI *power-domain*. Or maybe that layout should entirely be hidden in FW, thus doesn't need to be modeled in DT? What do you think?
In any case, the first step I suggest us looking at, is to try to make the SCMI perf-domain protocol to work for generic peripheral devices too, rather than as currently, being limited to CPUs. Does this make sense to you too?
Kind regards Uffe
On Tue, Dec 07, 2021 at 01:46:30PM +0100, Ulf Hansson wrote:
On Tue, 7 Dec 2021 at 11:46, Sudeep Holla sudeep.holla@arm.com wrote:
On Tue, Dec 07, 2021 at 11:27:06AM +0100, Ulf Hansson wrote:
Hi all,
This email intends to ask for potential interest in extending the support for the SCMI perf-domain protocol in the Linux kernel and in the firmware. Please, feel free to ignore this, while a short answer like "sounds interesting" would be sufficient information at this point. Some more details below.
Today, the current support in the Linux kernel for the SCMI perf-domain protocol, is limited to be used for CPU frequency scaling, through the cpufreq subsystem. However, the SCMI perf-domain protocol isn't really limited to CPUs, but fits well for other generic peripheral devices too. By extending the support, we can avoid the need for SoC specific protocols/interfaces, while scaling performance for non-CPU devices.
From the Linux kernel point of view, we already have generic support for DVFS (Dynamic Voltage Frequency Scaling), through a mixture of subsystems/libraries. Without going into details, we should be able to tap into these existing infrastructures, to add support for the SCMI perf-protocol. In this way, the support would be generic and nicely abstracted from lower layer drivers/subsystems.
Thoughts?
Definitely interested. As discussed in some other thread on the list, I am interested in more details on how this will look for CPUs. You did mention about creation of power domains to control these performance domains as one of the proposal. I would like to know what that means for CPUs with OSI cpuidle(as well as PC) which creates power domains already.
Sudeep, thanks for your reply! Good to hear that you are interested in this!
I am for sure very much interested. I had spent some time to see what is the best way to integrate SCMI perf with devfreq long ago but with limited time and not much interest from other(GPU in particular), I didn't pursue this much.
When it comes to the PSCI power domains (OSI or PC mode), controlled by the cpuidle driver - I believe it's probably a good idea to keep those decoupled from a potential SCMI perf "power-domain". A CPU can be part of multiple power domains, one for PSCI (idle) and one for SCMI (perf), for example.
I am interested in details and will wait to hear from you. I agree that it needs to be separate.
However, I need to explore things more before I can make a formal proposal. At this point, it is mostly ideas floating around in my head.
No worries, it will need some thinking esp. for CPUs, non CPUs may not be that difficult(I may be wrong but I think it will be simpler relatively)
One thing though, that is related to this, could be to explore a hierarchical power-domain layout, combining a PSCI power domain with an SCMI *power-domain*. Or maybe that layout should entirely be hidden in FW, thus doesn't need to be modeled in DT? What do you think?
I prefer not to have any more info in DT other than the SCMI perf domain it belongs to. But let us see how this will evolve. The idea is to not replicate any info or derive it from DT when it can be inferred from the firmware so that we won't end up with any conflicts.
In any case, the first step I suggest us looking at, is to try to make the SCMI perf-domain protocol to work for generic peripheral devices too, rather than as currently, being limited to CPUs. Does this make sense to you too?
Absolutely. GPU for example, we must be able to use Juno too for this in case we don't find any other *better* and *interesting* platform.
Thanks for pick up this. It have been in my TODO list forever, so I am all for this idea.
-- Regards, Sudeep
linaro-open-discussions@op-lists.linaro.org
-
Sudeep Holla -
Ulf Hansson