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

[PATCH v2 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 in Laurent's tree.
  https://gitlab.freedesktop.org/linux-media/users/pinchartl/-/tree/for-next/media/renesas?ref_type=heads
- Clock changes have been posted separately and are pending review.
  https://lore.kernel.org/all/20260615104845.4122868-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
- Patches apply on top of renesas-devel/renesas-dts-for-v7.3 (e0c6913891b1) branch.

v1->v2:
- Fixed typo in makefile for ARCH_R9A09G087
- Explicitly disabled the LED7 and key-1 in the overlay
- Dropped comment about DSW5[3] in patch#5
- Updated commit message in patch#5
- Dropped internal RB tag in patch#3

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   | 50 +++++++++++++++++++
 .../dts/renesas/r9a09g087m44-rzn2h-evk.dts    | 12 +++--
 .../dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi | 50 +++++++++++++++++++
 7 files changed, 246 insertions(+), 4 deletions(-)
 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 v2 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>
---
v1->v2:
- No change
---
 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 v2 1/5] arm64: dts: renesas: r9a09g077: Add VSPD and FCPVD nodes

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Missing required 'resets' property in VSP and FCP nodes causes DT binding violations and unconditional driver probe failure.
- [High] The device tree references an unregistered module clock `<&cpg CPG_MOD 1204>`.
- [Low] Undefined macro `R9A09G077_LCDC_CLKD` causes a fatal dtc compilation failure.
- [Low] Undocumented compatible strings used without updating the YAML bindings.
--

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

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

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

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> index 3761551c96472..29ecd0189ce72 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> @@ -1268,6 +1268,28 @@ sdhi1_vqmmc: vqmmc-regulator {
>  				status = "disabled";
>  			};
>  		};
> +
> +		fcpvd: fcp@920d0000 {
> +			compatible = "renesas,r9a09g077-fcpvd", "renesas,fcpv";

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

It seems renesas,r9a09g077-fcpvd is not added to renesas,fcp.yaml. This could
cause dtbs_check to report unrecognized compatibles. Since it falls back
to generic renesas,fcpv constraints, it might enforce maxItems: 1 for clocks
and trigger further validation errors.

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

[Severity: High]
Is module clock 1204 registered in the clock driver?

Looking at drivers/clk/renesas/r9a09g077-cpg.c, 1204 doesn't appear to be
defined in the module clock array. This would cause the clock framework's
of_xlate function to return -ENOENT, preventing the PM domain from enabling
the clock and resulting in a fatal probe failure.

> +				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;

[Severity: Low]
Is R9A09G077_LCDC_CLKD defined in the kernel tree?

It appears this macro isn't defined, which would leave the token unchanged by
the C preprocessor and cause a syntax error during device tree compilation.

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

[Severity: High]
Does this node need a resets property?

The device tree bindings for FCP require a resets property. Without it,
device initialization might be incomplete.

> +		};
> +
> +		vspd: vsp@920e0000 {
> +			compatible = "renesas,r9a09g077-vsp2", "renesas,r9a07g044-vsp2";

[Severity: Low]
Is the renesas,r9a09g077-vsp2 compatible string added to the bindings?

Without an update to renesas,vsp1.yaml, dtbs_check will report this as an
unrecognized compatible.

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

[Severity: High]
Would the unregistered CPG_MOD 1204 clock also cause probe failure for the
VSPD device here?

Similar to the fcpvd node, failing to acquire the clock will abort the probe.

> +				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;

[Severity: Low]
Could this undefined macro break dtc compilation here as well?

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

[Severity: High]
Does the vsp1 driver require a resets property to successfully probe?

Looking at drivers/media/platform/renesas/vsp1/vsp1_drv.c, vsp1_probe() calls
devm_reset_control_get_shared() without the optional flag. Because the resets
property is omitted here, this might return -ENOENT and immediately abort the
probe via dev_err_probe().

> +			renesas,fcp = <&fcpvd>;
> +		};
>  	};
>  
>  	stmmac_axi_setup: stmmac-axi-config {

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

[PATCH v2 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>
---
v1->v2:
- No change
---
 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 v2 2/5] arm64: dts: renesas: r9a09g077: Add DU node

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Missing mandatory `resets` property in du, fcpvd, and vspd nodes
- [High] Unregistered CPG_MOD 1204 clock referenced in du, fcpvd, and vspd nodes
- [Medium] Incomplete device tree implementation without driver support or fallback compatible string for du node
- [Low] Undefined macro R9A09G077_LCDC_CLKD causes build failure
--

commit 00c766c42ba26d88fa78760fe26949b97a0f53f2
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
> --- 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";

[Severity: Medium]
Does this compatible string need a generic fallback? 

Without a fallback like "renesas,r9a09g057-du", and with no driver currently
matching "renesas,r9a09g077-du" in the tree, won't this regression prevent the
node from binding to a driver and cause a schema validation failure?

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

[Severity: High]
Is module clock ID 1204 registered in the r9a09g077_mod_clks array in
drivers/clk/renesas/r9a09g077-cpg.c? 

When the Renesas CPG-MSSR PM domain governor attempts to attach the du, fcpvd,
and vspd devices, won't of_clk_get_from_provider() fail and return -ENOENT
because the clock is missing? Could this regression prevent the devices from
being attached to the power domain?

> +				 <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;

[Severity: Low]
Where is R9A09G077_LCDC_CLKD defined? 

Since it doesn't appear to be defined in the device tree bindings headers for
the du, fcpvd, and vspd nodes, won't this regression cause the device tree
compiler to fail with a syntax error and break the build?

[Severity: High]
Do the du, fcpvd, and vspd nodes also need a resets property? 

The DT bindings for the Renesas Display Unit, Frame Compression Processor,
and VSP Video Processing Engine mandate the resets property. Their respective
drivers call devm_reset_control_get_shared() without the _optional flag. 

Without it, won't reset_control_get() return -ENOENT and cause this regression
where the driver probes fail?

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

[ ... ]

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

[PATCH v2 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>
---
v1->v2:
- Dropped internal RB tag
---
 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 v2 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 strictly required 'resets' property in vspd and fcpvd nodes prevents driver probing.
- [Low] Undeclared clock macro `R9A09G087_LCDC_CLKD` causes dtc compilation failure.
- [Low] Undocumented compatibles 'renesas,r9a09g087-fcpvd' and 'renesas,r9a09g087-vsp2' trigger cascading schema validation failures.
--

commit bbd19abf3f870d8f56a21516f41a6bb33f488901
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 these new compatible strings documented in the bindings?

If renesas,r9a09g087-fcpvd is missing from the renesas,fcp.yaml schema,
dtbs_check might fall back to default rules (such as enforcing a single item
for clocks) and trigger cascading validation failures for the rest of this
node.

> +			reg = <0 0x920d0000 0 0x10000>;

[Severity: High]
Does this hardware block require a resets property to function?

The device tree binding schemas strictly require a resets property for fcpv.
Without it, driver initialization might fail or be unable to reset the hardware.

> +			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,
> +				 <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;

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

The R9A09G087_LCDC_CLKD macro does not appear to be defined in the clock
bindings header or elsewhere in the kernel tree. This usually results in a dtc
undeclared identifier error during compilation.

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

[Severity: Low]
Is renesas,r9a09g087-vsp2 documented in the renesas,vsp1.yaml schema?

Like the fcpvd node, an undocumented compatible string here might cause
dtbs_check validation failures.

> +			reg = <0 0x920e0000 0 0x8000>;
> +			interrupts = <GIC_SPI 780 IRQ_TYPE_LEVEL_HIGH>;

[Severity: High]
Will the vsp1 driver fail to probe here?

Looking at drivers/media/platform/renesas/vsp1/vsp1_drv.c, vsp1_probe() calls
devm_reset_control_get_shared() unconditionally. This will return -ENOENT if
the resets property is omitted from the device tree node. 

Does this node need a resets property to prevent the probe from aborting?

> +			clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
> +				 <&cpg CPG_MOD 1204>,
> +				 <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;

[Severity: Low]
Will this also fail to compile due to the undeclared R9A09G087_LCDC_CLKD
identifier?

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

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

[PATCH v2 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>
---
v1->v2:
- No change
---
 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 v2 4/5] arm64: dts: renesas: r9a09g087: Add DU node

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing the required `resets` property in the `du` node, leading to a driver probe failure.
- [Medium] Missing a fallback compatible string for the `du` node.
- [Low] The device tree compilation fails due to the use of an undeclared macro `R9A09G087_LCDC_CLKD`.
--

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

arm64: dts: renesas: r9a09g087: Add DU node

This commit adds the Display Unit node to the r9a09g087 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: Medium]
Does this node need a recognized fallback compatible string?

Neither "renesas,r9a09g087-du" nor "renesas,r9a09g077-du" are present in
the display driver's match table, and no existing fallback string
is provided. Without a recognized fallback, the device will fail to match
with the driver entirely, preventing the display unit from probing.

> +			reg = <0 0x920c0000 0 0x10000>;
> +			interrupts = <GIC_SPI 781 IRQ_TYPE_LEVEL_HIGH>;

[Severity: High]
Does this node need a resets property?

The renesas,rzg2l-du.yaml schema strictly requires the resets property.
Furthermore, the display driver in drivers/gpu/drm/renesas/rz-du/
unconditionally attempts to acquire the reset control via:

    devm_reset_control_get_shared(rcdu->dev, NULL)

Because the resets property is absent, this returns -ENOENT, which aborts
the driver probe and renders the display subsystem unusable.

> +			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 in the dt-bindings headers?

This macro is used as a clock specifier but does not appear to be defined
in the repository, causing the preprocessor to output the macro name as a
literal string. This results in a syntax error from dtc which expects a
phandle or integer.

> +			clock-names = "aclk", "pclk", "vclk";

[ ... ]

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

[PATCH v2 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.

Move the LED8 and LED9 preprocessor conditionals inside the node
definitions so that the nodes remain present in the base DTS. This
allows the LCDC overlay to reference and disable them when their pins
are reassigned to display functions.

According to the hardware manual, the LCDC pins should use slew-rate
setting 1 (fast). However, testing on the RZ/T2H and RZ/N2H EVKs with
the ADV7513 HDMI transmitter showed unstable display output with visible
screen flicker when configured for fast slew-rate operation. Configure
the LCDC pins with slew-rate setting 0 (slow) instead, which provides
stable display output on the evaluation platforms.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2:
- Fixed typo in makefile for CONFIG_ARCH_R9A09G087
- Explicitly disabled the led7 and key-1 in the overlay
- Dropped comment about DSW5[3]
- Updated commit message
---
 arch/arm64/boot/dts/renesas/Makefile          |  6 +++
 .../renesas/r9a09g077m44-evk-cn15-lcdc.dtso   | 40 +++++++++++++++
 .../renesas/r9a09g087m44-evk-cn20-lcdc.dtso   | 50 +++++++++++++++++++
 .../dts/renesas/r9a09g087m44-rzn2h-evk.dts    | 12 +++--
 .../dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi | 50 +++++++++++++++++++
 5 files changed, 154 insertions(+), 4 deletions(-)
 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..e4a7d7ab5b0e 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-rzn2h-evk-cn20-lcdc-dtbs := r9a09g087m44-rzn2h-evk.dtb r9a09g087m44-evk-cn20-lcdc.dtbo
+dtb-$(CONFIG_ARCH_R9A09G087) += r9a09g087m44-rzn2h-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..17bc71380860
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
@@ -0,0 +1,50 @@
+// 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, 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"
+
+&{/keys/key-1} {
+	/* P18_2 is used for DU function LCDC_DATB3. */
+	status = "disabled";
+};
+
+&{/leds/led-4} {
+	/* P18_1 is used for DU function LCDC_DATB2. */
+	status = "disabled";
+};
+
+&{/leds/led-7} {
+	/* P14_3 is used for DU function LCDC_DATG3. */
+	status = "disabled";
+};
+
+&{/leds/led-8} {
+	/* P14_6 is used for DU function LCDC_DATG6. */
+	status = "disabled";
+};
+
+&i2c0 {
+	status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts b/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
index 4e57d4fe195c..5176e620685a 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
+++ b/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
@@ -162,8 +162,8 @@ led-7 {
 			function-enumerator = <8>;
 		};
 
-#if LED8
 		led-8 {
+#if LED8
 			/*
 			 * USER_LED0
 			 * DSW15-8: OFF, DSW15-9: OFF, DSW15-10: ON
@@ -172,11 +172,13 @@ led-8 {
 			color = <LED_COLOR_ID_GREEN>;
 			function = LED_FUNCTION_DEBUG;
 			function-enumerator = <0>;
-		};
+#else
+			status = "disabled";
 #endif
+		};
 
-#if LED9
 		led-9 {
+#if LED9
 			/*
 			 * USER_LED1
 			 * DSW15-5: OFF, DSW15-6: ON
@@ -185,8 +187,10 @@ led-9 {
 			color = <LED_COLOR_ID_GREEN>;
 			function = LED_FUNCTION_DEBUG;
 			function-enumerator = <1>;
-		};
+#else
+			status = "disabled";
 #endif
+		};
 
 		led-10 {
 			/*
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 v2 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] Mismatch between commit message and implementation regarding LED9.
- [Low] Typo in the overlay header comment swapping I2C1 SDA and SCL pin mappings.
--

commit ab4b9f4219de83b53cbe289e906c4c7c0bf82541
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

Add DT overlay support enabling the DU/LCDC pipeline on the RZ/T2H and RZ/N2H
evaluation kits.

> 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
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
> @@ -0,0 +1,50 @@
[ ... ]
> +/*
> + * RZ/N2H LCDC configuration:
> + * ----------------------------------------------------------
> + * Function        Pin     SW Setting
> + * ----------------------------------------------------------
> + * LCDC_DATG0     P11_0, DSW12[3]: ON, DSW12[4]: OFF
> + * LCDC_DATG3     P14_3, 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
> + * ------------------------------------------------
> + */

[Severity: Low]
This isn't a bug, but is there a typo in the I2C1 pin mappings documented
here?  The base hardware pinmux assigns SCL to P03_3 and SDA to P03_4, which
suggests these comments have SDA and SCL swapped.

> diff --git a/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts b/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
> --- a/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
> +++ b/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
[ ... ]
> -#if LED9
>  		led-9 {
> +#if LED9
>  			/*
>  			 * USER_LED1
>  			 * DSW15-5: OFF, DSW15-6: ON
> @@ -185,8 +187,10 @@ led-9 {
>  			color = <LED_COLOR_ID_GREEN>;
>  			function = LED_FUNCTION_DEBUG;
>  			function-enumerator = <1>;
> -		};
> +#else
> +			status = "disabled";
>  #endif
> +		};

[Severity: Medium]
Is this base DTS conditional for led-9 actually utilized by the overlay?

The commit message states that moving this conditional allows the LCDC
overlay to reference and disable LED9 when its pin is reassigned to display
functions. However, the overlay (r9a09g087m44-evk-cn20-lcdc.dtso) does not
reference or disable led-9. Additionally, the display functions do not
reassign LED9's pin (P14_7) since LCDC_DATG7 uses P17_6.

Does the commit message need updating to match the implementation, or should
led-9 be disabled in the overlay?

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