Technical Sharing | ARM Series – Power and Clock Management

Today, we will look at SCMI (System Control and Management Interface). SCMI is a set of operating system-independent software interfaces used for system management, including the following aspects:

• Power Domain Management

• Performance Management

• Clock Management

• Sensor Management

• Reset Management

• Voltage Domain Management

It is worth mentioning that power domain management and voltage domain management are two different concepts. Power domain management refers to controlling the power switches of chips/modules based on pre-designed low-power states, while voltage domain management refers to configuring/controlling the supply voltage of chips and modules, such as implementing dynamic voltage scaling.

In large-scale SoC designs, the system management mentioned above is generally handled by a microcontroller, which can reduce the load on the Application Processor (AP). In practice, the microcontroller is sometimes referred to as the small core, and the application processor as the big core. The microcontroller corresponds to the concept of SCP (System Control Processor).

Under this architecture, the SCP receives requests from the AP and responds accordingly. This means that there needs to be a communication protocol interface between the AP and SCP. As shown in the figure below, today we will discuss SCMI.

SCMI mainly specifies two aspects:

• Protocols: Specifies the messages supported between components

• Transports: Specifies how messages are transmitted between components

The SCMI protocols are mainly designed to assist the operating system in power and performance management, which is to assist in completing OSPM (Operating System Power Management). Generally, the OS is referred to as the agent, while the SCP and its managed modules are referred to as the platform. The following figure is a schematic diagram of SCMI in the system.In the diagram, the platform controller generally refers to the SCP. The AP issues SCMI commands, which are sent to the SCP through secure or non-secure channels; the SCP coordinates requests from all these requests and drives the hardware to the appropriate power or performance state. In the upper part of the diagram, we can see that SCMI can support management of sensors, power, voltage, clock, reset, and performance.The agent and SCP communicate through a transport channel. An agent must have at least one dedicated channel, and the channel cannot be shared with other agents. The channel is unidirectional; on the A2P (agent to platform) channel, the agent is the initiator; on the P2A (platform to agent) channel, the platform is the initiator. Communication between the agent and platform can employ an interrupt mechanism. For example, in the P2A channel, when the agent completes the command from the platform, it can send an interrupt to the platform to indicate that this channel is idle and can continue to receive new commands.The following diagram describes how the agent and platform communicate through channels. Messages on the A2P channel, also known as commands, are used for the agent to initiate requests to the platform. Commands are further divided into synchronous commands and asynchronous commands. Messages on the P2A channel can also be classified into two categories: notifications and delayed responses. Synchronous commands will block the channel; the agent cannot issue new synchronous commands until the current command is completed; asynchronous commands do not block the channel. After receiving an asynchronous command, the SCP will arrange subsequent management operations accordingly, allowing the SCP to respond to the agent immediately after receiving the asynchronous command, and then return an additional response after the command is completed.Channels can be standard SCMI channels or FastChannel. FastChannel is a lightweight unidirectional channel specifically designed for controlling a single type of SCMI message for specific platform resources. Unlike standard channels, FastChannel cannot carry multiple message types and cannot explicitly control multiple platform resources. Due to the lack of multiple message types and their header requirements, FastChannel can provide a potential low-latency mechanism for communication between the agent and platform. However, compared to standard channels, FastChannel does not guarantee a shorter time for the platform to complete the requested operation. In the current version of SCMI (3.0), FastChannel only supports performance management protocols. Simply put, FastChannel supports fewer message types and has a simpler message format, so the transmission delay is relatively small, hence the name ‘fast’, but it only means faster transmission and does not guarantee that the SCP will complete the request in a shorter time. Each agent has its own dedicated (which can be multiple) channel, and channels cannot be shared between agents. The SCP distinguishes different channels by checking the unique channel identifier of each channel.Each message carries an 8-bit message header (also known as protocol ID) to identify different types of operation requests. Pay special attention to the protocols from 0x10 to 0x17; others are reserved protocols, depending on whether they are needed in the system and specific design implementation.For messages on standard channels, the message header has a total of 32 bits, starting from the lowest bit: 8 bits for message_id; 2 bits for message_type; 8 bits for protocol_id; 10 bits for token; and 4 bits for reserved bits. The message_type for commands (synchronous and asynchronous) is 0; the message_type for delayed responses is 1; the message_type for notifications is 2.ARM defines multiple protocols to assist communication between agents and platforms, such as power management, clock management, etc. However, in practical design, not all protocols may be implemented. Only basic protocols must be supported. Therefore, the first thing the agent must do is send a command to the platform to query how many protocols the platform supports. This process is called discovery (by the way, ARM seems to particularly like using the term discover). For each group of protocols, it is specified which commands must be supported and which commands are optional.The return code of the message is a negative 32-bit integer, with specific meanings as follows:Having laid the groundwork, let’s briefly list some specific protocol messages.1. Basic Protocol:A system may contain multiple agents, and not all agents can configure the system through basic protocol commands. ARM recommends that only trusted agents have this permission. If an agent does not have permission and sends a basic protocol command, the system should return a DENEID or NOT_SUPPORTED type response.

