[PATCH 0/4] Add DU support for RZ/T2H and RZ/N2H SoCs

[PATCH 0/4] Add DU support for RZ/T2H and RZ/N2H SoCs

[Prabhakar]

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

Hi All,

This series adds support for the Display Unit (DU) on the RZ/T2H
and RZ/N2H (R9A09G087) SoCs. The DU on these platforms is
functionally similar to the RZ/G2UL DU but includes some SoC
specific differences such as a single output port and explicit
DPI output enable control. The series includes the following
changes:
1. Add device tree bindings for the RZ/T2H and RZ/N2H DU variants,
   including a new compatible string and port property.
2. Make the DU reset control optional to allow probing on RZ/T2H
   where the DU does not have a reset line.
3. Move pixel clock validation logic to per-SoC constraints in
   rzg2l_du_device_info to accommodate different clock limits
   across SoCs.
4. Implement support for the RZ/T2H DU variant in the driver,
   including handling of the DPI output enable signal.

Patches are rebased on next-20260429 and apply on drm-next.

Cheers,
Prabhakar

Lad Prabhakar (4):
  dt-bindings: display: renesas,rzg2l-du: Add RZ/T2H and RZ/N2H support
  drm: renesas: rz-du: Make DU reset control optional for RZ/T2H support
  drm: renesas: rz-du: Move mode_valid logic to per-SoC clock limits
  drm: renesas: rz-du: Add support for RZ/T2H SoC

 .../bindings/display/renesas,rzg2l-du.yaml    | 24 +++++++++++++++++--
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c |  9 +++++--
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c  | 16 +++++++++++++
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h  | 14 +++++++++++
 .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.c  |  6 ++++-
 .../gpu/drm/renesas/rz-du/rzg2l_du_encoder.h  |  2 ++
 6 files changed, 66 insertions(+), 5 deletions(-)

-- 
2.54.0

[PATCH 1/4] dt-bindings: display: renesas, rzg2l-du: Add RZ/T2H and RZ/N2H support

[Prabhakar]

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

Document the Display Unit (DU) support for the RZ/T2H and RZ/N2H SoCs.

The DU block on RZ/T2H is functionally equivalent to the RZ/G2UL DU and
supports the DPI interface, but includes SoC-specific register differences.
Add a dedicated compatible string to represent this variant.

As the DU implementation on RZ/N2H matches RZ/T2H, describe it using an
RZ/N2H specific compatible string with the RZ/T2H compatible as fallback.

Unlike other DU variants which use a multi-port model, the RZ/T2H and
RZ/N2H DU has a single output and is modelled using a single port node
with one endpoint. Add a port property to support this and update the
allOf constraints accordingly.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
 .../bindings/display/renesas,rzg2l-du.yaml    | 24 +++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
index 2cc66dcef870..45678d536a75 100644
--- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -21,6 +21,7 @@ properties:
           - renesas,r9a07g043u-du # RZ/G2UL
           - renesas,r9a07g044-du # RZ/G2{L,LC}
           - renesas,r9a09g057-du # RZ/V2H(P)
+          - renesas,r9a09g077-du # RZ/T2H
       - items:
           - enum:
               - renesas,r9a07g054-du    # RZ/V2L
@@ -28,6 +29,9 @@ properties:
       - items:
           - const: renesas,r9a09g056-du # RZ/V2N
           - const: renesas,r9a09g057-du # RZ/V2H(P) fallback
+      - items:
+          - const: renesas,r9a09g087-du # RZ/N2H
+          - const: renesas,r9a09g077-du # RZ/T2H fallback
 
   reg:
     maxItems: 1
@@ -53,6 +57,10 @@ properties:
   power-domains:
     maxItems: 1
 
+  port:
+    $ref: /schemas/graph.yaml#/properties/port
+    description: Single output port for single-output DU variants.
+
   ports:
     $ref: /schemas/graph.yaml#/properties/ports
     description: |
@@ -83,9 +91,7 @@ required:
   - interrupts
   - clocks
   - clock-names
-  - resets
   - power-domains
