ARM64: juno: SCPI and dependent drivers for v4.3
Hi Olof,
Here is the first pull request for SCPI, clock and cpufreq support on ARM64 Juno development platform for v4.3
Regards,
Sudeep
The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:
Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)
are available in the git repository at:
git://linux-arm.org/linux-skn.git juno_dvfs
for you to fetch changes up to a42b1bbf7bf9a2a1fa4b0deff66581b83541b819:
arm64: dts: add clock support for all the cpus (2015-08-05 11:03:09
+0100)
----------------------------------------------------------------
Sudeep Holla (8):
Documentation: add DT binding for ARM System Control and Power
Interface(SCPI) protocol
firmware: add support for ARM System Control and Power
Interface(SCPI) protocol
clk: add support for clocks provided by SCP(System Control
Processor)
clk: scpi: add support for cpufreq virtual device
cpufreq: arm_big_little: add SCPI interface driver
arm64: dts: add SRAM, MHU mailbox and SCPI support on Juno
arm64: dts: add CPU topology on Juno
arm64: dts: add clock support for all the cpus
Documentation/devicetree/bindings/arm/arm,scpi.txt | 150 +++ MAINTAINERS | 10 + arch/arm64/boot/dts/arm/juno-base.dtsi | 54 ++ arch/arm64/boot/dts/arm/juno-r1.dts | 32 + arch/arm64/boot/dts/arm/juno.dts | 32 + drivers/clk/Kconfig | 10 + drivers/clk/Makefile | 1 + drivers/clk/clk-scpi.c | 325 +++++++ drivers/cpufreq/Kconfig.arm | 9 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/scpi-cpufreq.c | 124 +++ drivers/firmware/Kconfig | 19 + drivers/firmware/Makefile | 1 + drivers/firmware/arm_scpi.c | 711 +++++++++++++ include/linux/scpi_protocol.h | 61 ++ 15 files changed, 1540 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt create mode 100644 drivers/clk/clk-scpi.c
create mode 100644 drivers/cpufreq/scpi-cpufreq.c
create mode 100644 drivers/firmware/arm_scpi.c
create mode 100644 include/linux/scpi_protocol.h
Quoted 5 lines · Sudeep Holla
Hi Olof,
Here is the first pull request for SCPI, clock and cpufreq support on ARM64 Juno development platform for v4.3
Hi,
I'd like to hear from Catalin and Will on why ARM is doing this. Catalin and Will are pushing back very hard at vendors who don't use PSCI for CPU power management, and then they have coworkers that are looking to merge this directly into the kernel.
Hmm?
-Olof
Quoted 8 lines · Olof Johansson
Quoted 2 lines · Sudeep Holla
Here is the first pull request for SCPI, clock and cpufreq support on ARM64 Juno development platform for v4.3
I'd like to hear from Catalin and Will on why ARM is doing this. Catalin and Will are pushing back very hard at vendors who don't use PSCI for CPU power management, and then they have coworkers that are looking to merge this directly into the kernel.
Actually, the arm64 CPU power management story is pretty much handled by Lorenzo and Sudeep in my team, so I trust their judgement ;). But I agree with you that a better explanation on the reasons behind this is needed, otherwise we risk confusing messages. I'll try to summarise it below but Sudeep can reply with more details.
PSCI only covers CPU boot/cpuidle and platform suspend. It does not have any provisions for DVFS and I'm not sure this could be easily standardised (or whether we could find enough supporters to get it adopted).
SCPI is a (standard) interface to a coprocessor handling clocks etc. to be used with cpufreq. This patchset adds support for cpufreq/dvs which is not handled by PSCI. So, just to clarify the acronyms:
SCPI - System Control and Power Interface - it's a protocol for communicating with a System Control Processor (e.g. Cortex-M3) via mailboxes. It is used in Linux for DVFS but this is *not* a secure/EL3 firmware interface (a.k.a. SMC calls). It indeed a firmware interface but the firmware runs on a separate coprocessor and not on the CPU itself.
PSCI - Power State Coordination Interface - it is a secure firmware interface for coordinating the CPU power states (idle, not DVFS). The firmware may use an SCPI communication channel (e.g. deeper sleep states where clock changes are needed).
Signature · 1 line
Catalin
Quoted 10 lines · Catalin Marinas
Quoted 8 lines · Olof Johansson
Quoted 2 lines · Sudeep Holla
Here is the first pull request for SCPI, clock and cpufreq support on ARM64 Juno development platform for v4.3
I'd like to hear from Catalin and Will on why ARM is doing this. Catalin and Will are pushing back very hard at vendors who don't use PSCI for CPU power management, and then they have coworkers that are looking to merge this directly into the kernel.
Quoted 6 lines
Actually, the arm64 CPU power management story is pretty much handled by Lorenzo and Sudeep in my team, so I trust their judgement ;). But I agree with you that a better explanation on the reasons behind this is needed, otherwise we risk confusing messages. I'll try to summarise it below but Sudeep can reply with more details.
(I will use the acronomys directly as Catalin has already explained the difference)
Thanks Catalin for the detailed explanation. I agree that this pull request has not much details, but the patch series makes reference only to the clocks and features provided by the SCP(System Control Processor) to be used by Linux(non-secure) and nothing about CPU power states that are handled by PSCI. This SCPI is completely independent and orthogonal to PSCI.
Quoted 5 lines
PSCI only covers CPU boot/cpuidle and platform suspend. It does not have any provisions for DVFS and I'm not sure this could be easily standardised (or whether we could find enough supporters to get it adopted).
Though we are not campaigning it as aggressively as PSCI.
Quoted 10 lines
SCPI is a (standard) interface to a coprocessor handling clocks etc. to be used with cpufreq. This patchset adds support for cpufreq/dvs which is not handled by PSCI. So, just to clarify the acronyms:
SCPI - System Control and Power Interface - it's a protocol for communicating with a System Control Processor (e.g. Cortex-M3) via mailboxes. It is used in Linux for DVFS but this is *not* a secure/EL3 firmware interface (a.k.a. SMC calls). It indeed a firmware interface but the firmware runs on a separate coprocessor and not on the CPU itself.
Quoted 5 lines
PSCI - Power State Coordination Interface - it is a secure firmware interface for coordinating the CPU power states (idle, not DVFS). The firmware may use an SCPI communication channel (e.g. deeper sleep states where clock changes are needed).
I will add some more information to (hopefully) clarify the doubts.
SCP(System Control Processor) offers control and management of the core/cluster power states, various power domain DVFS including the core/cluster, certain system clocks configuration, thermal sensors and many others.
Though the core/cluster power states are also handled this SCP, they are accessible only through secure channels and PSCI firmware implementations on the platform rely on that internally. Non-secure access/requests are not possible.
Just to summarize, this SCP helps to offload all the power management work to a dedicated low power processor which can be always running. On Juno, its Cortex-M while on AMD Seattle it's Cortex-A5.
Regards,
Sudeep
Hi,
Quoted 23 lines · Sudeep Holla
Quoted 10 lines · Catalin Marinas
Quoted 8 lines · Olof Johansson
Quoted 2 lines · Sudeep Holla
Here is the first pull request for SCPI, clock and cpufreq support on ARM64 Juno development platform for v4.3
I'd like to hear from Catalin and Will on why ARM is doing this. Catalin and Will are pushing back very hard at vendors who don't use PSCI for CPU power management, and then they have coworkers that are looking to merge this directly into the kernel.
Quoted 6 lines
Actually, the arm64 CPU power management story is pretty much handled by Lorenzo and Sudeep in my team, so I trust their judgement ;). But I agree with you that a better explanation on the reasons behind this is needed, otherwise we risk confusing messages. I'll try to summarise it below but Sudeep can reply with more details.
(I will use the acronomys directly as Catalin has already explained the difference)
Quoted 6 lines
Thanks Catalin for the detailed explanation. I agree that this pull request has not much details, but the patch series makes reference only to the clocks and features provided by the SCP(System Control Processor) to be used by Linux(non-secure) and nothing about CPU power states that are handled by PSCI. This SCPI is completely independent and orthogonal to PSCI.
Yes, I am aware that PSCI and SCPI are two confusingly similar acronyms that represent separate things. My concern though is that we're letting in a poorly architected solution into the kernel with SCPI. PSCI is already choosing to abstract this outside of the kernel. Is there a reason SCPI isn't using the same approach?
Quoted 7 lines
Quoted 5 lines
PSCI only covers CPU boot/cpuidle and platform suspend. It does not have any provisions for DVFS and I'm not sure this could be easily standardised (or whether we could find enough supporters to get it adopted).
Though we are not campaigning it as aggressively as PSCI.
Which, given the resistance to pick up PSCI, this is unlikely to be used by anyone...
Quoted 23 lines
Quoted 10 lines
SCPI is a (standard) interface to a coprocessor handling clocks etc. to be used with cpufreq. This patchset adds support for cpufreq/dvs which is not handled by PSCI. So, just to clarify the acronyms:
SCPI - System Control and Power Interface - it's a protocol for communicating with a System Control Processor (e.g. Cortex-M3) via mailboxes. It is used in Linux for DVFS but this is *not* a secure/EL3 firmware interface (a.k.a. SMC calls). It indeed a firmware interface but the firmware runs on a separate coprocessor and not on the CPU itself.
Quoted 5 lines
PSCI - Power State Coordination Interface - it is a secure firmware interface for coordinating the CPU power states (idle, not DVFS). The firmware may use an SCPI communication channel (e.g. deeper sleep states where clock changes are needed).
I will add some more information to (hopefully) clarify the doubts.
SCP(System Control Processor) offers control and management of the core/cluster power states, various power domain DVFS including the core/cluster, certain system clocks configuration, thermal sensors and many others.
Quoted 8 lines
Though the core/cluster power states are also handled this SCP, they are accessible only through secure channels and PSCI firmware implementations on the platform rely on that internally. Non-secure access/requests are not possible.
Just to summarize, this SCP helps to offload all the power management work to a dedicated low power processor which can be always running. On Juno, its Cortex-M while on AMD Seattle it's Cortex-A5.
I understand what the SCP is used for. What I don't understand is why you're adding all this complexity in the kernel for it.
Also, is there only one known implementation of this today on Juno? Are there others coming soon? Single-user frameworks tend to be hard to get right, and it's usually much better to wait until it's clear it will fit more than just the original target.
Anyway, the git server you provided the link to in the original email (linux-arm.org) seems to be offline so I couldn't fetch a fresh copy of the branch to look at.
It's pretty clear this is not 4.3 material at this point, so I'll take a look at it later.
-Olof
Hi Olof,
Quoted 33 lines · Olof Johansson
Hi,
Quoted 23 lines · Sudeep Holla
Quoted 10 lines · Catalin Marinas
Quoted 8 lines · Olof Johansson
Quoted 2 lines · Sudeep Holla
Here is the first pull request for SCPI, clock and cpufreq support on ARM64 Juno development platform for v4.3
I'd like to hear from Catalin and Will on why ARM is doing this. Catalin and Will are pushing back very hard at vendors who don't use PSCI for CPU power management, and then they have coworkers that are looking to merge this directly into the kernel.
Quoted 6 lines
Actually, the arm64 CPU power management story is pretty much handled by Lorenzo and Sudeep in my team, so I trust their judgement ;). But I agree with you that a better explanation on the reasons behind this is needed, otherwise we risk confusing messages. I'll try to summarise it below but Sudeep can reply with more details.
(I will use the acronomys directly as Catalin has already explained the difference)
Quoted 6 lines
Thanks Catalin for the detailed explanation. I agree that this pull request has not much details, but the patch series makes reference only to the clocks and features provided by the SCP(System Control Processor) to be used by Linux(non-secure) and nothing about CPU power states that are handled by PSCI. This SCPI is completely independent and orthogonal to PSCI.
Quoted 6 lines
Yes, I am aware that PSCI and SCPI are two confusingly similar acronyms that represent separate things. My concern though is that we're letting in a poorly architected solution into the kernel with SCPI. PSCI is already choosing to abstract this outside of the kernel. Is there a reason SCPI isn't using the same approach?
I am not sure we can compare the CPU power states with the CPU DVFS. In case of power states, we need to ensure all the exception levels have saved the context and hence PSCI abstraction makes sense for the kernel. However the CPU DVFS is mostly driven by the kernel based on the load, so we talk directly to the power controller from the kernel.
In way SCPI is abstracting by hiding all the regulators and PLLs you need to handle. So I may be missing to understand when you say SCPI also use PSCI approach.
Quoted 11 lines
Quoted 7 lines
Quoted 5 lines
PSCI only covers CPU boot/cpuidle and platform suspend. It does not have any provisions for DVFS and I'm not sure this could be easily standardised (or whether we could find enough supporters to get it adopted).
Though we are not campaigning it as aggressively as PSCI.
Which, given the resistance to pick up PSCI, this is unlikely to be used by anyone...
Agreed even I am not sure how widely will that be accepted, but we need to support the systems which have SCPI right ? Like Juno for now.
Quoted 28 lines
Quoted 28 lines
Quoted 10 lines
SCPI is a (standard) interface to a coprocessor handling clocks etc. to be used with cpufreq. This patchset adds support for cpufreq/dvs which is not handled by PSCI. So, just to clarify the acronyms:
SCPI - System Control and Power Interface - it's a protocol for communicating with a System Control Processor (e.g. Cortex-M3) via mailboxes. It is used in Linux for DVFS but this is *not* a secure/EL3 firmware interface (a.k.a. SMC calls). It indeed a firmware interface but the firmware runs on a separate coprocessor and not on the CPU itself.
Quoted 5 lines
PSCI - Power State Coordination Interface - it is a secure firmware interface for coordinating the CPU power states (idle, not DVFS). The firmware may use an SCPI communication channel (e.g. deeper sleep states where clock changes are needed).
I will add some more information to (hopefully) clarify the doubts.
SCP(System Control Processor) offers control and management of the core/cluster power states, various power domain DVFS including the core/cluster, certain system clocks configuration, thermal sensors and many others.
Though the core/cluster power states are also handled this SCP, they are accessible only through secure channels and PSCI firmware implementations on the platform rely on that internally. Non-secure access/requests are not possible.
Quoted 7 lines
Quoted 3 lines
Just to summarize, this SCP helps to offload all the power management work to a dedicated low power processor which can be always running. On Juno, its Cortex-M while on AMD Seattle it's Cortex-A5.
I understand what the SCP is used for. What I don't understand is why you're adding all this complexity in the kernel for it.
I am not sure how we can avoid that though. Any thoughts ?
Quoted 5 lines
Also, is there only one known implementation of this today on Juno? Are there others coming soon? Single-user frameworks tend to be hard to get right, and it's usually much better to wait until it's clear it will fit more than just the original target.
No argument on that, the specification is not reviewed as much as PSCI but we do have version, so can be fixed/enhanced in future. It's no different w.r.t PSCI in that
respect IMO.
Yes currently only on Juno, but future ARM Ltd. platforms have plans to reuse the same.
Quoted 4 lines
Anyway, the git server you provided the link to in the original email (linux-arm.org) seems to be offline so I couldn't fetch a fresh copy of the branch to look at.
Extremely sorry for that(not much under my control :(), I will get it fixed ASAP.
I am current away attending LPC.
Quoted 3 lines
It's pretty clear this is not 4.3 material at this point, so I'll take a look at it later.
Fair enough, I understand that its too late for v4.3
Regards,
Sudeep
Hi,
Am Freitag, 21. August 2015, 09:17:32 schrieb Olof Johansson:
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
PSCI only covers CPU boot/cpuidle and platform suspend. It does not have any provisions for DVFS and I'm not sure this could be easily standardised (or whether we could find enough supporters to get it adopted).
Though we are not campaigning it as aggressively as PSCI.
Which, given the resistance to pick up PSCI, this is unlikely to be used by anyone...
Rockchip seems to use SCPI to offload ddr frequency to a mcu scaling on the rk3368 ;-)
Heiko
Quoted 8 lines · Heiko Stuebner
Hi,
Am Freitag, 21. August 2015, 09:17:32 schrieb Olof Johansson:
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
PSCI only covers CPU boot/cpuidle and platform suspend. It does not have any provisions for DVFS and I'm not sure this could be easily standardised (or whether we could find enough supporters to get it adopted).
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Though we are not campaigning it as aggressively as PSCI.
Which, given the resistance to pick up PSCI, this is unlikely to be used by anyone...
Rockchip seems to use SCPI to offload ddr frequency to a mcu scaling on the rk3368 ;-)
Good to hear that, thanks Heiko for letting us know. IMHO I must admit I am still sceptical about large SCPI adoption.
Regards,
Sudeep