Commands	message_id	protocol_id	Mandatory	Description
PROTOCOL_VERSION	0x0	0x10	yes	Returns the current version information of the protocol
PROTOCOL_ATTRIBUTES	0x1	0x10	yes	Returns implementation details associated with this protocol: the number of agents in the system, and which protocols other than the basic protocol are implemented
PROTOCOL_MESSAGE_ATTRIBUTES	0x2	0x10	yes	Returns implementation details associated with a specific message in this protocol
BASE_DISCOVER_VENDOR	0x3	0x10	yes	Vendor-specific identifier ASCII string
BASE_DISCOVER_SUB_VENDOR	0x4	0x10	yes	Vendor-specific identifier ASCII substring
BASE_DISCOVER_IMPLEMENTATION_VERSION	0x5	0x10	yes	Vendor-specific 32-bit implementation version, the specific format is determined by the vendor
BASE_DISCOVER_LIST_PROTOCOLS	0x6	0x10	yes	This command is used for the agent to discover which protocols it can access, and the returned protocol list should be sorted in ascending order by number
BASE_DISCOVER_AGENT	0x7	0x10	no	Allows the caller to discover the name of the agent, described by an ASCII string of up to 16 bytes
BASE_NOTIFY_ERRORS	0x8	0x10	no	Optionally provides error notifications in the platform to agents registered to receive them
BASE_SET_DEVICE_PERMISSIONS	0x9	0x10	no	Used to indicate whether a certain agent has permission to access the device
BASE_SET_PROTOCOL_PERMISSIONS	0xA	0x10	no	Used to indicate whether the agent has permission to access platform resources associated with specific devices using the protocol
BASE_RESET_AGENT_CONFIGURATION	0xB	0x10	no	Resets previously configured platform resource settings by the agent, such as power domains, clocks, sensors, etc.

Notifications:

Notifications	message_id	protocol_id	Mandatory	Description
BASE_ERROR_EVENT	0x0	0x10	No	If the platform implements basic error notifications, these notifications will be sent to any agent registered to receive them

2. Power Domain Management Protocol:This protocol is used for the state of power domains.

Commands	message_id	protocol_id	Mandatory	Description
PROTOCOL_VERSION	0x0	0x11	Yes	Returns the current version information of the protocol
PROTOCOL_ATTRIBUTES	0x1	0x11	Yes	Returns implementation details associated with this protocol
PROTOCOL_MESSAGE_ATTRIBUTES	0x2	0x11	Yes	Returns implementation details associated with a specific message in this protocol
POWER_DOMAIN_ATTRIBUTES	0x3	0x11	Yes	Returns attribute flags associated with a specific power domain
POWER_STATE_SET	0x4	0x11	Yes	Agent sets the state of a certain power domain (synchronous or asynchronous mode)
POWER_STATE_GET	0x5	0x11	Yes	Agent obtains the current state of a certain power domain
POWER_STATE_NOTIFY	0x6	0x11	No	When the state of a specific power domain changes, the platform notifies the agent that invoked this command
POWER_STATE_CHANGE_REQUESTED_NOTIFY	0x8	0x11	No	This command allows the caller to receive notifications from the platform when it receives requests to change the power domain state from another agent

