* [PATCH 0/7] arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD SoC and Geist board
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
Add support for the Renesas R-Car M3Le (R8A779MD) SoC, a register-compatible
variant of the R8A77965 (M3-N) with reduced set of peripherals. Add support
for the Geist board based on the Renesas R-Car R8A779MD (M3Le).
The DU part does probe, and to the best of my knowledge, should correctly
describe the hardware, but is otherwise untested due to no remote display
access. Note that the DU uses ports 0 and 2, which is unusual.
VIN is also untested due to no remote hardware access.
Marek Vasut (5):
dt-bindings: display: renesas,du: Document Renesas R-Car R8A779MD M3Le
drm/rcar-du: Add support for Renesas R-Car R8A779MD M3Le
dt-bindings: clock: cs2000-cp: document CS2500
dt-bindings: soc: renesas: Document Renesas R-Car R8A779MD Geist
soc: renesas: Identify Renesas R-Car R8A779MD M3Le SoC
Nguyen Tran (2):
arm64: dts: renesas: r8a779md: Add Renesas R-Car R8A779MD M3Le DTs
arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD
Geist
.../bindings/clock/cirrus,cs2000-cp.yaml | 10 +-
.../bindings/display/renesas,du.yaml | 70 ++
.../bindings/soc/renesas/renesas.yaml | 6 +
arch/arm64/boot/dts/renesas/Makefile | 3 +
.../dts/renesas/geist-panel-aa104xd12.dtso | 17 +
.../arm64/boot/dts/renesas/r8a779md-geist.dts | 832 ++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a779md.dtsi | 48 +
drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 25 +
drivers/soc/renesas/renesas-soc.c | 1 +
9 files changed, 1009 insertions(+), 3 deletions(-)
create mode 100644 arch/arm64/boot/dts/renesas/geist-panel-aa104xd12.dtso
create mode 100644 arch/arm64/boot/dts/renesas/r8a779md-geist.dts
create mode 100644 arch/arm64/boot/dts/renesas/r8a779md.dtsi
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
--
2.53.0
^ permalink raw reply
* [PATCH 2/7] drm/rcar-du: Add support for Renesas R-Car R8A779MD M3Le
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Add support the Renesas R-Car R8A779MD M3Le SoC. This SoC is
similar to R-Car R8A77965 M3-N SoC, except the HDMI port@1 is
not present.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
index 031d07f4508e9..be862b5524fd2 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_drv.c
@@ -564,6 +564,30 @@ static const struct rcar_du_device_info rcar_du_r8a779h0_info = {
.dsi_clk_mask = BIT(0),
};
+static const struct rcar_du_device_info rcar_du_r8a779md_info = {
+ .gen = 3,
+ .features = RCAR_DU_FEATURE_CRTC_IRQ
+ | RCAR_DU_FEATURE_CRTC_CLOCK
+ | RCAR_DU_FEATURE_VSP1_SOURCE
+ | RCAR_DU_FEATURE_INTERLACED
+ | RCAR_DU_FEATURE_TVM_SYNC,
+ .channels_mask = BIT(1) | BIT(0),
+ .routes = {
+ /* R8A779MD has one RGB output and one LVDS output. */
+ [RCAR_DU_OUTPUT_DPAD0] = {
+ .possible_crtcs = BIT(1),
+ .port = 0,
+ },
+ [RCAR_DU_OUTPUT_LVDS0] = {
+ .possible_crtcs = BIT(0),
+ .port = 2,
+ },
+ },
+ .num_lvds = 1,
+ .num_rpf = 5,
+ .dpll_mask = BIT(1),
+};
+
static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7742", .data = &rcar_du_r8a7790_info },
{ .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info },
@@ -591,6 +615,7 @@ static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a779a0", .data = &rcar_du_r8a779a0_info },
{ .compatible = "renesas,du-r8a779g0", .data = &rcar_du_r8a779g0_info },
{ .compatible = "renesas,du-r8a779h0", .data = &rcar_du_r8a779h0_info },
+ { .compatible = "renesas,du-r8a779md", .data = &rcar_du_r8a779md_info },
{ }
};
--
2.53.0
^ permalink raw reply related
* [PATCH 1/7] dt-bindings: display: renesas,du: Document Renesas R-Car R8A779MD M3Le
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Extend the Renesas DU display bindings to support the Renesas R-Car
R8A779MD M3Le SoC. This SoC is similar to R-Car R8A77965 M3-N SoC,
except the HDMI port@1 is not present.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
.../bindings/display/renesas,du.yaml | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
index c27dfea7fc622..3c3667ff4a27f 100644
--- a/Documentation/devicetree/bindings/display/renesas,du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
@@ -42,6 +42,7 @@ properties:
- renesas,du-r8a779a0 # for R-Car V3U compatible DU
- renesas,du-r8a779g0 # for R-Car V4H compatible DU
- renesas,du-r8a779h0 # for R-Car V4M compatible DU
+ - renesas,du-r8a779md # for R-Car M3Le compatible DU
reg:
maxItems: 1
@@ -890,6 +891,75 @@ allOf:
- reset-names
- renesas,vsps
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - renesas,du-r8a779md
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ items:
+ - description: Functional clock for DU0
+ - description: Functional clock for DU1
+ - description: Functional clock for DU3
+ - description: DU_DOTCLKIN0 input clock
+ - description: DU_DOTCLKIN1 input clock
+ - description: DU_DOTCLKIN3 input clock
+
+ clock-names:
+ minItems: 3
+ items:
+ - const: du.0
+ - const: du.1
+ - const: du.3
+ - pattern: '^dclkin\.[013]$'
+ - pattern: '^dclkin\.[013]$'
+ - pattern: '^dclkin\.[013]$'
+
+ interrupts:
+ minItems: 3
+ maxItems: 3
+
+ resets:
+ minItems: 2
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: du.0
+ - const: du.3
+
+ ports:
+ properties:
+ port@0:
+ description: DPAD 0
+ port@1: false
+ port@2:
+ description: LVDS 0
+ port@3: false
+
+ required:
+ - port@0
+ - port@2
+
+ renesas,cmms:
+ minItems: 3
+ maxItems: 3
+
+ renesas,vsps:
+ minItems: 3
+ maxItems: 3
+
+ required:
+ - clock-names
+ - interrupts
+ - resets
+ - reset-names
+ - renesas,vsps
+
additionalProperties: false
examples:
--
2.53.0
^ permalink raw reply related
* [PATCH 3/7] dt-bindings: clock: cs2000-cp: document CS2500
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Document backward compatibility support for CS2500 chip, which
is a drop-in replacement for CS2000 chip.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
.../devicetree/bindings/clock/cirrus,cs2000-cp.yaml | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
index d416c374e8534..031c52b2e5cec 100644
--- a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
+++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml
@@ -11,14 +11,18 @@ maintainers:
description: |
The CS2000-CP is an extremely versatile system clocking device that
- utilizes a programmable phase lock loop.
+ utilizes a programmable phase lock loop. CP2500-CP is a compatible
+ drop-in replacement for CP2000-CP.
Link: https://www.cirrus.com/products/cs2000/
properties:
compatible:
- enum:
- - cirrus,cs2000-cp
+ oneOf:
+ - items:
+ - const: cirrus,cs2500-cp
+ - const: cirrus,cs2000-cp
+ - const: cirrus,cs2000-cp
clocks:
description:
--
2.53.0
^ permalink raw reply related
* [PATCH 4/7] dt-bindings: soc: renesas: Document Renesas R-Car R8A779MD Geist
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Document the compatible value for the Renesas R-Car M3Le (R8A779MD)
SoC and the Renesas Geist development board. The Renesas M3Le SoC is
a register-compatible variant of the R8A77965 (M3-N) with reduced set
of peripherals. The Geist board is derived from Renesas Salvator-X/XS
boards, with adjustment for the R8A779MD SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
Documentation/devicetree/bindings/soc/renesas/renesas.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
index 5c22c51b1533d..bda223237c812 100644
--- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml
@@ -473,6 +473,12 @@ properties:
- const: renesas,r8a779mb
- const: renesas,r8a7795
+ - description: R-Car M3Le (R8A779MD)
+ items:
+ - const: renesas,geist # M3Le Geist
+ - const: renesas,r8a779md
+ - const: renesas,r8a77965
+
- description: R-Car X5H (R8A78000)
items:
- enum:
--
2.53.0
^ permalink raw reply related
* [PATCH 5/7] soc: renesas: Identify Renesas R-Car R8A779MD M3Le SoC
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, David Airlie, Geert Uytterhoeven,
Kieran Bingham, Krzysztof Kozlowski, Kuninori Morimoto,
Laurent Pinchart, Magnus Damm, Maxime Ripard, Michael Turquette,
Rob Herring, Simona Vetter, Stephen Boyd, Thomas Zimmermann,
Tomi Valkeinen, devicetree, dri-devel, linux-clk, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
Add support for identifying the R-Car M3Le (R8A779MD) SoC.
The Renesas R-Car R8A779MD M3Le SoC is a variant of the
already supported R-Car M3-N SoC with reduced peripherals.
Enable support for the M3Le SoC through already existing
ARCH_R8A77965 configuration symbol. PRR reads 0x67c05501 .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
drivers/soc/renesas/renesas-soc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/renesas/renesas-soc.c b/drivers/soc/renesas/renesas-soc.c
index 38ff0b823bdaf..c82835cf6d8e9 100644
--- a/drivers/soc/renesas/renesas-soc.c
+++ b/drivers/soc/renesas/renesas-soc.c
@@ -361,6 +361,7 @@ static const struct of_device_id renesas_socs[] __initconst __maybe_unused = {
{ .compatible = "renesas,r8a77965", .data = &soc_rcar_m3_n },
{ .compatible = "renesas,r8a779m4", .data = &soc_rcar_m3_n },
{ .compatible = "renesas,r8a779m5", .data = &soc_rcar_m3_n },
+ { .compatible = "renesas,r8a779md", .data = &soc_rcar_m3_n },
#endif
#ifdef CONFIG_ARCH_R8A77970
{ .compatible = "renesas,r8a77970", .data = &soc_rcar_v3m },
--
2.53.0
^ permalink raw reply related
* [PATCH 6/7] arm64: dts: renesas: r8a779md: Add Renesas R-Car R8A779MD M3Le DTs
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Nguyen Tran, Marek Vasut, Conor Dooley, David Airlie,
Geert Uytterhoeven, Kieran Bingham, Krzysztof Kozlowski,
Kuninori Morimoto, Laurent Pinchart, Magnus Damm, Maxime Ripard,
Michael Turquette, Rob Herring, Simona Vetter, Stephen Boyd,
Thomas Zimmermann, Tomi Valkeinen, devicetree, dri-devel,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
From: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
Add support for the Renesas R-Car M3Le (R8A779MD) SoC, a variant of the
R-Car M3-N (R8A77965) SoC. The Renesas M3Le SoC is a register-compatible
variant of the R8A77965 (M3-N) with reduced set of peripherals.
Signed-off-by: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/r8a779md.dtsi | 48 +++++++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 arch/arm64/boot/dts/renesas/r8a779md.dtsi
diff --git a/arch/arm64/boot/dts/renesas/r8a779md.dtsi b/arch/arm64/boot/dts/renesas/r8a779md.dtsi
new file mode 100644
index 0000000000000..7e0f5fe4cd439
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a779md.dtsi
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Device Tree Source for the R-Car M3Le (R8A779MD) SoC
+ *
+ * Copyright (C) 2025-2026 Renesas Electronics Corp.
+ */
+
+#include "r8a77965.dtsi"
+
+/ {
+ compatible = "renesas,r8a779md", "renesas,r8a77965";
+};
+
+/delete-node/ &csi20;
+/delete-node/ &drif00;
+/delete-node/ &drif01;
+/delete-node/ &drif10;
+/delete-node/ &drif11;
+/delete-node/ &drif20;
+/delete-node/ &drif21;
+/delete-node/ &drif30;
+/delete-node/ &drif31;
+/delete-node/ &hdmi0;
+/delete-node/ &mlp;
+/delete-node/ &pciec1;
+/delete-node/ &sata;
+/delete-node/ &sdhi3;
+/delete-node/ &usb3_peri0;
+/delete-node/ &usb3_phy0;
+/delete-node/ &vin0csi20;
+/delete-node/ &vin1csi20;
+/delete-node/ &vin2csi20;
+/delete-node/ &vin3csi20;
+/delete-node/ &vin4csi20;
+/delete-node/ &vin5csi20;
+/delete-node/ &vin6csi20;
+/delete-node/ &vin7csi20;
+/delete-node/ &xhci0;
+
+&du {
+ compatible = "renesas,du-r8a779md";
+ renesas,cmms = <&cmm0>, <&cmm3>;
+ renesas,vsps = <&vspd0 0>, <&vspd1 0>;
+
+ ports {
+ /delete-node/ port@1;
+ };
+};
--
2.53.0
^ permalink raw reply related
* [PATCH 7/7] arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist
From: Marek Vasut @ 2026-04-19 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Nguyen Tran, Marek Vasut, Conor Dooley, David Airlie,
Geert Uytterhoeven, Kieran Bingham, Krzysztof Kozlowski,
Kuninori Morimoto, Laurent Pinchart, Magnus Damm, Maxime Ripard,
Michael Turquette, Rob Herring, Simona Vetter, Stephen Boyd,
Thomas Zimmermann, Tomi Valkeinen, devicetree, dri-devel,
linux-clk, linux-kernel, linux-renesas-soc
In-Reply-To: <20260419193718.133174-1-marek.vasut+renesas@mailbox.org>
From: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
Add support for the Geist board based on the Renesas R-Car R8A779MD (M3Le)
SoC, a register-compatible variant of the R8A77965 (M3-N) with reduced set
of peripherals. The Geist board design references the Renesas Salvator-X/XS
boards, adapting their configuration for the R8A779MD SoC.
Signed-off-by: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
arch/arm64/boot/dts/renesas/Makefile | 3 +
.../dts/renesas/geist-panel-aa104xd12.dtso | 17 +
.../arm64/boot/dts/renesas/r8a779md-geist.dts | 832 ++++++++++++++++++
3 files changed, 852 insertions(+)
create mode 100644 arch/arm64/boot/dts/renesas/geist-panel-aa104xd12.dtso
create mode 100644 arch/arm64/boot/dts/renesas/r8a779md-geist.dts
diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index ca45d2857ea7f..0b8fbc7b00c6e 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -60,6 +60,9 @@ r8a77965-salvator-xs-panel-aa104xd12-dtbs := r8a77965-salvator-xs.dtb salvator-p
dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-salvator-xs-panel-aa104xd12.dtb
dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb.dtb
dtb-$(CONFIG_ARCH_R8A77965) += r8a77965-ulcb-kf.dtb
+dtb-$(CONFIG_ARCH_R8A77965) += r8a779md-geist.dtb
+r8a779md-geist-panel-aa104xd12-dtbs := r8a779md-geist.dtb geist-panel-aa104xd12.dtbo
+dtb-$(CONFIG_ARCH_R8A77965) += r8a779md-geist-panel-aa104xd12.dtb
dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle.dtb
dtb-$(CONFIG_ARCH_R8A77970) += r8a77970-eagle-function-expansion.dtbo
diff --git a/arch/arm64/boot/dts/renesas/geist-panel-aa104xd12.dtso b/arch/arm64/boot/dts/renesas/geist-panel-aa104xd12.dtso
new file mode 100644
index 0000000000000..c8e39811eb051
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/geist-panel-aa104xd12.dtso
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree overlay for the AA104XD12 panel connected to LVDS0 on a Geist board
+ *
+ * Copyright 2026 Marek Vasut
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "salvator-panel-aa104xd12.dtso"
+
+&{/panel} {
+ data-mapping = "jeida-24";
+};
diff --git a/arch/arm64/boot/dts/renesas/r8a779md-geist.dts b/arch/arm64/boot/dts/renesas/r8a779md-geist.dts
new file mode 100644
index 0000000000000..1a25acf638ea1
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a779md-geist.dts
@@ -0,0 +1,832 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Device Tree Source for the Geist board with R-Car M3Le
+ *
+ * Copyright (C) 2025-2026 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "r8a779md.dtsi"
+
+/ {
+ model = "Renesas Geist board based on r8a779md";
+ compatible = "renesas,geist", "renesas,r8a779md", "renesas,r8a77965";
+
+ aliases {
+ serial0 = &scif2;
+ serial1 = &hscif1;
+ ethernet0 = &avb;
+ mmc0 = &sdhi2;
+ mmc1 = &sdhi0;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel rw root=/dev/nfs ip=on";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@48000000 {
+ device_type = "memory";
+ /* first 128MB is reserved for secure area. */
+ reg = <0x0 0x48000000 0x0 0x78000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* Device specific region for Lossy Decompression */
+ lossy_decompress: linux,lossy_decompress@54000000 {
+ no-map;
+ reg = <0x00000000 0x54000000 0x0 0x03000000>;
+ };
+ };
+
+ audio_clkout: audio-clkout {
+ /*
+ * FIXME
+ * This is same as <&rcar_sound 0>
+ * but needed to avoid cs2500/rcar_sound probe dead-lock
+ */
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12288000>;
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 50000>;
+
+ brightness-levels = <256 128 64 16 8 4 0>;
+ default-brightness-level = <6>;
+
+ power-supply = <®_12v>;
+ enable-gpios = <&gpio6 7 GPIO_ACTIVE_HIGH>;
+ };
+
+ cvbs-in {
+ compatible = "composite-video-connector";
+ label = "CVBS IN";
+
+ port {
+ cvbs_con: endpoint {
+ remote-endpoint = <&adv7482_ain7>;
+ };
+ };
+ };
+
+ hdmi-in {
+ compatible = "hdmi-connector";
+ label = "HDMI IN";
+ type = "a";
+
+ port {
+ hdmi_in_con: endpoint {
+ remote-endpoint = <&adv7482_hdmi>;
+ };
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&keys_pins>;
+ pinctrl-names = "default";
+
+ key-1 {
+ gpios = <&gpio5 17 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_1>;
+ label = "SW4-1";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-2 {
+ gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_2>;
+ label = "SW4-2";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-3 {
+ gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_3>;
+ label = "SW4-3";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-4 {
+ gpios = <&gpio5 23 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_4>;
+ label = "SW4-4";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-a {
+ gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_A>;
+ label = "TSW0";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-b {
+ gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_B>;
+ label = "TSW1";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+
+ key-c {
+ gpios = <&gpio6 13 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_C>;
+ label = "TSW2";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ };
+
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_12v: regulator2 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-12V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sound_card: sound {
+ compatible = "audio-graph-card";
+
+ label = "rcar-sound";
+ dais = <&rsnd_port0>; /* AK4619 Audio Codec */
+ };
+
+ vbus0_usb2: regulator-vbus0-usb2 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "USB20_VBUS0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+
+ gpio = <&gpio6 16 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vcc_sdhi0: regulator-vcc-sdhi0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI0 Vcc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi0: regulator-vccq-sdhi0 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI0 VccQ";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <3300000 1>, <1800000 0>;
+ };
+
+ vga {
+ compatible = "vga-connector";
+
+ port {
+ vga_in: endpoint {
+ remote-endpoint = <&adv7123_out>;
+ };
+ };
+ };
+
+ vga-encoder {
+ compatible = "adi,adv7123";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ adv7123_in: endpoint {
+ remote-endpoint = <&du_out_rgb>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ adv7123_out: endpoint {
+ remote-endpoint = <&vga_in>;
+ };
+ };
+ };
+ };
+
+ x12_clk: x12 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24576000>;
+ };
+
+ /* External DU dot clocks */
+ x21_clk: x21-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <33000000>;
+ };
+
+ x22_clk: x22-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <33000000>;
+ };
+
+ x23_clk: x23-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ x3013_clk: x3013-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+};
+
+&audio_clk_a {
+ clock-frequency = <22579200>;
+};
+
+&avb {
+ pinctrl-0 = <&avb_pins>;
+ pinctrl-names = "default";
+ phy-handle = <&phy0>;
+ tx-internal-delay-ps = <2000>;
+ status = "okay";
+
+ phy0: ethernet-phy@0 {
+ rxc-skew-ps = <1500>;
+ reg = <0>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <100>;
+ reset-deassert-us = <100>;
+ };
+};
+
+&csi40 {
+ status = "okay";
+
+ ports {
+ port@0 {
+ csi40_in: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&adv7482_txa>;
+ };
+ };
+ };
+};
+
+&du {
+ pinctrl-0 = <&du_pins>;
+ pinctrl-names = "default";
+ clocks = <&cpg CPG_MOD 724>,
+ <&cpg CPG_MOD 723>,
+ <&cpg CPG_MOD 721>,
+ <&versaclock5 1>,
+ <&x21_clk>,
+ <&versaclock5 2>;
+ clock-names = "du.0", "du.1", "du.3",
+ "dclkin.0", "dclkin.1", "dclkin.3";
+ status = "okay";
+
+ ports {
+ port@0 {
+ du_out_rgb: endpoint {
+ remote-endpoint = <&adv7123_in>;
+ };
+ };
+ };
+};
+
+&ehci0 {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&extalr_clk {
+ clock-frequency = <32768>;
+};
+
+&extal_clk {
+ clock-frequency = <16666666>;
+};
+
+&hscif1 {
+ pinctrl-0 = <&hscif1_pins>;
+ pinctrl-names = "default";
+
+ uart-has-rtscts;
+ /* Please only enable hscif1 or scif1 */
+ status = "okay";
+};
+
+&hsusb {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-0 = <&i2c2_pins>;
+ pinctrl-names = "default";
+ clock-frequency = <100000>;
+ status = "okay";
+
+ ak4619: codec@10 {
+ compatible = "asahi-kasei,ak4619";
+ reg = <0x10>;
+ clocks = <&rcar_sound 3>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+
+ port {
+ ak4619_endpoint: endpoint {
+ remote-endpoint = <&rsnd_endpoint0>;
+ };
+ };
+ };
+
+ /* Pin-to-pin, register map, and control compatible with CS2000 and CS2200 */
+ cs2500: clk_multiplier@4f {
+ #clock-cells = <0>;
+ compatible = "cirrus,cs2500-cp", "cirrus,cs2000-cp";
+ reg = <0x4f>;
+ clocks = <&audio_clkout>, <&x12_clk>;
+ clock-names = "clk_in", "ref_clk";
+
+ assigned-clocks = <&cs2500>;
+ assigned-clock-rates = <24576000>; /* 1/1 divide */
+ };
+};
+
+&i2c4 {
+ clock-frequency = <400000>;
+ status = "okay";
+
+ versaclock3: clock-generator@68 {
+ compatible = "renesas,5p35023";
+ reg = <0x68>;
+ #clock-cells = <1>;
+ clocks = <&x3013_clk>;
+ assigned-clocks = <&versaclock3 4>, <&versaclock3 5>;
+ assigned-clock-rates = <100000000>, <100000000>;
+ };
+
+ versaclock5: clock-generator@6a {
+ compatible = "idt,5p49v5923";
+ reg = <0x6a>;
+ #clock-cells = <1>;
+ clocks = <&x23_clk>;
+ clock-names = "xin";
+ };
+
+ video-receiver@70 {
+ compatible = "adi,adv7482";
+ reg = <0x70 0x71 0x72 0x73 0x74 0x75
+ 0x60 0x61 0x62 0x63 0x64 0x65>;
+ reg-names = "main", "dpll", "cp", "hdmi", "edid", "repeater",
+ "infoframe", "cbus", "cec", "sdp", "txa", "txb" ;
+
+ interrupt-parent = <&gpio6>;
+ interrupts = <30 IRQ_TYPE_LEVEL_LOW>,
+ <31 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "intrq1", "intrq2";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@7 {
+ reg = <7>;
+
+ adv7482_ain7: endpoint {
+ remote-endpoint = <&cvbs_con>;
+ };
+ };
+
+ port@8 {
+ reg = <8>;
+
+ adv7482_hdmi: endpoint {
+ remote-endpoint = <&hdmi_in_con>;
+ };
+ };
+
+ port@a {
+ reg = <10>;
+
+ adv7482_txa: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csi40_in>;
+ };
+ };
+ };
+ };
+
+ csa_vdd: adc@7c {
+ compatible = "maxim,max9611";
+ reg = <0x7c>;
+
+ shunt-resistor-micro-ohms = <5000>;
+ };
+
+ csa_dvfs: adc@7f {
+ compatible = "maxim,max9611";
+ reg = <0x7f>;
+
+ shunt-resistor-micro-ohms = <5000>;
+ };
+};
+
+&i2c_dvfs {
+ status = "okay";
+
+ clock-frequency = <400000>;
+
+ eeprom@50 {
+ compatible = "rohm,br24t01", "atmel,24c01";
+ reg = <0x50>;
+ pagesize = <8>;
+ };
+};
+
+&ohci0 {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&pcie_bus_clk {
+ status = "disabled";
+};
+
+&pciec0 {
+ clocks = <&cpg CPG_MOD 319>, <&versaclock3 4>;
+ status = "okay";
+};
+
+&pciec0_rp {
+ clocks = <&versaclock3 5>;
+};
+
+&pfc {
+ pinctrl-0 = <&scif_clk_pins>;
+ pinctrl-names = "default";
+
+ avb_pins: avb {
+ mux {
+ groups = "avb_link", "avb_mdio", "avb_mii";
+ function = "avb";
+ };
+
+ pins_mdio {
+ groups = "avb_mdio";
+ drive-strength = <24>;
+ };
+
+ pins_mii_tx {
+ pins = "PIN_AVB_TX_CTL", "PIN_AVB_TXC", "PIN_AVB_TD0",
+ "PIN_AVB_TD1", "PIN_AVB_TD2", "PIN_AVB_TD3";
+ drive-strength = <12>;
+ };
+ };
+
+ du_pins: du {
+ groups = "du_rgb888", "du_sync", "du_oddf", "du_clk_out_0";
+ function = "du";
+ };
+
+ hscif1_pins: hscif1 {
+ groups = "hscif1_data_a", "hscif1_ctrl_a";
+ function = "hscif1";
+ };
+
+ i2c2_pins: i2c2 {
+ groups = "i2c2_a";
+ function = "i2c2";
+ };
+
+ irq0_pins: irq0 {
+ groups = "intc_ex_irq0";
+ function = "intc_ex";
+ };
+
+ keys_pins: keys {
+ pins = "GP_5_17", "GP_5_20", "GP_5_22";
+ bias-pull-up;
+ };
+
+ pwm1_pins: pwm1 {
+ groups = "pwm1_a";
+ function = "pwm1";
+ };
+
+ pwm2_pins: pwm2 {
+ groups = "pwm2_a";
+ function = "pwm2";
+ };
+
+ scif1_pins: scif1 {
+ groups = "scif1_data_a", "scif1_ctrl";
+ function = "scif1";
+ };
+
+ scif2_pins: scif2 {
+ groups = "scif2_data_a";
+ function = "scif2";
+ };
+
+ scif_clk_pins: scif_clk {
+ groups = "scif_clk_a";
+ function = "scif_clk";
+ };
+
+ sdhi0_pins: sd0 {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
+ };
+
+ sdhi2_pins: sd2 {
+ groups = "sdhi2_data8", "sdhi2_ctrl", "sdhi2_ds";
+ function = "sdhi2";
+ power-source = <1800>;
+ };
+
+ sound_pins: sound {
+ groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data_a";
+ function = "ssi";
+ };
+
+ sound_clk_pins: sound_clk {
+ groups = "audio_clk_a_a", "audio_clk_b_a", "audio_clk_c_a",
+ "audio_clkout_a", "audio_clkout3_a";
+ function = "audio_clk";
+ };
+
+ usb0_pins: usb0 {
+ groups = "usb0";
+ function = "usb0";
+ };
+
+ usb1_pins: usb1 {
+ mux {
+ groups = "usb1";
+ function = "usb1";
+ };
+
+ ovc {
+ pins = "GP_6_27";
+ bias-pull-up;
+ };
+
+ pwen {
+ pins = "GP_6_26";
+ bias-pull-down;
+ };
+ };
+};
+
+&pwm1 {
+ pinctrl-0 = <&pwm1_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-0 = <&pwm2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&rcar_sound {
+ pinctrl-0 = <&sound_pins>, <&sound_clk_pins>;
+ pinctrl-names = "default";
+
+ /* Single DAI */
+ #sound-dai-cells = <0>;
+
+ /* audio_clkout0/1/2/3 */
+ #clock-cells = <1>;
+ clock-frequency = <12288000 11289600>;
+
+ status = "okay";
+
+ /* update <audio_clk_b> to <cs2500> */
+ clocks = <&cpg CPG_MOD 1005>,
+ <&cpg CPG_MOD 1006>, <&cpg CPG_MOD 1007>,
+ <&cpg CPG_MOD 1008>, <&cpg CPG_MOD 1009>,
+ <&cpg CPG_MOD 1010>, <&cpg CPG_MOD 1011>,
+ <&cpg CPG_MOD 1012>, <&cpg CPG_MOD 1013>,
+ <&cpg CPG_MOD 1014>, <&cpg CPG_MOD 1015>,
+ <&cpg CPG_MOD 1022>, <&cpg CPG_MOD 1023>,
+ <&cpg CPG_MOD 1024>, <&cpg CPG_MOD 1025>,
+ <&cpg CPG_MOD 1026>, <&cpg CPG_MOD 1027>,
+ <&cpg CPG_MOD 1028>, <&cpg CPG_MOD 1029>,
+ <&cpg CPG_MOD 1030>, <&cpg CPG_MOD 1031>,
+ <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+ <&cpg CPG_MOD 1020>, <&cpg CPG_MOD 1021>,
+ <&cpg CPG_MOD 1019>, <&cpg CPG_MOD 1018>,
+ <&audio_clk_a>, <&cs2500>,
+ <&audio_clk_c>,
+ <&cpg CPG_MOD 922>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rsnd_port0: port {
+ rsnd_endpoint0: endpoint {
+ remote-endpoint = <&ak4619_endpoint>;
+ dai-format = "left_j";
+ bitclock-master = <&rsnd_endpoint0>;
+ frame-master = <&rsnd_endpoint0>;
+ playback = <&ssi0>, <&src0>, <&dvc0>;
+ capture = <&ssi1>, <&src1>, <&dvc1>;
+ };
+ };
+ };
+};
+
+&rwdt {
+ timeout-sec = <60>;
+ status = "okay";
+};
+
+&scif1 {
+ pinctrl-0 = <&scif1_pins>;
+ pinctrl-names = "default";
+
+ uart-has-rtscts;
+ /* Please only enable hscif1 or scif1 */
+ /* status = "okay"; */
+};
+
+&scif2 {
+ pinctrl-0 = <&scif2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&scif_clk {
+ clock-frequency = <14745600>;
+};
+
+&sdhi0 {
+ pinctrl-0 = <&sdhi0_pins>;
+ pinctrl-1 = <&sdhi0_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <&vcc_sdhi0>;
+ vqmmc-supply = <&vccq_sdhi0>;
+ cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
+ bus-width = <4>;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
+
+&sdhi2 {
+ /* used for on-board 8bit eMMC */
+ pinctrl-0 = <&sdhi2_pins>;
+ pinctrl-1 = <&sdhi2_pins>;
+ pinctrl-names = "default", "state_uhs";
+
+ iommus = <&ipmmu_ds1 34>;
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ bus-width = <8>;
+ mmc-hs200-1_8v;
+ no-sd;
+ no-sdio;
+ non-removable;
+ fixed-emmc-driver-type = <1>;
+ full-pwr-cycle-in-suspend;
+ status = "okay";
+};
+
+&ssi1 {
+ shared-pin;
+};
+
+&usb_extal_clk {
+ clock-frequency = <50000000>;
+};
+
+&usb2_phy0 {
+ pinctrl-0 = <&usb0_pins>;
+ pinctrl-names = "default";
+
+ vbus-supply = <&vbus0_usb2>;
+ status = "okay";
+};
+
+&usb2_phy1 {
+ pinctrl-0 = <&usb1_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&vin0 {
+ status = "okay";
+};
+
+&vin1 {
+ status = "okay";
+};
+
+&vin2 {
+ status = "okay";
+};
+
+&vin3 {
+ status = "okay";
+};
+
+&vin4 {
+ status = "okay";
+};
+
+&vin5 {
+ status = "okay";
+};
+
+&vin6 {
+ status = "okay";
+};
+
+&vin7 {
+ status = "okay";
+};
+
+&vspb {
+ status = "okay";
+};
+
+&vspi0 {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* Re: Testing remoteproc on imx8mp-evk
From: Fabio Estevam @ 2026-04-19 19:53 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: NXP Linux Team,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAOMZO5CSzvBdgN5b5E0v0DB1FT4481pRTwoQJ9YzC8yMt81kmA@mail.gmail.com>
On Wed, Mar 25, 2026 at 10:48 PM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Peng,
>
> I'm trying to use remoteproc on an imx8mp-evk board running mainline
> U-Boot and the mainline kernel.
>
> Could you please share a simple Cortex-M7 .elf file I can use for
> testing? Even a simple Hello World will suffice.
>
> It would be helpful if we add an imx8mp-evk devicetree overlay that
> includes the described remoteproc nodes.
>
> Could you please share the remoteproc devicetree?
I used the remoteproc description as the one sent by Marek for
imx8mp-data-modul-edm-sbc-overlay-cm7.dtso:
https://lore.kernel.org/linux-arm-kernel/20260407211850.79881-4-marex@nabladev.com/
I had to manually build the hello_world_cm7 SDK example, and now it
loads successfully:
# cat /sys/class/remoteproc/remoteproc0/state
offline
# echo hello_world_cm7.elf > /sys/class/remoteproc/remoteproc0/firmware
# echo start > /sys/class/remoteproc/remoteproc0/state
# echo stop > /sys/class/remoteproc/remoteproc0/state
# dmesg | grep remoteproc
[ 0.197328] remoteproc remoteproc0: imx-rproc is available
[ 82.061452] remoteproc remoteproc0: powering up imx-rproc
[ 82.066846] remoteproc remoteproc0: Booting fw image
hello_world_cm7.elf, size 232592
[ 82.067105] remoteproc remoteproc0: remote processor imx-rproc is now up
[ 99.565501] remoteproc remoteproc0: stopped remote processor imx-rproc
^ permalink raw reply
* Re: [PATCH] watchdog: ixp4xx: fix reference leak on platform_device_register() failure
From: Linus Walleij @ 2026-04-19 20:22 UTC (permalink / raw)
To: Guangshuo Li
Cc: Imre Kaloz, Daniel Lezcano, Thomas Gleixner, Guenter Roeck,
linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260413154727.3051321-1-lgs201920130244@gmail.com>
Hi Guangshuo,
thanks for your patch!
On Mon, Apr 13, 2026 at 5:47 PM Guangshuo Li <lgs201920130244@gmail.com> wrote:
> ixp4xx_timer_probe() directly returns the result of
> platform_device_register(&ixp4xx_watchdog_device). When registration
> fails, the embedded struct device in ixp4xx_watchdog_device has already
> been initialized by device_initialize(), but the failure path does not
> drop the device reference, leading to a reference leak.
(...)
> - return platform_device_register(&ixp4xx_watchdog_device);
> + ret = platform_device_register(&ixp4xx_watchdog_device);
> + if (ret)
> + platform_device_put(&ixp4xx_watchdog_device);
If the problem in the description is indeed there, it seems the bug
is inside platform_device_register(), surely a function returning an
error code is supposed to clean up any resources it takes before
returning an error. It seems wrong to try to fix this in all the
consumers.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/4] Add hstimer support for H616 and T113-S3
From: Andre Przywara @ 2026-04-19 20:55 UTC (permalink / raw)
To: Michal Piekos
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard, linux-kernel, devicetree, linux-arm-kernel,
linux-sunxi
In-Reply-To: <20260419-h616-t113s-hstimer-v1-0-1af74ebef7c5@mmpsystems.pl>
On Sun, 19 Apr 2026 14:46:06 +0200
Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
Hi Michal,
> Add support for Allwinner H616 high speed timer in sun5i hstimer driver
> and describe corresponding nodes in dts for H616 and T113-S3.
>
> H616 uses same model as existing driver except register shift compared
> to older variants.
>
> Added register layout abstraction in the driver, extended the binding
> with new compatibles and wired up dts nodes for H616 and T113-S3 which
> uses H616 as fallback compatible.
Can you say *why* we need this? IIUC Linux only ever uses one clock
source, and selects the (non-optional) Generic Timer (aka arch timer)
for that? So can you say what this hstimer clock source adds? I guess
higher resolution, but what is your use case, so why would you need the
200 MHz? And does this offset the higher access cost of an MMIO
access, compared to the arch timer's sysreg based access? Also, IIUC,
people would need to manually select this as the clocksource, why and
when would they do so? (Given they even know about it in the first
place).
Also the hstimer hasn't been used since the A20, so nobody seemed to
have missed it meanwhile?
Cheers,
Andre
>
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
> Michal Piekos (4):
> dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
> clocksource/drivers/sun5i: add H616 hstimer support
> arm64: dts: allwinner: h616: add hstimer node
> arm: dts: allwinner: t113s: add hstimer node
>
> .../timer/allwinner,sun5i-a13-hstimer.yaml | 8 +++-
> arch/arm/boot/dts/allwinner/sun8i-t113s.dtsi | 12 +++++
> arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi | 9 ++++
> drivers/clocksource/timer-sun5i.c | 56 +++++++++++++++++++---
> 4 files changed, 78 insertions(+), 7 deletions(-)
> ---
> base-commit: faeab166167f5787719eb8683661fd41a3bb1514
> change-id: 20260413-h616-t113s-hstimer-62939948f91c
>
> Best regards,
^ permalink raw reply
* Re: [PATCH] watchdog: ixp4xx: fix reference leak on platform_device_register() failure
From: Guenter Roeck @ 2026-04-19 21:07 UTC (permalink / raw)
To: Linus Walleij, Guangshuo Li
Cc: Imre Kaloz, Daniel Lezcano, Thomas Gleixner, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <CAD++jLnC5MGg1e_Suv6BD_=XKbsn1aLxHxRfCdD3Nos+2XRzfw@mail.gmail.com>
On 4/19/26 13:22, Linus Walleij wrote:
> Hi Guangshuo,
>
> thanks for your patch!
>
> On Mon, Apr 13, 2026 at 5:47 PM Guangshuo Li <lgs201920130244@gmail.com> wrote:
>
>> ixp4xx_timer_probe() directly returns the result of
>> platform_device_register(&ixp4xx_watchdog_device). When registration
>> fails, the embedded struct device in ixp4xx_watchdog_device has already
>> been initialized by device_initialize(), but the failure path does not
>> drop the device reference, leading to a reference leak.
> (...)
>
>> - return platform_device_register(&ixp4xx_watchdog_device);
>> + ret = platform_device_register(&ixp4xx_watchdog_device);
>> + if (ret)
>> + platform_device_put(&ixp4xx_watchdog_device);
>
> If the problem in the description is indeed there, it seems the bug
> is inside platform_device_register(), surely a function returning an
> error code is supposed to clean up any resources it takes before
> returning an error. It seems wrong to try to fix this in all the
> consumers.
>
From platform_device_register():
/**
* platform_device_register - add a platform-level device
* @pdev: platform device we're adding
*
* NOTE: _Never_ directly free @pdev after calling this function, even if it
* returned an error! Always use platform_device_put() to give up the
* reference initialised in this function instead.
*/
Not that any code actually does that as far as I can see, but isn't
the above doing exactly what the comment suggests ?
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 3/4] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Linus Walleij @ 2026-04-19 21:19 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君], Michael Walle
Cc: Bartosz Golaszewski, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰], robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
TY_Chang[張子逸]
In-Reply-To: <52bf9ce2b7754af8af69b0afee0d07b2@realtek.com>
Hi Yu-Chun,
On Fri, Apr 10, 2026 at 11:39 AM Yu-Chun Lin [林祐君]
<eleanor.lin@realtek.com> wrote:
> We did look into gpio-mmio and gpio-regmap, but they are not quite suitable for
> our platform due to the specific hardware design:
>
> 1. Per-GPIO Dedicated Registers: Unlike typical GPIO controllers that pack 32 pins
> into a single 32-bit register (1 bit per pin), our hardware uses a dedicated 32-bit
> register for each individual GPIO. This single register controls the
> input/output state, direction, and interrupt trigger type for that specific pin.
Isn't that attainable by:
- setting .ngpio_per_reg to 1 in struct gpio_regmap_config
- extend .reg_mask_xlate callback with an enum for each operation
(need to change all users of the .reg_mask_xlate callback but
who cares, they are not many):
e.g.
enum gpio_regmap_operation {
GPIO_REGMAP_GET_OP,
GPIO_REGMAP_SET_OP,
GPIO_REGMAP_SET_WITH_CLEAR_OP,
GPIO_REGMAP_GET_DIR_OP,
GPIO_REGMAP_SET_DIR_OP,
};
int (*reg_mask_xlate)(struct gpio_regmap *gpio,
enum_gpio_regmap_operation op,
unsigned int base,
unsigned int offset, unsigned int *reg,
unsigned int *mask);
This way .reg_mask_xlate() can hit different bits in the returned
*mask depending on operation and it will be find to pack all of
the bits into one 32bit register.
Added Michael Walle to the the thread, he will know if this is a
good idea.
> 2. Write-Enable (WREN) Mask Mechanism: Our hardware requires a specific Write-Enable
> mask to be written simultaneously when updating the register values.
Which is to just set bit 31.
With the above scheme your .reg_mask_xlate callback can just set bit 31
no matter what operating you're doing. Piece of cake.
> 3. Hardware Debounce: We also need to support hardware debounce settings per pin,
> which requires custom configuration via set_config mapped to these specific per-pin
> registers.
Just add a version of an optional .set_config() call to gpio-regmap.c
to handle this using .reg_mask_xlate() per above and add a new
GPIO_REGMAP_CONFIG_OP to the above enum, problem solved.
If it seems too hard I can write patch 1 & 2 adding this infrastructure
but I bet you can easily see what can be done with gpio-regmap.c
here provided Michael W approves the idea.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: timer: allwinner,sun5i-a13-hstimer: add H616 and T113-S3
From: Andre Przywara @ 2026-04-19 21:21 UTC (permalink / raw)
To: Michal Piekos
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard, linux-kernel, devicetree, linux-arm-kernel,
linux-sunxi
In-Reply-To: <20260419-h616-t113s-hstimer-v1-1-1af74ebef7c5@mmpsystems.pl>
On Sun, 19 Apr 2026 14:46:07 +0200
Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
> H616 is compatible with the existing sun5i binding, but
> require its own compatible string to differentiate register offsets.
Just a nit: if the register offsets are different, then it's not
compatible, not even with the binding. So just say something like "they
are similar, but with different register offsets".
> T113-S3 uses same offsets as H616.
So it looks like (somewhat naturally) this is true for D1 as well? And
since that SoC was the first, we use "sun20i-d1" as the compatible
string prefix for this SoC's devices. I think we should follow suit
here and name that similarly.
>
> Add allwinner,sun50i-h616-hstimer
> Add allwinner,sun8i-t113s-hstimer with fallback to
> allwinner,sun50i-h616-hstimer
> Extend schema condition for interrupts to cover H616 compatible variant.
>
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
> .../devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
> index f1853daec2f9..bb60a85dc34b 100644
> --- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
> +++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml
> @@ -15,9 +15,13 @@ properties:
> oneOf:
> - const: allwinner,sun5i-a13-hstimer
> - const: allwinner,sun7i-a20-hstimer
> + - const: allwinner,sun50i-h616-hstimer
> - items:
> - const: allwinner,sun6i-a31-hstimer
> - const: allwinner,sun7i-a20-hstimer
> + - items:
> + - const: allwinner,sun8i-t113s-hstimer
> + - const: allwinner,sun50i-h616-hstimer
>
> reg:
> maxItems: 1
> @@ -45,7 +49,9 @@ required:
> if:
> properties:
> compatible:
> - const: allwinner,sun5i-a13-hstimer
> + enum:
> + - allwinner,sun5i-a13-hstimer
> + - allwinner,sun50i-h616-hstimer
IIUC this just matches the H616, but wouldn't match the T113/D1? And
there is some construct with "contains" to match for fallback
compatibles?
Cheers,
Andre
>
> then:
> properties:
>
^ permalink raw reply
* Re: [PATCH] pinctrl: mediatek: moore: implement gpio_chip::get_direction()
From: Linus Walleij @ 2026-04-19 21:25 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Frank Wunderlich, bartosz.golaszewski, linux, sean.wang,
matthias.bgg, angelogioacchino.delregno, brgl, linux-mediatek,
linux-gpio, linux-kernel, linux-arm-kernel
In-Reply-To: <dc46f7d784281642aad6d47e79a3e91652eec667@linux.dev>
On Mon, Apr 13, 2026 at 6:59 PM Frank Wunderlich
<frank.wunderlich@linux.dev> wrote:
> Am 13. April 2026 um 10:01 schrieb "Linus Walleij" <linusw@kernel.org mailto:linusw@kernel.org?to=%22Linus%20Walleij%22%20%3Clinusw%40kernel.org%3E >:
> >
> > On Fri, Apr 10, 2026 at 11:24 AM Frank Wunderlich
> > <frank-w@public-files.de> wrote:
> >
> > >
> > > Gesendet: Freitag, 10. April 2026 um 09:09
> > > Von: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
> > > An: "Frank Wunderlich" <linux@fw-web.de>, "Sean Wang" <sean.wang@kernel.org>, "Linus Walleij" <linusw@kernel.org>, "Matthias Brugger" <matthias.bgg@gmail.com>, "AngeloGioacchino Del Regno" <angelogioacchino.delregno@collabora.com>, "Bartosz Golaszewski" <brgl@kernel.org>
> > > CC: linux-mediatek@lists.infradead.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
> > > Betreff: [PATCH] pinctrl: mediatek: moore: implement gpio_chip::get_direction()
> > >
> > > If the gpio_chip::get_direction() callback is not implemented by the GPIO
> > > controller driver, GPIOLIB emits a warning.
> > >
> > > Implement get_direction() for the GPIO part of pinctrl-moore.
> > >
> > > Fixes: 471e998c0e31 ("gpiolib: remove redundant callback check")
> > > Fixes: e623c4303ed1 ("gpiolib: sanitize the return value of gpio_chip::get_direction()")
> > > Reported-by: Frank Wunderlich <linux@fw-web.de>
> > >
> > > please use the email i used for SoB in my linked patch (closes link below), the other email i use only for sending patches due to mail provider limitation.
> > >
> > I can't fix this up because the closes link isn't working right now.
> > Is it the same
> > as the one this mail came from frank-w@public-files.de?
>
> yes, closes-link works for me
Fixed up and applied. Will be going in as fix for v7.1.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] watchdog: ixp4xx: fix reference leak on platform_device_register() failure
From: Linus Walleij @ 2026-04-19 21:34 UTC (permalink / raw)
To: Guenter Roeck
Cc: Guangshuo Li, Imre Kaloz, Daniel Lezcano, Thomas Gleixner,
linux-arm-kernel, linux-kernel, stable
In-Reply-To: <aa801626-2e33-489a-931f-600540fe4ae3@roeck-us.net>
On Sun, Apr 19, 2026 at 11:08 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On 4/19/26 13:22, Linus Walleij wrote:
> > Hi Guangshuo,
> >
> > thanks for your patch!
> >
> > On Mon, Apr 13, 2026 at 5:47 PM Guangshuo Li <lgs201920130244@gmail.com> wrote:
> >
> >> ixp4xx_timer_probe() directly returns the result of
> >> platform_device_register(&ixp4xx_watchdog_device). When registration
> >> fails, the embedded struct device in ixp4xx_watchdog_device has already
> >> been initialized by device_initialize(), but the failure path does not
> >> drop the device reference, leading to a reference leak.
> > (...)
> >
> >> - return platform_device_register(&ixp4xx_watchdog_device);
> >> + ret = platform_device_register(&ixp4xx_watchdog_device);
> >> + if (ret)
> >> + platform_device_put(&ixp4xx_watchdog_device);
> >
> > If the problem in the description is indeed there, it seems the bug
> > is inside platform_device_register(), surely a function returning an
> > error code is supposed to clean up any resources it takes before
> > returning an error. It seems wrong to try to fix this in all the
> > consumers.
> >
>
> From platform_device_register():
>
> /**
> * platform_device_register - add a platform-level device
> * @pdev: platform device we're adding
> *
> * NOTE: _Never_ directly free @pdev after calling this function, even if it
> * returned an error! Always use platform_device_put() to give up the
> * reference initialised in this function instead.
> */
>
> Not that any code actually does that as far as I can see, but isn't
> the above doing exactly what the comment suggests ?
Yeah and Johan Hovold wrote that comment and he usually knows
what he's doing so let's go with this then, I'm convinced!
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] gpio: rockchip: Fix GPIO after convert to dynamic base allocation
From: Linus Walleij @ 2026-04-19 21:42 UTC (permalink / raw)
To: Jonas Karlman
Cc: Bartosz Golaszewski, Heiko Stuebner, Shawn Lin,
Bartosz Golaszewski, linux-gpio, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260416154928.2103388-1-jonas@kwiboo.se>
Thanks for fixing this Jonas,
this also uses the function in the right way: instead of using
gc->base which just happened to match the pin base it passes
bank->pin_base which makes a lot of sense.
(My original response mail was a bit whimsical because I
didn't realize the offset passed as argument 1 is local and not
global.... but you figured that out.)
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Andrey Konovalov @ 2026-04-19 21:48 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CAADnVQKv5y+gq=TnOAEXSqgBRpmHNjwqCfxpLaw5XkcbQ+23bg@mail.gmail.com>
On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> I think we're talking past each other.
> We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS.
> We're not going to modify arm64 JIT at all.
>
> This is purely KASAN_GENRIC and only on x86-64.
> JIT will emit exactly what compilers emit for generic
> which is __asan_load/store. This is as stable ABI as it can get
> and we don't want to deviate from it.
OK, I supposed that's fair. You did throw me off point with your
performance comment. But if you decide to add SW_TAGS support at some
point, I think this discussion needs to be revisited.
But please add a comment saying that those functions are only exposed
for BPF JIT and they are not supposed to be used by other parts of the
kernel. And in case you do end up adding a new config option, guard
the public declarations by a corresponding ifdef.
> The goal here is to find bugs in the verifier.
> If something got past it, that shouldn't have,
> kasan generic on x86-64 is enough.
FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code.
^ permalink raw reply
* [PATCH] rtc: ab8500: replace sprintf() with sysfs_emit()
From: Maxwell Doose @ 2026-04-19 22:36 UTC (permalink / raw)
To: linusw, alexandre.belloni; +Cc: linux-arm-kernel, linux-rtc, linux-kernel
This patch replaces sprintf() with sysfs_emit() to ensure proper
bounds checking. It also simplifies the return logic by directly
returning the error after logging, instead of logging, calling
sprintf(), then returning.
Signed-off-by: Maxwell Doose <m32285159@gmail.com>
---
drivers/rtc/rtc-ab8500.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ab8500.c b/drivers/rtc/rtc-ab8500.c
index ed2b6b8bb3bf..c6147837f957 100644
--- a/drivers/rtc/rtc-ab8500.c
+++ b/drivers/rtc/rtc-ab8500.c
@@ -284,11 +284,10 @@ static ssize_t ab8500_sysfs_show_rtc_calibration(struct device *dev,
retval = ab8500_rtc_get_calibration(dev, &calibration);
if (retval < 0) {
dev_err(dev, "Failed to read RTC calibration attribute\n");
- sprintf(buf, "0\n");
return retval;
}
- return sprintf(buf, "%d\n", calibration);
+ return sysfs_emit(buf, "%d\n", calibration);
}
static DEVICE_ATTR(rtc_calibration, S_IRUGO | S_IWUSR,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/4] clocksource/drivers/sun5i: add H616 hstimer support
From: Andre Przywara @ 2026-04-19 22:39 UTC (permalink / raw)
To: Michal Piekos
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Maxime Ripard, linux-kernel, devicetree, linux-arm-kernel,
linux-sunxi
In-Reply-To: <20260419-h616-t113s-hstimer-v1-2-1af74ebef7c5@mmpsystems.pl>
On Sun, 19 Apr 2026 14:46:08 +0200
Michal Piekos <michal.piekos@mmpsystems.pl> wrote:
Hi,
> H616 high speed timer differs from existing timer-sun5i by register base
> offset.
>
> Add selectable register layout structures.
> Add H616 compatible string to OF match table.
>
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
> drivers/clocksource/timer-sun5i.c | 56 ++++++++++++++++++++++++++++++++++-----
> 1 file changed, 50 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/clocksource/timer-sun5i.c b/drivers/clocksource/timer-sun5i.c
> index f827d3f98f60..125abc11c3c3 100644
> --- a/drivers/clocksource/timer-sun5i.c
> +++ b/drivers/clocksource/timer-sun5i.c
> @@ -21,18 +21,52 @@
> #define TIMER_IRQ_EN_REG 0x00
> #define TIMER_IRQ_EN(val) BIT(val)
> #define TIMER_IRQ_ST_REG 0x04
> -#define TIMER_CTL_REG(val) (0x20 * (val) + 0x10)
> #define TIMER_CTL_ENABLE BIT(0)
> #define TIMER_CTL_RELOAD BIT(1)
> -#define TIMER_CTL_CLK_PRES(val) (((val) & 0x7) << 4)
> #define TIMER_CTL_ONESHOT BIT(7)
> -#define TIMER_INTVAL_LO_REG(val) (0x20 * (val) + 0x14)
> -#define TIMER_INTVAL_HI_REG(val) (0x20 * (val) + 0x18)
> -#define TIMER_CNTVAL_LO_REG(val) (0x20 * (val) + 0x1c)
> -#define TIMER_CNTVAL_HI_REG(val) (0x20 * (val) + 0x20)
> +#define TIMER_CTL_CLK_PRES(val) (((val) & 0x7) << 4)
> +#define TIMER_CTL_REG(val) \
> + (soc_base->stride * (val) + soc_base->ctl_base)
> +#define TIMER_INTVAL_LO_REG(val) \
> + (soc_base->stride * (val) + soc_base->intval_lo_base)
> +#define TIMER_INTVAL_HI_REG(val) \
> + (soc_base->stride * (val) + soc_base->intval_hi_base)
> +#define TIMER_CNTVAL_LO_REG(val) \
> + (soc_base->stride * (val) + soc_base->cntval_lo_base)
> +#define TIMER_CNTVAL_HI_REG(val) \
> + (soc_base->stride * (val) + soc_base->cntval_hi_base)
>
> #define TIMER_SYNC_TICKS 3
>
> +struct sunxi_timer_base {
> + u32 ctl_base;
> + u32 intval_lo_base;
> + u32 intval_hi_base;
> + u32 cntval_lo_base;
> + u32 cntval_hi_base;
> + u32 stride;
> +};
> +
> +static const struct sunxi_timer_base sun5i_base = {
> + .ctl_base = 0x10,
> + .intval_lo_base = 0x14,
> + .intval_hi_base = 0x18,
> + .cntval_lo_base = 0x1c,
> + .cntval_hi_base = 0x20,
Mmmh, why all these members? Aren't those all the same, just offset by
0x10? So we just need a single value reg_offs, being either 0x0 or 0x10?
> + .stride = 0x20
What it this about? It's the same stride for both versions, so why is
this a field?
> +};
> +
> +static const struct sunxi_timer_base sun50i_base = {
> + .ctl_base = 0x20,
> + .intval_lo_base = 0x24,
> + .intval_hi_base = 0x28,
> + .cntval_lo_base = 0x2c,
> + .cntval_hi_base = 0x30,
> + .stride = 0x20
> +};
> +
> +static const struct sunxi_timer_base *soc_base;
This doesn't look right. Differentiating between slightly different
hardware revision via the compatible string is a common pattern, look
at for instance drivers/media/rc/sunxi-cir.c and its usage of quirks for
an example how to handle this more nicely.
Cheers,
Andre
> +
> struct sun5i_timer {
> void __iomem *base;
> struct clk *clk;
> @@ -238,6 +272,7 @@ static int sun5i_setup_clockevent(struct platform_device *pdev,
> static int sun5i_timer_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> + struct device_node *node = dev_of_node(&pdev->dev);
> struct sun5i_timer *st;
> struct reset_control *rstc;
> void __iomem *timer_base;
> @@ -251,6 +286,14 @@ static int sun5i_timer_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, st);
>
> + if (!node)
> + return -EINVAL;
> +
> + if (of_device_is_compatible(node, "allwinner,sun50i-h616-hstimer"))
> + soc_base = &sun50i_base;
> + else
> + soc_base = &sun5i_base;
> +
> timer_base = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(timer_base)) {
> dev_err(dev, "Can't map registers\n");
> @@ -314,6 +357,7 @@ static void sun5i_timer_remove(struct platform_device *pdev)
> static const struct of_device_id sun5i_timer_of_match[] = {
> { .compatible = "allwinner,sun5i-a13-hstimer" },
> { .compatible = "allwinner,sun7i-a20-hstimer" },
> + { .compatible = "allwinner,sun50i-h616-hstimer" },
> {},
> };
> MODULE_DEVICE_TABLE(of, sun5i_timer_of_match);
>
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Alexei Starovoitov @ 2026-04-19 22:51 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Yonghong Song, Jiri Olsa,
John Fastabend, David S. Miller, David Ahern, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, X86 ML, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, LKML, Network Development,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32,
linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <CA+fCnZe-b0Qqbo5gGv3HN20twquQETDfYYkE1r9tPr9zUFbW9Q@mail.gmail.com>
On Sun, Apr 19, 2026 at 2:49 PM Andrey Konovalov <andreyknvl@gmail.com> wrote:
>
> On Tue, Apr 14, 2026 at 5:58 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > I think we're talking past each other.
> > We're not interested in KASAN_SW_TAGS or KASAN_HW_TAGS.
> > We're not going to modify arm64 JIT at all.
> >
> > This is purely KASAN_GENRIC and only on x86-64.
> > JIT will emit exactly what compilers emit for generic
> > which is __asan_load/store. This is as stable ABI as it can get
> > and we don't want to deviate from it.
>
> OK, I supposed that's fair. You did throw me off point with your
> performance comment. But if you decide to add SW_TAGS support at some
> point, I think this discussion needs to be revisited.
>
> But please add a comment saying that those functions are only exposed
> for BPF JIT and they are not supposed to be used by other parts of the
> kernel. And in case you do end up adding a new config option, guard
> the public declarations by a corresponding ifdef.
I feel concerns of misuse are overblown.
Being in include/linux/kasan.h doesn't make them free-for-all
all of a sudden, but if you prefer we can just copy paste:
+void __asan_load1(void *p);
+void __asan_store1(void *p);
into bpf_jit_comp.c
> > The goal here is to find bugs in the verifier.
> > If something got past it, that shouldn't have,
> > kasan generic on x86-64 is enough.
>
> FWIW, I suspect HW_TAGS KASAN already just works with JITed BPF code.
Ohh. Good point. Looks like modern arm64 cpus in public clouds
don't have that enabled, so one would need pixel phone to
catch verifier bugs via hw_tags.
So we still need this x86-specific jit kasan.
I guess eventually it can be removed when hw_tags support is widespread.
^ permalink raw reply
* Re: [PATCH RFC v2 02/11] ASoC: meson: aiu-encoder-i2s: use gx_iface and gx_stream structures
From: Valerio Setti @ 2026-04-19 23:17 UTC (permalink / raw)
To: Jerome Brunet
Cc: Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Neil Armstrong, Kevin Hilman, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-sound,
linux-arm-kernel, linux-amlogic, devicetree
In-Reply-To: <1jy0ios3f9.fsf@starbuckisacylon.baylibre.com>
On 4/15/26 16:28, Jerome Brunet wrote:
>
> Huh interresting, I had not thought of that. Valerio and I discussed the
> clock part a lot for this rework. It is the crux since since the
> interface and clock setting lives in the AIU subsys but serves both the
> AIU and AUDIN subsys.
>
> Valerio maybe you could keep function above just to set the rate, but
> enabling the clocks through a DAPM supply widget ? This is kind of what
> the AXG is doing.
>
> what do you think ?
>
> (actually in the AXG the each formatter widget call CCF
> clk_prepare_enable() but a supply widget poking the register would do
> the same thing)
>
Hi Jerome,
thanks for your review and suggestion.
I took some time to investigate it and I think I have a different
proposal that reduces the amount of changes compared to the current
implementation, but gets to the same result.
The thing is in "axg-tdm-interface.c" MCLK is enabled/disabled using
"set_bias_level()" callback which works fine because in that case the
interface driver is also a standalone component. On the GX platform the
interface is a DAI which is part of the AIU component, so this callback
isn't available. To get the same behavior I would need to add a new DAPM
widget in "aiu_cpu_dapm_widgets[]" and then add it to both
"aiu_cpu_dapm_routes[]" both in "aiu.c" and in the device-tree for AUDIN.
What if instead I add the "prepare()" callback to
"aiu_encoder_i2s_dai_ops" and enable MCLK and I2S clock divider there?
This would match "hw_free()" calls and it would be a change only
internal to "aiu-encoder-i2s.c".
To support this I will:
- remove calls to "gx_stream_set_cont_clocks" which are arguably not
very useful for the GX platform;
- use the "clk_enabled" field of "struct gx_stream" (unused after
removal of "gx_stream_set_cont_clocks" calls) to track the status of
MCLK and enable/disable it only when necessary (ex: prevent multiple
calls to "prepare" to enable MCLK multiple times, etc);
- keep using "snd_soc_dai_active" in "hw_free" to know when to disable
the I2S clock divider. Or perhaps I can rely on "clk_enabled" also for
this one so that I can manage these 2 clocks uniformly.
Is this an acceptable alternative approach for you?
--
Valerio
^ permalink raw reply
* [PATCH v2 1/9] ASoC: dt-bindings: mt2701-afe-pcm: add HDMI audio path clocks
From: Daniel Golle @ 2026-04-20 1:13 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Arnd Bergmann, Cyril Chao,
Daniel Golle, Nícolas F. R. A. Prado, Kuninori Morimoto,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1776646435.git.daniel@makrotopia.org>
Document four additional optional clocks feeding the HDMI audio
output path on MT2701: the HADDS2 PLL (root of the HDMI audio
clock tree), the HDMI audio and S/PDIF interface power gates,
and the audio APLL root gate. Older device trees that do not
wire these up remain valid via minItems. MT7622 does not have
HDMI audio hardware, so its compatible is restricted to the
base set of 34 clocks.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v2:
* Restrict the four HDMI clocks to mediatek,mt2701-audio only
using an allOf/if/then conditional; MT7622 is capped at 34
clocks (Krzysztof Kozlowski)
.../bindings/sound/mediatek,mt2701-audio.yaml | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
index 45382c4d86aa3..871bf197650b5 100644
--- a/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
@@ -32,6 +32,7 @@ properties:
maxItems: 1
clocks:
+ minItems: 34
items:
- description: audio infra sys clock
- description: top audio mux 1
@@ -67,8 +68,13 @@ properties:
- description: top audio a1 sys pd
- description: top audio a2 sys pd
- description: audio merge interface pd
+ - description: HADDS2 PLL 294 MHz (HDMI audio path root)
+ - description: HDMI audio interface pd
+ - description: S/PDIF interface pd
+ - description: audio APLL root pd
clock-names:
+ minItems: 34
items:
- const: infra_sys_audio_clk
- const: top_audio_mux1_sel
@@ -104,6 +110,10 @@ properties:
- const: audio_a1sys_pd
- const: audio_a2sys_pd
- const: audio_mrgif_pd
+ - const: hadds2pll_294m
+ - const: audio_hdmi_pd
+ - const: audio_spdf_pd
+ - const: audio_apll_pd
required:
- compatible
@@ -114,3 +124,16 @@ required:
- clock-names
additionalProperties: false
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt7622-audio
+ then:
+ properties:
+ clocks:
+ maxItems: 34
+ clock-names:
+ maxItems: 34
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/9] ASoC: dt-bindings: mediatek,mt2701-hdmi-audio: add MT2701 HDMI audio
From: Daniel Golle @ 2026-04-20 1:13 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Arnd Bergmann, Cyril Chao,
Daniel Golle, Nícolas F. R. A. Prado, Kuninori Morimoto,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1776646435.git.daniel@makrotopia.org>
Describe the sound card node that routes the MT2701/MT7623N AFE
HDMI playback path to the on-chip HDMI transmitter. This is
separate from the AFE platform binding (mediatek,mt2701-audio)
because it represents board-level audio routing between the AFE
and the HDMI codec, not an additional IP block. MT7623N boards
carry the same IP and use the mt7623n- compatible as a fallback
to mt2701-.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v2:
* Fix subject prefix to use schema filename (Krzysztof Kozlowski)
* Rewrite title and description to describe hardware, not driver
(Krzysztof Kozlowski)
* Clarify in commit message why this is a separate binding from
mediatek,mt2701-audio (Krzysztof Kozlowski)
.../sound/mediatek,mt2701-hdmi-audio.yaml | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
new file mode 100644
index 0000000000000..9d5a8166e51ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt2701-hdmi-audio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT2701/MT7623N HDMI audio output
+
+maintainers:
+ - Daniel Golle <daniel@makrotopia.org>
+
+description:
+ Sound card routing the MT2701/MT7623N Audio Front End HDMI
+ playback path to the on-chip HDMI transmitter. The AFE
+ provides the DMA memif and internal I2S engine; the HDMI
+ transmitter acts as the audio codec on the serialised link.
+
+properties:
+ compatible:
+ oneOf:
+ - const: mediatek,mt2701-hdmi-audio
+ - items:
+ - const: mediatek,mt7623n-hdmi-audio
+ - const: mediatek,mt2701-hdmi-audio
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle of the MT2701/MT7623N AFE platform node.
+
+ mediatek,audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle of the HDMI transmitter acting as audio codec.
+
+required:
+ - compatible
+ - mediatek,platform
+ - mediatek,audio-codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound-hdmi {
+ compatible = "mediatek,mt7623n-hdmi-audio",
+ "mediatek,mt2701-hdmi-audio";
+ mediatek,platform = <&afe>;
+ mediatek,audio-codec = <&hdmi0>;
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH v2 3/9] ASoC: mediatek: mt2701: add AFE HDMI register definitions
From: Daniel Golle @ 2026-04-20 1:13 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Arnd Bergmann, Cyril Chao,
Daniel Golle, Nícolas F. R. A. Prado, Kuninori Morimoto,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1776646435.git.daniel@makrotopia.org>
Add register offsets and bit defines for the MT2701/MT7623N AFE
HDMI audio output path: the HDMI BCK divider in AUDIO_TOP_CON3,
the HDMI output memif control and descriptor registers, the 8-bit
AFE_HDMI_CONN0 interconnect, and the AFE_8CH_I2S_OUT_CON engine
that drives the HDMI TX serial link. These are a prerequisite for
adding an HDMI playback path to the mt2701 AFE driver and have no
behavioural effect on their own.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
v2: no changes
sound/soc/mediatek/mt2701/mt2701-reg.h | 35 ++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/sound/soc/mediatek/mt2701/mt2701-reg.h b/sound/soc/mediatek/mt2701/mt2701-reg.h
index c84d14cdd7ae8..b7a25bfb58662 100644
--- a/sound/soc/mediatek/mt2701/mt2701-reg.h
+++ b/sound/soc/mediatek/mt2701/mt2701-reg.h
@@ -10,10 +10,17 @@
#define _MT2701_REG_H_
#define AUDIO_TOP_CON0 0x0000
+#define AUDIO_TOP_CON3 0x000c
#define AUDIO_TOP_CON4 0x0010
#define AUDIO_TOP_CON5 0x0014
#define AFE_DAIBT_CON0 0x001c
#define AFE_MRGIF_CON 0x003c
+#define AFE_HDMI_OUT_CON0 0x0370
+#define AFE_HDMI_OUT_BASE 0x0374
+#define AFE_HDMI_OUT_CUR 0x0378
+#define AFE_HDMI_OUT_END 0x037c
+#define AFE_HDMI_CONN0 0x0390
+#define AFE_8CH_I2S_OUT_CON 0x0394
#define ASMI_TIMING_CON1 0x0100
#define ASMO_TIMING_CON1 0x0104
#define PWR1_ASM_CON1 0x0108
@@ -125,6 +132,34 @@
#define AFE_MEMIF_PBUF_SIZE_DLM_BYTE_MASK (0x3 << 12)
#define AFE_MEMIF_PBUF_SIZE_DLM_32BYTES (0x1 << 12)
+/* AUDIO_TOP_CON0 (0x0000) -- HDMI audio clock gating */
+#define AUDIO_TOP_CON0_PDN_HDMI_CK (0x1 << 20)
+#define AUDIO_TOP_CON0_PDN_SPDIF_CK (0x1 << 21)
+#define AUDIO_TOP_CON0_PDN_SPDIF2_CK (0x1 << 22)
+#define AUDIO_TOP_CON0_PDN_APLL_CK (0x1 << 23)
+
+/* AUDIO_TOP_CON3 (0x000c) -- HDMI BCK divider */
+#define AUDIO_TOP_CON3_HDMI_BCK_DIV_MASK (0x3f << 8)
+#define AUDIO_TOP_CON3_HDMI_BCK_DIV(x) (((x) & 0x3f) << 8)
+
+/* AFE_HDMI_OUT_CON0 (0x0370) */
+#define AFE_HDMI_OUT_CON0_OUT_ON (0x1 << 0)
+#define AFE_HDMI_OUT_CON0_BIT_WIDTH_MASK (0x1 << 1)
+#define AFE_HDMI_OUT_CON0_BIT_WIDTH_16 (0x0 << 1)
+#define AFE_HDMI_OUT_CON0_BIT_WIDTH_32 (0x1 << 1)
+#define AFE_HDMI_OUT_CON0_CH_NUM_MASK (0xf << 4)
+#define AFE_HDMI_OUT_CON0_CH_NUM(x) (((x) & 0xf) << 4)
+
+/* AFE_8CH_I2S_OUT_CON (0x0394) -- on-SoC 8-channel I2S that feeds HDMI TX */
+#define AFE_8CH_I2S_OUT_CON_EN (0x1 << 0)
+#define AFE_8CH_I2S_OUT_CON_BCK_INV (0x1 << 1)
+#define AFE_8CH_I2S_OUT_CON_LRCK_INV (0x1 << 2)
+#define AFE_8CH_I2S_OUT_CON_I2S_DELAY (0x1 << 3)
+#define AFE_8CH_I2S_OUT_CON_WLEN_MASK (0x3 << 4)
+#define AFE_8CH_I2S_OUT_CON_WLEN_16BIT (0x1 << 4)
+#define AFE_8CH_I2S_OUT_CON_WLEN_24BIT (0x2 << 4)
+#define AFE_8CH_I2S_OUT_CON_WLEN_32BIT (0x3 << 4)
+
/* I2S in/out register bit control */
#define ASYS_I2S_CON_FS (0x1f << 8)
#define ASYS_I2S_CON_FS_SET(x) ((x) << 8)
--
2.53.0
^ permalink raw reply related
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