NXP Confidential
On Wed, May 14, 2026 at 11:38:13AM +0000, Krzysztof Kozlowski wrote:
> > +description:
> > + This binding provides support for managing Cortex-A cores as remote
> > + processors on i.MX platforms using the PSCI (Power State Coordination
> > + Interface) for CPU power management operations. This allows single
> > + Cortex-A core or multiple Cortex-A cores to be controlled by Linux as
> > + a remote processor, enabling them to run RTOS or bare-metal applications.
>
> Describe the hardware, not the binding.
Will fix. Updated to describe the hardware:
NXP i.MX SoCs integrate multiple Cortex-A cores. On certain i.MX
platforms, one or more of these cores can be offloaded to run RTOS
or bare-metal firmware as a remote processor, while the remaining
cores run Linux. The cores are powered on and off via PSCI (Power
State Coordination Interface) CPU_ON/CPU_OFF calls to the firmware.
> > + compatible:
> > + const: fsl,imx-rproc-psci
>
> Why isn't the compatible specific?
Will fix. Updated to use a SoC-specific compatible with a generic
fallback:
compatible:
- items:
- enum:
- fsl,imx93-ca53-rproc-
- const: fsl,imx-rproc-psci
> > + fsl,cpus-mask:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description:
> > + Bitmask indicating which CPU cores are assigned to this remote
> > + processor instance. Each bit represents a CPU core, where bit N
> > + corresponds to CPU N. For example, 0x2 (0b10) assigns CPU core 1,
> > + while 0x6 (0b110) assigns CPU cores 1 and 2.
>
> So you partition existing Cortex-A cores? Or how exactly? Why isn't this
> deducible from the compatible (I assume you read carefully writing
> bindings)?
Yes, we partition existing Cortex-A cores. On i.MX93 for example,
there are 2 Cortex-A55 cores. Core 0 runs Linux as the primary OS,
while core 1 (or any subset of the remaining cores on SoCs with more
cores, e.g. 4x A55) can be assigned to a remoteproc instance to run
RTOS or bare-metal firmware.
The reason fsl,cpus-mask cannot be deduced from the compatible is
that the assignment is flexible and board/use-case specific. On a
4-core SoC, the user may assign core 1 only, cores 1+2, cores 2+3,
or all non-primary cores to one or more remoteproc instances. This
runtime flexibility cannot be encoded in the compatible string.
We considered using a `cpus` phandle list instead, but the CPU nodes
in the DT are already claimed by the Linux CPU topology and do not
naturally represent "remote processor" assignments. The bitmask
approach directly maps to the PSCI CPU_ON/CPU_OFF MPIDR-based
interface used by the firmware.
> > + remoteproc-ca55-1 {
>
> Implement previous comments.
Will fix the example node name to follow DT naming conventions.
Best regards,
Jiafei
