|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC v1 0/5] Introduce SCI-mediator feature
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
>
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |