On 12/08/2026 11:19, Jiafei Pan wrote: > > 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
Don't do generic fallbacks. Works poor, as visible in multiple cases now. > >>> + 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. You replied three months after my comment. Well, you have such right but so you know entire context is gone and I am not going to put my time to read the binding again. Just for you know - if you partition the cpus, they are gone from the cpus list as well. Not sure how this affects the bitmask but remember to model only available CPUs properly in DT. Best regards, Krzysztof
