arm: introduce basic scmi support and scmi reset driver by GrygiriiS · Pull Request #124 · xen-troops/zephyr

GrygiriiS · 2024-08-07T08:13:02Z

The SCMI [1] is a set of operating system-independent software interfaces
that are used in system management. The SCMI is intended to resolve
critical HW platform resources management problem in the modern
multiprocessor systems where different software (Operating systems,
firmware) are running on different processors (or in virtualized
environment), but still have to access some shared system resources like
power, clocks, etc.

SCMI Design Document v3.2 is currently defines interfaces for:

Discovery and self-description of the interfaces it supports.
Power domain management.
Performance management
Clock management.
Sensor management.
Reset domain management.
Voltage domain management.
Power capping and monitoring.
Pin control protocol

In terms of the SCMI design, the platform code is designated to handle
resource management requests in centralized manner and can run - or on
separate System Control Processor (SCP), or as part of Trusted Firmware
(ARM TF, OPTEE). In terms of the SCMI design, the agent is used to
describe the caller of the SCMI. The SCMI Transport describes how messages
are exchanged between agents and the platform.

This patch introduces basic support for ARM System Control and Management
Interface (SCMI) which implements interface to SCMI compliant firmware with
ARM SMC/HVC transport through the shared memory and can be extended.
The SCMI DT bindings are overall based on Linux Kernel ARM SCMI bindings
[2] with major difference that the SCMI protocol nodes are required to have
compatibility property.

      +-------------+
      |   SCMI      |
      |   Transport |
      |   device    |
      +------+------+
             |
       +-----v-------+
       |SCMI XFER API|
+------+             |
|      +-------------+
|
|
|     +---------------+  Zephyr reset API
+----->SCMI reset     +--------->
|     |  device       |
|     +---------------+
|
|     +---------------+  Zephyr clock API
+-----> SCMI clock    +--------->
|     |  device       |
|     +---------------+
|      ...
|     +---------------+
+-----> SCMI X        |
      |  device       |
      +---------------+

The SCMI Transport device is intended to implement required SCMI transport
according to the SCMI DT compatibility property.
For example:

"arm,scmi-smc" SCMI compliant firmware with ARM SMC/HVC transport;
"arm,scmi-smc-param" SCMI compliant firmware with ARM SMC/HVC transport
with shmem address(4KB-page, offset) as parameters.
And expose SCMI transfer (XFER) API which can be used by other SCMI
functional devices.

The SCMI functional devices appear as child devices of the SCMI Transport
device, implement SCMI protocols for resource management and provide
corresponding standard Zephyr APIs.

For example, SCMI Reset domain management protocol (0x16, compatible
"arm,scmi-reset") is implemented as standard Zephyr Reset Controller
device/driver.

This implementation provides:

only SCMI Transport device which implements ARM SMC/HVC transport with
shared memory;
only sync transfers are implemented hence SMC/HVC transport only supports
"completed on return" functionality.

[1] https://developer.arm.com/Architectures/System%20Control%20and%20Management%20Interface
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml

GrygiriiS · 2024-08-07T09:03:37Z

@lorc @oleksiimoisieiev

lorc

Great job!

I have a number of minor questions, though.

lorc · 2024-08-07T10:21:26Z

Do we really need KConfig entries for features that are not available yet?

+1. And keep on mind that for mailbox transport - new compatible string should be introduced - "arm,scmi"
That's why I think that transport can be deternime based on copmatibility string. Also you have mentioned "arm,scmi-smc-param" compatible in the commit description, but haven't introduce it in the code. Maybe it will be better to remove this/

lorc · 2024-08-07T10:31:41Z

Do you really need this callback? As I can see, depending on build configuration scmi_smccc_smc/hvc can call either arm_smccc_smc or arm_smccc_hvc. Why do you need extra layer of indirection?

You can have one function scmi_smccc_call that calls either arm_smccc_smc or arm_smccc_hvc, depending on CONFIG_ARM_SCMI_SMC_METHOD_SMC

lorc · 2024-08-07T12:33:50Z

I believe you can do this in KConfig. Something like

depends on DT_HAS_ARM_SCMI_SMC_ENABLED

Here no as diferent compatible need to be selected

lorc · 2024-08-07T12:38:37Z

Why this is part of the driver itself and not part of the shell.c?

It can't be moved there as it uses private reset scmi functions.
This scmi reset and shell.c placed in different driver's folders.