Notifications:

Notifications	message_id	protocol_id	Mandatory	Description
POWER_STATE_CHANGED	0x0	0x11	No	When the power domain state changes, the platform notifies the agent (provided that the agent has registered for power domain state change notifications)
POWER_STATE_CHANGE_REQUESTED	0x1	0x11	No	Agent registers for power domain state change notifications

3. System Power Management Protocol:This protocol is used for system shutdown, suspend, and reset.

Commands	message_id	protocol_id	Mandatory	Description
PROTOCOL_VERSION	0x0	0x12	Yes	Returns the current version information of the protocol
PROTOCOL_ATTRIBUTES	0x1	0x12	Yes	Returns implementation details associated with this protocol
PROTOCOL_MESSAGE_ATTRIBUTES	0x2	0x12	Yes	Returns implementation details associated with a specific message in this protocol
SYSTEM_POWER_STATE_SET	0x3	0x12	Yes	Used for system power off or reset
SYSTEM_POWER_STATE_GET	0x4	0x12	Yes	Gets the system power state
SYSTEM_POWER_STATE_NOTIFY	0x5	0x12	Yes	Requests notification of system power state. This command can be used for two points: OSPM receives notifications of system power state requests; when OSPM requests a forced state transition, management agents or privileged agents receive notifications

Notifications:

Notifications	message_id	protocol_id	Mandatory	Description
SYSTEM_POWER_STATE_NOTIFIER	0x0	0x12	No	When the system power state changes, the platform notifies the agent (provided that the agent has registered for system power state change notifications)

4. Performance Domain Management Protocol:This group of protocols is mainly used for AP performance management. A performance domain consists of a group of devices that must operate at the same performance level.

Commands	message_id	protocol_id	Mandatory	Description
PROTOCOL_VERSION	0x0	0x13	Yes	Returns the current version information of the protocol
PROTOCOL_ATTRIBUTES	0x1	0x13	Yes	Returns implementation details associated with this protocol
PROTOCOL_MESSAGE_ATTRIBUTES	0x2	0x13	Yes	Returns implementation details associated with a specific message in this protocol
PERFORMANCE_DOMAIN_ATTRIBUTES	0x3	0x13	Yes	Returns attributes of a specific performance domain
PERFORMANCE_DESCRIBE_LEVELS	0x4	0x13	Yes	Allows the agent to query the performance levels supported by the platform (usually a set of discrete values) and the corresponding power consumption
PERFORMANCE_LIMITS_SET	0x5	0x13	Yes	Sets the upper and lower limits of a specific performance domain
PERFORMANCE_LIMITS_GET	0x6	0x13	Yes	Gets the upper and lower limits of a specific performance domain
PERFORMANCE_LEVEL_SET	0x7	0x13	Yes	Allows the agent to set the performance level of a specific performance domain
PERFORMANCE_LEVEL_GET	0x8	0x13	Yes	Gets the performance level of a specific performance domain
PERFORMANCE_NOTIFY_LIMITS	0x9	0x13	No	Agent requests that when the platform changes the performance level and exceeds the limits, it sends notifications to the agent
PERFORMANCE_NOTIFY_LEVEL	0xA	0x13	No	Agent requests that when the platform changes the performance level, it sends notifications to the agent
PERFORMANCE_DESCRIBE_FASTCHANNEL	0xB	0x13	No	Allows the agent to discover the FastChannel attributes of a specific performance domain and a specific message

Notifications:

Notifications	message_id	protocol_id	Mandatory	Description
PERFORMANCE_LIMITS_CHANGED	0x0	0x13	No	When the performance state exceeds the limits, the platform notifies the agent (provided that the agent has registered to receive notifications)
PERFORMANCE_LEVEL_CHANGED	0x1	0x13	No	When the performance state changes, the platform notifies the agent (provided that the agent has registered to receive notifications)

