RE: [PATCH 1/4] dt-bindings: display: renesas,rzg2l-du: Add RZ/T2H and RZ/N2H support
From: Biju Das
Date: Thu May 07 2026 - 06:54:53 EST
Hi Laurent,
Thanks for the feedback.
> -----Original Message-----
> From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxx>
> > > > >
> > > > > 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