Hi Laurent and Rob,
Thanks for the feedback
> -----Original Message-----
> From: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx>
> Sent: Tuesday, August 13, 2024 8:39 PM
> Subject: Re: [PATCH v3 1/4] dt-bindings: display: renesas,rzg2l-du: Document RZ/G2UL DU bindings
>
> Hi Rob,
>
> On Tue, Aug 13, 2024 at 10:32:20AM -0600, Rob Herring wrote:
> > On Mon, Aug 05, 2024 at 04:52:35PM +0100, Biju Das wrote:
> > > Document DU found in RZ/G2UL SoC. The DU block is identical to
> > > RZ/G2L SoC, but has only DPI interface.
> > >
> > > While at it, add missing required property port@1 for RZ/G2L and
> > > RZ/V2L SoCs. Currently there is no user for the DPI interface and
> > > hence there won't be any ABI breakage for adding port@1 as required
> > > property for RZ/G2L and RZ/V2L SoCs.
> > >
> > > Signed-off-by: Biju Das <biju.das.jz@xxxxxxxxxxxxxx>
> > > ---
> > > v2->v3:
> > > * Replaced ports->port property for RZ/G2UL as it supports only DPI.
> > > and retained ports property for RZ/{G2L,V2L} as it supports both DSI
> > > and DPI output interface.
> >
> > Why? Having port and ports is just a needless complication.
>
> I agree that making the ports node mandatory, even when the device has a single port, will simplify
> the bindings. In hindsight we should never have made ports optional, but that can't be changed.
>
> > > * Added missing blank line before example.
> > > * Dropped tags from Conor and Geert as there are new changes.
> > > v1->v2:
> > > * Updated commit description related to non ABI breakage.
> > > * Added Ack from Conor.
> > > ---
> > > .../bindings/display/renesas,rzg2l-du.yaml | 35 +++++++++++++++++--
> > > 1 file changed, 32 insertions(+), 3 deletions(-)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > index 08e5b9478051..ca01bf26c4c0 100644
> > > ---
> > > a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yam
> > > +++ l
> > > @@ -18,6 +18,7 @@ properties:
> > > compatible:
> > > oneOf:
> > > - enum:
> > > + - renesas,r9a07g043u-du # RZ/G2UL
> > > - renesas,r9a07g044-du # RZ/G2{L,LC}
> > > - items:
> > > - enum:
> > > @@ -60,8 +61,9 @@ properties:
> > > $ref: /schemas/graph.yaml#/properties/port
> > > unevaluatedProperties: false
> > >
> > > - required:
> > > - - port@0
> > > + port:
> > > + $ref: /schemas/graph.yaml#/properties/port
> > > + description: Connection to the DU output video port.
> > >
> > > unevaluatedProperties: false
> > >
> > > @@ -83,11 +85,38 @@ required:
> > > - clock-names
> > > - resets
> > > - power-domains
> > > - - ports
> > > - renesas,vsps
> > >
> > > additionalProperties: false
> > >
> > > +allOf:
> > > + - if:
> > > + properties:
> > > + compatible:
> > > + contains:
> > > + const: renesas,r9a07g043u-du
> > > + then:
> > > + properties:
> > > + port:
> > > + description: DPI
> >
> > This is equivalent to 'port@0'. IMO, this case should have a 'port@1'
> > node so that DPI interface is *always* the same port.
>
> That's what Biju did in the previous version, and I recommended to number the ports based on hardware
> indices, not types. Mapping port numbers to the hardware documentation makes it more consistent for DT
> writers, makes the logic simpler to understand (in my opinion, based on my experience with the R-Car
> DU) on the driver side, but most importantly, type-based numbering wouldn't scale as SoCs could have
> multiple ports of the same type (we've seen that happening with R-Car).
OK, I will send bindings based on hardware indices.
Cheers,
Biju
>
> > > +
> > > + required:
> > > + - port
> > > + else:
> > > + properties:
> > > + ports:
> > > + properties:
> > > + port@0:
> > > + description: DSI
> > > + port@1:
> > > + description: DPI
> > > +
> > > + required:
> > > + - port@0
> > > + - port@1
> > > + required:
> > > + - ports
> > > +
> > > examples:
> > > # RZ/G2L DU
> > > - |
>
> --
> Regards,
>
> Laurent Pinchart