5. Clock Management Protocol:Unlike the performance domain management protocol, this part manages other peripherals besides the CPU and GPU.

Commands	message_id	protocol_id	Mandatory	Description
PROTOCOL_VERSION	0x0	0x14	Yes	Returns the current version information of the protocol
PROTOCOL_ATTRIBUTES	0x1	0x14	Yes	Returns implementation details associated with this protocol
PROTOCOL_MESSAGE_ATTRIBUTES	0x2	0x14	Yes	Returns implementation details associated with a specific message in this protocol
CLOCK _ATTRIBUTES	0x3	0x14	Yes	Returns attributes associated with a specific clock
CLOCK_DESCRIBE_RATES	0x4	0x14	Yes	The agent queries the effective clock frequency that can be set through this command. It usually returns a set of clock frequency values (Hz)
CLOCK_RATE_SET	0x5	0x14	Yes	The agent sets the clock frequency value (Hz) through this command
CLOCK_RATE_GET	0x6	0x14	Yes	The agent obtains the current clock frequency information (Hz) through this command
CLOCK_CONFIG_SET	0x7	0x14	Yes	The agent requests to configure the clock through this command

Delayed response:

Delayed response	message_id	protocol_id	Mandatory	Description
CLOCK_RATE_SET_COMPLETE	0x5	0x14	No	If the agent asynchronously changes the clock rate using CLOCK_RATE_SET, the platform will send this delayed response to the agent when the clock rate change occurs

6. Sensor Management Protocol:This protocol is mainly used for managing platform sensors.

Commands	message_id	protocol_id	Mandatory	Description
PROTOCOL_VERSION	0x0	0x15	Yes	Returns the current version information of the protocol
PROTOCOL_ATTRIBUTES	0x1	0x15	Yes	Returns implementation details associated with this protocol
PROTOCOL_MESSAGE_ATTRIBUTES	0x2	0x15	Yes	Returns implementation details associated with a specific message in this protocol
SENSOR_ DESCRIPTION_GET	0x3	0x15	Yes	Used to explore platform sensors. On success, returns a set of sensor descriptors
SENSOR_TRIP_POINT_NOTIFY	0x4	0x15	No	Agent used to globally control notifications about crossing events
SENSOR_TRIP_POINT_CONFIG	0x5	0x15	Yes	Used to select and configure trigger points
SENSOR_READING_GET	0x6	0x15	Yes	Requests the platform to provide the current value of the sensor represented by sensor_id
SENSOR_ AXIS_DESCRIPTION_GET	0x7	0x15	Yes	Used to explore sensor axis properties. On success, returns sensor axis property descriptors
SENSOR_LIST_UPDATE_INTERVALS	0x8	0x15	No	Allows the agent to determine the update intervals supported by the sensor. If successful, this command will return an array containing multiple update interval entries
SENSOR_CONFIG_GET	0x9	0x15	Yes	Reads the sensor configuration
SENSOR_CONFIG_SET	0xA	0x15	Yes	Used to configure the sensor update interval and enable timestamps for sensor values
SENSOR_CONTINUOUS_UPDATE_NOTIFY	0xB	0x15	No	If the sensor has values to report, this command allows the agent to request notifications from the platform

Delayed response:

Delayed response	message_id	protocol_id	Mandatory	Description
SENSOR_READING_COMPLETE	0x6	0x15	No	Delayed response to the asynchronous SENSOR_READING_GET command issued by the agent

Notifications:

Notifications	message_id	protocol_id	Mandatory	Description
SENSOR_TRIP_POINT_EVENT	0x0	0x15	No	When the sensor reaches a certain trigger point, the platform sends a notification to the agent
SENSOR_UPDATE	0x1	0x15	No	The platform issues a SENSOR_UPDATE notification to provide sensor readings