oleksiimoisieiev · 2024-08-07T12:52:03Z

+1. And keep on mind that for mailbox transport - new compatible string should be introduced - "arm,scmi"
That's why I think that transport can be deternime based on copmatibility string. Also you have mentioned "arm,scmi-smc-param" compatible in the commit description, but haven't introduce it in the code. Maybe it will be better to remove this/

oleksiimoisieiev · 2024-08-07T13:09:07Z

Great job. thank you. Also, a few comments from me

GrygiriiS · 2024-08-19T14:17:57Z

Updated and ready for review

oleksiimoisieiev

LGTM Reviewed-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com>

GrygiriiS · 2024-08-22T18:23:26Z

Updated:

added separate SCMI sample
DT changes moved into the board overlay of the SCMI sample
added more Base shell commands:

uart:~$ arm_scmi base help
base - SCMI Base proto commands.
Subcommands:
  revision           : SCMI Base get revision info
                      Usage: arm_scmi base revision

  discover_agent     : SCMI Base discover an agent
                      Usage: arm_scmi base discover_agent [agent_id]

  device_permission  : SCMI Base set an agent permissions to access device
                      Usage: arm_scmi base discover_agent <agent_id> <device_id>
                      <allow := 0|1>

  reset_agent_cfg    : SCMI Base reset an agent configuration
                      Usage: arm_scmi base reset_agent_cfg <agent_id>
                      <reset_perm := 0|1>

firscity

Also, I am not sure if it should go to rpi5_dev branch, all patches that you've asked for were added to zephyr-v3.6.0-xt and I think you can start moving whole RPI5 setup to it.

With 2 comments:
Acked-by: Dmytro Firsov <dmytro_firsov@epam.com>

GrygiriiS · 2024-08-23T13:51:22Z

Also, I am not sure if it should go to rpi5_dev branch, all patches that you've asked for were added to zephyr-v3.6.0-xt and I think you can start moving whole RPI5 setup to it.

With 2 comments: Acked-by: Dmytro Firsov <dmytro_firsov@epam.com>

It's in a dev stage and rpi5 not switched fully yet. I'll updated it on top zephyr-v3.6.0-xt when rpi is switched.

Add DT bindings for ARM System Control and Management Interface (SCMI) DT bindings with SMC/shmem based transport and for Reset domain management protocol. The SCMI bindings are overall based on Linux Kernel ARM SCMI bindings [1]. Hence Zephyr is not supported multi-compatible bindings definitions in one yaml file the separate bindings has to be created for each defined ARM SCMI compatible. This path introduces bindings (arm,scmi-smc.yaml) only for: "arm,scmi-smc" - description: SCMI compliant firmware with ARM SMC/HVC transport. "arm,scmi-smc-param" - SCMI compliant firmware with ARM SMC/HVC transport with shmem address(4KB-page, offset) as parameters In addition, the Zephyr's DT processing design and devices instantiating is tightly based on compatibility property presence in DT node, therefore, as per this bindings, the SCMI protocol nodes are required to have compatibility property. Example: firmware { scmi { compatible = "arm,scmi-smc"; arm,smc-id = <0x82000002>; #address-cells = <1>; #size-cells = <0>; shmem = <&scmi_buf>; scmi_reset: protocol@16 { compatible = "arm,scmi-reset"; reg = <0x16>; #reset-cells = <1>; }; }; }; reserved-memory { #address-cells = <2>; #size-cells = <1>; ranges; scmi_buf: scmi@2201f000 { compatible = "zephyr,memory-region"; reg = <0x0 0x3ff00000 4096>; zephyr,memory-region = "scmi"; }; }; [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com> Reviewed-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com> Acked-by: Dmytro Firsov <dmytro_firsov@epam.com>

