[PATCH 0/5] Add DU, VSPD and FCPVD support for RZ/T2H and RZ/N2H SoCs

[PATCH 0/5] Add DU, VSPD and FCPVD support for RZ/T2H and RZ/N2H SoCs

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Hi all,

This patch series adds support for the Display Unit (DU) on the RZ/T2H
(r9a09g077) and RZ/N2H (r9a09g087) SoCs. The DU is a key component of
the display pipeline, responsible for driving the display output.
The patches include:
- Adding VSPD and FCPVD nodes to the SoC DTSI files for both RZ/T2H
  and RZ/N2H.
- Adding the DU node to the SoC DTSI files, including clock and
  interrupt configurations.
- Adding DT overlay support for enabling the DU/LCDC pipeline on the
  RZ/T2H and RZ/N2H evaluation kits when fitted with a CN15/CN20
  ADV7513 HDMI transmitter.

Note,
- DU driver patches have been merged into-next.
- FCP/VSP patches have been posted separately and are pending review.
  https://lore.kernel.org/all/20260430100929.1088281-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
- Clock changes have been posted separately and are pending review.
  https://lore.kernel.org/all/20260609105924.962573-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
- Patches apply on top of renesas-devel/renesas-dts-for-v7.3 (039608fad808) branch.

Cheers,
Prabhakar

Lad Prabhakar (5):
  arm64: dts: renesas: r9a09g077: Add VSPD and FCPVD nodes
  arm64: dts: renesas: r9a09g077: Add DU node
  arm64: dts: renesas: r9a09g087: Add VSPD and FCPVD nodes
  arm64: dts: renesas: r9a09g087: Add DU node
  arm64: dts: renesas: Add LCDC overlays for RZ/T2H and RZ/N2H EVKs with
    ADV7513

 arch/arm64/boot/dts/renesas/Makefile          |  6 +++
 arch/arm64/boot/dts/renesas/r9a09g077.dtsi    | 46 +++++++++++++++++
 .../renesas/r9a09g077m44-evk-cn15-lcdc.dtso   | 40 +++++++++++++++
 arch/arm64/boot/dts/renesas/r9a09g087.dtsi    | 46 +++++++++++++++++
 .../renesas/r9a09g087m44-evk-cn20-lcdc.dtso   | 35 +++++++++++++
 .../dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi | 50 +++++++++++++++++++
 6 files changed, 223 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r9a09g077m44-evk-cn15-lcdc.dtso
 create mode 100644 arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
 create mode 100644 arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi

-- 
2.54.0

[PATCH 1/5] arm64: dts: renesas: r9a09g077: Add VSPD and FCPVD nodes

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Add VSPD and FCPVD nodes to RZ/T2H SoC DTSI.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
 arch/arm64/boot/dts/renesas/r9a09g077.dtsi | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
index 40494159831d..dda7008acdd9 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
@@ -1376,6 +1376,28 @@ sdhi1_vqmmc: vqmmc-regulator {
 				status = "disabled";
 			};
 		};
