From: Geert Uytterhoeven <geert+renesas@glider.be>
To: Sudeep Holla <sudeep.holla@kernel.org>,
Cristian Marussi <cristian.marussi@arm.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
Ulf Hansson <ulfh@kernel.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Brian Masney <bmasney@redhat.com>,
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
Vinod Koul <vkoul@kernel.org>,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Kevin Hilman <khilman@baylibre.com>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Marek Vasut <marek.vasut+renesas@mailbox.org>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: arm-scmi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
linux-clk@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-kernel@vger.kernel.org,
Geert Uytterhoeven <geert+renesas@glider.be>
Subject: [PATCH v2 00/10] R-Car X5H Ironhide CPG/MDLC SCMI remapping support
Date: Wed, 8 Jul 2026 12:16:18 +0200 [thread overview]
Message-ID: <cover.1783505329.git.geert+renesas@glider.be> (raw)
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.
- There may be different SCP firmware lineages, e.g. proprietary and
certified variants, and FLOSS variants,
- SCMI features may differ across firmware versions,
- 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].
Experience has taught that not describing the hardware in DT may
lead to major issues later.
- 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,
- U-Boot IPL (Initial Program Loader) needs a proper hardware
description in DT, not using SCMI.
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.
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[3]. 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 and
abstractions (or replacements, in case they are unusable,
unavailable, or too different), in Linux drivers, based on the
detected firmware version.
This has the following advantages:
1. The DT ABI is stable,
2. DT bindings and drivers for existing hardware blocks do not need to
be modified,
2. Current and future firmware can be handled in driver code,
3. U-Boot IPL can use almost the same DTS; it just needs stripping of
SCMI-related nodes and properties.
4. 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,
This series depends on "[PATCH v2 0/6] R-Car X5H CPG/MDLC support"[4],
and consists of four parts:
1. Patches 1-4 add new interfaces needed by the remapping support,
2. Patches 5-6 update the DT bindings for the R-Car X5H Clock Pulse
Generator (CPG) and Module Controller (MDLC) blocks,
3. Patches 7-8 add SCMI remapping support to the R-Car X5H CPG and
MDLC drivers,
4. Patches 9-10 enables more SCMI protocols on R-Car X5H Ironhide, and
link the CPG and MDLC blocks to their SCMI provider.
Changes compared to v1[5]:
- Drop SCMI quirks and SCMI mapping tables,
- Move CPG/MDLC DT bindings and minimal base drivers to a separate
series,
- Add that SCMI may provide different abstractions,
- Add missing asterisk to blank kerneldoc line,
- Let scmi_get_base_info() return -EPROBE_DEFER or -EOPNOTSUPP instead
of -ENOENT, and propagate these errors in callers,
- Fall back to the default support when SCMI support or firmware is
not available, or when the detected SCMI firmware version is not
supported by the driver,
- Improve error message on scmi_get_base_info() failure,
- Check if SCMI firmware node is available,
- Use reverse xmas ordering in r8a78000_cpg_probe(),
- Replace the scmi_*_np members of struct r8a78000_*_priv by local
variables in the probe functions, and pass them to the fill_*_map()
functions,
- Join split short lines,
- Move check for supported firmware version up,
- Fix DT misindentations,
- Add scmi_clk node, as it is no longer added in earlier commits.
Note that in reponse of feedback on v1, I did try to use SCMI IDs in DT,
and handle most issues in Linux SCMI drivers and SCMI quirks[6]. While
the result worked, it did not solve everything in the issues list above.
Note that this series does not include actual SCMI quirks and CPG/MDLC
mapping tables, as the SCMI firmware for R-Car X5H is still under
development.
For testing, I have pushed this series plus additional work to[7].
Thanks for your comments!
[1] Documentation/devicetree/bindings/firmware/arm,scmi.yaml
[2] "[PATCH net-next v11 1/7] dt-bindings: phy: document the serdes PHY on sa8255p"
https://lore.kernel.org/20260629-qcom-sa8255p-emac-v11-1-1b7fb95b51f9@oss.qualcomm.com
[3] "Firmware ABI stability" at Linux Plumbers Conference 2025
https://lpc.events/event/19/contributions/2153/
[4] "[PATCH v2 0/6] R-Car X5H CPG/MDLC support"
https://lore.kernel.org/cover.1783505142.git.geert+renesas@glider.be
[5] "[PATCH/RFC 00/14] R-Car X5H Ironhide SCMI CPG/MDLC remapping"
https://lore.kernel.org/cover.1776793163.git.geert+renesas@glider.be
[6] "[PATCH/RFC 0/9] R-Car X5H Ironhide pure SCMI proof-of-concept"
https://lore.kernel.org/cover.1781171705.git.geert+renesas@glider.be/
[7] topic/rcar-x5h-ironhide-scmi-cpg-mdlc-remapping-v2 branch of
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
Geert Uytterhoeven (10):
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: renesas,r8a78000-cpg: Add firmware property
dt-bindings: power: renesas,r8a78000-mdlc: Add firmware property
clk: renesas: r8a78000: Add SCMI remapping support
pmdomain: renesas: r8a78000: Add SCMI remapping support
arm64: dts: renesas: ironhide: Enable SCMI devpd, sys, clock, and
reset
arm64: dts: renesas: ironhide: Add CPG/MDLC firmware properties
.../bindings/clock/renesas,r8a78000-cpg.yaml | 7 +
.../bindings/power/renesas,r8a78000-mdlc.yaml | 7 +
.../boot/dts/renesas/r8a78000-ironhide.dts | 135 ++++++++
drivers/clk/renesas/r8a78000-cpg.c | 161 ++++++++-
drivers/firmware/arm_scmi/driver.c | 33 ++
drivers/of/property.c | 2 +
drivers/pmdomain/core.c | 4 +-
drivers/pmdomain/renesas/r8a78000-mdlc.c | 311 +++++++++++++++++-
drivers/reset/core.c | 11 +
include/linux/pm_domain.h | 7 +
include/linux/reset-controller.h | 6 +
include/linux/scmi_protocol.h | 8 +
12 files changed, 665 insertions(+), 27 deletions(-)
--
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
next reply other threads:[~2026-07-08 10:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-08 10:16 Geert Uytterhoeven [this message]
2026-07-08 10:16 ` [PATCH v2 01/10] firmware: arm_scmi: Add scmi_get_base_info() Geert Uytterhoeven
2026-07-08 10:16 ` [PATCH v2 02/10] of: property: fw_devlink: Add support for firmware Geert Uytterhoeven
2026-07-08 10:16 ` [PATCH v2 03/10] pmdomain: Make genpd_get_from_provider() public Geert Uytterhoeven
2026-07-08 10:16 ` [PATCH v2 04/10] reset: Add reset_controller_get_provider() Geert Uytterhoeven
2026-07-10 14:49 ` Philipp Zabel
2026-07-08 10:16 ` [PATCH v2 05/10] dt-bindings: clock: renesas,r8a78000-cpg: Add firmware property Geert Uytterhoeven
2026-07-10 10:21 ` Krzysztof Kozlowski
2026-07-10 11:02 ` Geert Uytterhoeven
2026-07-08 10:16 ` [PATCH v2 06/10] dt-bindings: power: renesas,r8a78000-mdlc: " Geert Uytterhoeven
2026-07-08 10:16 ` [PATCH v2 07/10] clk: renesas: r8a78000: Add SCMI remapping support Geert Uytterhoeven
2026-07-08 10:16 ` [PATCH v2 08/10] pmdomain: " Geert Uytterhoeven
2026-07-08 10:16 ` [PATCH v2 09/10] arm64: dts: renesas: ironhide: Enable SCMI devpd, sys, clock, and reset Geert Uytterhoeven
2026-07-08 15:42 ` [PATCH v2 00/10] R-Car X5H Ironhide CPG/MDLC SCMI remapping support Marek Vasut
2026-07-08 16:04 ` Geert Uytterhoeven
2026-07-08 16:48 ` Marek Vasut
2026-07-08 16:00 ` [PATCH v2 10/10] arm64: dts: renesas: ironhide: Add CPG/MDLC firmware properties Geert Uytterhoeven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1783505329.git.geert+renesas@glider.be \
--to=geert+renesas@glider.be \
--cc=arm-scmi@vger.kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=bmasney@redhat.com \
--cc=conor+dt@kernel.org \
--cc=cristian.marussi@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=florian.fainelli@broadcom.com \
--cc=khilman@baylibre.com \
--cc=konrad.dybcio@oss.qualcomm.com \
--cc=krzk+dt@kernel.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=marek.vasut+renesas@mailbox.org \
--cc=mturquette@baylibre.com \
--cc=p.zabel@pengutronix.de \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=saravanak@kernel.org \
--cc=sboyd@kernel.org \
--cc=sudeep.holla@kernel.org \
--cc=ulfh@kernel.org \
--cc=vkoul@kernel.org \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox