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

[Geert Uytterhoeven]

Hi Sudeep,

On Fri, 17 Jul 2026 at 10:05, Sudeep Holla <sudeep.holla@xxxxxxxxxx> wrote:
> On Wed, Jul 08, 2026 at 12:16:18PM +0200, Geert Uytterhoeven wrote:
> > 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.

For an actual product, I tend to agree. But even then there might be
a need to reconsider partitioning during the long (e.g. automotive ;-)
lifetime, e.g. to counter a new attack vector.

For a development platform, the situation is different: the same board
will be used for various use cases, with different partitioning of
responsibilities, and will run various firmware versions.

> >   - There may be different SCP firmware lineages, e.g. proprietary and
> >     certified variants, and FLOSS variants,
>
> No sure if I understand the issue here.

Safety-critical products may require certified firmware, which may
be completely different from what is generally available.

> >   - 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).

So you end up with multiple compatible values for the same hardware
blocks, depending on direct hardware access or SCMI, and on the
actual firmware.
What is the policy for naming such compatible values?  How many
different DT bindings are we willing to support for the same hardware?
What about driver changes? Maintenance of all these drivers?

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

E.g. one may miss one internal clock input when describing a device in
DT, where control of the clock turns out to be critical for a specific
hardware feature?

> 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.

How do you fix it when everything is hidden, e.g. behind a single
virtual clock?

> >   - 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.

It is common on embedded SoCs (e.g. TI, Rockchip, Renesas) to not only
have power domains that can be powered down, but also a clock domain:
a clock controller provides a common way to put a hardware module into
standby mode by gating its clock inputs.

In Linux PM Domains, the following callbacks are used:
  - generic_pm_domain.power_{on,off}(), to power a power domain on/off,
  - generic_pm_domain.dev_ops.{start,stop}(), to start/stop a device
    inside a power domain.
Both are handled automatically through Runtime PM
(pm_runtime_{resume_and_get,put}(dev)), so drivers don't need to care
about the intricate details.

However, for this to work, the PM Domain needs to know which clocks are
meant for module standby.  Without this knowledge, individual drivers
must control these module clocks explicitly.  During the last two
decades, lots of drivers have been converted from explicit module clock
control to Runtime PM, and reversing this would IMHO be a step backward.

I already posted patches before [1] to add support for clock domains
using a quirk.  Without a quirk, the SCMI clock protocol should be
extended to advertize whether a clock is intended for power-management
of a hardware module.  One way to handle this, the SCMI CLOCK_ATTRIBUTES
could be extended with a new flag in the returned attributes as I
pointed out in the cover letter of that series.

> >   - U-Boot IPL (Initial Program Loader) needs a proper hardware
> >     description in DT, not using SCMI.
>
> I am going to ignore that.

And of course we like the DT used by U-Boot (IPL or not) to be as close
as possible to the DT used by Linux.

Thanks, and have a nice weekend!

[1] Series "[PATCH/RFC 0/9] R-Car X5H Ironhide pure SCMI proof-of-concept"
  - "[PATCH/RFC 4/9] firmware: arm_scmi: Add a flag for power-management clocks"
  - "[PATCH/RFC 5/9] clk: scmi: Add scmi_clk_is_pm_clk()"
  - "[PATCH/RFC 6/9] dt-bindings: firmware: arm,scmi: Document arm,clock-domain"
  - "[PATCH/RFC 7/9] pmdomain: arm: scmi: Add clock domain support"
  - "[PATCH/RFC 8/9] firmware: arm_scmi: quirk: Handle power
management clocks on R-Car X5H"
https://lore.kernel.org/all/cover.1781171705.git.geert+renesas@xxxxxxxxx/


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds