Re: [PATCH v2 00/10] R-Car X5H Ironhide CPG/MDLC SCMI remapping support

[Sudeep Holla]

On Wed, Jul 08, 2026 at 12:16:18PM +0200, Geert Uytterhoeven wrote:
> 	Hi all,
> 
> TL;DR:
> 
>     Describe hardware in DT, and perform the mapping to SCMI in Linux.
> 
> The Renesas R-Car X5H-based Ironhide board is the first Renesas
> SoC/board combination that implements the ARM System Control and
> Management Interface (SCMI).
> 
> This means Linux can no longer perform various system operations (e.g.
> clock, power domain, and reset control) by accessing the hardware
> directly.  Instead, these operations are abstracted according to various
> SCMI sub-protocols, and Linux has to send messages to an SCMI-compliant
> firmware running on a System Control Processor (SCP).
> More specifically, the R-Car X5H SCP FW SCMI controls access to:
>   1. Core clocks and module clocks,
>   2. Module resets,
>   3. Power domains,
>   4. System power.
> The latter is not relevant for this discussion.
> 
> Using SCMI also has an impact on the board DTS: besides the addition of
> a firmware/scmi node with protocol-specific subnodes, devices using
> SCMI-abstracted system resources now have to refer to these resources
> using resource specifiers containing phandles to the SCMI protocol
> subnodes, and firmware-specific object IDs[1].
> 
> Unfortunately we encountered several issues with this:
>   - The clock, reset, and power domain IDs are not stable by design,
>     causing DT incompatibilities.
>     SCMI requires that the ID space exposed to an agent (i.e. Linux)
>     starts at zero and is contiguous.  Hence any change in system
>     partitioning (Application CPU core vs. Realtime CPU core,
>     virtualization, ...) may mean a renumbering of all SCMI IDs,
>     implying a massive change to the DT.

Yes it is well known fact. But where this is a feature or limitation
is debatable. Why would SCP firmware churn and re-number or re-assign
a differ domain ID everytime it is updated is questionable to me.

>   - There may be different SCP firmware lineages, e.g. proprietary and
>     certified variants, and FLOSS variants,

No sure if I understand the issue here.

>   - SCMI features may differ across firmware versions,

Again, features must be discoverable that is the advantage of DT vs this
firmware interface, so not sure what is the issue in this matter.

>   - SCMI may abstract the hardware in a different way, requiring changes
>     in (possibly existing) DT bindings and drivers to support the same
>     hardware with and without SCMI:
>       - E.g. the number of SCMI clocks inputs to a hardware block may
> 	differ from the actual hardware,
>       - E.g. hardware clock inputs may be abstracted as SCMI power
> 	domains (or vice versa), like on Qualcomm SA8255P[2].

True, the moment SCMI like interface is used in OSPM, the firmware
description hides real h/w details and provide what firmware thinks
OSPM must view hardware as(how VMMs virtualise things for VMs, firmware
can have similar effect with such interfaces).

>     Experience has taught that not describing the hardware in DT may
>     lead to major issues later.

OK, that's interesting. But the whole point with these interfaces is to
hide those, so just don't use such abstraction interface if you want the
hardware to be described as is to the OSPM.

>   - SCMI does not support the concept of a clock domain, so existing
>     drivers can no longer rely on Runtime PM, but need to be changed to
>     manage functional clocks explicitly,

Not sure what that means, you mean clock protocol is not good enough to
model the h/w clock domains on your platform ? If so, you are welcome to
improve the specification.

>   - U-Boot IPL (Initial Program Loader) needs a proper hardware
>     description in DT, not using SCMI.
> 

I am going to ignore that.

> This list deliberately ignores ID instability and the need for SCMI
> quirks during development of the SCMI firmware.  While upstream Linux
> must only support sufficiently mature firmware versions, vendor trees
> (e.g. renesas-lts) may still want to support development firmware
> versions.
> 

Fair enough, but the acceptance of such changes depends on maintenance
and possible absuse with such spec deviations.

-- 
Regards,
Sudeep