* [PATCH/RFC 10/14] dt-bindings: power: Document Renesas R-Car X5H Module Controller
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Document support for Renesas R-Car X5H Module Controllers, and
add definitions for power domains not backed by registers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
.../bindings/power/renesas,r8a78000-mdlc.yaml | 63 +++++++++++++++++++
.../dt-bindings/power/renesas,r8a78000-mdlc.h | 16 +++++
2 files changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/renesas,r8a78000-mdlc.yaml
create mode 100644 include/dt-bindings/power/renesas,r8a78000-mdlc.h
diff --git a/Documentation/devicetree/bindings/power/renesas,r8a78000-mdlc.yaml b/Documentation/devicetree/bindings/power/renesas,r8a78000-mdlc.yaml
new file mode 100644
index 0000000000000000..c3075bb308962f59
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/renesas,r8a78000-mdlc.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/renesas,r8a78000-mdlc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car X5H Module Controller
+
+maintainers:
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+
+description:
+ Each instance of the R-Car X5H Module Controller (MODULE CONTROL) provides
+ Power Gating for up to 64 Power Domains, and Module Standby and Reset for up
+ to 256 modules in the Power Domain of each Module hierarchy.
+
+properties:
+ compatible:
+ const: renesas,r8a78000-mdlc
+
+ reg:
+ maxItems: 1
+
+ '#power-domain-cells':
+ description: |
+ - The first power domain specifier cell must be either the Module
+ Power Domain Gating (MPDG) register index (0x00-0x3f) from the
+ datasheet, or a Power Domain number, as defined in
+ <dt-bindings/power/renesas,r8a78000-mdlc.h>,
+ - The second power domain specifier cell must be the module number
+ (0x00-0xff), composed of the Module System Reset (MSRES) register index
+ in the high nibble, and the Module Reset Destination bitfield index in
+ the low nibble.
+ const: 2
+
+ '#reset-cells':
+ description:
+ The single reset specifier cell must be the module number (0x00-0xff).
+ const: 1
+
+ firmware:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Reference to the SCMI firmware device node on systems where SCMI must be
+ used instead of direct hardware access.
+
+required:
+ - compatible
+ - reg
+ - '#power-domain-cells'
+ - '#reset-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ system-controller@c3060000 {
+ compatible = "renesas,r8a78000-mdlc";
+ reg = <0xc3060000 0x1000>;
+ #power-domain-cells = <2>;
+ #reset-cells = <1>;
+ firmware = <&scmi>;
+ };
diff --git a/include/dt-bindings/power/renesas,r8a78000-mdlc.h b/include/dt-bindings/power/renesas,r8a78000-mdlc.h
new file mode 100644
index 0000000000000000..31aa4935a7c5cf94
--- /dev/null
+++ b/include/dt-bindings/power/renesas,r8a78000-mdlc.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2026 Glider bv
+ */
+#ifndef __DT_BINDINGS_POWER_RENESAS_R8A78000_MDLC_H__
+#define __DT_BINDINGS_POWER_RENESAS_R8A78000_MDLC_H__
+
+/* R-Car X5H MDLC Power Domains */
+
+#define R8A78000_MDLC_PD_AON 0x40
+#define R8A78000_MDLC_PD_SCP 0x41
+#define R8A78000_MDLC_PD_APL 0x42
+#define R8A78000_MDLC_PD_CMN 0x43
+#define R8A78000_MDLC_PD_ACL 0x44
+
+#endif /* __DT_BINDINGS_POWER_RENESAS_R8A78000_MDLC_H__ */
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 09/14] dt-bindings: clock: Document Renesas R-Car X5H Clock Pulse Generator
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Document support for the Renesas R-Car X5H Clock Pulse Generator,
and add definitions for a very limited and preliminary set of clocks.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
.../bindings/clock/renesas,r8a78000-cpg.yaml | 62 +++++++++++++++++++
.../dt-bindings/clock/renesas,r8a78000-cpg.h | 15 +++++
2 files changed, 77 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/renesas,r8a78000-cpg.yaml
create mode 100644 include/dt-bindings/clock/renesas,r8a78000-cpg.h
diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a78000-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,r8a78000-cpg.yaml
new file mode 100644
index 0000000000000000..fc499e7cf52e4f0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,r8a78000-cpg.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/renesas,r8a78000-cpg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car X5H Clock Pulse Generator
+
+maintainers:
+ - Geert Uytterhoeven <geert+renesas@glider.be>
+
+description:
+ The R-Car X5H Clock Pulse Generator (CLK CONTROL) consists of oscillators,
+ PLL circuits, clock dividers and clock control circuits. It provides various
+ clocks for other modules.
+
+properties:
+ compatible:
+ const: renesas,r8a78000-cpg
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: extal
+ - const: extalr
+
+ '#clock-cells':
+ description:
+ The single clock specifier cell must be the clock number, as defined in
+ <dt-bindings/clock/renesas,r8a78000-cpg.h>.
+ const: 1
+
+ firmware:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Reference to the SCMI firmware device node on systems where SCMI must be
+ used instead of direct hardware access.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#clock-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ clock-controller@c1320000 {
+ compatible = "renesas,r8a78000-cpg";
+ reg = <0xc1320000 0x10000>;
+ clocks = <&extal_clk>, <&extalr_clk>;
+ clock-names = "extal", "extalr";
+ #clock-cells = <1>;
+ firmware = <&scmi>;
+ };
diff --git a/include/dt-bindings/clock/renesas,r8a78000-cpg.h b/include/dt-bindings/clock/renesas,r8a78000-cpg.h
new file mode 100644
index 0000000000000000..8c8bc4d1feac6d26
--- /dev/null
+++ b/include/dt-bindings/clock/renesas,r8a78000-cpg.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+/*
+ * Copyright (C) 2026 Glider bv
+ */
+#ifndef __DT_BINDINGS_CLOCK_RENESAS_R8A78000_CPG_H__
+#define __DT_BINDINGS_CLOCK_RENESAS_R8A78000_CPG_H__
+
+/* R-Car X5H CPG Clocks */
+
+// FIXME Preliminary
+#define R8A78000_CPG_SGASYNCD4_PERW_BUS 0
+#define R8A78000_CPG_SGASYNCD16_PERW_BUS 1
+#define R8A78000_CPG_MSOCK_PERW_BUS 2
+
+#endif /* __DT_BINDINGS_CLOCK_RENESAS_R8A78000_CPG_H__ */
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 08/14] reset: Add reset_controller_get_provider()
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
The reset subsystem differs from the clock subsystem in multiple ways:
1. It does not provide a public way to lookup resets from a reset
provider (clock has of_clk_get_from_provider()),
2. The xlate callback does not return a reset object, but merely an
index, which is converted to a reset object by the reset core.
Hence add a public helper reset_controller_get_provider(), which just
returns the provider, and will be used by the R-Car X5H Module
Controller driver.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/reset/core.c | 11 +++++++++++
include/linux/reset-controller.h | 6 ++++++
2 files changed, 17 insertions(+)
diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 38e189d04d09b270..57c427bb33b322e2 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -1135,6 +1135,17 @@ __reset_find_rcdev(const struct fwnode_reference_args *args, bool gpio_fallback)
return NULL;
}
+struct reset_controller_dev *
+reset_controller_get_provider(struct fwnode_handle *fwnode)
+{
+ struct fwnode_reference_args args = { .fwnode = fwnode };
+
+ guard(mutex)(&reset_list_mutex);
+
+ return __reset_find_rcdev(&args, false);
+}
+EXPORT_SYMBOL_GPL(reset_controller_get_provider);
+
struct reset_control *
__fwnode_reset_control_get(struct fwnode_handle *fwnode, const char *id, int index,
enum reset_control_flags flags)
diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h
index 52a5a4e81f184407..0c17a36466115ba6 100644
--- a/include/linux/reset-controller.h
+++ b/include/linux/reset-controller.h
@@ -74,6 +74,7 @@ void reset_controller_unregister(struct reset_controller_dev *rcdev);
struct device;
int devm_reset_controller_register(struct device *dev,
struct reset_controller_dev *rcdev);
+struct reset_controller_dev *reset_controller_get_provider(struct fwnode_handle *fwnode);
#else
static inline int reset_controller_register(struct reset_controller_dev *rcdev)
{
@@ -89,6 +90,11 @@ static inline int devm_reset_controller_register(struct device *dev,
{
return 0;
}
+
+static inline struct reset_controller_dev *reset_controller_get_provider(struct fwnode_handle *fwnode)
+{
+ return NULL;
+}
#endif
#endif
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 07/14] pmdomain: Make genpd_get_from_provider() public
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Unlike the corresponding function in the clock subsystem
(of_clk_get_from_provider()), genpd_get_from_provider() is private, and
thus cannot be used by PM Domain drivers.
Make it public, so it be used by the R-Car X5H Module Controller driver.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/pmdomain/core.c | 4 ++--
include/linux/pm_domain.h | 7 +++++++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 4d32fc676aaf53cf..23c7cd480a7e026d 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -2900,8 +2900,7 @@ EXPORT_SYMBOL_GPL(of_genpd_del_provider);
* Returns a valid pointer to struct generic_pm_domain on success or ERR_PTR()
* on failure.
*/
-static struct generic_pm_domain *genpd_get_from_provider(
- const struct of_phandle_args *genpdspec)
+struct generic_pm_domain *genpd_get_from_provider(const struct of_phandle_args *genpdspec)
{
struct generic_pm_domain *genpd = ERR_PTR(-ENOENT);
struct of_genpd_provider *provider;
@@ -2923,6 +2922,7 @@ static struct generic_pm_domain *genpd_get_from_provider(
return genpd;
}
+EXPORT_SYMBOL_GPL(genpd_get_from_provider);
/**
* of_genpd_add_device() - Add a device to an I/O PM domain
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index b299dc0128d65ee5..568aebf51d830210 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -458,6 +458,7 @@ int of_genpd_add_provider_simple(struct device_node *np,
int of_genpd_add_provider_onecell(struct device_node *np,
struct genpd_onecell_data *data);
void of_genpd_del_provider(struct device_node *np);
+struct generic_pm_domain *genpd_get_from_provider(const struct of_phandle_args *genpdspec);
int of_genpd_add_device(const struct of_phandle_args *args, struct device *dev);
int of_genpd_add_subdomain(const struct of_phandle_args *parent_spec,
const struct of_phandle_args *subdomain_spec);
@@ -488,6 +489,12 @@ static inline int of_genpd_add_provider_onecell(struct device_node *np,
static inline void of_genpd_del_provider(struct device_node *np) {}
+static inline struct generic_pm_domain *genpd_get_from_provider(
+ const struct of_phandle_args *genpdspec)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline int of_genpd_add_device(const struct of_phandle_args *args,
struct device *dev)
{
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 06/14] of: property: fw_devlink: Add support for firmware
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Let fw_devlink create device links between consumers and suppliers of
firmware, and enforce these dependencies.
This prevents probing of drivers before the firmware they depend on
becomes available, thus avoiding unneeded probe deferrals.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Written for the upcoming R-Car X5H Clock Pulse Generator and Module
Controller drivers and their dependency on SCMI, but the existing
Raspberry Pi power domain driver should benefit from this, too.
---
drivers/of/property.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 136946f8b746f745..34aeba20040348d6 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -1378,6 +1378,7 @@ DEFINE_SIMPLE_PROP(dmas, "dmas", "#dma-cells")
DEFINE_SIMPLE_PROP(power_domains, "power-domains", "#power-domain-cells")
DEFINE_SIMPLE_PROP(hwlocks, "hwlocks", "#hwlock-cells")
DEFINE_SIMPLE_PROP(extcon, "extcon", NULL)
+DEFINE_SIMPLE_PROP(firmware, "firmware", NULL)
DEFINE_SIMPLE_PROP(nvmem_cells, "nvmem-cells", "#nvmem-cell-cells")
DEFINE_SIMPLE_PROP(phys, "phys", "#phy-cells")
DEFINE_SIMPLE_PROP(wakeup_parent, "wakeup-parent", NULL)
@@ -1527,6 +1528,7 @@ static const struct supplier_bindings of_supplier_bindings[] = {
{ .parse_prop = parse_power_domains, },
{ .parse_prop = parse_hwlocks, },
{ .parse_prop = parse_extcon, },
+ { .parse_prop = parse_firmware, },
{ .parse_prop = parse_nvmem_cells, },
{ .parse_prop = parse_phys, },
{ .parse_prop = parse_wakeup_parent, },
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Currently non-SCMI drivers cannot find out what the specific versions of
each SCMI provider implementation on the running system are.
However, different versions may use different ABIs (e.g. different clock
IDs), or behave different, requiring remapping or workarounds in other
drivers.
Add a public function to obtain base protocol information for the
selected SCMI provider. This will be used by the R-Car X5H Clock Pulse
Generator and Module Controller drivers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/firmware/arm_scmi/driver.c | 31 ++++++++++++++++++++++++++++++
include/linux/scmi_protocol.h | 8 ++++++++
2 files changed, 39 insertions(+)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 3e0d975ec94c4485..dfa8961775aa952d 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -3504,6 +3504,37 @@ int scmi_inflight_count(const struct scmi_handle *handle)
}
}
+/**
+ * scmi_get_base_info() - Get SCMI base protocol information
+ *
+ * @of_node: pointer to a device node for an SCMI provider
+ * @version: pointer to write base protocol information
+ *
+ * Check if an SCMI device has been instantiated for the passed device node
+ * pointer, and, if found, return its base info.
+
+ * Return: 0 on Success or -ENOENT.
+ */
+int scmi_get_base_info(struct device_node *of_node,
+ struct scmi_base_info *version)
+{
+ struct scmi_info *info;
+ int ret = -ENOENT;
+
+ mutex_lock(&scmi_list_mutex);
+ list_for_each_entry(info, &scmi_list, node) {
+ if (info->dev->of_node == of_node) {
+ *version = info->version;
+ ret = 0;
+ break;
+ }
+ }
+ mutex_unlock(&scmi_list_mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(scmi_get_base_info);
+
static int __init scmi_driver_init(void)
{
scmi_quirks_initialize();
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index 49cc39e0cbca5a0b..52eba920de264bd7 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -972,6 +972,8 @@ struct scmi_driver {
int scmi_driver_register(struct scmi_driver *driver,
struct module *owner, const char *mod_name);
void scmi_driver_unregister(struct scmi_driver *driver);
+int scmi_get_base_info(struct device_node *of_node,
+ struct scmi_base_info *version);
#else
static inline int
scmi_driver_register(struct scmi_driver *driver, struct module *owner,
@@ -981,6 +983,12 @@ scmi_driver_register(struct scmi_driver *driver, struct module *owner,
}
static inline void scmi_driver_unregister(struct scmi_driver *driver) {}
+
+static inline int scmi_get_base_info(struct device_node *of_node,
+ struct scmi_base_info *version)
+{
+ return -ENOENT;
+}
#endif /* CONFIG_ARM_SCMI_PROTOCOL */
#define scmi_register(driver) \
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 04/14] arm64: dts: renesas: ironhide: Enable SCMI devpd, sys, and reset
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
SCP FW SDKv4.28.0 and later for Renesas R-Car X5H Ironhide not only
implements the SCMI base and clock management protocols, but also the
SCMI power domain, system power, and reset domain management protocols.
Enable support for the latter by adding the corresponding SCMI protocol
subnodes.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts b/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
index e2470257d2f32a03..2fb9557a7eb9dbb7 100644
--- a/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
+++ b/arch/arm64/boot/dts/renesas/r8a78000-ironhide.dts
@@ -31,10 +31,24 @@ scmi: scmi {
#address-cells = <1>;
#size-cells = <0>;
+ scmi_devpd: protocol@11 {
+ reg = <0x11>;
+ #power-domain-cells = <1>;
+ };
+
+ scmi_sys: protocol@12 {
+ reg = <0x12>;
+ };
+
scmi_clk: protocol@14 {
reg = <0x14>;
#clock-cells = <1>;
};
+
+ scmi_reset: protocol@16 {
+ reg = <0x16>;
+ #reset-cells = <1>;
+ };
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 03/14] firmware: arm_scmi: quirk: Handle critical clocks on R-Car X5H
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Renesas R-Car X5H SCP FW SDKv4.28.0, v4.31.0, and v4.32.0 advertise a
few clocks that crash the system when disabled. Add quirks to prevent
such crashes.
As SCMI clock IDs are identical for SDKv4.31.0 and v4.32.0, the quirk
for these two versions can be shared.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Some of these could be handled by improving hardware descriptions in DT,
or by the CPG and MDLC drivers.
---
drivers/firmware/arm_scmi/clock.c | 23 +++++++++++++++++++++++
drivers/firmware/arm_scmi/quirks.c | 6 ++++++
drivers/firmware/arm_scmi/quirks.h | 2 ++
3 files changed, 31 insertions(+)
diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index d530882a0bac88c3..4fec8c3216df7a51 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -920,6 +920,26 @@ scmi_clock_config_set_v2(const struct scmi_protocol_handle *ph, u32 clk_id,
return ret;
}
+#define QUIRK_RCAR_X5H_4_28_CRIT_CLOCKS \
+ ({ \
+ switch (clk_id) { \
+ case 468: /* MDLC_INTAP0 */ \
+ case 498: /* MDLC_APRTMGINT0 */ \
+ case 840: /* CLK_ZD_APU0 */ \
+ return -EPERM; \
+ } \
+ })
+
+#define QUIRK_RCAR_X5H_4_31_CRIT_CLOCKS \
+ ({ \
+ switch (clk_id) { \
+ case 464: /* MDLC_INTAP0 */ \
+ case 494: /* MDLC_APRTMGINT0 */ \
+ case 836: /* CLK_ZD_APU0 */ \
+ return -EPERM; \
+ } \
+ })
+
static int scmi_clock_enable(const struct scmi_protocol_handle *ph, u32 clk_id,
bool atomic)
{
@@ -950,6 +970,9 @@ static int scmi_clock_disable(const struct scmi_protocol_handle *ph, u32 clk_id,
if (clk->state_ctrl_forbidden)
return -EACCES;
+ SCMI_QUIRK(clock_rcar_x5h_4_28_crit_clocks, QUIRK_RCAR_X5H_4_28_CRIT_CLOCKS);
+ SCMI_QUIRK(clock_rcar_x5h_4_31_crit_clocks, QUIRK_RCAR_X5H_4_31_CRIT_CLOCKS);
+
return ci->clock_config_set(ph, clk_id, CLK_STATE_DISABLE,
NULL_OEM_TYPE, 0, atomic);
}
diff --git a/drivers/firmware/arm_scmi/quirks.c b/drivers/firmware/arm_scmi/quirks.c
index e27c21b14220ab5f..4ca6d06f85ebc7b2 100644
--- a/drivers/firmware/arm_scmi/quirks.c
+++ b/drivers/firmware/arm_scmi/quirks.c
@@ -173,6 +173,10 @@ struct scmi_quirk {
DEFINE_SCMI_QUIRK(clock_rates_triplet_out_of_spec, NULL, NULL, NULL);
DEFINE_SCMI_QUIRK(clock_rcar_x5h_no_attributes, "Renesas", NULL, "0x10a0000-",
"renesas,r8a78000");
+DEFINE_SCMI_QUIRK(clock_rcar_x5h_4_28_crit_clocks, "Renesas", NULL, "0x10a0000",
+ "renesas,r8a78000");
+DEFINE_SCMI_QUIRK(clock_rcar_x5h_4_31_crit_clocks, "Renesas", NULL,
+ "0x10d0000-0x10e0000", "renesas,r8a78000");
DEFINE_SCMI_QUIRK(perf_level_get_fc_force, "Qualcomm", NULL, "0x20000-");
DEFINE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, "Renesas", NULL,
"0x10a0000-0x10e0000", "renesas,r8a78000");
@@ -186,6 +190,8 @@ DEFINE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, "Renesas", NULL,
static struct scmi_quirk *scmi_quirks_table[] = {
__DECLARE_SCMI_QUIRK_ENTRY(clock_rates_triplet_out_of_spec),
__DECLARE_SCMI_QUIRK_ENTRY(clock_rcar_x5h_no_attributes),
+ __DECLARE_SCMI_QUIRK_ENTRY(clock_rcar_x5h_4_28_crit_clocks),
+ __DECLARE_SCMI_QUIRK_ENTRY(clock_rcar_x5h_4_31_crit_clocks),
__DECLARE_SCMI_QUIRK_ENTRY(perf_level_get_fc_force),
__DECLARE_SCMI_QUIRK_ENTRY(power_rcar_x5h_4_28_bad_domains),
NULL
diff --git a/drivers/firmware/arm_scmi/quirks.h b/drivers/firmware/arm_scmi/quirks.h
index 67818b6cf0909f8e..56adb5fa87de0127 100644
--- a/drivers/firmware/arm_scmi/quirks.h
+++ b/drivers/firmware/arm_scmi/quirks.h
@@ -48,6 +48,8 @@ static inline void scmi_quirks_enable(struct device *dev, const char *vend,
/* Quirk delarations */
DECLARE_SCMI_QUIRK(clock_rates_triplet_out_of_spec);
DECLARE_SCMI_QUIRK(clock_rcar_x5h_no_attributes);
+DECLARE_SCMI_QUIRK(clock_rcar_x5h_4_28_crit_clocks);
+DECLARE_SCMI_QUIRK(clock_rcar_x5h_4_31_crit_clocks);
DECLARE_SCMI_QUIRK(perf_level_get_fc_force);
DECLARE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains);
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 02/14] firmware: arm_scmi: quirk: Handle bad clocks on R-Car X5H
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Renesas R-Car X5H SCP FW SDKv4.28.0, v4.31.0, and v4.32.0 expose a few
clocks that do not support the CLOCK_ATTRIBUTES or CLOCK_DESCRIBE_RATES
command. Since commit 0d8b0c8068a8ff5f ("firmware: arm_scmi: Harden
clock protocol initialization") in scmi/for-linux-next (next-20260319
and later), scmi_clock_attributes_get() or
scmi_clock_describe_rates_get() failures are no longer ignored, but
prevent the SCMI clock driver from initializing.
Hence add a quirk to ignore such failures, like before. As the quirk
handling is harmless for unaffected systems, make it generic for all
R-Car X5H systems using SCP FW SDKv4.28.0 or later.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/firmware/arm_scmi/clock.c | 14 ++++++++++++++
drivers/firmware/arm_scmi/quirks.c | 3 +++
drivers/firmware/arm_scmi/quirks.h | 1 +
3 files changed, 18 insertions(+)
diff --git a/drivers/firmware/arm_scmi/clock.c b/drivers/firmware/arm_scmi/clock.c
index ce6f968925af38c0..d530882a0bac88c3 100644
--- a/drivers/firmware/arm_scmi/clock.c
+++ b/drivers/firmware/arm_scmi/clock.c
@@ -1232,6 +1232,18 @@ static const struct scmi_protocol_events clk_protocol_events = {
.num_events = ARRAY_SIZE(clk_events),
};
+#define QUIRK_RCAR_X5H_NO_ATTRIBUTES \
+ ({ \
+ if (ret == -EREMOTEIO || ret == -EOPNOTSUPP) \
+ continue; \
+ })
+
+#define QUIRK_RCAR_X5H_NO_RATES \
+ ({ \
+ if (ret == -EOPNOTSUPP) \
+ ret = 0; \
+ })
+
static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
{
int clkid, ret;
@@ -1256,10 +1268,12 @@ static int scmi_clock_protocol_init(const struct scmi_protocol_handle *ph)
for (clkid = 0; clkid < cinfo->num_clocks; clkid++) {
cinfo->clkds[clkid].id = clkid;
ret = scmi_clock_attributes_get(ph, clkid, cinfo);
+ SCMI_QUIRK(clock_rcar_x5h_no_attributes, QUIRK_RCAR_X5H_NO_ATTRIBUTES);
if (ret)
return ret;
ret = scmi_clock_describe_rates_get(ph, clkid, cinfo);
+ SCMI_QUIRK(clock_rcar_x5h_no_attributes, QUIRK_RCAR_X5H_NO_RATES);
if (ret)
return ret;
}
diff --git a/drivers/firmware/arm_scmi/quirks.c b/drivers/firmware/arm_scmi/quirks.c
index c1a2f58505c1a757..e27c21b14220ab5f 100644
--- a/drivers/firmware/arm_scmi/quirks.c
+++ b/drivers/firmware/arm_scmi/quirks.c
@@ -171,6 +171,8 @@ struct scmi_quirk {
/* Global Quirks Definitions */
DEFINE_SCMI_QUIRK(clock_rates_triplet_out_of_spec, NULL, NULL, NULL);
+DEFINE_SCMI_QUIRK(clock_rcar_x5h_no_attributes, "Renesas", NULL, "0x10a0000-",
+ "renesas,r8a78000");
DEFINE_SCMI_QUIRK(perf_level_get_fc_force, "Qualcomm", NULL, "0x20000-");
DEFINE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, "Renesas", NULL,
"0x10a0000-0x10e0000", "renesas,r8a78000");
@@ -183,6 +185,7 @@ DEFINE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, "Renesas", NULL,
*/
static struct scmi_quirk *scmi_quirks_table[] = {
__DECLARE_SCMI_QUIRK_ENTRY(clock_rates_triplet_out_of_spec),
+ __DECLARE_SCMI_QUIRK_ENTRY(clock_rcar_x5h_no_attributes),
__DECLARE_SCMI_QUIRK_ENTRY(perf_level_get_fc_force),
__DECLARE_SCMI_QUIRK_ENTRY(power_rcar_x5h_4_28_bad_domains),
NULL
diff --git a/drivers/firmware/arm_scmi/quirks.h b/drivers/firmware/arm_scmi/quirks.h
index 108c8d11f6043a61..67818b6cf0909f8e 100644
--- a/drivers/firmware/arm_scmi/quirks.h
+++ b/drivers/firmware/arm_scmi/quirks.h
@@ -47,6 +47,7 @@ static inline void scmi_quirks_enable(struct device *dev, const char *vend,
/* Quirk delarations */
DECLARE_SCMI_QUIRK(clock_rates_triplet_out_of_spec);
+DECLARE_SCMI_QUIRK(clock_rcar_x5h_no_attributes);
DECLARE_SCMI_QUIRK(perf_level_get_fc_force);
DECLARE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains);
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 01/14] firmware: arm_scmi: quirk: Handle bad power domains on R-Car X5H
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1776793163.git.geert+renesas@glider.be>
Renesas R-Car X5H SCP FW SDKv4.28.0, v4.31.0, and v4.32.0 advertise a
few power domains that crash the system when touched or powered off.
Add a quirk to prevent such crashes.
As the SCMI power domain IDs are identical for all three versions, the
quirk can be shared.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Preventing power off could be handled in the MDLC driver, but no-touch
cannot.
---
drivers/firmware/arm_scmi/power.c | 20 ++++++++++++++++++++
drivers/firmware/arm_scmi/quirks.c | 3 +++
drivers/firmware/arm_scmi/quirks.h | 1 +
3 files changed, 24 insertions(+)
diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
index bb5062ab8280e02b..81b9035aa5a2eafe 100644
--- a/drivers/firmware/arm_scmi/power.c
+++ b/drivers/firmware/arm_scmi/power.c
@@ -12,6 +12,7 @@
#include "protocols.h"
#include "notify.h"
+#include "quirks.h"
/* Updated only after ALL the mandatory features for that version are merged */
#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x30001
@@ -150,6 +151,23 @@ scmi_power_domain_attributes_get(const struct scmi_protocol_handle *ph,
return ret;
}
+#define QUIRK_RCAR_X5H_4_28_BAD_DOMAINS \
+ ({ \
+ switch (domain) { \
+ /* Do not touch */ \
+ case 29: /* PD_RC08 */ \
+ case 92: /* PD_ACL0 */ \
+ case 116: /* PD_CMN */ \
+ return -EPERM; \
+ \
+ /* Do not power off */ \
+ case 76: /* PD_AC00 */ \
+ if (state == SCMI_POWER_STATE_GENERIC_OFF) \
+ return -EPERM; \
+ break; \
+ } \
+ })
+
static int scmi_power_state_set(const struct scmi_protocol_handle *ph,
u32 domain, u32 state)
{
@@ -157,6 +175,8 @@ static int scmi_power_state_set(const struct scmi_protocol_handle *ph,
struct scmi_xfer *t;
struct scmi_power_set_state *st;
+ SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, QUIRK_RCAR_X5H_4_28_BAD_DOMAINS);
+
ret = ph->xops->xfer_get_init(ph, POWER_STATE_SET, sizeof(*st), 0, &t);
if (ret)
return ret;
diff --git a/drivers/firmware/arm_scmi/quirks.c b/drivers/firmware/arm_scmi/quirks.c
index 2b38ba3f59a13c9e..c1a2f58505c1a757 100644
--- a/drivers/firmware/arm_scmi/quirks.c
+++ b/drivers/firmware/arm_scmi/quirks.c
@@ -172,6 +172,8 @@ struct scmi_quirk {
/* Global Quirks Definitions */
DEFINE_SCMI_QUIRK(clock_rates_triplet_out_of_spec, NULL, NULL, NULL);
DEFINE_SCMI_QUIRK(perf_level_get_fc_force, "Qualcomm", NULL, "0x20000-");
+DEFINE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains, "Renesas", NULL,
+ "0x10a0000-0x10e0000", "renesas,r8a78000");
/*
* Quirks Pointers Array
@@ -182,6 +184,7 @@ DEFINE_SCMI_QUIRK(perf_level_get_fc_force, "Qualcomm", NULL, "0x20000-");
static struct scmi_quirk *scmi_quirks_table[] = {
__DECLARE_SCMI_QUIRK_ENTRY(clock_rates_triplet_out_of_spec),
__DECLARE_SCMI_QUIRK_ENTRY(perf_level_get_fc_force),
+ __DECLARE_SCMI_QUIRK_ENTRY(power_rcar_x5h_4_28_bad_domains),
NULL
};
diff --git a/drivers/firmware/arm_scmi/quirks.h b/drivers/firmware/arm_scmi/quirks.h
index d8ba60b956522d04..108c8d11f6043a61 100644
--- a/drivers/firmware/arm_scmi/quirks.h
+++ b/drivers/firmware/arm_scmi/quirks.h
@@ -48,5 +48,6 @@ static inline void scmi_quirks_enable(struct device *dev, const char *vend,
/* Quirk delarations */
DECLARE_SCMI_QUIRK(clock_rates_triplet_out_of_spec);
DECLARE_SCMI_QUIRK(perf_level_get_fc_force);
+DECLARE_SCMI_QUIRK(power_rcar_x5h_4_28_bad_domains);
#endif /* _SCMI_QUIRKS_H */
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 00/14] R-Car X5H Ironhide SCMI CPG/MDLC remapping
From: Geert Uytterhoeven @ 2026-04-21 18:11 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, Saravana Kannan, Michael Turquette,
Stephen Boyd, Philipp Zabel, Ulf Hansson, Rafael J . Wysocki,
Kevin Hilman, Florian Fainelli, Wolfram Sang, Marek Vasut,
Kuninori Morimoto
Cc: arm-scmi, linux-arm-kernel, linux-renesas-soc, linux-clk,
devicetree, linux-pm, linux-kernel, Geert Uytterhoeven
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
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Conor Dooley @ 2026-04-21 17:57 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <OSQPR06MB725251546BFEB158F9AA1C4D8B2C2@OSQPR06MB7252.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 8325 bytes --]
Billy, Linus,
On Tue, Apr 21, 2026 at 06:15:44AM +0000, Billy Tsai wrote:
> > > > > > > + properties:
> > > > > > > + function:
> > > > > > > + enum:
> > > > > > > + - EMMC
> > > > > > > + - JTAGDDR
> > > > > > > + - JTAGM0
> > > > > > > + - JTAGPCIEA
> > > > > > > + - JTAGPCIEB
> > > > > > > + - JTAGPSP
> > > > > > > + - JTAGSSP
> > > > > > > + - JTAGTSP
> > > > > > > + - JTAGUSB3A
> > > > > > > + - JTAGUSB3B
> > > > > > > + - PCIERC0PERST
> > > > > > > + - PCIERC1PERST
> > > > > > > + - TSPRSTN
> > > > > > > + - UFSCLKI
> > > > > > > + - USB2AD0
> > > > > > > + - USB2AD1
> > > > > > > + - USB2AH
> > > > > > > + - USB2AHP
> > > > > > > + - USB2AHPD0
> > > > > > > + - USB2AXH
> > > > > > > + - USB2AXH2B
> > > > > > > + - USB2AXHD1
> > > > > > > + - USB2AXHP
> > > > > > > + - USB2AXHP2B
> > > > > > > + - USB2AXHPD1
> > > > > > > + - USB2BD0
> > > > > > > + - USB2BD1
> > > > > > > + - USB2BH
> > > > > > > + - USB2BHP
> > > > > > > + - USB2BHPD0
> > > > > > > + - USB2BXH
> > > > > > > + - USB2BXH2A
> > > > > > > + - USB2BXHD1
> > > > > > > + - USB2BXHP
> > > > > > > + - USB2BXHP2A
> > > > > > > + - USB2BXHPD1
> > > > > > > + - USB3AXH
> > > > > > > + - USB3AXH2B
> > > > > > > + - USB3AXHD
> > > > > > > + - USB3AXHP
> > > > > > > + - USB3AXHP2B
> > > > > > > + - USB3AXHPD
> > > > > > > + - USB3BXH
> > > > > > > + - USB3BXH2A
> > > > > > > + - USB3BXHD
> > > > > > > + - USB3BXHP
> > > > > > > + - USB3BXHP2A
> > > > > > > + - USB3BXHPD
> > > > > > > + - VB
> > > > > > > + - VGADDC
> > > > > > > +
> > > > > > > + groups:
> > > > > > > + enum:
> > > > > > > + - EMMCCDN
> > > > > > > + - EMMCG1
> > > > > > > + - EMMCG4
> > > > > > > + - EMMCG8
> > > > > > > + - EMMCWPN
> > > > > > > + - JTAG0
> > > > > > > + - PCIERC0PERST
> > > > > > > + - PCIERC1PERST
> > > > > > > + - TSPRSTN
> > > > > > > + - UFSCLKI
> > > > > > > + - USB2A
> > > > > > > + - USB2AAP
> > > > > > > + - USB2ABP
> > > > > > > + - USB2ADAP
> > > > > > > + - USB2AH
> > > > > > > + - USB2AHAP
> > > > > > > + - USB2B
> > > > > > > + - USB2BAP
> > > > > > > + - USB2BBP
> > > > > > > + - USB2BDBP
> > > > > > > + - USB2BH
> > > > > > > + - USB2BHBP
> > > > > > > + - USB3A
> > > > > > > + - USB3AAP
> > > > > > > + - USB3ABP
> > > > > > > + - USB3B
> > > > > > > + - USB3BAP
> > > > > > > + - USB3BBP
> > > > > > > + - VB0
> > > > > > > + - VB1
> > > > > > > + - VGADDC
> > > > > > > + pins:
> > > > > > > + enum:
> > > > > > > + - AB13
> > > > > > > + - AB14
> > > > > > > + - AC13
> > > > > > > + - AC14
> > > > > > > + - AD13
> > > > > > > + - AD14
> > > > > > > + - AE13
> > > > > > > + - AE14
> > > > > > > + - AE15
> > > > > > > + - AF13
> > > > > > > + - AF14
> > > > > > > + - AF15
>
> > > > > > Why do you have groups and pins?
> > > > > > Is it valid in your device to have groups and pins in the same node?
>
> > > > > The intent is to support both group-based mux selection and
> > > > > configuration, as well as per-pin configuration.
>
> > > > > In our hardware:
> > > > > - `function` + `groups` are used for pinmux selection.
> > > > > - `pins` is used for per-pin configuration (e.g. drive strength,
> > > > > bias settings).
> > > > > - `groups` may also be used for group-level configuration.
>
> > > > > As a result, both `groups` and `pins` may appear in the same node,
> > > > > but they serve different purposes and do not conflict:
> > > > > - `groups` selects the mux function and may apply configuration to
> > > > > the entire group.
> > > > > - `pins` allows overriding or specifying configuration for individual
> > > > > pins.
>
> > > > > In most cases, only one of them is needed, but both are allowed when
> > > > > both group-level and per-pin configuration are required.
>
> > > > To be honest, that sounds like your groups are not sufficiently
> > > > granular and should be reduced such that you can use them for pin
> > > > settings.
>
> > > The intent was to keep the binding flexible, but in practice the mixed
> > > use of `groups` and `pins` in the same node is not expected to be used.
> > >
> > > Given that, I agree this flexibility is unnecessary and makes the
> > > binding semantics less clear. I'll rework the binding to make the
> > > expected usage explicit rather than allowing combinations that do not
> > > correspond to a real use case.
> > >
> > > In particular, I'll split the constraints as follows:
> > >
> > > - For pinmux, the presence of `function` will require `groups`, and
> > > `pins` will not be allowed. This reflects the hardware design, where
> > > the groups are defined by the pins affected by a given mux expression
> > >
> > > - For pin configuration, exactly one of `groups` or `pins` will be
> > > required (using oneOf), so that configuration is applied either at
> > > group level or per-pin, but not both.
> > >
> > >
> > > - if:
> > > required:
> > > - function
> > > then:
> > > required:
> > > - groups
> > > not:
> > > required:
> > > - pins
> > > else:
> > > oneOf:
> > > - required:
> > > - groups
> > > not:
> > > required:
> > > - pins
> > > - required:
> > > - pins
> > > not:
> > > required:
> > > - groups
> > > Does this match what you had in mind?
>
> > It's an improvement I think, but I am wondering why you cannot do
> > without pins entirely and apply pinconf stuff at the group level?
> > Of course that may not be possible with the current groups, but if you
> > made the groups more granular, would it be possible?
>
> Within a given group, it is not always the case that all pins share the
> same configuration requirements (e.g. drive strength or bias settings),
> so applying pinconf purely at the group level would be too restrictive.
Right. That's pretty normal.
> Making the groups more granular to match all possible configuration
> combinations would not reflect the actual mux granularity and would
> significantly increase the number of groups.
>
> For example, we have encountered a timing issue due to the PCB layout,
> where only the eMMC clock pin requires a different drive strength:
>
> # The EMMCG4 group includes pins AC14, AE15, AD14, AE14, AF14, AB13
> # AC14: clock
> # AE15: command
> # AD14–AB13: data
>
> pinconf_emmc_clk: emmc-clk-pinconf {
> pins = "AC14";
> drive-strength = <8>;
> };
>
> In this case, applying pin configuration at the group level would affect
> all pins in the group, which is not desirable. Allowing per-pin
> configuration via `pins` is therefore necessary.
>
> For this reason, `groups` is used for mux selection, while `pins` is
> required to express per-pin configuration where needed.
Right, yeah, I figured your objection to it was because of how
annoyingly small it would make the groups. I suppose the alternative is
going without groups and always using pins.
Having groups and pins seems really suboptimal to me, but there are
some other bindings where this is done. Linus, what is your take on
nodes supporting both? I'm biased towards having a more straightforward
binding but if you think this mix makes sense then I'll defer to your
vastly greater experience with these devices.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net v4 2/2] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
From: Paolo Abeni @ 2026-04-21 17:32 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <aeewoVjN7EHLZTW_@lore-desk>
On 4/21/26 7:15 PM, Lorenzo Bianconi wrote:
>> On 4/17/26 8:36 AM, Lorenzo Bianconi wrote:
>>> @@ -1055,8 +1058,33 @@ static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
>>> e->dma_addr = 0;
>>> e->skb = NULL;
>>> list_add_tail(&e->list, &q->tx_list);
>>> +
>>> + /* Reset DMA descriptor */
>>> + WRITE_ONCE(desc->ctrl, 0);
>>> + WRITE_ONCE(desc->addr, 0);
>>> + WRITE_ONCE(desc->data, 0);
>>> + WRITE_ONCE(desc->msg0, 0);
>>> + WRITE_ONCE(desc->msg1, 0);
>>> + WRITE_ONCE(desc->msg2, 0);
>>
>> Sashiko has some complains on this patch that look legit to me.
>>
>> Also the pre-existing issues mentioned WRT patch 1/2 makes such patch
>> IMHO almost ineffective, I think you should address them in the same series.
>>
>> Note that you should have commented on sashiko review on the ML, it
>> would have saved a significant amount of time on us.
>
> Since this series is marked as 'Changes Requested', it is not clear to me what
> next steps are. I guess we have two possible approach here:
>
> 1) - Post patch 1/2 ("net: airoha: Move ndesc initialization at
> end of airoha_qdma_init_tx()") with the series available upstream
> (not merged yet) in [0] where I am fixing similar issues for
> airoha_qdma_init_rx_queue() and airoha_qdma_tx_irq_init().
> - Post patch 2/2 ("net: airoha: Add missing bits in
> airoha_qdma_cleanup_tx_queue()") with a fix for airoha_ndo_stop() waiting
> for TX/RX DMA engine to complete before running
> airoha_qdma_cleanup_tx_queue().
>
> 2) - Since all the issues rised by Sashiko are not strictly related to this
> series and they are already fixed in pending patches, just apply the fixes
> separately without the needs to repost this series.
Given the current flood on the ML I think option 2 could be the better.
Note that the tree is currently in Jakub's hands and he can very legitly
disagree.
/P
^ permalink raw reply
* Re: [PATCH net v4 2/2] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
From: Lorenzo Bianconi @ 2026-04-21 17:15 UTC (permalink / raw)
To: Paolo Abeni
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <210f5d0b-6232-4c0f-adff-3a97d54159b3@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
> On 4/17/26 8:36 AM, Lorenzo Bianconi wrote:
> > @@ -1055,8 +1058,33 @@ static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
> > e->dma_addr = 0;
> > e->skb = NULL;
> > list_add_tail(&e->list, &q->tx_list);
> > +
> > + /* Reset DMA descriptor */
> > + WRITE_ONCE(desc->ctrl, 0);
> > + WRITE_ONCE(desc->addr, 0);
> > + WRITE_ONCE(desc->data, 0);
> > + WRITE_ONCE(desc->msg0, 0);
> > + WRITE_ONCE(desc->msg1, 0);
> > + WRITE_ONCE(desc->msg2, 0);
>
> Sashiko has some complains on this patch that look legit to me.
>
> Also the pre-existing issues mentioned WRT patch 1/2 makes such patch
> IMHO almost ineffective, I think you should address them in the same series.
>
> Note that you should have commented on sashiko review on the ML, it
> would have saved a significant amount of time on us.
Since this series is marked as 'Changes Requested', it is not clear to me what
next steps are. I guess we have two possible approach here:
1) - Post patch 1/2 ("net: airoha: Move ndesc initialization at
end of airoha_qdma_init_tx()") with the series available upstream
(not merged yet) in [0] where I am fixing similar issues for
airoha_qdma_init_rx_queue() and airoha_qdma_tx_irq_init().
- Post patch 2/2 ("net: airoha: Add missing bits in
airoha_qdma_cleanup_tx_queue()") with a fix for airoha_ndo_stop() waiting
for TX/RX DMA engine to complete before running
airoha_qdma_cleanup_tx_queue().
2) - Since all the issues rised by Sashiko are not strictly related to this
series and they are already fixed in pending patches, just apply the fixes
separately without the needs to repost this series.
Which approach do you prefer?
Regards,
Lorenzo
[0] https://patchwork.kernel.org/project/netdevbpf/cover/20260420-airoha_qdma_init_rx_queue-fix-v2-0-d99347e5c18d@kernel.org/
>
> /P
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: arm: amlogic: add support for Amediatech X98Q
From: Conor Dooley @ 2026-04-21 17:13 UTC (permalink / raw)
To: christian.koever-draxl
Cc: robh, krzk+dt, conor+dt, neil.armstrong, khilman, jbrunet,
martin.blumenstingl, devicetree, linux-amlogic, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260421155328.26359-2-christian.koever-draxl@student.uibk.ac.at>
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
On Tue, Apr 21, 2026 at 05:53:27PM +0200, christian.koever-draxl@student.uibk.ac.at wrote:
> From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
> Add the board binding for the Amediatech X98Q TV box
>
> Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Conor Dooley @ 2026-04-21 17:05 UTC (permalink / raw)
To: Ronald Claveau
Cc: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260421-add-thermal-t7-vim4-v3-1-a2e7215ed003@aliel.fr>
[-- Attachment #1: Type: text/plain, Size: 925 bytes --]
On Tue, Apr 21, 2026 at 09:19:43AM +0200, Ronald Claveau wrote:
> Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
>
> Unlike existing variants which use a phandle to the ao-secure syscon,
> the T7 relies on a secure monitor interface described by a phandle and
> a sensor index argument.
>
> The T7 integrates multiple thermal sensors, all accessed through the
> same SMC call. The sensor index argument is required to identify which
> sensor's calibration data the secure monitor should return, as a single
> SM_THERMAL_CALIB_READ command serves all of them.
>
> Introduce the amlogic,secure-monitor property as a phandle-array and
> make amlogic,ao-secure or amlogic,secure-monitor conditionally required
> depending on the compatible.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Treat ID_AA64DFR0_EL1.PMUVer as an unsigned field
From: Marc Zyngier @ 2026-04-21 16:45 UTC (permalink / raw)
To: Jing Zhang
Cc: KVM, KVMARM, ARMLinux, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Paolo Bonzini
In-Reply-To: <20260421164112.2448553-1-jingzhangos@google.com>
On Tue, 21 Apr 2026 17:41:12 +0100,
Jing Zhang <jingzhangos@google.com> wrote:
>
> ID_AA64DFR0_EL1.PMUVer is an unsigned 4-bit field, but was historically
> marked as signed in the cpufeature table. This led
> kvm_init_host_debug_data() to fail detection of PMUv3 implementation on
> systems with PMUv3p8 or newer, as the signed extraction of the field
> (e.g., 0b1000 for PMUv3p8) would result in a negative value.
>
> Fix this by marking the field as unsigned in the ftr_id_aa64dfr0 table
> and updating the KVM initialization code to use unsigned extraction.
> While at it, ensure that both the 'Not Implemented' (0b0000) and
> 'Implementation Defined' (0b1111) values are correctly handled as
> indicating the absence of a standard PMUv3.
>
> Signed-off-by: Jing Zhang <jingzhangos@google.com>
https://lore.kernel.org/all/20260305-james-kvm-pmuver-sign-v2-0-ee80a125af9b@linaro.org/
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Conor Dooley @ 2026-04-21 16:43 UTC (permalink / raw)
To: linux-kernel-dev
Cc: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown,
linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm
In-Reply-To: <20260421-add-mcu-fan-khadas-vim4-v4-1-447114a28f2d@aliel.fr>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Tue, Apr 21, 2026 at 01:49:18PM +0200, Ronald Claveau via B4 Relay wrote:
> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>
> The Khadas VIM4 MCU register is slightly different
> from previous boards' MCU.
> This board also features a switchable power source for its fan.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] KVM: arm64: Treat ID_AA64DFR0_EL1.PMUVer as an unsigned field
From: Jing Zhang @ 2026-04-21 16:41 UTC (permalink / raw)
To: KVM, KVMARM, ARMLinux, Marc Zyngier, Oliver Upton
Cc: Joey Gouly, Suzuki K Poulose, Zenghui Yu, Paolo Bonzini,
Jing Zhang
ID_AA64DFR0_EL1.PMUVer is an unsigned 4-bit field, but was historically
marked as signed in the cpufeature table. This led
kvm_init_host_debug_data() to fail detection of PMUv3 implementation on
systems with PMUv3p8 or newer, as the signed extraction of the field
(e.g., 0b1000 for PMUv3p8) would result in a negative value.
Fix this by marking the field as unsigned in the ftr_id_aa64dfr0 table
and updating the KVM initialization code to use unsigned extraction.
While at it, ensure that both the 'Not Implemented' (0b0000) and
'Implementation Defined' (0b1111) values are correctly handled as
indicating the absence of a standard PMUv3.
Signed-off-by: Jing Zhang <jingzhangos@google.com>
---
arch/arm64/kernel/cpufeature.c | 2 +-
arch/arm64/kvm/debug.c | 4 +++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 32c2dbcc0c641..1b5e37a1a41b4 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -565,7 +565,7 @@ static const struct arm64_ftr_bits ftr_id_aa64dfr0[] = {
* We can instantiate multiple PMU instances with different levels
* of support.
*/
- S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_EL1_PMUVer_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_EXACT, ID_AA64DFR0_EL1_PMUVer_SHIFT, 4, 0),
ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64DFR0_EL1_DebugVer_SHIFT, 4, 0x6),
ARM64_FTR_END,
};
diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
index 3ad6b7c6e4ba7..2834d7ef9dedb 100644
--- a/arch/arm64/kvm/debug.c
+++ b/arch/arm64/kvm/debug.c
@@ -75,8 +75,10 @@ static void kvm_arm_setup_mdcr_el2(struct kvm_vcpu *vcpu)
void kvm_init_host_debug_data(void)
{
u64 dfr0 = read_sysreg(id_aa64dfr0_el1);
+ u64 pmuver;
- if (cpuid_feature_extract_signed_field(dfr0, ID_AA64DFR0_EL1_PMUVer_SHIFT) > 0)
+ pmuver = cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_PMUVer_SHIFT);
+ if (pmuv3_implemented(pmuver))
*host_data_ptr(nr_event_counters) = FIELD_GET(ARMV8_PMU_PMCR_N,
read_sysreg(pmcr_el0));
--
2.54.0.rc1.555.g9c883467ad-goog
^ permalink raw reply related
* Re: [PATCH] iommu/arm-smmu-v3: Stop queue allocation retry at PAGE_SIZE
From: Will Deacon @ 2026-04-21 16:38 UTC (permalink / raw)
To: Robin Murphy; +Cc: leo.jiang1224, joro, iommu, linux-arm-kernel
In-Reply-To: <0fdf4b1f-90f2-4f69-9d2b-dc5f608e9c1c@arm.com>
On Tue, Apr 21, 2026 at 04:56:47PM +0100, Robin Murphy wrote:
> On 18/04/2026 6:31 am, leo.jiang1224@foxmail.com wrote:
> > From: LoserJL <leo.jiang1224@foxmail.com>
> >
> > In arm_smmu_init_one_queue(), the loop reduces max_n_shift if
> > dmam_alloc_coherent() fails. However, since dmam_alloc_coherent()
> > allocates at least PAGE_SIZE, retrying with a smaller size after
> > a PAGE_SIZE failure is logically redundant.
>
> Says who? It's certainly not a guarantee offered by the DMA API itself, and
> indeed some allocation paths can definitely still allocate less than a page
> - e.g. anything which hits a per-device or global coherent pool.
>
> > Moreover, if a sub-page retry were to succeed due to concurrent memory
> > release, the hardware would be configured with a smaller queue depth
> > despite a full page being allocated. This leads to inefficient memory
> > usage and unnecessary hardware performance limitation.
> >
> > Terminate the loop once qsz reaches PAGE_SIZE to ensure logical
> > consistency and optimal hardware configuration.
>
> That's really not an argument - even if an allocator does happen to
> over-allocate for the requested size, that is hardly the caller's concern;
> and as far as "optimal" queue sizes go in this case, those very much depend
> on the number of CPUs issuing commands and volume of expected stall/PRI
> events - in many cases PAGE_SIZE would already be far too small to really
> work well.
>
> Also note that if we _were_ to fail to allocate a PAGE_SIZE or smaller
> queue, there would be very little chance of the subsequent allocation(s) for
> the stream table succeeding, so realistically the driver is probably going
> to end up failing to probe in such circumstances anyway.
That's all true, but tbf I think I just fscked up the comparison in
d25f6ead162e ("iommu/arm-smmu-v3: Increase maximum size of queues") so
I'm not against fixing that up even though the "rationale" given by
Loser doesn't make a whole lot of sense.
Will
^ permalink raw reply
* Re: [PATCH v3 0/2] Add support for Amediatech X98Q (Amlogic S905W2)
From: Ferass El Hafidi @ 2026-04-21 16:37 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, robh, krzk+dt, conor+dt,
neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260421155328.26359-1-christian.koever-draxl@student.uibk.ac.at>
On Tue, 21 Apr 2026 15:53, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>Changes in v3:
>- Change position of the entry in the amlogic.yaml.
>- Change formatting of the Amlogic W150S1 Wi-Fi module comment.
>- Fix several formatting issues.
>
>Changes in v2:
>- Split dt-bindings and dts changes into separate patches.
>- Updated model string to match documented vendor prefix.
>- Put vddio_sd states array in a single line.
>- Added a comment for the unsupported Amlogic W150S1 Wi-Fi module.
>
Where did the rest of the cover letter go?
>Christian Stefan Kövér-Draxl (2):
> dt-bindings: arm: amlogic: add support for Amediatech X98Q
> arm64: dts: amlogic: add support for X98Q
>
> .../devicetree/bindings/arm/amlogic.yaml | 7 +
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
> 3 files changed, 257 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
>
>--
>2.53.0
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: dts: amlogic: add support for X98Q
From: Ferass El Hafidi @ 2026-04-21 16:33 UTC (permalink / raw)
To: linux-amlogic, christian.koever-draxl, robh, krzk+dt, conor+dt,
neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260421155328.26359-3-christian.koever-draxl@student.uibk.ac.at>
On Tue, 21 Apr 2026 15:53, christian.koever-draxl@student.uibk.ac.at wrote:
>From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>
>Add dts enabling core hardware for the Amediatech X98Q.
>
You should explain what the Amediatech X98Q is. You did this in the v2's
cover letter, but it should additionally go in here too so it's visible
in git commits in the kernel. What hardware does it have? Maybe also what is
enabled in the DT?
>Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
>---
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
> 2 files changed, 250 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
><...>
--
Best regards,
Ferass
^ permalink raw reply
* Re: [PATCH v2 5/9] ASoC: mediatek: mt2701: add HDMI audio memif, FE and BE DAIs
From: Daniel Golle @ 2026-04-21 16:12 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jaroslav Kysela,
Takashi Iwai, Arnd Bergmann, Cyril Chao,
Nícolas F. R. A. Prado, Kuninori Morimoto, Eugen Hristev,
linux-sound, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <95e1067c-3c8e-4dd4-997d-f3be9d2cba29@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]
On Mon, Apr 20, 2026 at 07:08:01PM +0100, Mark Brown wrote:
> On Mon, Apr 20, 2026 at 02:13:34AM +0100, Daniel Golle wrote:
>
> > +static int mt2701_afe_hdmi_trigger(struct snd_pcm_substream *substream, int cmd,
> > + struct snd_soc_dai *dai)
> > +{
> > + struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
> > +
> > + switch (cmd) {
> > + case SNDRV_PCM_TRIGGER_START:
> > + case SNDRV_PCM_TRIGGER_RESUME:
> > + /* Ungate HDMI and SPDIF power islands. */
> > + regmap_update_bits(afe->regmap, AUDIO_TOP_CON0,
> > + AUDIO_TOP_CON0_PDN_HDMI_CK |
> > + AUDIO_TOP_CON0_PDN_SPDIF_CK, 0);
>
> It looks like we have clock API clocks for HDMI and S/PDIF on this SoC
> (see clk-mt2701-aud.c) - are there going to be problem with peering
> directly at the register? We do manage some clocks via the clock API
> but not those ones.
Yeah, you are right. That came from a super-old vendor driver and I
didn't realise the exact same gate bits are alrady driven by the
clock driver. I'll drop that and prepare v3...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 0/4] arm64: rockchip: The hunt for exact pixel clocks on RK3576
From: Maxime Ripard @ 2026-04-21 16:10 UTC (permalink / raw)
To: Brian Masney
Cc: Sebastian Reichel, Alexey Charkov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Pavel Zhovner, Andy Yan,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
linux-clk, Cristian Ciocaltea
In-Reply-To: <aeZOMnZfBcBHzR8c@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4443 bytes --]
Hi Brian, Alexey,
On Mon, Apr 20, 2026 at 12:02:58PM -0400, Brian Masney wrote:
> On Sat, Apr 18, 2026 at 12:24:57AM +0200, Sebastian Reichel wrote:
> > On Fri, Apr 17, 2026 at 07:11:43PM +0400, Alexey Charkov wrote:
> > > Dear all,
> > >
> > > Need the help of the collective wisdom of the community.
> > >
> > > The problem I'm trying to solve is reliably obtaining the exact pixel
> > > clock for arbitrary display modes supported by the RK3576 SoC.
> > >
> > > Rockchip RK3576 has three display output processors VP0~VP2, each
> > > supporting different ranges of display modes, roughly as follows:
> > > - VP0: 4K 120Hz
> > > - VP1: 2.5k 60Hz
> > > - VP2: 1080p 60Hz
Do any of those have an additional multiplier or divider after the PLL?
I'm asking because 4k@120Hz is 1188MHz, and 1080p@60Hz is 148.5 (so 1188
/ 8). 2.5k @ 60 might be a bit more problematic, but my point is that
for HDMI/DP, most resolutions all have a pixel clock that are multiples
of 148.5MHz.
If you manage to get the PLL to the highest you need (1188MHz), and then
apply dividers, you don't need to change the PLL frequency anymore.
> > > Each one obviously needs a pixel clock. The required frequencies for the
> > > pixel clocks vary greatly depending on the display mode, and need to be
> > > matched within a tight tolerance, or else many displays will refuse to
> > > work. E.g. the preferred (maximum) display mode out of VP1 is particularly
> > > awkward, because it requires a pixel clock of 248.88 MHz, which cannot
> > > be obtained using integer dividers from its default clock source (GPLL
> > > at 1188 MHz), and the nearest approximation is 237.6 MHz, which is well
> > > outside the tolerance of e.g. DP specification, resulting in a blank
> > > screen on most displays by default.
> > >
> > > The clock sources are of course configurable, in particular there are muxes
> > > connected to each VP for selecting the source of the pixel clock:
> > > - Each VP can take the clock either from the (single!) HDMI PHY or from
> > > its dedicated dclk_vpX_src mux
> > > - The dclk_vpX_src mux can select the clock from a number of system PLLs
> > > (GPLL, CPLL, VPLL, BPLL, LPLL)
> > >
> > > While the system PLLs can be configured to output a wide range of
> > > frequencies, they are shared between many system components. E.g. on the
> > > current mainline kernel on one of my RK3576 boards I've got the following:
> > > GPLL: 1188 MHz, enable count 20
> > > CPLL: 1000 MHz, enable count 17
> > > VPLL: 594 MHz, enable count 0 (yaay!)
> > > BPLL, LPLL: 816 MHz, enable count 0 (but these last ones don't have
> > > predividers, so are less flexible)
> > >
> > > So ultimately there is exactly one free fractional PLL (VPLL) which can be
> > > used to generate arbitrary pixel clocks, but we have up to three consumers
> > > trying to drive different display modes from it (e.g. HDMI on VP0, DP on
> > > VP1 and MIPI DSI on VP2). We also want to be able to adjust the PLL output
> > > frequency on the fly to satisfy the requirements of the selected display
> > > mode.
> > >
> > > And this is where I'm stuck. Trying to satisfy the requirements of up to
> > > three consumers while changing the PLL frequency on the fly sounds like
> > > a poorly tractable mathematical problem (is it 3-SAT?). We can take the
> > > HDMI output out of the equation, because it can be driven from the HDMI
> > > PHY (which is capable of arbitrary rates) instead of the mux, but that
> > > makes the decision of which dclk source to use for a VP block dependent on
> > > which downstream consumer is connected to it (HDMI vs. something else).
> >
> > It becomes more messy: The HDMI PHY cannot be used as clock source
> > for modes exceeding 4K@60Hz.
> >
> > > Even then we somehow need two devices to cooperate in picking a PLL
> > > frequency that satisfies the requirements of both of them, and change to it
> > > without display corruption. I'm not even sure if the CCF has mechanisms
> > > for that?..
It's not *just* the CCF though. You will disrupt the other, already
active display, which might affect the user because the screen will
blank, throw off the vblank timings and thus userspace, etc.
Brian's solution is great progress on that front already, but if you can
just save yourself the trouble, I'd advise you to do that instead :)
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2] arm64/irqflags: __always_inline the arch_local_irq_*() helpers
From: Leonardo Bras @ 2026-04-21 16:07 UTC (permalink / raw)
To: Breno Leitao
Cc: Leonardo Bras, Catalin Marinas, Will Deacon, mark.rutland,
leo.yan, linux-arm-kernel, linux-kernel, palmer, paulmck,
puranjay, usama.arif, rmikey, kernel-team
In-Reply-To: <20260421-arm64_always_inline-v2-1-c59d1400514d@debian.org>
On Tue, Apr 21, 2026 at 08:58:57AM -0700, Breno Leitao wrote:
> The arch_local_irq_*() wrappers in <asm/irqflags.h> dispatch between two
> underlying primitives: the __daif_* path on most systems, and the
> __pmr_* path on builds that use GIC PMR-based masking (Pseudo-NMI). The
> leaf primitives are already __always_inline, but the wrappers themselves
> are plain "static inline".
>
> That is unsafe for noinstr callers: nothing prevents the compiler from
> emitting an out-of-line copy of e.g. arch_local_irq_disable(), and an
> out-of-line copy can be instrumented (ftrace, kcov, sanitizers), which
> breaks the noinstr contract on the entry/idle paths that rely on these
> helpers.
>
> x86 hit and fixed exactly this class of bug in commit 7a745be1cc90
> ("x86/entry: __always_inline irqflags for noinstr").
>
> Force-inline all of the arch_local_irq_*() wrappers so they cannot be
> emitted out-of-line:
>
> - arch_local_irq_enable()
> - arch_local_irq_disable()
> - arch_local_save_flags()
> - arch_irqs_disabled_flags()
> - arch_irqs_disabled()
> - arch_local_irq_save()
> - arch_local_irq_restore()
>
> The primary motivation is noinstr safety. There is a useful side effect
> for fleet-wide profiling: when the wrapper is emitted out-of-line,
> samples taken inside it during the post-WFI IRQ unmask in
> default_idle_call() are attributed to arch_local_irq_enable rather than
> default_idle_call(), and the FP-unwinder loses default_idle_call() from
> the chain.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> Changes in v2:
> - Expand the functions that uses always_inline in arm64
> - Link to v1: https://patch.msgid.link/20260420-arm64_always_inline-v1-1-dba919cf46bc@debian.org
> ---
> arch/arm64/include/asm/irqflags.h | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm64/include/asm/irqflags.h b/arch/arm64/include/asm/irqflags.h
> index d4d7451c2c129..a8cb5a5c93b78 100644
> --- a/arch/arm64/include/asm/irqflags.h
> +++ b/arch/arm64/include/asm/irqflags.h
> @@ -40,7 +40,7 @@ static __always_inline void __pmr_local_irq_enable(void)
> barrier();
> }
>
> -static inline void arch_local_irq_enable(void)
> +static __always_inline void arch_local_irq_enable(void)
> {
> if (system_uses_irq_prio_masking()) {
> __pmr_local_irq_enable();
> @@ -68,7 +68,7 @@ static __always_inline void __pmr_local_irq_disable(void)
> barrier();
> }
>
> -static inline void arch_local_irq_disable(void)
> +static __always_inline void arch_local_irq_disable(void)
> {
> if (system_uses_irq_prio_masking()) {
> __pmr_local_irq_disable();
> @@ -90,7 +90,7 @@ static __always_inline unsigned long __pmr_local_save_flags(void)
> /*
> * Save the current interrupt enable state.
> */
> -static inline unsigned long arch_local_save_flags(void)
> +static __always_inline unsigned long arch_local_save_flags(void)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_local_save_flags();
> @@ -109,7 +109,7 @@ static __always_inline bool __pmr_irqs_disabled_flags(unsigned long flags)
> return flags != GIC_PRIO_IRQON;
> }
>
> -static inline bool arch_irqs_disabled_flags(unsigned long flags)
> +static __always_inline bool arch_irqs_disabled_flags(unsigned long flags)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_irqs_disabled_flags(flags);
> @@ -128,7 +128,7 @@ static __always_inline bool __pmr_irqs_disabled(void)
> return __pmr_irqs_disabled_flags(__pmr_local_save_flags());
> }
>
> -static inline bool arch_irqs_disabled(void)
> +static __always_inline bool arch_irqs_disabled(void)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_irqs_disabled();
> @@ -160,7 +160,7 @@ static __always_inline unsigned long __pmr_local_irq_save(void)
> return flags;
> }
>
> -static inline unsigned long arch_local_irq_save(void)
> +static __always_inline unsigned long arch_local_irq_save(void)
> {
> if (system_uses_irq_prio_masking()) {
> return __pmr_local_irq_save();
> @@ -187,7 +187,7 @@ static __always_inline void __pmr_local_irq_restore(unsigned long flags)
> /*
> * restore saved IRQ state
> */
> -static inline void arch_local_irq_restore(unsigned long flags)
> +static __always_inline void arch_local_irq_restore(unsigned long flags)
> {
> if (system_uses_irq_prio_masking()) {
> __pmr_local_irq_restore(flags);
>
> ---
> base-commit: bee6ea30c48788e18348309f891ed8afbf7702ac
> change-id: 20260420-arm64_always_inline-6bc9dd3c17e6
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
>
Looks correct to what was discussed in V1. FWIW:
Reviewed-by: Leonardo Bras <leo.bras@arm.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox