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, and may
    change from one SCP firmware release to another, causing DTB
    incompatibilities,
  - There may be different SCP firmware lineages, e.g. proprietary and
    certified variants, and FLOSS variants,
  - SCMI features and quirks may differ across firmware versions,
  - Not all quirks can be handled as SCMI quirks,
  - Some core clocks do not support the CLOCK_ATTRIBUTES command, and
    thus are not accessible to Linux, while Linux may need them,
    requiring dummy clocks,
  - Some module clocks are not accessible to Linux, or report a zero
    clock rate and have no parent, while several existing drivers need
    to know their clock rates,
  - 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
    explicit management of functional clocks,
  - Some clocks and power domains are critical and must not be disabled,
    or even touched,
  - Some module resets are reserved, and operating them returns an
    error,
  - U-Boot IPL (Initial Program Loader) needs a proper hardware
    description in DT, not using SCMI.

During last OSSJ/LPC, Marek Vasut pondered if we could keep our own ID
lists stable, and perform a mapping to the IDs used by the actual SCMI
implementation running on the system.  This was also briefly discussed
at LPC[2].  After some refining of the initial idea, this series takes a
slightly different approach, by:
  1. Describing the actual hardware components in DT, plus a minimum
     SCMI glue,
  2. Mapping DT hardware descriptions to SCMI-backed objects (or
     replacements in case they are unusable), in Linux drivers, based on
     the detected firmware version.

This has the following advantages:
  1. The DT ABI is stable,
  2. Current and future firmware quirks can be handled in driver code,
  3. If ever needed, the Clock Pulse Generator (CPG) and Module
     Controller (MDLC) drivers can be extended to program the hardware
     directly if SCMI is not present,
  4. U-Boot IPL can use almost the same DTS; it just needs stripping of
     SCMI-related nodes and properties.

This series is based on renesas-drivers-2026-04-14-v7.0, which includes
a.o. the scmi/for-linux-next branch.  It consists of multiple parts:
  1. Patches 1-3 add various quirks to the SCMI driver code,
  2. Patch 4 enables more SCMI protocols on R-Car X5H Ironhide,
  3. Patches 5-8 add new interfaces needed by the remapping drivers,
  4. Patches 9-10 add DT bindings for the R-Car X5H Clock Pulse Generator
     (CPG) and Module Controller (MDLC) blocks,
  5. Patches 11-12 add remapping drivers for the R-Car X5H Clock Pulse
     Generator (CPG) and Module Controller (MDLC) blocks,
  6. Patches 13-14 add DTS description for R-Car X5H Ironhide.

Dependencies:
  - Lifting "#define SCMI_MAX_NUM_RATES 16" (e.g. scmi/for-linux-next),
  - "[PATCH v4 0/3] soc: renesas: add MFIS driver"[3],
  - R-Car X5H MFIS and Ironhide SCMI DTS enablement (not yet posted).

For testing, I have pushed this series and its dependencies to the
topic/rcar-x5h-ironhide-scmi-cpg-mdlc-remapping-v1 branch of
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
With this, Ironhide can boot into a serial console shell from a ramdisk,
without needing any of "clk_ignore_unused" and "pd_ignore_unused".

FTR, alternative locations to do remapping that we considered:
  - Inside the SCMI clock, reset, and power-domain drivers,
  - Inside the subsystem driver core (e.g. of_parse_clkspec()),
  - Inside the OF driver core,
  - Inside the DTB.

Remapping inside DT is usually done through a nexus node (see Devicetree
Specification, Section 2.5 Nexus Nodes and Specifier Mapping), using
"<specifier>-map", "<specifier>-map-mask", and
"<specifier>-map-pass-thru" properties.  Linux has support for e.g.
remapping interrupts (open-coded in drivers/of/irq.c), and gpios or pwms
(using the of_parse_phandle_with_args_map()) helper.  So far there is no
support for remapping clocks or power domains, but at least for clocks
patches have been posted[4].  Then the remapping can be done by adding
e.g. "clocks-map{,-mask,-pass-thru}" properties with translation data
to the CPG/MDLC DT node, using a DT overlay.  The DT overlay could be
applied by the firmware or bootloader (e.g. in in fitImage script), or
even by the CPG/MDLC Linux driver at runtime (based on detected SCP
firmware version).  Consumer nodes do not need to be modified.
Note that such translations can only support simple cases.  If e.g. a
workaround is needed to map a single DT clock to multiple SCMI clocks,
this cannot be done using a simple translation table.
While a DT overlay is quite flexible and can also do other fixup, it is
less user-friendly than doing the remapping in a Linux driver.

Thanks for your comments!

[1] Documentation/devicetree/bindings/firmware/arm,scmi.yaml
[2] "Firmware ABI stability" at Linux Plumbers Conference 2025
    https://lpc.events/event/19/contributions/2153/
[3] "[PATCH v4 0/3] soc: renesas: add MFIS driver"
    https://lore.kernel.org/20260402112709.13002-1-wsa+renesas@sang-engineering.com/
[4] "[PATCH] clk: Add support for clock nexus dt bindings"
     https://lore.kernel.org/20260129201003.288605-1-miquel.raynal@bootlin.com/

Geert Uytterhoeven (14):
  firmware: arm_scmi: quirk: Handle bad power domains on R-Car X5H
  firmware: arm_scmi: quirk: Handle bad clocks on R-Car X5H
  firmware: arm_scmi: quirk: Handle critical clocks on R-Car X5H
  arm64: dts: renesas: ironhide: Enable SCMI devpd, sys, and reset
  firmware: arm_scmi: Add scmi_get_base_info()
  of: property: fw_devlink: Add support for firmware
  pmdomain: Make genpd_get_from_provider() public
  reset: Add reset_controller_get_provider()
  dt-bindings: clock: Document Renesas R-Car X5H Clock Pulse Generator
  dt-bindings: power: Document Renesas R-Car X5H Module Controller
  clk: renesas: Add R-Car X5H CPG SCMI remapping driver
  pmdomain: renesas: Add R-Car X5H MDLC SCMI remapping driver
  arm64: dts: renesas: r8a78000: Add CPG/MDLC nodes
  arm64: dts: renesas: ironhide: Add CPG/MDLC firmware properties

 .../bindings/clock/renesas,r8a78000-cpg.yaml  |   62 +
 .../bindings/power/renesas,r8a78000-mdlc.yaml |   63 +
 .../boot/dts/renesas/r8a78000-ironhide.dts    |  130 +++
 arch/arm64/boot/dts/renesas/r8a78000.dtsi     |  300 ++++-
 drivers/clk/renesas/Kconfig                   |    4 +
 drivers/clk/renesas/Makefile                  |    1 +
 drivers/clk/renesas/r8a78000-cpg.c            |  335 ++++++
 drivers/firmware/arm_scmi/clock.c             |   37 +
 drivers/firmware/arm_scmi/driver.c            |   31 +
 drivers/firmware/arm_scmi/power.c             |   20 +
 drivers/firmware/arm_scmi/quirks.c            |   12 +
 drivers/firmware/arm_scmi/quirks.h            |    4 +
 drivers/of/property.c                         |    2 +
 drivers/pmdomain/core.c                       |    4 +-
 drivers/pmdomain/renesas/Kconfig              |    4 +
 drivers/pmdomain/renesas/Makefile             |    1 +
 drivers/pmdomain/renesas/r8a78000-mdlc.c      | 1021 +++++++++++++++++
 drivers/reset/core.c                          |   11 +
 drivers/soc/renesas/Kconfig                   |    1 +
 .../dt-bindings/clock/renesas,r8a78000-cpg.h  |   15 +
 .../dt-bindings/power/renesas,r8a78000-mdlc.h |   16 +
 include/linux/pm_domain.h                     |    7 +
 include/linux/reset-controller.h              |    6 +
 include/linux/scmi_protocol.h                 |    8 +
 24 files changed, 2068 insertions(+), 27 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a78000-cpg.yaml
 create mode 100644 Documentation/devicetree/bindings/power/renesas,r8a78000-mdlc.yaml
 create mode 100644 drivers/clk/renesas/r8a78000-cpg.c
 create mode 100644 drivers/pmdomain/renesas/r8a78000-mdlc.c
 create mode 100644 include/dt-bindings/clock/renesas,r8a78000-cpg.h
 create mode 100644 include/dt-bindings/power/renesas,r8a78000-mdlc.h