+
+		fcpvd: fcp@920d0000 {
+			compatible = "renesas,r9a09g077-fcpvd", "renesas,fcpv";
+			reg = <0 0x920d0000 0 0x10000>;
+			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
+				 <&cpg CPG_MOD 1204>,
+				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;
+			clock-names = "aclk", "pclk", "vclk";
+			power-domains = <&cpg>;
+		};
+
+		vspd: vsp@920e0000 {
+			compatible = "renesas,r9a09g077-vsp2", "renesas,r9a07g044-vsp2";
+			reg = <0 0x920e0000 0 0x8000>;
+			interrupts = <GIC_SPI 780 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
+				 <&cpg CPG_MOD 1204>,
+				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;
+			clock-names = "aclk", "pclk", "vclk";
+			power-domains = <&cpg>;
+			renesas,fcp = <&fcpvd>;
+		};
 	};
 
 	stmmac_axi_setup: stmmac-axi-config {
-- 
2.54.0

Re: [PATCH 1/5] arm64: dts: renesas: r9a09g077: Add VSPD and FCPVD nodes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `vspd` node is missing the required `resets` property, which causes the `vsp1` driver probe to fail.
- [High] Clock module index `1204` is requested but not defined in the CPG driver.
- [Low] The macro `R9A09G077_LCDC_CLKD` is undefined, causing device tree compilation to fail.
--

commit ed649581c488eb5d4825350ff0a4c3886f2bbb0c
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

arm64: dts: renesas: r9a09g077: Add VSPD and FCPVD nodes

This commit adds the VSPD and FCPVD device nodes to the RZ/T2H SoC device
tree.

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> --- a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
[ ... ]
> +		fcpvd: fcp@920d0000 {
> +			compatible = "renesas,r9a09g077-fcpvd", "renesas,fcpv";
> +			reg = <0 0x920d0000 0 0x10000>;
> +			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,

[Severity: High]
Will this clock lookup fail during probe?

Looking at the CPG driver in drivers/clk/renesas/r9a09g077-cpg.c, the
r9a09g077_mod_clks array does not seem to contain an entry for module index
1204.

Without this definition, devm_clk_get() will return an error, preventing the
fcpvd device from probing successfully.

> +				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;

[Severity: Low]
Does this cause a compilation failure when building the device tree?

The macro R9A09G077_LCDC_CLKD does not appear to be defined anywhere in the
tree.

Because it is undefined, the preprocessor will leave the literal string in
the output, resulting in a dtc syntax error when an integer is expected.

> +			clock-names = "aclk", "pclk", "vclk";
> +			power-domains = <&cpg>;
> +		};
> +
> +		vspd: vsp@920e0000 {
> +			compatible = "renesas,r9a09g077-vsp2", "renesas,r9a07g044-vsp2";
> +			reg = <0 0x920e0000 0 0x8000>;

[Severity: High]
Is a resets property required for this node to probe successfully?

The bindings for renesas,r9a07g044-vsp2 require a resets property.
Additionally, the vsp1 driver probe function unconditionally calls
devm_reset_control_get_shared() in drivers/media/platform/renesas/vsp1/vsp1_drv.c.

If the resets property is missing from the vspd node, __reset_control_get()
will return an error and abort the driver probe.

> +			interrupts = <GIC_SPI 780 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,

[Severity: High]
Similarly to the fcpvd node, does the missing definition for module clock
index 1204 prevent the vspd device from probing as well?

> +				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;

[Severity: Low]
As with the fcpvd node, will this undefined R9A09G077_LCDC_CLKD macro also
cause a device tree compilation error here?

> +			clock-names = "aclk", "pclk", "vclk";
> +			power-domains = <&cpg>;
> +			renesas,fcp = <&fcpvd>;
> +		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609125353.401124-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=1

[PATCH 2/5] arm64: dts: renesas: r9a09g077: Add DU node

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Add Display Unit (DU) node to SoC DTSI.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
 arch/arm64/boot/dts/renesas/r9a09g077.dtsi | 24 ++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
index dda7008acdd9..93e792d0c4a0 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
@@ -1377,6 +1377,30 @@ sdhi1_vqmmc: vqmmc-regulator {
 			};
 		};
 
+		du: display@920c0000 {
+			compatible = "renesas,r9a09g077-du";
+			reg = <0 0x920c0000 0 0x10000>;
+			interrupts = <GIC_SPI 781 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
+				 <&cpg CPG_MOD 1204>,
+				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;
+			clock-names = "aclk", "pclk", "vclk";
+			power-domains = <&cpg>;
+			renesas,vsps = <&vspd 0>;
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+					du_out_rgb: endpoint {
+					};
+				};
+			};
+		};
+
 		fcpvd: fcp@920d0000 {
 			compatible = "renesas,r9a09g077-fcpvd", "renesas,fcpv";
 			reg = <0 0x920d0000 0 0x10000>;
-- 
2.54.0

Re: [PATCH 2/5] arm64: dts: renesas: r9a09g077: Add DU node

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The `du` node is missing the `resets` property, which will cause the DRM driver to unconditionally abort probing.
- [High] The `du` node references an unregistered clock module ID (`<&cpg CPG_MOD 1204>`), which will fail to resolve during probe.
- [Low] The device tree macro `R9A09G077_LCDC_CLKD` is referenced in the `clocks` property of the `du` node, but it is undeclared, causing a dtc syntax error.
--

commit b1b9bb2b4166cd4bcef17245d412315735a742e6
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

arm64: dts: renesas: r9a09g077: Add DU node

Add Display Unit (DU) node to SoC DTSI.

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> index 29ecd0189ce72..32a3fb1187000 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> @@ -1269,6 +1269,30 @@ sdhi1_vqmmc: vqmmc-regulator {
>  			};
>  		};
>  
> +		du: display@920c0000 {
> +			compatible = "renesas,r9a09g077-du";
> +			reg = <0 0x920c0000 0 0x10000>;

[Severity: High]
Are we missing the resets property for the du node here?

The rzg2l-du DRM driver unconditionally calls devm_reset_control_get_shared()
during rzg2l_du_crtc_create(). Because the resets property is absent in this
node, the call will fail and return -ENOENT. This breaks the driver probe
and prevents the display from initializing.

> +			interrupts = <GIC_SPI 781 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,

[Severity: High]
Does this reference an unregistered clock module ID?

The module clock ID 1204 does not appear to be registered in the CPG driver's
module clock array (r9a09g077_mod_clks). When the display drivers attempt to
acquire this clock, the clock framework will fail to resolve it and return
-ENOENT, which will prevent the display pipeline from initializing.

> +				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;

[Severity: Low]
Is the device tree macro R9A09G077_LCDC_CLKD declared?

It seems this identifier is referenced in the clocks property but is never
defined in the bindings header. The C preprocessor will leave the identifier
unexpanded, causing dtc to encounter a raw string where it expects a cell
integer value. This throws a syntax error and fails the device tree
compilation.

> +			clock-names = "aclk", "pclk", "vclk";
> +			power-domains = <&cpg>;
> +			renesas,vsps = <&vspd 0>;
> +			status = "disabled";

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609125353.401124-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=2

[PATCH 3/5] arm64: dts: renesas: r9a09g087: Add VSPD and FCPVD nodes

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Add VSPD and FCPVD nodes to RZ/N2H SoC DTSI.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
---
 arch/arm64/boot/dts/renesas/r9a09g087.dtsi | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
index e8d4f76949cc..174f683fa68d 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
@@ -1379,6 +1379,28 @@ sdhi1_vqmmc: vqmmc-regulator {
 				status = "disabled";
 			};
 		};
