drivers/firmware/arm_scmi/vendors/imx/imx95.rst
Source file repositories/reference/linux-study-clean/drivers/firmware/arm_scmi/vendors/imx/imx95.rst
File Facts
- System
- Linux kernel
- Corpus path
drivers/firmware/arm_scmi/vendors/imx/imx95.rst- Extension
.rst- Size
- 104412 bytes
- Lines
- 1740
- Domain
- Driver Families
- Bucket
- drivers/firmware
- Inferred role
- Driver Families: documentation
- Status
- atlas-only
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
===============================================================================
i.MX95 System Control and Management Interface(SCMI) Vendor Protocols Extension
===============================================================================
:Copyright: |copy| 2024 NXP
:Author: Peng Fan <peng.fan@nxp.com>
The System Manager (SM) is a low-level system function which runs on a System
Control Processor (SCP) to support isolation and management of power domains,
clocks, resets, sensors, pins, etc. on complex application processors. It often
runs on a Cortex-M processor and provides an abstraction to many of the
underlying features of the hardware. The primary purpose of the SM is to allow
isolation between software running on different cores in the SoC. It does this
by having exclusive access to critical resources such as those controlling
power, clocks, reset, PMIC, etc. and then providing an RPC interface to those
clients. This allows the SM to provide access control, arbitration, and
aggregation policies for those shared critical resources.
SM introduces a concept Logic Machine(LM) which is analogous to VM and each has
its own instance of SCMI. All normal SCMI calls only apply to that LM. That
includes boot, shutdown, reset, suspend, wake, etc. Each LM (e.g. A55 and M7)
are completely isolated from the others and each LM has its own communication
channels talking to the same SCMI server.
This document covers all the information necessary to understand, maintain,
port, and deploy the SM on supported processors.
The SM implements an interface compliant with the Arm SCMI Specification
with additional vendor specific extensions.
System Control and Management Logical Machine Management Vendor Protocol
========================================================================
The SM adds the concept of logical machines (LMs). These are analogous to
VMs and each has its own instance of SCMI. All normal SCMI calls only apply
the LM running the calling agent. That includes boot, shutdown, reset,
suspend, wake, etc. If a caller makes the SCMI base call to get a list
of agents, it will only get those on that LM. Each LM is completely isolated
from the others. This is mandatory for these to operate independently.
This protocol is intended to support boot, shutdown, and reset of other logical
machines (LM). It is usually used to allow one LM(e.g. OSPM) to manage
another LM which is usually an offload or accelerator engine. Notifications
from this protocol can also be used to manage a communication link to another
LM. The LMM protocol provides commands to:
- Describe the protocol version.
- Discover implementation attributes.
- Discover all the LMs defined in the system.
- Boot a target LM.
- Shutdown a target LM (gracefully or forcibly).
- Reset a target LM (gracefully or forcibly).
- Wake a target LM from suspend.
- Suspend a target LM (gracefully).
- Read boot/shutdown/reset information for a target LM.
- Get notifications when a target LM boots or shuts down (e.g. LM 'X' requested
notification of LM 'Y' boots or shuts down, when LM 'Y' boots or shuts down,
SCMI firmware will send notification to LM 'X').
'Graceful' means asking LM itself to shutdown/reset/etc (e.g. sending
notification to Linux, Then Linux reboots or powers down itself). It is async
command that the SUCCESS of the command just means the command successfully
return, not means reboot/reset successfully finished.
'Forceful' means the SM will force shutdown/reset/etc the LM. It is sync
command that the SUCCESS of the command means the LM has been successfully
Annotation
- Atlas domain: Driver Families / drivers/firmware.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.