-- 
2.43.0

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Geert Uytterhoeven <geert+renesas@glider.be> writes:

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

I'm very curious how power domain hierarchy is described on this SoC,
because one more issue to add to your list is that hierarchy cannot be
described for power domains in SCMI.

I know you're aware of it already, but just FYI for anyone else
exploring this space, I have a series[1] in-flight right now to address
this limitation of SCMI so that we can at least describe this hierarchy
in DT and the pmdomain framework.

Kevin

[1] https://lore.kernel.org/linux-pm/20260420-topic-lpm-pmdomain-child-ids-v3-0-c2c40bef238c@baylibre.com/

Hi Kevin,

On Thu, 23 Apr 2026 at 00:48, Kevin Hilman <khilman@baylibre.com> wrote:
> Geert Uytterhoeven <geert+renesas@glider.be> writes:
> > 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,
>
> I'm very curious how power domain hierarchy is described on this SoC,
> because one more issue to add to your list is that hierarchy cannot be
> described for power domains in SCMI.

So far I had no need for such a description. AFAIK, this is handled
inside the SCMI firmware, which does know the hierarchy.  Hence the
firmware can power up a domain when any of its children is powered up,
and power it down when the last of its children is powered down?

I think the clue lies in having a PSCI top-level domain, cfr. what
you wrote in [1]:

   "But... how do I describe the relationship of this hierarchy? In
    particular, when the SCMI-controlled PDs are actually subdomains of a
    top-level, non-SCMI PD."

Or am I missing something?

So far I have used only a few devices on R-Car X5H, and e.g. the
serial ports are in the always-on domain.  I did experiment with
a dummy UFS driver, as UFS is inside a real power domain, and that
seemed to work fine.

[1] https://lore.kernel.org/arm-scmi/7hecy3h7ky.fsf@baylibre.com/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

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

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> Hi Kevin,
>
> On Thu, 23 Apr 2026 at 00:48, Kevin Hilman <khilman@baylibre.com> wrote:
>> Geert Uytterhoeven <geert+renesas@glider.be> writes:
>> > 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,
>>
>> I'm very curious how power domain hierarchy is described on this SoC,
>> because one more issue to add to your list is that hierarchy cannot be
>> described for power domains in SCMI.
>
> So far I had no need for such a description. AFAIK, this is handled
> inside the SCMI firmware, which does know the hierarchy.  Hence the
> firmware can power up a domain when any of its children is powered up,
> and power it down when the last of its children is powered down?

Yes, but this firwmare behavior is subject to the normal list of 
limitations/quirks/lack-of-bugs/etc. that we usually run into with
firmware.  So if there's ever a need for linux to understand hierarchy
for those reasons, you may find yourself stuck. :)

> I think the clue lies in having a PSCI top-level domain, cfr. what
> you wrote in [1]:
>
>    "But... how do I describe the relationship of this hierarchy? In
>     particular, when the SCMI-controlled PDs are actually subdomains of a
>     top-level, non-SCMI PD."
>
> Or am I missing something?

Indeed, the tricky part is when the domains may have CPUs/clusters in
them, and in my case with the TI SoCs, the top-level domain with CPU
clusters is PSCI controlled.

It wouldn't suprise me that other SoCs have similar features where some
domains are children or siblings of domains with CPUs in them.  This
kind of dependency is pretty complex to manage in just SCP firmware,
because it involves TF-A/PSCI as well, so it's a likely spot for
firmware "quirks".

Kevin