The SCMI [1] is a set of operating system-independent software interfaces that are used in system management. The SCMI is intended to resolve critical HW platform resources management problem in the modern multiprocessor systems where different software (Operating systems, firmware) are running on different processors (or in virtualized environment), but still have to access some shared system resources like power, clocks, etc. SCMI Design Document v3.2 is currently defines interfaces for: - Discovery and self-description of the interfaces it supports. - Power domain management. - Performance management - Clock management. - Sensor management. - Reset domain management. - Voltage domain management. - Power capping and monitoring. - Pin control protocol In terms of the SCMI design, the *platform* code is designated to handle resource management requests in centralized manner and can run - or on separate System Control Processor (SCP), or as part of Trusted Firmware (ARM TF, OPTEE). In terms of the SCMI design, the *agent* is used to describe the caller of the SCMI. The SCMI Transport describes how messages are exchanged between agents and the platform. This patch introduces basic support for ARM System Control and Management Interface (SCMI) which implements interface to SCMI compliant firmware with ARM SMC/HVC transport through the shared memory and can be extended. The SCMI DT bindings are overall based on Linux Kernel ARM SCMI bindings [2] with major difference that the SCMI protocol nodes are required to have compatibility property. +-------------+ | SCMI | | Transport | | device | +------+------+ | +-----v-------+ |SCMI XFER API| +------+ | | +-------------+ | | | +---------------+ Zephyr reset API +----->SCMI reset +---------> | | device | | +---------------+ | | +---------------+ Zephyr clock API +-----> SCMI clock +---------> | | device | | +---------------+ | ... | +---------------+ +-----> SCMI X | | device | +---------------+ The SCMI Transport device is intended to implement required SCMI transport according to the SCMI DT compatibility property. For example: - "arm,scmi-smc" SCMI compliant firmware with ARM SMC/HVC transport; - "arm,scmi-smc-param" SCMI compliant firmware with ARM SMC/HVC transport with shmem address(4KB-page, offset) as parameters. And expose SCMI transfer (XFER) API which can be used by other SCMI functional devices. The SCMI functional devices appear as child devices of the SCMI Transport device, implement SCMI protocols for resource management and provide corresponding standard Zephyr APIs. For example, SCMI Reset domain management protocol (0x16, compatible "arm,scmi-reset") is implemented as standard Zephyr Reset Controller device/driver. This implementation provides: - only SCMI Transport device which implements ARM SMC/HVC transport with shared memory; - only sync transfers are implemented hence SMC/HVC transport only supports "completed on return" functionality. [1] https://developer.arm.com/Architectures/System%20Control%20and%20Management%20Interface [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/firmware/arm,scmi.yaml Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com> Reviewed-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com> Acked-by: Dmytro Firsov <dmytro_firsov@epam.com>

Add basic shell interface for testing purposes. This patch introduces base *arm_scmi* shell command with following format: arm_scmi <proto> [protocol params] The following commands introduced for Base protocol: arm_scmi base help base - SCMI Base proto commands. Subcommands: revision : SCMI Base get revision info Usage: arm_scmi base revision discover_agent : SCMI Base discover an agent Usage: arm_scmi base discover_agent [agent_id] device_permission : SCMI Base set an agent permissions to access device Usage: arm_scmi base discover_agent <agent_id> <device_id> <allow := 0|1> reset_agent_cfg : SCMI Base reset an agent configuration Usage: arm_scmi base reset_agent_cfg <agent_id> <reset_perm := 0|1> In the future more commands will be implemented as for Base protocol as for other protocols. For example, for Reset domain management protocol following shell commands are going to be added: arm_scmi reset <revision|list|info|assert|deassert|autoreset> [params] Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com> Reviewed-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com> Acked-by: Dmytro Firsov <dmytro_firsov@epam.com>

This patch adds reset driver which implements ARM SCMI Reset domain management protocol and exposes Zephyr Reset API. The current implementation supports only sync operations. Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com> Reviewed-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com> Acked-by: Dmytro Firsov <dmytro_firsov@epam.com>

Add ARM SCMI Reset shell interface for demo and testing purposes, which is defined as sub-command of *arm_scmi* command. It's optional and can be enabled by CONFIG_ARM_SCMI_RESET_SHELL option. The ARM SCMI Reset shell interface defined as following: $arm_scmi reset reset - SCMI Reset proto commands. Subcommands: revision : SCMI Reset proto show revision information Usage: arm_scmi reset revision list : SCMI Reset domains list Usage: arm_scmi reset list info : SCMI Reset domain show info Usage: arm_scmi reset info <domain_id> assert : SCMI Reset domain assert Usage: arm_scmi reset assert <domain_id> deassert : SCMI Reset domain de-assert Usage: arm_scmi reset deassert <domain_id> autoreset : SCMI Reset domain Autonomous reset Usage: arm_scmi reset autoreset <domain_id> Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com> Reviewed-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com> Acked-by: Dmytro Firsov <dmytro_firsov@epam.com>

Add ARM SCMI shell sample application. Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com> Reviewed-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com> Acked-by: Dmytro Firsov <dmytro_firsov@epam.com>

GrygiriiS · 2024-08-27T06:36:03Z

As requested updated on top of zephyr-v3.6.0-xt

oleksiimoisieiev · 2024-08-28T09:54:41Z

@firscity please take a look and merge if everything is ok

firscity · 2024-08-28T10:20:26Z

No objections from my side, but I would like to have @lorc AB/RB when he will be available

lorc · 2024-09-02T19:04:20Z

This PR should be reworked, taking into account zephyrproject-rtos#75102

GrygiriiS · 2024-09-02T19:40:07Z

This PR should be reworked, taking into account zephyrproject-rtos#75102

ok. @klogg @oleksiimoisieiev FYI.

xakep-amatop · 2024-11-06T10:54:17Z

Are we going to merge this PR?
Does it need to be reviewed?

GrygiriiS force-pushed the rpi5_dev_scmi1 branch from 5e49228 to 76bf3d5 Compare August 7, 2024 08:52

lorc reviewed Aug 7, 2024

View reviewed changes

oleksiimoisieiev reviewed Aug 7, 2024

View reviewed changes

GrygiriiS force-pushed the rpi5_dev_scmi1 branch 2 times, most recently from 9a16630 to 67fe7d8 Compare August 19, 2024 14:15

GrygiriiS force-pushed the rpi5_dev_scmi1 branch from 67fe7d8 to 75fb2f9 Compare August 20, 2024 09:26

oleksiimoisieiev approved these changes Aug 20, 2024

View reviewed changes

Comment thread dts/bindings/firmware/arm,scmi-reset.yaml Outdated

Comment thread drivers/reset/Kconfig.arm_scmi Outdated

GrygiriiS force-pushed the rpi5_dev_scmi1 branch from 75fb2f9 to 8dfde74 Compare August 22, 2024 18:21

firscity approved these changes Aug 23, 2024

View reviewed changes

Comment thread samples/drivers/firmware/arm_scmi/README.rst Outdated

GrygiriiS force-pushed the rpi5_dev_scmi1 branch from 8dfde74 to c5b128b Compare August 23, 2024 13:48

GrygiriiS changed the base branch from rpi5_dev to zephyr-v3.6.0-xt August 23, 2024 13:49

GrygiriiS changed the base branch from zephyr-v3.6.0-xt to rpi5_dev August 23, 2024 13:49

Grygorii Strashko added 6 commits August 27, 2024 09:13

samples: drivers: firmware: add arm scmi sample

c14efb5

Add ARM SCMI shell sample application. Signed-off-by: Grygorii Strashko <grygorii_strashko@epam.com> Reviewed-by: Oleksii Moisieiev <oleksii_moisieiev@epam.com> Acked-by: Dmytro Firsov <dmytro_firsov@epam.com>

GrygiriiS force-pushed the rpi5_dev_scmi1 branch from c5b128b to c14efb5 Compare August 27, 2024 06:34

GrygiriiS changed the base branch from rpi5_dev to zephyr-v3.6.0-xt August 27, 2024 06:35

GrygiriiS mentioned this pull request Sep 2, 2024

drivers: firmware: scmi: add more protocols and APIs zephyrproject-rtos/zephyr#77437

Merged

GrygiriiS mentioned this pull request Sep 5, 2024

RPI5: add scmi and wifi support xen-troops/meta-xt-prod-devel-rpi5#41

Merged

Conversation

GrygiriiS commented Aug 7, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GrygiriiS commented Aug 7, 2024

Uh oh!

lorc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

oleksiimoisieiev commented Aug 7, 2024

Uh oh!

GrygiriiS commented Aug 19, 2024

Uh oh!

oleksiimoisieiev left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

GrygiriiS commented Aug 22, 2024

Uh oh!

firscity left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

GrygiriiS commented Aug 23, 2024

Uh oh!

GrygiriiS commented Aug 27, 2024

Uh oh!

oleksiimoisieiev commented Aug 28, 2024

Uh oh!

firscity commented Aug 28, 2024

Uh oh!

lorc commented Sep 2, 2024

Uh oh!

GrygiriiS commented Sep 2, 2024

Uh oh!

xakep-amatop commented Nov 6, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

GrygiriiS commented Aug 7, 2024 •

edited

Loading