+
+		fcpvd: fcp@920d0000 {
+			compatible = "renesas,r9a09g087-fcpvd", "renesas,fcpv";
+			reg = <0 0x920d0000 0 0x10000>;
+			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
+				 <&cpg CPG_MOD 1204>,
+				 <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;
+			clock-names = "aclk", "pclk", "vclk";
+			power-domains = <&cpg>;
+		};
+
+		vspd: vsp@920e0000 {
+			compatible = "renesas,r9a09g087-vsp2", "renesas,r9a07g044-vsp2";
+			reg = <0 0x920e0000 0 0x8000>;
+			interrupts = <GIC_SPI 780 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
+				 <&cpg CPG_MOD 1204>,
+				 <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;
+			clock-names = "aclk", "pclk", "vclk";
+			power-domains = <&cpg>;
+			renesas,fcp = <&fcpvd>;
+		};
 	};
 
 	stmmac_axi_setup: stmmac-axi-config {
-- 
2.54.0

Re: [PATCH 3/5] arm64: dts: renesas: r9a09g087: Add VSPD and FCPVD nodes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing mandatory 'resets' property in vspd node causes driver probe failure.
- [Low] Undeclared macro R9A09G087_LCDC_CLKD breaks DTB compilation.
- [Low] Undocumented compatible strings and missing required properties cause strict DT schema validation failures.
--

commit 0838fa73798a48fc749c7ebe19ded83603bdc112
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

arm64: dts: renesas: r9a09g087: Add VSPD and FCPVD nodes
    
Add VSPD and FCPVD nodes to RZ/N2H SoC DTSI.

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> index f697e9698ed39..cb2eabe3242e0 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi

[ ... ]

> @@ -1271,6 +1271,28 @@ sdhi1_vqmmc: vqmmc-regulator {
>  				status = "disabled";
>  			};
>  		};
> +
> +		fcpvd: fcp@920d0000 {
> +			compatible = "renesas,r9a09g087-fcpvd", "renesas,fcpv";

[Severity: Low]
Are the compatible strings "renesas,r9a09g087-fcpvd" and
"renesas,r9a09g087-vsp2" documented in the dt-binding schemas? 

It seems they might be missing from renesas,fcp.yaml and renesas,vsp1.yaml.
For fcpvd, this causes validation to fall through to a generic schema that
strictly enforces maxItems: 1 for the clocks property, which fails against
the 3 clocks specified here.

> +			reg = <0 0x920d0000 0 0x10000>;
> +			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,
> +				 <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;

[Severity: Low]
Where is R9A09G087_LCDC_CLKD defined?

This macro appears to be undeclared in the dt-bindings header or anywhere
else in the patch series, which will result in a syntax error when compiling
the device tree.

> +			clock-names = "aclk", "pclk", "vclk";
> +			power-domains = <&cpg>;
> +		};
> +
> +		vspd: vsp@920e0000 {
> +			compatible = "renesas,r9a09g087-vsp2", "renesas,r9a07g044-vsp2";
> +			reg = <0 0x920e0000 0 0x8000>;

[Severity: High]
Does the vspd node need a "resets" property to probe successfully?

Looking at vsp1_probe() in drivers/media/platform/renesas/vsp1/vsp1_drv.c,
it unconditionally requires a reset control:

	vsp1->rstc = devm_reset_control_get_shared(&pdev->dev, NULL);
	if (IS_ERR(vsp1->rstc))
		return dev_err_probe(&pdev->dev, PTR_ERR(vsp1->rstc),

Without the resets property, this call will return -ENOENT and cause the probe
sequence to abort. Additionally, missing the resets property will cause
dtbs_check validation failures.

> +			interrupts = <GIC_SPI 780 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,
> +				 <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;

[Severity: Low]
Does this also need the missing R9A09G087_LCDC_CLKD macro definition, similar
to the fcpvd node above?

> +			clock-names = "aclk", "pclk", "vclk";
> +			power-domains = <&cpg>;
> +			renesas,fcp = <&fcpvd>;
> +		};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609125353.401124-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=3

[PATCH 4/5] arm64: dts: renesas: r9a09g087: Add DU node

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Add Display Unit (DU) node to SoC DTSI.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
 arch/arm64/boot/dts/renesas/r9a09g087.dtsi | 24 ++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
index 174f683fa68d..308d3ccc21d1 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
@@ -1380,6 +1380,30 @@ sdhi1_vqmmc: vqmmc-regulator {
 			};
 		};
 
+		du: display@920c0000 {
+			compatible = "renesas,r9a09g087-du", "renesas,r9a09g077-du";
+			reg = <0 0x920c0000 0 0x10000>;
+			interrupts = <GIC_SPI 781 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
+				 <&cpg CPG_MOD 1204>,
+				 <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;
+			clock-names = "aclk", "pclk", "vclk";
+			power-domains = <&cpg>;
+			renesas,vsps = <&vspd 0>;
+			status = "disabled";
+
+			ports {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				port@0 {
+					reg = <0>;
+					du_out_rgb: endpoint {
+					};
+				};
+			};
+		};
+
 		fcpvd: fcp@920d0000 {
 			compatible = "renesas,r9a09g087-fcpvd", "renesas,fcpv";
 			reg = <0 0x920d0000 0 0x10000>;
-- 
2.54.0

Re: [PATCH 4/5] arm64: dts: renesas: r9a09g087: Add DU node

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] The macro `R9A09G087_LCDC_CLKD` is referenced in the `clocks` property but is undeclared, causing a Device Tree build failure.
- [Low] The compatible strings `renesas,r9a09g087-du` and `renesas,r9a09g077-du` are added without corresponding Device Tree binding schemas.
--

commit 3aa7f5ef71efe2b2f0c8c868ca73eebb03c02010
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

