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

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

[Rob Herring (Arm)]

On Wed, 29 Apr 2026 18:00:09 +0100, Prabhakar wrote:
> 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(-)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

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

[Laurent Pinchart]

Hi Prabhakar,

Thank you for the patch.

On Wed, Apr 29, 2026 at 06:00:09PM +0100, Prabhakar wrote:
> 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.

Wouldn't it be simpler to always have a "ports" node, even for variants
with a single port ?

> 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

-- 
Regards,

Laurent Pinchart

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

[Lad, Prabhakar]

Hi Laurent,

Thank you for the review.

On Wed, May 6, 2026 at 8:50 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Wed, Apr 29, 2026 at 06:00:09PM +0100, Prabhakar wrote:
> > 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.
>
> Wouldn't it be simpler to always have a "ports" node, even for variants
> with a single port ?
>
I agree that, from a binding perspective, always having a "ports" node
keeps things simpler and consistent. Biju suggested this change based
on earlier feedback for the RZ/G3E series.

Cheers,
Prabhakar

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

[Biju Das]

Hi Laurent/Prabhakar,

> -----Original Message-----
> From: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> Sent: 06 May 2026 20:58
> Subject: Re: [PATCH 1/4] dt-bindings: display: renesas,rzg2l-du: Add RZ/T2H and RZ/N2H support
> 
> Hi Laurent,
> 
> Thank you for the review.
> 
> On Wed, May 6, 2026 at 8:50 PM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> >
> > Hi Prabhakar,
> >
> > Thank you for the patch.
> >
> > On Wed, Apr 29, 2026 at 06:00:09PM +0100, Prabhakar wrote:
> > > 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.
> >
> > Wouldn't it be simpler to always have a "ports" node, even for
> > variants with a single port ?
> >
> I agree that, from a binding perspective, always having a "ports" node keeps things simpler and
> consistent. Biju suggested this change based on earlier feedback for the RZ/G3E series.

From G3E feedback, I got the impression that going forward all future SoCs needs to have
single port and multiple endpoints. That is the reason for suggesting port for new SoCs.

Cheers,
Biju

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

[Laurent Pinchart]

On Thu, May 07, 2026 at 09:24:48AM +0000, Biju Das wrote:
> On 06 May 2026 20:58, Lad, Prabhakar wrote:
> > On Wed, May 6, 2026 at 8:50 PM Laurent Pinchart wrote:
> > > On Wed, Apr 29, 2026 at 06:00:09PM +0100, Prabhakar wrote:
> > > > 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.
> > >
> > > Wouldn't it be simpler to always have a "ports" node, even for
> > > variants with a single port ?
> > >
> > I agree that, from a binding perspective, always having a "ports" node keeps things simpler and
> > consistent. Biju suggested this change based on earlier feedback for the RZ/G3E series.
> 
> From G3E feedback, I got the impression that going forward all future SoCs needs to have
> single port and multiple endpoints. That is the reason for suggesting port for new SoCs.

Right, let's clarify that.

TL;DR: it depends on the hardware architecture (what a surprise :-))

When reviewing the G3E, I noticed that the LCDC has a single output that
is connected to one or multiple encoders, depending on the SoC. I think
this should be modeled in DT with a single port.

Note that this does not preclude using a "ports" node, containing a
single "port@0". If you're confident enough that no future generation
will require multiple ports, then it makes sense to standardize on a
single "port" node and no "ports". If, on the other hand, you think that
some SoCs would have multiple ports, then using a top-level "ports" node
unconditionally would lead to simpler bindings.

I'll let you all decide what you think is the most suitable approach.

-- 
Regards,

Laurent Pinchart

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

[Biju Das]

Hi Laurent,

Thanks for the feedback.

