About this project

System Control and Management Interface (SCMI) has been designed to standardize the interface between a power coprocessor and other parts of a SoC. That includes the application processor (AP) on which we can have both rich OS like Linux but also a TEE like OP-TEE.

Each client of the power coprocessor has its own access points with specific control permissions on the power resources. But on some “medium/small” systems, the power coprocessor may not be present or doesn’t provide enough access points. In such a case, the AP itself has to control and filter the access to the power resources.

For security reason, the TEE must have the control of shared resources and populates the authorized resources to the non secure world. The TEE acts as a power coprocessor from Linux PoV and we can keep using the same SCMI interface.

Even if OP-tee is our first target, similar requirements arise when several guest VM have to manage share resources like a system PLL or a shared power domain. The configuration used with OP-TEE can be extended to any execution environment on the system and a SCMI backend can run in a VM acting as a rpoxy between guest VM and shared resources an example:

Wherever it runs, the core of the SCMI server remains the same and only the execution environment interface will change. In order to ease the port of the SCMI server in different context, several features need to be enabled like new transport methods. Or easing the porting on a different OSes.

Get Involved

• Meetings/Calls

• Join the scmi-dev ML (archive)

Meetings

Code

• https://git.kernel.org

Documentation