7. Reset Management Protocol:This protocol is used to reset modules in the platform that can be reset.

Commands	message_id	protocol_id	Mandatory	Description
PROTOCOL_VERSION	0x0	0x16	Yes	Returns the current version information of the protocol
PROTOCOL_ATTRIBUTES	0x1	0x16	Yes	Returns implementation details associated with this protocol
PROTOCOL_MESSAGE_ATTRIBUTES	0x2	0x16	Yes	Returns implementation details associated with a specific message in this protocol
RESET_DOMAIN_ATTRIBUTES	0x3	0x16	Yes	Returns attribute information for the reset domain specified in the command
RESET	0x4	0x16	Yes	Allows the agent to reset the reset domain specified in the command
RESET_NOTIFY	0x5	0x16	No	Agent requests that when the platform resets a certain domain, it sends notifications to it

Delayed response:

Delayed response	message_id	protocol_id	Mandatory	Description
RESET_COMPLETE	0x4	0x16	No	Delayed response to the asynchronous reset command issued by the agent

Notifications:

Notifications	message_id	protocol_id	Mandatory	Description
RESET_ISSUED	0x0	0x16	No	When a specified reset domain is reset, the platform sends this notification to registered agents

8. Voltage Domain Management Protocol:

Commands	message_id	protocol_id	Mandatory	Description
PROTOCOL_VERSION	0x0	0x17	Yes	Returns the current version information of the protocol
PROTOCOL_ATTRIBUTES	0x1	0x17	Yes	Returns implementation details associated with this protocol
PROTOCOL_MESSAGE_ATTRIBUTES	0x2	0x17	Yes	Returns implementation details associated with a specific message in this protocol
VOLTAGE_DOMAIN_ATTRIBUTES	0x3	0x17	Yes	Returns attribute information for a specified voltage domain
VOLTAGE_DESCRIBE_LEVELS	0x4	0x17	Yes	Allows the agent to get the voltage levels supported by the voltage domain
VOLTAGE_CONFIG_SET	0x5	0x17	Yes	Allows the agent to set the configuration of a certain voltage domain
VOLTAGE_CONFIG_GET	0x6	0x17	Yes	Allows the agent to obtain the current configuration of a certain voltage domain
VOLTAGE_LEVEL_SET	0x7	0x17	Yes	Allows the agent to set the voltage value of a certain voltage domain
VOLTAGE_LEVEL_GET	0x8	0x17	Yes	Allows the agent to obtain the current voltage value of a certain voltage domain

The above is the protocol part of SCMI. Regarding transmission, messages between the AP and SCP can be stored using shared memory. The communication process can use interrupts, doorbells, or polling to actively query the status of the message channel. The communication process using interrupts is shown in the figure below:

1. The initiator must ensure that the channel is idle;
2. The initiator writes the message and its payload into the shared memory area;
3. The initiator marks the channel as busy by updating the channel status;
4. The initiator writes to the doorbell register, notifying the receiver that there is a message waiting to be processed in the shared memory area;
5. The receiver processes the command in the shared memory area;
6. The receiver updates the shared memory area with any return data related to message processing;
7. The receiver marks the channel as idle by updating the channel status;
8. The receiver sends an interrupt to the initiator, indicating that processing is complete;
9. The initiator processes the content of the shared memory area.

The communication process based on the polling mechanism is as follows. Unlike the interrupt method, the receiver does not send an interrupt to the initiator after completing message processing; instead, the initiator must poll the channel status.Transmitted by | Lao Qin Talks about Chips

Copyright belongs to the original author, if there is any infringement, please contact to delete

END










关于安芯教育


安芯教育是聚焦AIoT（人工智能+物联网）的创新教育平台，提供从中小学到高等院校的贯通式AIoT教育解决方案。
安芯教育依托Arm技术，开发了ASC（Arm智能互联）课程及人才培养体系。已广泛应用于高等院校产学研合作及中小学STEM教育，致力于为学校和企业培养适应时代需求的智能互联领域人才。