| Message ID | cover.1639472078.git.oleksii_moisieiev@epam.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Introduce SCI-mediator feature | expand |
On 14.12.21 11:34, Oleksii Moisieiev wrote: Hi Oleksii > Introducing the feature, called SCI mediator. > It's purpose is to redirect SCMI requests from the domains to firmware > (SCP, ATF etc), which controls the power/clock/resets etc. > The idea is to make SCP firmware (or similar, such as AT-F) responsible for > control power/clock/resets and provide SCMI interface so controls can be shared > between the Domains. > Originally, we've met a problem, that the devices, shared between different > Domains, can't have an access to HW registers to work with clocks/resets/power > etc. You have to pass cpg to the Domain, so the devices can access HW directly. > The solution for this is to move HW controls over power/clock/resets to > SCP firmware and use Linux-kernel SCMI drivers to pass requests to SCP. > Xen is responsible for permissions setting, so Domain can access only to > power/clock/resets which are related to this Domain. Also XEN is the mediator > which redirects SCMI requests, adding agentID so firmware should know the > sender. > SMC is currently used as transport, but this should be configurable. > > Here is the high level design: > > SCI (System Control Interface) feature can be enabled in xen_config: >> CONFIG_SCI=y > Mediator can be configured: >> CONFIG_SCMI_SMC=y > Currently, only SCMI_SMC mediator is implemented, which using shared memory > region to communicate with firmware and SMC as transport. > > Xen scmi should be configured in the device-tree. > Format is the following: > cpu_scp_shm: scp-shmem@0x53FF0000 { > compatible = "arm,scmi-shmem"; > reg = <0x0 0x53FF0000 0x0 0x1000>; > }; > > firmware { > scmi { > compatible = "arm,scmi-smc"; > arm,smc-id = <0x82000002>; > shmem = <&cpu_scp_shm>; > #address-cells = <1>; > #size-cells = <0>; > > scmi_power: protocol@11 { > reg = <0x11>; > #power-domain-cells = <1>; > }; > > scmi_clock: protocol@14 { > reg = <0x14>; > #clock-cells = <1>; > }; > > scmi_reset: protocol@16 { > reg = <0x16>; > #reset-cells = <1>; > }; > }; > }; > > Where: > &cpu_scp_shm is the shared memory for scmi buffers; > 0x53FF0000, size 0x1000 is the platform specific free address, which provide > space for the communication. > &scmi node, which should be copied to Dom0 device-tree. > > Device configured to use scmi: > &avb { > scmi_devid = <0>; > clocks = <&scmi_clock 0>; > power-domains = <&scmi_power 0>; > resets = <&scmi_reset 0>; > }; > > Where: > scmi_devid - id from the firmware, which is assigned for AVB. > > During initialization, XEN scans probes the first SCI-mediator driver which has > matching node in the device-tree. If no device-tree was provided, then the > first registered mediator driver should be probed. > > DomX should be configured: > Device-tree should include the same nodes, described above. > &cpu_scp_shm should be altered during domain creation. Xen allocates free page > from the memory region, provided in &cpu_scp_shm in XEN device-tree, so each > domain should have unique page. Nodes &cpu_scp_shm and /firmware/scmi should be > copied from partial device-tree to domain device-tree, so kernel can initialize > scmi driver. > > SCI mediator can be enabled in dom.cfg the following way: >> sci = "scmi_smc" > which sets scmi_smc to be used for the domain. Great work! I can imagine this is going to be nice feature once upstreamed. I am wondering, would the Xen (with the required updates of course) also be able to send it's own requests to the SCP? For example, to control overall system performance (CPU frequency) or other let's say important power management task. > > Oleksii Moisieiev (5): > xen/arm: add support for Renesas R-Car Gen3 platform > xen/arm: add generic SCI mediator framework > xen/arm: introduce SCMI-SMC mediator driver > tools/arm: add "scmi_smc" option to xl.cfg > xen/arm: add SCI mediator support for DomUs > > MAINTAINERS | 6 + > docs/man/xl.cfg.5.pod.in | 22 + > tools/include/libxl.h | 5 + > tools/include/xenctrl.h | 3 + > tools/include/xenguest.h | 2 + > tools/libs/ctrl/xc_domain.c | 23 + > tools/libs/guest/xg_dom_arm.c | 5 +- > tools/libs/light/libxl_arm.c | 122 ++++- > tools/libs/light/libxl_create.c | 54 +- > tools/libs/light/libxl_dom.c | 1 + > tools/libs/light/libxl_internal.h | 4 + > tools/libs/light/libxl_types.idl | 6 + > tools/xl/xl_parse.c | 9 + > xen/arch/arm/Kconfig | 10 + > xen/arch/arm/Makefile | 1 + > xen/arch/arm/domain.c | 24 + > xen/arch/arm/domain_build.c | 11 + > xen/arch/arm/domctl.c | 15 + > xen/arch/arm/platforms/Makefile | 1 + > xen/arch/arm/platforms/rcar3.c | 47 ++ > xen/arch/arm/sci/Kconfig | 10 + > xen/arch/arm/sci/Makefile | 2 + > xen/arch/arm/sci/sci.c | 128 +++++ > xen/arch/arm/sci/scmi_smc.c | 795 ++++++++++++++++++++++++++++++ > xen/arch/arm/setup.c | 1 + > xen/arch/arm/xen.lds.S | 7 + > xen/include/asm-arm/domain.h | 4 + > xen/include/asm-arm/sci/sci.h | 162 ++++++ > xen/include/public/arch-arm.h | 11 + > xen/include/public/domctl.h | 9 + > 30 files changed, 1485 insertions(+), 15 deletions(-) > create mode 100644 xen/arch/arm/platforms/rcar3.c > create mode 100644 xen/arch/arm/sci/Kconfig > create mode 100644 xen/arch/arm/sci/Makefile > create mode 100644 xen/arch/arm/sci/sci.c > create mode 100644 xen/arch/arm/sci/scmi_smc.c > create mode 100644 xen/include/asm-arm/sci/sci.h >
Hi Oleksandr, On Thu, Dec 16, 2021 at 02:33:28AM +0200, Oleksandr wrote: > > On 14.12.21 11:34, Oleksii Moisieiev wrote: > > > Hi Oleksii > > > Introducing the feature, called SCI mediator. > > It's purpose is to redirect SCMI requests from the domains to firmware > > (SCP, ATF etc), which controls the power/clock/resets etc. > > The idea is to make SCP firmware (or similar, such as AT-F) responsible for > > control power/clock/resets and provide SCMI interface so controls can be shared > > between the Domains. > > Originally, we've met a problem, that the devices, shared between different > > Domains, can't have an access to HW registers to work with clocks/resets/power > > etc. You have to pass cpg to the Domain, so the devices can access HW directly. > > The solution for this is to move HW controls over power/clock/resets to > > SCP firmware and use Linux-kernel SCMI drivers to pass requests to SCP. > > Xen is responsible for permissions setting, so Domain can access only to > > power/clock/resets which are related to this Domain. Also XEN is the mediator > > which redirects SCMI requests, adding agentID so firmware should know the > > sender. > > SMC is currently used as transport, but this should be configurable. > > > > Here is the high level design: > > > > SCI (System Control Interface) feature can be enabled in xen_config: > > > CONFIG_SCI=y > > Mediator can be configured: > > > CONFIG_SCMI_SMC=y > > Currently, only SCMI_SMC mediator is implemented, which using shared memory > > region to communicate with firmware and SMC as transport. > > > > Xen scmi should be configured in the device-tree. > > Format is the following: > > cpu_scp_shm: scp-shmem@0x53FF0000 { > > compatible = "arm,scmi-shmem"; > > reg = <0x0 0x53FF0000 0x0 0x1000>; > > }; > > > > firmware { > > scmi { > > compatible = "arm,scmi-smc"; > > arm,smc-id = <0x82000002>; > > shmem = <&cpu_scp_shm>; > > #address-cells = <1>; > > #size-cells = <0>; > > > > scmi_power: protocol@11 { > > reg = <0x11>; > > #power-domain-cells = <1>; > > }; > > > > scmi_clock: protocol@14 { > > reg = <0x14>; > > #clock-cells = <1>; > > }; > > > > scmi_reset: protocol@16 { > > reg = <0x16>; > > #reset-cells = <1>; > > }; > > }; > > }; > > > > Where: > > &cpu_scp_shm is the shared memory for scmi buffers; > > 0x53FF0000, size 0x1000 is the platform specific free address, which provide > > space for the communication. > > &scmi node, which should be copied to Dom0 device-tree. > > > > Device configured to use scmi: > > &avb { > > scmi_devid = <0>; > > clocks = <&scmi_clock 0>; > > power-domains = <&scmi_power 0>; > > resets = <&scmi_reset 0>; > > }; > > > > Where: > > scmi_devid - id from the firmware, which is assigned for AVB. > > > > During initialization, XEN scans probes the first SCI-mediator driver which has > > matching node in the device-tree. If no device-tree was provided, then the > > first registered mediator driver should be probed. > > > > DomX should be configured: > > Device-tree should include the same nodes, described above. > > &cpu_scp_shm should be altered during domain creation. Xen allocates free page > > from the memory region, provided in &cpu_scp_shm in XEN device-tree, so each > > domain should have unique page. Nodes &cpu_scp_shm and /firmware/scmi should be > > copied from partial device-tree to domain device-tree, so kernel can initialize > > scmi driver. > > > > SCI mediator can be enabled in dom.cfg the following way: > > > sci = "scmi_smc" > > which sets scmi_smc to be used for the domain. > > > Great work! I can imagine this is going to be nice feature once upstreamed. > > I am wondering, would the Xen (with the required updates of course) also be > able to send it's own requests to the SCP? For example, to control overall > system performance (CPU frequency) > > or other let's say important power management task. > I think yes. In current implementation Xen register itself as privilleged agent and use it's own channel to request which is used to get agent configuration and process device permissions. I think this channel can also be used to do some configuration tasks via SCMI. But this will require updates. -- Oleksii. > > > > > Oleksii Moisieiev (5): > > xen/arm: add support for Renesas R-Car Gen3 platform > > xen/arm: add generic SCI mediator framework > > xen/arm: introduce SCMI-SMC mediator driver > > tools/arm: add "scmi_smc" option to xl.cfg > > xen/arm: add SCI mediator support for DomUs > > > > MAINTAINERS | 6 + > > docs/man/xl.cfg.5.pod.in | 22 + > > tools/include/libxl.h | 5 + > > tools/include/xenctrl.h | 3 + > > tools/include/xenguest.h | 2 + > > tools/libs/ctrl/xc_domain.c | 23 + > > tools/libs/guest/xg_dom_arm.c | 5 +- > > tools/libs/light/libxl_arm.c | 122 ++++- > > tools/libs/light/libxl_create.c | 54 +- > > tools/libs/light/libxl_dom.c | 1 + > > tools/libs/light/libxl_internal.h | 4 + > > tools/libs/light/libxl_types.idl | 6 + > > tools/xl/xl_parse.c | 9 + > > xen/arch/arm/Kconfig | 10 + > > xen/arch/arm/Makefile | 1 + > > xen/arch/arm/domain.c | 24 + > > xen/arch/arm/domain_build.c | 11 + > > xen/arch/arm/domctl.c | 15 + > > xen/arch/arm/platforms/Makefile | 1 + > > xen/arch/arm/platforms/rcar3.c | 47 ++ > > xen/arch/arm/sci/Kconfig | 10 + > > xen/arch/arm/sci/Makefile | 2 + > > xen/arch/arm/sci/sci.c | 128 +++++ > > xen/arch/arm/sci/scmi_smc.c | 795 ++++++++++++++++++++++++++++++ > > xen/arch/arm/setup.c | 1 + > > xen/arch/arm/xen.lds.S | 7 + > > xen/include/asm-arm/domain.h | 4 + > > xen/include/asm-arm/sci/sci.h | 162 ++++++ > > xen/include/public/arch-arm.h | 11 + > > xen/include/public/domctl.h | 9 + > > 30 files changed, 1485 insertions(+), 15 deletions(-) > > create mode 100644 xen/arch/arm/platforms/rcar3.c > > create mode 100644 xen/arch/arm/sci/Kconfig > > create mode 100644 xen/arch/arm/sci/Makefile > > create mode 100644 xen/arch/arm/sci/sci.c > > create mode 100644 xen/arch/arm/sci/scmi_smc.c > > create mode 100644 xen/include/asm-arm/sci/sci.h > > > -- > Regards, > > Oleksandr Tyshchenko >