> -----Original Message-----
> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Sent: 07 May 2026 11:39
> Subject: Re: [PATCH 1/4] dt-bindings: display: renesas,rzg2l-du: Add RZ/T2H and RZ/N2H support
> 
> On Thu, May 07, 2026 at 09:24:48AM +0000, Biju Das wrote:
> > On 06 May 2026 20:58, Lad, Prabhakar wrote:
> > > On Wed, May 6, 2026 at 8:50 PM Laurent Pinchart wrote:
> > > > On Wed, Apr 29, 2026 at 06:00:09PM +0100, Prabhakar wrote:
> > > > > 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.
> > > >
> > > > Wouldn't it be simpler to always have a "ports" node, even for
> > > > variants with a single port ?
> > > >
> > > I agree that, from a binding perspective, always having a "ports"
> > > node keeps things simpler and consistent. Biju suggested this change based on earlier feedback for
> the RZ/G3E series.
> >
> > From G3E feedback, I got the impression that going forward all future
> > SoCs needs to have single port and multiple endpoints. That is the reason for suggesting port for new
> SoCs.
> 
> Right, let's clarify that.
> 
> TL;DR: it depends on the hardware architecture (what a surprise :-))
> 
> When reviewing the G3E, I noticed that the LCDC has a single output that is connected to one or
> multiple encoders, depending on the SoC. I think this should be modeled in DT with a single port.

OK.

> 
> Note that this does not preclude using a "ports" node, containing a single "port@0". If you're
> confident enough that no future generation will require multiple ports, then it makes sense to
> standardize on a single "port" node and no "ports". If, on the other hand, you think that some SoCs
> would have multiple ports, then using a top-level "ports" node unconditionally would lead to simpler
> bindings.

OK.

> 
> I'll let you all decide what you think is the most suitable approach.

Thanks for the advice. We will use ports that will make the binding simpler.
We will continue to use ports for SoCs which has single output connected to
Single encoder(RZ/T2H) as well as multiple encoders(RZ/G3{E,L}).

Cheers,
Biju

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

[Lad, Prabhakar]

Hi Biju, Laurent,

On Thu, May 7, 2026 at 11:54 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
>
> Hi Laurent,
>
> Thanks for the feedback.
>
> > -----Original Message-----
> > From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Sent: 07 May 2026 11:39
> > Subject: Re: [PATCH 1/4] dt-bindings: display: renesas,rzg2l-du: Add RZ/T2H and RZ/N2H support
> >
> > On Thu, May 07, 2026 at 09:24:48AM +0000, Biju Das wrote:
> > > On 06 May 2026 20:58, Lad, Prabhakar wrote:
> > > > On Wed, May 6, 2026 at 8:50 PM Laurent Pinchart wrote:
> > > > > On Wed, Apr 29, 2026 at 06:00:09PM +0100, Prabhakar wrote:
> > > > > > 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.
> > > > >
> > > > > Wouldn't it be simpler to always have a "ports" node, even for
> > > > > variants with a single port ?
> > > > >
> > > > I agree that, from a binding perspective, always having a "ports"
> > > > node keeps things simpler and consistent. Biju suggested this change based on earlier feedback for
> > the RZ/G3E series.
> > >
> > > From G3E feedback, I got the impression that going forward all future
> > > SoCs needs to have single port and multiple endpoints. That is the reason for suggesting port for new
> > SoCs.
> >
> > Right, let's clarify that.
> >
> > TL;DR: it depends on the hardware architecture (what a surprise :-))
> >
> > When reviewing the G3E, I noticed that the LCDC has a single output that is connected to one or
> > multiple encoders, depending on the SoC. I think this should be modeled in DT with a single port.
>
> OK.
>
> >
> > Note that this does not preclude using a "ports" node, containing a single "port@0". If you're
> > confident enough that no future generation will require multiple ports, then it makes sense to
> > standardize on a single "port" node and no "ports". If, on the other hand, you think that some SoCs
> > would have multiple ports, then using a top-level "ports" node unconditionally would lead to simpler
> > bindings.
>
> OK.
>
> >
> > I'll let you all decide what you think is the most suitable approach.
>
> Thanks for the advice. We will use ports that will make the binding simpler.
> We will continue to use ports for SoCs which has single output connected to
> Single encoder(RZ/T2H) as well as multiple encoders(RZ/G3{E,L}).
>
As agreed, I will switch back to the ports property.

Cheers,
Prabhakar

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

[Laurent Pinchart]

On Wed, Apr 29, 2026 at 06:00:10PM +0100, Prabhakar wrote:
> 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.

This assume a device tree compliant with the bindings. In case of a
non-compliant device tree on platforms other than RZ/T2H, the driver may
silently fail to work as it won't complain about the lack of reset. I
think that's acceptable, as the reset should be specified in the SoC's
.dtsi. If if was the responsibility of board DT authors I would be a bit
more concerned.

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

