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@xxxxxxxxxxxxxx> wrote:
>
> 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}).
>
As agreed, I will switch back to the ports property.

Cheers,
Prabhakar