arm64: dts: renesas: r9a09g087: Add DU node

This commit adds the Display Unit (DU) node to the RZ/N2H (r9a09g087) SoC
Device Tree.

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> index cb2eabe3242e0..21250caf31493 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> @@ -1272,6 +1272,30 @@ sdhi1_vqmmc: vqmmc-regulator {
>  			};
>  		};
>  
> +		du: display@920c0000 {
> +			compatible = "renesas,r9a09g087-du", "renesas,r9a09g077-du";

[Severity: Low]
Are these compatible strings documented in the device tree bindings?

It appears they are introduced here without a corresponding update to the YAML
schemas in Documentation/devicetree/bindings/, which might cause
make dtbs_check validation errors.

> +			reg = <0 0x920c0000 0 0x10000>;
> +			interrupts = <GIC_SPI 781 IRQ_TYPE_LEVEL_HIGH>;
> +			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,
> +				 <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;

[Severity: Low]
Is the R9A09G087_LCDC_CLKD macro defined anywhere?

It seems its definition is missing from the clock bindings header, which will
cause a Device Tree Compiler (dtc) syntax error and break the build.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609125353.401124-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=4

[PATCH 5/5] arm64: dts: renesas: Add LCDC overlays for RZ/T2H and RZ/N2H EVKs with ADV7513

[Prabhakar]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Add DT overlay support enabling the DU/LCDC pipeline on the RZ/T2H
(r9a09g077) and RZ/N2H (r9a09g087) evaluation kits when fitted with a
CN15/CN20 ADV7513 HDMI transmitter.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
Note, as per the HW manual the slew rate setting for the LCDC pins should
be 1 (fast), but while testing on the EVKs with ADV7513, the display output
was unstable (flickers were seen) with slew rate 1. Setting the slew rate
to 0 (slow) resolved the issue.
---
 arch/arm64/boot/dts/renesas/Makefile          |  6 +++
 .../renesas/r9a09g077m44-evk-cn15-lcdc.dtso   | 40 +++++++++++++++
 .../renesas/r9a09g087m44-evk-cn20-lcdc.dtso   | 35 +++++++++++++
 .../dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi | 50 +++++++++++++++++++
 4 files changed, 131 insertions(+)
 create mode 100644 arch/arm64/boot/dts/renesas/r9a09g077m44-evk-cn15-lcdc.dtso
 create mode 100644 arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
 create mode 100644 arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi

diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index 8bf155badd11..34a4ef0d715a 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -216,8 +216,14 @@ r9a09g057h48-kakip-pixpaper-dtbs := r9a09g057h48-kakip.dtb r9a09g057h48-kakip-pi
 dtb-$(CONFIG_ARCH_R9A09G057) += r9a09g057h48-kakip-pixpaper.dtb
 
 dtb-$(CONFIG_ARCH_R9A09G077) += r9a09g077m44-rzt2h-evk.dtb
+dtb-$(CONFIG_ARCH_R9A09G077) += r9a09g077m44-evk-cn15-lcdc.dtbo
+r9a09g077m44-rzt2h-evk-cn15-lcdc-dtbs := r9a09g077m44-rzt2h-evk.dtb r9a09g077m44-evk-cn15-lcdc.dtbo
+dtb-$(CONFIG_ARCH_R9A09G077) += r9a09g077m44-rzt2h-evk-cn15-lcdc.dtb
 
 dtb-$(CONFIG_ARCH_R9A09G087) += r9a09g087m44-rzn2h-evk.dtb
+dtb-$(CONFIG_ARCH_R9A09G087) += r9a09g087m44-evk-cn20-lcdc.dtbo
+r9a09g087m44-rzt2h-evk-cn20-lcdc-dtbs := r9a09g087m44-rzn2h-evk.dtb r9a09g087m44-evk-cn20-lcdc.dtbo
+dtb-$(CONFIG_ARCH_R9A09G087) += r9a09g087m44-rzt2h-evk-cn20-lcdc.dtb
 
 dtb-$(CONFIG_ARCH_RCAR_GEN3) += draak-ebisu-panel-aa104xd12.dtbo
 dtb-$(CONFIG_ARCH_RCAR_GEN3) += salvator-panel-aa104xd12.dtbo
diff --git a/arch/arm64/boot/dts/renesas/r9a09g077m44-evk-cn15-lcdc.dtso b/arch/arm64/boot/dts/renesas/r9a09g077m44-evk-cn15-lcdc.dtso
new file mode 100644
index 000000000000..41c695325729
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r9a09g077m44-evk-cn15-lcdc.dtso
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT overlay for the RZ/T2H EVK with ADV7513 transmitter
+ * connected to DU enabled.
+ *
+ * Copyright (C) 2026 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+/plugin/;
+
+/*
+ * RZ/T2H LCDC configuration:
+ * ----------------------------------------------------------
+ * Function        Pin     SW Setting
+ * ----------------------------------------------------------
+ * LCDC_DATG0     P11_0, SW6[3]: OFF, SW6[4]: ON, SW6[5]: OFF
+ * LCDC_DATB1     P18_0, SW8[3]: OFF, SW8[4]: ON
+ * LCDC_DATB2     P18_1, SW8[1]: OFF, SW8[2]: ON
+ * HEADER_IRQ8    P22_6, SW2[1]: ON, SW2[2]: OFF
+ */
+#include "rzt2h-n2h-evk-du-adv7513.dtsi"
+
+&{/leds/led-4} {
+	/* P18_0 is used for DU function LCDC_DATB1. */
+	status = "disabled";
+};
+
+&{/leds/led-5} {
+	/* P18_1 is used for DU function LCDC_DATB2. */
+	status = "disabled";
+};
+
+/*
+ * Disable SDHI0 as SW2 settings for eMMC/SD card conflict with DU pin
+ * settings.
+ */
+&sdhi0 {
+	status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso b/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
new file mode 100644
index 000000000000..bc8a91278920
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT overlay for the RZ/N2H EVK with ADV7513 transmitter
+ * connected to DU enabled.
+ *
+ * Copyright (C) 2026 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+/plugin/;
+
+/*
+ * RZ/N2H LCDC configuration:
+ * ----------------------------------------------------------
+ * Function        Pin     SW Setting
+ * ----------------------------------------------------------
+ * LCDC_DATG0     P11_0, DSW12[3]: ON, DSW12[4]: OFF
+ * LCDC_DATG3     P14_3, DSW5[3]: OFF, DSW18[5]: OFF, DSW18[6]: ON
+ * LCDC_DATG6     P14_6, DSW15[8]: ON, DSW15[9]: OFF, DSW15[10]: OFF
+ * LCDC_DATB2     P18_1, DSW18[9]: OFF, DSW18[10]: ON
+ * I2C_SDA1       P03_3, DSW7[1]: ON, DSW7[2]: OFF
+ * I2C_SCL1       P03_4, DSW7[3]: ON, DSW7[4]: OFF
+ * ------------------------------------------------
+ */
+
+#include "rzt2h-n2h-evk-du-adv7513.dtsi"
+
+&{/leds/led-4} {
+	/* P18_1 is used for DU function LCDC_DATB2. */
+	status = "disabled";
+};
+
+&i2c0 {
+	status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi b/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi
new file mode 100644
index 000000000000..c537b2221fdc
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT overlay common parts for the RZ/{T2H/N2H} EVKs with ADV7513
+ * transmitter connected to DU enabled.
+ *
+ * Copyright (C) 2026 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/pinctrl/renesas,r9a09g077-pinctrl.h>
+
+#define ADV7513_PARENT_I2C i2c1
+#include "rz-smarc-du-adv7513.dtsi"
+
+&pinctrl {
+	du_pins: du-pins {
+		pinmux = <RZT2H_PORT_PINMUX(9, 4, 0x28)>, /* LCDC_CLK */
+			 <RZT2H_PORT_PINMUX(9, 5, 0x28)>, /* LCDC_HSYNC */
+			 <RZT2H_PORT_PINMUX(9, 6, 0x28)>, /* LCDC_VSYNC */
+			 <RZT2H_PORT_PINMUX(9, 7, 0x28)>, /* LCDC_DE */
+			 <RZT2H_PORT_PINMUX(10, 0, 0x28)>, /* LCDC_DATR0 */
+			 <RZT2H_PORT_PINMUX(10, 1, 0x28)>, /* LCDC_DATR1 */
+			 <RZT2H_PORT_PINMUX(10, 2, 0x28)>, /* LCDC_DATR2 */
+			 <RZT2H_PORT_PINMUX(10, 3, 0x28)>, /* LCDC_DATR3 */
+			 <RZT2H_PORT_PINMUX(10, 4, 0x28)>, /* LCDC_DATR4 */
+			 <RZT2H_PORT_PINMUX(10, 5, 0x28)>, /* LCDC_DATR5 */
+			 <RZT2H_PORT_PINMUX(10, 6, 0x28)>, /* LCDC_DATR6 */
+			 <RZT2H_PORT_PINMUX(10, 7, 0x28)>, /* LCDC_DATR7 */
+			 <RZT2H_PORT_PINMUX(11, 0, 0x28)>, /* LCDC_DATG0 */
+			 <RZT2H_PORT_PINMUX(14, 1, 0x28)>, /* LCDC_DATG1 */
+			 <RZT2H_PORT_PINMUX(14, 2, 0x28)>, /* LCDC_DATG2 */
+			 <RZT2H_PORT_PINMUX(14, 3, 0x28)>, /* LCDC_DATG3 */
+			 <RZT2H_PORT_PINMUX(14, 4, 0x28)>, /* LCDC_DATG4 */
+			 <RZT2H_PORT_PINMUX(14, 5, 0x28)>, /* LCDC_DATG5 */
+			 <RZT2H_PORT_PINMUX(14, 6, 0x28)>, /* LCDC_DATG6 */
+			 <RZT2H_PORT_PINMUX(17, 6, 0x28)>, /* LCDC_DATG7 */
+			 <RZT2H_PORT_PINMUX(17, 7, 0x28)>, /* LCDC_DATB0 */
+			 <RZT2H_PORT_PINMUX(18, 0, 0x28)>, /* LCDC_DATB1 */
+			 <RZT2H_PORT_PINMUX(18, 1, 0x28)>, /* LCDC_DATB2 */
+			 <RZT2H_PORT_PINMUX(18, 2, 0x28)>, /* LCDC_DATB3 */
+			 <RZT2H_PORT_PINMUX(18, 3, 0x28)>, /* LCDC_DATB4 */
+			 <RZT2H_PORT_PINMUX(18, 4, 0x28)>, /* LCDC_DATB5 */
+			 <RZT2H_PORT_PINMUX(18, 5, 0x28)>, /* LCDC_DATB6 */
+			 <RZT2H_PORT_PINMUX(18, 6, 0x28)>; /* LCDC_DATB7 */
+		drive-strength-microamp = <11800>;
+		slew-rate = <0>;
+	};
+};
-- 
2.54.0

Re: [PATCH 5/5] arm64: dts: renesas: Add LCDC overlays for RZ/T2H and RZ/N2H EVKs with ADV7513

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The RZ/N2H overlay fails to disable conflicting devices (`led-7`, `key-1`, and `sdhi1`), causing pinctrl and physical hardware collisions.
- [Low] Typo in the Makefile causes the composite DTB for the RZ/N2H EVK to be incorrectly named with 'rzt2h' instead of 'rzn2h'.
--

commit efe0a5ca8f3fdb36ded9b05e9b5a45260bb5135a
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

arm64: dts: renesas: Add LCDC overlays for RZ/T2H and RZ/N2H EVKs with ADV7513

This commit adds device tree overlay support to enable the DU/LCDC pipeline
on the RZ/T2H and RZ/N2H evaluation kits. It configures the overlays for use
with a CN15/CN20 ADV7513 HDMI transmitter.

> diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
> index ca45d2857ea7f..0f64a8820e374 100644
> --- a/arch/arm64/boot/dts/renesas/Makefile
> +++ b/arch/arm64/boot/dts/renesas/Makefile
[ ... ]
> @@ -215,8 +215,14 @@ r9a09g057h48-kakip-pixpaper-dtbs := r9a09g057h48-kakip.dtb r9a09g057h48-kakip-pi
>  dtb-$(CONFIG_ARCH_R9A09G057) += r9a09g057h48-kakip-pixpaper.dtb
>  
>  dtb-$(CONFIG_ARCH_R9A09G077) += r9a09g077m44-rzt2h-evk.dtb
> +dtb-$(CONFIG_ARCH_R9A09G077) += r9a09g077m44-evk-cn15-lcdc.dtbo
> +r9a09g077m44-rzt2h-evk-cn15-lcdc-dtbs := r9a09g077m44-rzt2h-evk.dtb r9a09g077m44-evk-cn15-lcdc.dtbo
> +dtb-$(CONFIG_ARCH_R9A09G077) += r9a09g077m44-rzt2h-evk-cn15-lcdc.dtb
>  
>  dtb-$(CONFIG_ARCH_R9A09G087) += r9a09g087m44-rzn2h-evk.dtb
> +dtb-$(CONFIG_ARCH_R9A09G087) += r9a09g087m44-evk-cn20-lcdc.dtbo
> +r9a09g087m44-rzt2h-evk-cn20-lcdc-dtbs := r9a09g087m44-rzn2h-evk.dtb r9a09g087m44-evk-cn20-lcdc.dtbo
> +dtb-$(CONFIG_ARCH_R9A09G087) += r9a09g087m44-rzt2h-evk-cn20-lcdc.dtb

[Severity: Low]
Does this code contain a copy-paste typo? The target is the RZ/N2H EVK, but
the variables use rzt2h instead of rzn2h for the composite DTB names.

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso b/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
> new file mode 100644
> index 0000000000000..bc8a91278920e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
[ ... ]
> +&{/leds/led-4} {
> +	/* P18_1 is used for DU function LCDC_DATB2. */
> +	status = "disabled";
> +};
> +
> +&i2c0 {
> +	status = "disabled";
> +};

[Severity: Medium]
Does this overlay omit disabling conflicting devices like led-7, key-1, and
sdhi1?

The shared DU overlay configures du-pins to use P18_2 for LCDC_DATB3 and
P14_3 for LCDC_DATG3. In the base RZ/N2H device tree, P18_2 is statically
assigned to key-1 and P14_3 is assigned to led-7. Leaving them enabled could
lead to a pinctrl collision during boot.

Also, the overlay specifies that LCDC_DATG3 requires hardware switch DSW5[3]
to be OFF, but sdhi1 in the base device tree requires DSW5[3] to be ON for
card detect and IO voltage supply. Could sdhi1 be explicitly disabled here as
well to prevent physical hardware conflicts?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609125353.401124-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=5