> 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);

-- 
Regards,

Laurent Pinchart

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

[Lad, Prabhakar]

Hi Laurent,

Thank you for the review.

On Wed, May 6, 2026 at 9:08 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Wed, Apr 29, 2026 at 06:00:10PM +0100, Prabhakar wrote:
> > 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.
>
> This assume a device tree compliant with the bindings. In case of a
> non-compliant device tree on platforms other than RZ/T2H, the driver may
> silently fail to work as it won't complain about the lack of reset. I
> think that's acceptable, as the reset should be specified in the SoC's
> .dtsi. If if was the responsibility of board DT authors I would be a bit
> more concerned.
>
I agree. Since the reset is expected to be defined in the SoC-level
.dtsi and dtbs checks do complain if it is missed.

Cheers,
Prabhakar

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

[Laurent Pinchart]

On Wed, Apr 29, 2026 at 06:00:11PM +0100, Prabhakar wrote:
> 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;

You could use

	struct rzg2l_du_device *rcdu = to_rzg2l_du_device(renc->base.dev);
	const struct rzg2l_du_device_info *info = rcdu->info;

and avoid the info pointer in struct rzg2l_du_encoder. Up to you.

>  
> -	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;

The new check now applies to all outputs, not just the DPAD0 output. Is
that intentional ?

>  
>  	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;

If you want to keep a pointer here to avoid going through
to_rzg2l_du_device(), I would store a backpointer to rzg2l_du_device
instead of just an info pointer, it could come handy in other places.

>  };
>  
>  static inline struct rzg2l_du_encoder *to_rzg2l_encoder(struct drm_encoder *e)

-- 
Regards,

Laurent Pinchart

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

[Lad, Prabhakar]

Hi Laurent,

Thank you for the review.

On Wed, May 6, 2026 at 9:14 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Wed, Apr 29, 2026 at 06:00:11PM +0100, Prabhakar wrote:
> > 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;
>
> You could use
>
>         struct rzg2l_du_device *rcdu = to_rzg2l_du_device(renc->base.dev);
>         const struct rzg2l_du_device_info *info = rcdu->info;
>
> and avoid the info pointer in struct rzg2l_du_encoder. Up to you.
>
Agreed, I will drop the info pointer for now.

> >
> > -     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;
>
> The new check now applies to all outputs, not just the DPAD0 output. Is
> that intentional ?
>
The RZ/G2UL SoC only supports DPAD0 so the check is redundant.

> >
> >       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;
>
> If you want to keep a pointer here to avoid going through
> to_rzg2l_du_device(), I would store a backpointer to rzg2l_du_device
> instead of just an info pointer, it could come handy in other places.
>
As agreed above I will drop this pointer for now.

Cheers,
Prabhakar

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

[Laurent Pinchart]

On Fri, May 08, 2026 at 11:00:15AM +0100, Lad, Prabhakar wrote:
> On Wed, May 6, 2026 at 9:14 PM Laurent Pinchart wrote:
> > On Wed, Apr 29, 2026 at 06:00:11PM +0100, Prabhakar wrote:
> > > 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;
> >
> > You could use
> >
> >         struct rzg2l_du_device *rcdu = to_rzg2l_du_device(renc->base.dev);
> >         const struct rzg2l_du_device_info *info = rcdu->info;
> >
> > and avoid the info pointer in struct rzg2l_du_encoder. Up to you.
> 
> Agreed, I will drop the info pointer for now.
> 
> > >
> > > -     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;
> >
> > The new check now applies to all outputs, not just the DPAD0 output. Is
> > that intentional ?
> 
> The RZ/G2UL SoC only supports DPAD0 so the check is redundant.

Ah right. Please mention that in the commit message.

> > >
> > >       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;
> >
> > If you want to keep a pointer here to avoid going through
> > to_rzg2l_du_device(), I would store a backpointer to rzg2l_du_device
> > instead of just an info pointer, it could come handy in other places.
> 
> As agreed above I will drop this pointer for now.

-- 
Regards,

Laurent Pinchart

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

[Laurent Pinchart]

On Wed, Apr 29, 2026 at 06:00:12PM +0100, Prabhakar 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>

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.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__ */

-- 
Regards,

Laurent Pinchart