-  - ports
   - renesas,vsps
 
 additionalProperties: false
@@ -137,6 +143,20 @@ allOf:
 
           required:
             - port@0
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: renesas,r9a09g077-du
+    then:
+      properties:
+        resets: false
+      required:
+        - port
+    else:
+      required:
+        - resets
+        - ports
 
 examples:
   # RZ/G2L DU
-- 
2.54.0

[PATCH 2/4] drm: renesas: rz-du: Make DU reset control optional for RZ/T2H support

[Prabhakar]

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

Update the DU CRTC initialisation to request the reset control using
devm_reset_control_get_optional_shared(). On RZ/T2H SoCs the DU block does
not expose a reset line, and treating the reset as mandatory prevents the
driver from probing on those platforms.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
index 18e2b981b691..2b772a11c7ee 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
@@ -380,7 +380,7 @@ int rzg2l_du_crtc_create(struct rzg2l_du_device *rcdu)
 	struct drm_plane *primary;
 	int ret;
 
-	rcrtc->rstc = devm_reset_control_get_shared(rcdu->dev, NULL);
+	rcrtc->rstc = devm_reset_control_get_optional_shared(rcdu->dev, NULL);
 	if (IS_ERR(rcrtc->rstc)) {
 		dev_err(rcdu->dev, "can't get cpg reset\n");
 		return PTR_ERR(rcrtc->rstc);
-- 
2.54.0

[PATCH 3/4] drm: renesas: rz-du: Move mode_valid logic to per-SoC clock limits

[Prabhakar]

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

Move pixel clock validation from a fixed encoder check to per SoC
constraints stored in rzg2l_du_device_info.

Pixel clock limits differ across SoCs in the RZ DU family and cannot be
expressed by a single shared rule. For example, RZ/G2UL (R9A07G043U)
limits the DPAD0 pixel clock to 83.5 MHz, while other SoCs such as
RZ/T2H require a wider operating range.

Add mode_clock_min and mode_clock_max fields to rzg2l_du_device_info to
describe the supported pixel clock range for each SoC. Update
rzg2l_du_encoder_mode_valid() to return MODE_CLOCK_LOW when the pixel
clock falls below mode_clock_min and MODE_CLOCK_HIGH when it exceeds
mode_clock_max.

Set the pixel clock limits for RZ/G2UL(R9A07G043U) to 20.875MHz minimum
and 83.5MHz maximum.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c     | 2 ++
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h     | 4 ++++
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c | 6 +++++-
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h | 2 ++
 4 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
index 0fef33a5a089..3b7162c6e1f4 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
@@ -35,6 +35,8 @@ static const struct rzg2l_du_device_info rzg2l_du_r9a07g043u_info = {
 			.port = 0,
 		},
 	},
+	.mode_clock_min = 20875,
+	.mode_clock_max = 83500,
 };
 
 static const struct rzg2l_du_device_info rzg2l_du_r9a07g044_info = {
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
index 58806c2a8f2b..885558eb9547 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
@@ -44,10 +44,14 @@ struct rzg2l_du_output_routing {
  * struct rzg2l_du_device_info - DU model-specific information
  * @channels_mask: bit mask of available DU channels
  * @routes: array of CRTC to output routes, indexed by output (RZG2L_DU_OUTPUT_*)
+ * @mode_clock_min: minimum pixel clock in kHz
+ * @mode_clock_max: maximum pixel clock in kHz
  */
 struct rzg2l_du_device_info {
 	unsigned int channels_mask;
 	struct rzg2l_du_output_routing routes[RZG2L_DU_OUTPUT_MAX];
+	u32 mode_clock_min;
+	u32 mode_clock_max;
 };
 
 #define RZG2L_DU_MAX_CRTCS		1
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
index d53068733c66..ad02efec1c23 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
@@ -50,8 +50,11 @@ rzg2l_du_encoder_mode_valid(struct drm_encoder *encoder,
 			    const struct drm_display_mode *mode)
 {
 	struct rzg2l_du_encoder *renc = to_rzg2l_encoder(encoder);
+	const struct rzg2l_du_device_info *info = renc->info;
 
-	if (renc->output == RZG2L_DU_OUTPUT_DPAD0 && mode->clock > 83500)
+	if (info->mode_clock_min && mode->clock < info->mode_clock_min)
+		return MODE_CLOCK_LOW;
+	if (info->mode_clock_max && mode->clock > info->mode_clock_max)
 		return MODE_CLOCK_HIGH;
 
 	return MODE_OK;
@@ -107,6 +110,7 @@ int rzg2l_du_encoder_init(struct rzg2l_du_device  *rcdu,
 	if (IS_ERR(renc))
 		return PTR_ERR(renc);
 
+	renc->info = rcdu->info;
 	renc->output = output;
 	drm_encoder_helper_add(&renc->base, &rzg2l_du_encoder_helper_funcs);
 
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h
index 3e430c1f6132..39a1d178b856 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h
@@ -14,10 +14,12 @@
 #include <linux/container_of.h>
 
 struct rzg2l_du_device;
+struct rzg2l_du_device_info;
 
 struct rzg2l_du_encoder {
 	struct drm_encoder base;
 	enum rzg2l_du_output output;
+	const struct rzg2l_du_device_info *info;
 };
 
 static inline struct rzg2l_du_encoder *to_rzg2l_encoder(struct drm_encoder *e)
-- 
2.54.0

[PATCH 4/4] drm: renesas: rz-du: Add support for RZ/T2H SoC

[Prabhakar]

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

The RZ/T2H (R9A09G077) SoC includes a DU with a DPI interface,
supporting resolutions up to WXGA with two RPFs for layer blending.
Unlike earlier RZ/G2L SoCs, RZ/T2H requires explicit assertion of a
DPI output-enable signal (DU_MCR0_DPI_EN) during CRTC startup.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c |  7 ++++++-
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c  | 14 ++++++++++++++
 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h  | 10 ++++++++++
 3 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
index 2b772a11c7ee..017d5f26bc96 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
@@ -28,6 +28,7 @@
 #include "rzg2l_du_vsp.h"
 
 #define DU_MCR0			0x00
+#define DU_MCR0_DPI_EN		BIT(0)
 #define DU_MCR0_DI_EN		BIT(8)
 
 #define DU_DITR0		0x10
@@ -217,8 +218,12 @@ static void rzg2l_du_crtc_put(struct rzg2l_du_crtc *rcrtc)
 static void rzg2l_du_start_stop(struct rzg2l_du_crtc *rcrtc, bool start)
 {
 	struct rzg2l_du_device *rcdu = rcrtc->dev;
+	u32 val = DU_MCR0_DI_EN;
 
-	writel(start ? DU_MCR0_DI_EN : 0, rcdu->mmio + DU_MCR0);
+	if (start && rzg2l_du_has(rcdu, RZG2L_DU_FEATURE_DPIO_OE))
+		val |= DU_MCR0_DPI_EN;
+
+	writel(start ? val : 0, rcdu->mmio + DU_MCR0);
 }
 
 static void rzg2l_du_crtc_start(struct rzg2l_du_crtc *rcrtc)
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
index 3b7162c6e1f4..fc55dfffebaf 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
@@ -63,10 +63,24 @@ static const struct rzg2l_du_device_info rzg2l_du_r9a09g057_info = {
 	},
 };
 
+static const struct rzg2l_du_device_info rzg2l_du_r9a09g077_info = {
+	.channels_mask = BIT(0),
+	.routes = {
+		[RZG2L_DU_OUTPUT_DPAD0] = {
+			.possible_outputs = BIT(0),
+			.port = 0,
+		},
+	},
+	.features = RZG2L_DU_FEATURE_DPIO_OE,
+	.mode_clock_min = 5000,
+	.mode_clock_max = 100000,
+};
+
 static const struct of_device_id rzg2l_du_of_table[] = {
 	{ .compatible = "renesas,r9a07g043u-du", .data = &rzg2l_du_r9a07g043u_info },
 	{ .compatible = "renesas,r9a07g044-du", .data = &rzg2l_du_r9a07g044_info },
 	{ .compatible = "renesas,r9a09g057-du", .data = &rzg2l_du_r9a09g057_info },
+	{ .compatible = "renesas,r9a09g077-du", .data = &rzg2l_du_r9a09g077_info },
 	{ /* sentinel */ }
 };
 
diff --git a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
index 885558eb9547..baf076d69cda 100644
--- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
+++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
@@ -20,6 +20,8 @@
 struct device;
 struct drm_property;
 
+#define RZG2L_DU_FEATURE_DPIO_OE	BIT(0)	/* Has DPIO output enable control */
+
 enum rzg2l_du_output {
 	RZG2L_DU_OUTPUT_DSI0,
 	RZG2L_DU_OUTPUT_DPAD0,
@@ -46,12 +48,14 @@ struct rzg2l_du_output_routing {
  * @routes: array of CRTC to output routes, indexed by output (RZG2L_DU_OUTPUT_*)
  * @mode_clock_min: minimum pixel clock in kHz
  * @mode_clock_max: maximum pixel clock in kHz
+ * @features: device features (RZG2L_DU_FEATURE_*)
  */
 struct rzg2l_du_device_info {
 	unsigned int channels_mask;
 	struct rzg2l_du_output_routing routes[RZG2L_DU_OUTPUT_MAX];
 	u32 mode_clock_min;
 	u32 mode_clock_max;
+	unsigned int features;
 };
 
 #define RZG2L_DU_MAX_CRTCS		1
@@ -77,6 +81,12 @@ static inline struct rzg2l_du_device *to_rzg2l_du_device(struct drm_device *dev)
 	return container_of(dev, struct rzg2l_du_device, ddev);
 }
 
+static inline bool rzg2l_du_has(struct rzg2l_du_device *rcdu,
+				unsigned int feature)
+{
+	return rcdu->info->features & feature;
+}
+
 const char *rzg2l_du_output_name(enum rzg2l_du_output output);
 
 #endif /* __RZG2L_DU_DRV_H__ */
-- 
2.54.0

Re: [PATCH 4/4] drm: renesas: rz-du: Add support for RZ/T2H SoC

[Geert Uytterhoeven]

Hi Prabhakar,

On Wed, 29 Apr 2026 at 19:00, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> The RZ/T2H (R9A09G077) SoC includes a DU with a DPI interface,
> supporting resolutions up to WXGA with two RPFs for layer blending.
> Unlike earlier RZ/G2L SoCs, RZ/T2H requires explicit assertion of a
> DPI output-enable signal (DU_MCR0_DPI_EN) during CRTC startup.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

Thanks for your patch!

> --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> @@ -20,6 +20,8 @@
>  struct device;
>  struct drm_property;
>
> +#define RZG2L_DU_FEATURE_DPIO_OE       BIT(0)  /* Has DPIO output enable control */

Note that this addition conflicts with

    #define RZG2L_DU_FEATURE_SMUX2_DSI_CLK BIT(0) /* Per output mux */

in "[PATCH v6 15/21] drm: renesas: rz-du: Add RZ/G3E support"
https://lore.kernel.org/11313371ef0b31cb5f014e171ba0d9868eb0710d.1775636898.git.tommaso.merciai.xr@bp.renesas.com/

> +
>  enum rzg2l_du_output {
>         RZG2L_DU_OUTPUT_DSI0,
>         RZG2L_DU_OUTPUT_DPAD0,

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 4/4] drm: renesas: rz-du: Add support for RZ/T2H SoC

[Lad, Prabhakar]

Hi Geert,

On Thu, Apr 30, 2026 at 8:55 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Prabhakar,
>
> On Wed, 29 Apr 2026 at 19:00, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > The RZ/T2H (R9A09G077) SoC includes a DU with a DPI interface,
> > supporting resolutions up to WXGA with two RPFs for layer blending.
> > Unlike earlier RZ/G2L SoCs, RZ/T2H requires explicit assertion of a
> > DPI output-enable signal (DU_MCR0_DPI_EN) during CRTC startup.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Thanks for your patch!
>
> > --- a/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > +++ b/drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> > @@ -20,6 +20,8 @@
> >  struct device;
> >  struct drm_property;
> >
> > +#define RZG2L_DU_FEATURE_DPIO_OE       BIT(0)  /* Has DPIO output enable control */
>
> Note that this addition conflicts with
>
>     #define RZG2L_DU_FEATURE_SMUX2_DSI_CLK BIT(0) /* Per output mux */
>
> in "[PATCH v6 15/21] drm: renesas: rz-du: Add RZ/G3E support"
> https://lore.kernel.org/11313371ef0b31cb5f014e171ba0d9868eb0710d.1775636898.git.tommaso.merciai.xr@bp.renesas.com/
>
Tommaso has kindly agreed to rebase his patches on top of T2H, as the
G3E DU design is still under discussion, and the T2H DU pipeline is
simpler than the G3E one.

Cheers,
Prabhakar

> > +
> >  enum rzg2l_du_output {
> >         RZG2L_DU_OUTPUT_DSI0,
> >         RZG2L_DU_OUTPUT_DPAD0,
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Claude review: Add DU support for RZ/T2H and RZ/N2H SoCs

[Claude Code Review Bot]

Overall Series Review

Subject: Add DU support for RZ/T2H and RZ/N2H SoCs
Author: Prabhakar <prabhakar.csengg@gmail.com>
Patches: 7
Reviewed: 2026-05-05T11:22:42.358043

---

This is a well-structured 4-patch series adding Display Unit support for Renesas RZ/T2H and RZ/N2H SoCs. The series follows the existing driver patterns cleanly: dt-bindings first, then incremental driver changes. The overall design is sound — per-SoC clock limits and feature flags are the right abstraction for differentiating SoC variants.

However, there are several issues worth discussing, ranging from a binding design concern (the `port` vs `ports` approach), missing clock limits for existing SoCs, and the optional reset potentially weakening validation on existing platforms.

---

---
Generated by Claude Code Patch Reviewer

Claude review: dt-bindings: display: renesas, rzg2l-du: Add RZ/T2H and RZ/N2H support

[Claude Code Review Bot]

Patch Review

**The compatible strings and fallback pattern look fine.** The RZ/N2H→RZ/T2H fallback follows the established pattern used by RZ/V2L→RZ/G2L and RZ/V2N→RZ/V2H.

**Issue 1 — Removing `resets` and `ports` from global required list:**

```yaml
 required:
   - compatible
   - reg
   - interrupts
   - clocks
   - clock-names
-  - resets
   - power-domains
-  - ports
   - renesas,vsps
```

Removing `resets` and `ports` from the global `required` and conditionally adding them back in the `else` clause is workable, but the `else` clause will match _any_ compatible that does NOT contain `renesas,r9a09g077-du`. This is fine today but could be fragile if another SoC is added that also lacks a reset or uses `port` instead of `ports`. A more robust pattern would be to add an explicit `if` for the existing SoCs that require `resets`/`ports` rather than relying on an `else` that implicitly covers all non-T2H variants.

Actually, looking more carefully, the `else` is tied to the `r9a09g077-du` conditional:

```yaml
  - if:
      properties:
        compatible:
          contains:
            const: renesas,r9a09g077-du
    then:
      properties:
        resets: false
      required:
        - port
    else:
      required:
        - resets
        - ports
```

This is technically correct — the `else` covers all non-RZ/T2H variants, re-requiring `resets` and `ports`. But note that `resets: false` in the `then` clause actively forbids the property, which is a strong statement. The cover letter says "the DU does not have a reset line" — if that's definitive, this is fine, but it means DT authors can't even include an empty/stub reset on T2H. Confirm this is the hardware intent.

**Issue 2 — `port` vs `ports` with single port:**

The patch adds a new `port` property alongside the existing `ports`:

```yaml
  port:
    $ref: /schemas/graph.yaml#/properties/port
    description: Single output port for single-output DU variants.
```

The existing DU variants already handle single-output configurations using `ports` with a single `port@0` child (see the r9a07g043u and r9a09g057 cases). Using a bare `port` instead of `ports` for T2H creates an inconsistency in the binding. Consider whether `ports` with a single `port@0` child would be more consistent with the existing binding structure. This is a DT binding convention question that the DT maintainers (Rob/Krzysztof) should weigh in on.

**Issue 3 — No RZ/T2H-specific port description in allOf:**

The existing `allOf` blocks describe what each port represents (e.g., "DPI", "DSI"). The T2H `then` clause only requires `port` but doesn't add a description for what the port represents (presumably DPI). Minor but worth adding for consistency.

---
Generated by Claude Code Patch Reviewer

Claude review: drm: renesas: rz-du: Make DU reset control optional for RZ/T2H support

[Claude Code Review Bot]

Patch Review

The change itself is a single-line diff:

```c
-	rcrtc->rstc = devm_reset_control_get_shared(rcdu->dev, NULL);
+	rcrtc->rstc = devm_reset_control_get_optional_shared(rcdu->dev, NULL);
```

**Issue 1 — NULL reset not guarded in callers:**

When the reset is optional, `devm_reset_control_get_optional_shared()` returns `NULL` if no reset is specified in DT. The error path immediately after:

```c
	if (IS_ERR(rcrtc->rstc)) {
		dev_err(rcdu->dev, "can't get cpg reset\n");
		return PTR_ERR(rcrtc->rstc);
	}
```

This correctly handles the `IS_ERR` case, and `NULL` will pass through (not an error). However, we need to verify that all callers of `rcrtc->rstc` handle `NULL` safely. The reset control API (`reset_control_deassert`, `reset_control_assert`) does handle `NULL` arguments gracefully (they're no-ops), so this should be safe. This is fine.

**Issue 2 — Ordering concern:**

This patch makes the reset optional unconditionally for all SoCs, but the DT binding in patch 1 uses `resets: false` to forbid it only on T2H. The driver change is broader than the binding constraint, which is acceptable since the optional API is safe for all variants. But the commit message should clarify that the reset API itself is NULL-safe, so existing SoCs with resets continue to work unchanged.

**Minor — Error message is now misleading:**

The error log `"can't get cpg reset\n"` still triggers on failure, but since the reset is optional, the error path only fires for actual errors (not absence). This is fine, but the message could note it's a lookup error vs. absence.

---
Generated by Claude Code Patch Reviewer

Claude review: drm: renesas: rz-du: Move mode_valid logic to per-SoC clock limits

[Claude Code Review Bot]

Patch Review

Good refactoring. The old code was:

```c
	if (renc->output == RZG2L_DU_OUTPUT_DPAD0 && mode->clock > 83500)
		return MODE_CLOCK_HIGH;
```

The new code:

```c
	const struct rzg2l_du_device_info *info = renc->info;

	if (info->mode_clock_min && mode->clock < info->mode_clock_min)
		return MODE_CLOCK_LOW;
	if (info->mode_clock_max && mode->clock > info->mode_clock_max)
		return MODE_CLOCK_HIGH;
```

**Issue 1 — Only r9a07g043u gets clock limits; r9a07g044 and r9a09g057 are left at 0:**

```c
 static const struct rzg2l_du_device_info rzg2l_du_r9a07g043u_info = {
 	...
+	.mode_clock_min = 20875,
+	.mode_clock_max = 83500,
 };
```

But `rzg2l_du_r9a07g044_info` and `rzg2l_du_r9a09g057_info` have no clock limits added, so `.mode_clock_min` and `.mode_clock_max` remain zero. The `0` check skips validation when these fields are zero, which means **the 83.5 MHz limit is silently removed for r9a07g044** (RZ/G2L). The old code applied the 83500 cap to all DPAD0 outputs. If RZ/G2L has the same pixel clock constraint (it likely does — it's the same DU IP), this is a regression.

The r9a09g057 (RZ/V2H) only has DSI0 output, so the old code never capped it anyway — no change there.

**The r9a07g044 needs `.mode_clock_max = 83500` added** to preserve the existing behavior.

**Issue 2 — The output-type check is dropped:**

The old code only applied the cap to `RZG2L_DU_OUTPUT_DPAD0`, not `DSI0`. The new code applies the clock limits regardless of output type. For r9a07g044 which has both DSI0 and DPAD0, the DSI output may have different clock constraints than DPAD. Moving to per-SoC limits loses the per-output-type granularity. This may be fine if the clock limits truly apply to the DU block itself rather than the output interface, but the commit message should address this design choice.

**Issue 3 — Storing `info` pointer in encoder:**

```c
+	renc->info = rcdu->info;
```

The encoder could access the device info through `renc->base.dev->dev_private` or similar DRM device traversal instead of storing a redundant pointer. However, this is a minor style point — the direct pointer is cleaner for the `mode_valid` hot path and matches patterns seen in other drivers. Acceptable.

---
Generated by Claude Code Patch Reviewer

Claude review: drm: renesas: rz-du: Add support for RZ/T2H SoC

[Claude Code Review Bot]

Patch Review

The core enablement patch. Adds the device info, feature flag, and DPI output enable handling.

**The feature flag design is clean:**

```c
#define RZG2L_DU_FEATURE_DPIO_OE	BIT(0)

static inline bool rzg2l_du_has(struct rzg2l_du_device *rcdu,
				unsigned int feature)
{
	return rcdu->info->features & feature;
}
```

**The start/stop logic looks correct:**

```c
 static void rzg2l_du_start_stop(struct rzg2l_du_crtc *rcrtc, bool start)
 {
 	struct rzg2l_du_device *rcdu = rcrtc->dev;
+	u32 val = DU_MCR0_DI_EN;
 
-	writel(start ? DU_MCR0_DI_EN : 0, rcdu->mmio + DU_MCR0);
+	if (start && rzg2l_du_has(rcdu, RZG2L_DU_FEATURE_DPIO_OE))
+		val |= DU_MCR0_DPI_EN;
+
+	writel(start ? val : 0, rcdu->mmio + DU_MCR0);
 }
```

When `start` is false, the write is `0` regardless — clearing both DI_EN and DPI_EN. When `start` is true, DPI_EN is conditionally ORed in. This is correct.

**Issue 1 — `val` initialization is misleading when `start` is false:**

`val` is always initialized to `DU_MCR0_DI_EN` even when `start` is false, in which case it's unused (the ternary writes `0`). This is harmless but slightly confusing — a reader might wonder if `val` matters when `start` is false. The logic is correct but could be clearer with a restructure. Very minor.

**Issue 2 — RZ/T2H device info uses `.port = 0` for DPAD0:**

```c
+static const struct rzg2l_du_device_info rzg2l_du_r9a09g077_info = {
+	.channels_mask = BIT(0),
+	.routes = {
+		[RZG2L_DU_OUTPUT_DPAD0] = {
+			.possible_outputs = BIT(0),
+			.port = 0,
+		},
+	},
```

This matches the DT binding where T2H uses a bare `port` instead of `ports/port@0`. But the driver's `rzg2l_du_modeset_init()` function uses `of_graph_get_remote_node()` which takes a port number. We should verify that `of_graph_get_remote_node(rcdu->dev->of_node, 0, 0)` works with a bare `port` property (no `ports` container). The OF graph API does support bare `port` nodes — it falls through from looking for `ports/port@N` to looking for `port` when there's only one port. So this should work, but it's worth a quick sanity check.

**Issue 3 — The `features` field doc appears in patch 4 but struct changes span patches 3 and 4:**

In patch 3, `mode_clock_min` and `mode_clock_max` are added to the struct with documentation. In patch 4, `features` is added. The kernel-doc comment for the struct is updated incrementally across both patches, which is fine.

**Overall the patch is clean.** The feature flag mechanism and conditional DPI_EN assertion are well done.

---
Generated by Claude Code Patch Reviewer