diff mbox series

[PATCH/RFC,2/6] dt-bindings: display: bridge: renesas,dw-hdmi: Convert binding to YAML

Message ID 20200405233935.27599-3-laurent.pinchart+renesas@ideasonboard.com (mailing list archive)
State New
Delegated to: Kieran Bingham
Headers show
Series dt-bindings: display: Convert DWC HDMI TX bindings to YAML | expand

Commit Message

Laurent Pinchart April 5, 2020, 11:39 p.m. UTC
Convert the Renesas R-Car DWC HDMI TX text binding to YAML.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
 .../display/bridge/renesas,dw-hdmi.txt        |  86 -----------
 .../display/bridge/renesas,dw-hdmi.yaml       | 142 ++++++++++++++++++
 2 files changed, 142 insertions(+), 86 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
 create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml

Comments

Maxime Ripard April 6, 2020, 7:57 a.m. UTC | #1
Hi,

On Mon, Apr 06, 2020 at 02:39:31AM +0300, Laurent Pinchart wrote:
> diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
> new file mode 100644
> index 000000000000..9a543740c81d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
> @@ -0,0 +1,142 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/renesas,dw-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas R-Car DWC HDMI TX Encoder
> +
> +maintainers:
> +  - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> +
> +description: |
> +  The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> +  with a companion PHY IP.
> +
> +allOf:
> +  - $ref: synopsys,dw-hdmi.yaml#
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +        - renesas,r8a774a1-hdmi # for R8A774A1 (RZ/G2M) compatible HDMI TX
> +        - renesas,r8a774b1-hdmi # for R8A774B1 (RZ/G2N) compatible HDMI TX
> +        - renesas,r8a7795-hdmi # for R8A7795 (R-Car H3) compatible HDMI TX
> +        - renesas,r8a7796-hdmi # for R8A7796 (R-Car M3-W) compatible HDMI TX
> +        - renesas,r8a77965-hdmi # for R8A77965 (R-Car M3-N) compatible HDMI TX
> +      - const: renesas,rcar-gen3-hdmi
> +
> +  reg: true
> +
> +  reg-io-width:
> +    const: 1
> +
> +  clocks:
> +    minItems: 2
> +    maxItems: 2

You don't need both, if one is missing the other will be filled by the
dt-schema tools. In this particular case, I guess maxItems would make
more sense.

> +
> +  clock-names:
> +    items:
> +      - const: iahb
> +      - const: isfr
> +
> +  interrupts: true
> +
> +  ports:
> +    type: object
> +    description: |
> +      This device has three video ports. Their connections are modelled using the
> +      OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +      Each port shall have a single endpoint.
> +
> +    properties:
> +      '#address-cells':
> +        const: 1
> +
> +      '#size-cells':
> +        const: 0
> +
> +      port@0:
> +        type: object
> +        description: Parallel RGB input port
> +
> +      port@1:
> +        type: object
> +        description: HDMI output port
> +
> +      port@2:
> +        type: object
> +        description: Sound input port
> +
> +    required:
> +      - port@0
> +      - port@1
> +      - port@2
> +
> +    additionalProperties: false
> +
> +  power-domains:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - interrupts
> +  - ports
> +
> +additionalProperties: false

In the case where you have some kind of generic schema and then a more
specific one like you have here, unevaluatedProperties make more sense
that additionalProperties.

additionalProperties checks that there are no extra properties on the
current schema, which is a problem here since you have to duplicate
the entire list of properties found in the generic schema, while
unevaluatedProperties checks that there are no extra properties in the
entire set of all schemas that apply to this node.

This way, you can just put what is different from the generic schema,
and you don't have to keep it in sync.

It's a feature that has been added in the spec of the schemas that
went on right after the one we support in the tools, so for now the
kernel meta-schemas only allows that property to be there (just like
deprecated) but won't do anything.

This should be fixed quite soon however, the library we depend on
has started to work on that spec apparently.

Maxime
Geert Uytterhoeven April 6, 2020, 8:51 a.m. UTC | #2
Hi Laurent,

On Mon, Apr 6, 2020 at 1:40 AM Laurent Pinchart
<laurent.pinchart+renesas@ideasonboard.com> wrote:
> Convert the Renesas R-Car DWC HDMI TX text binding to YAML.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Thanks for your patch!

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml

> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +        - renesas,r8a774a1-hdmi # for R8A774A1 (RZ/G2M) compatible HDMI TX
> +        - renesas,r8a774b1-hdmi # for R8A774B1 (RZ/G2N) compatible HDMI TX
> +        - renesas,r8a7795-hdmi # for R8A7795 (R-Car H3) compatible HDMI TX
> +        - renesas,r8a7796-hdmi # for R8A7796 (R-Car M3-W) compatible HDMI TX

R8A77960 (I know you don't support R8A77961 yet ;-)

> +        - renesas,r8a77965-hdmi # for R8A77965 (R-Car M3-N) compatible HDMI TX

Wouldn't it be sufficient to just have the SoC name (e.g. "R-Car M3-N") in
the comments?

> +      - const: renesas,rcar-gen3-hdmi

# R-Car Gen3 and RZ/G2

> +examples:
> +  - |
> +    #include <dt-bindings/clock/r8a7795-cpg-mssr.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/power/r8a7795-sysc.h>
> +
> +    hdmi@fead0000 {
> +        compatible = "renesas,r8a7795-hdmi", "renesas,rcar-gen3-hdmi";
> +        reg = <0 0xfead0000 0 0x10000>;

Examples are built with #{address,size}-cells = <1>.

Gr{oetje,eeting}s,

                        Geert
Laurent Pinchart April 6, 2020, 11:28 a.m. UTC | #3
Hi Maxime,

On Mon, Apr 06, 2020 at 09:57:05AM +0200, Maxime Ripard wrote:
> On Mon, Apr 06, 2020 at 02:39:31AM +0300, Laurent Pinchart wrote:
> > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
> > new file mode 100644
> > index 000000000000..9a543740c81d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
> > @@ -0,0 +1,142 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/renesas,dw-hdmi.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Renesas R-Car DWC HDMI TX Encoder
> > +
> > +maintainers:
> > +  - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > +
> > +description: |
> > +  The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> > +  with a companion PHY IP.
> > +
> > +allOf:
> > +  - $ref: synopsys,dw-hdmi.yaml#
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - enum:
> > +        - renesas,r8a774a1-hdmi # for R8A774A1 (RZ/G2M) compatible HDMI TX
> > +        - renesas,r8a774b1-hdmi # for R8A774B1 (RZ/G2N) compatible HDMI TX
> > +        - renesas,r8a7795-hdmi # for R8A7795 (R-Car H3) compatible HDMI TX
> > +        - renesas,r8a7796-hdmi # for R8A7796 (R-Car M3-W) compatible HDMI TX
> > +        - renesas,r8a77965-hdmi # for R8A77965 (R-Car M3-N) compatible HDMI TX
> > +      - const: renesas,rcar-gen3-hdmi
> > +
> > +  reg: true
> > +
> > +  reg-io-width:
> > +    const: 1
> > +
> > +  clocks:
> > +    minItems: 2
> > +    maxItems: 2
> 
> You don't need both, if one is missing the other will be filled by the
> dt-schema tools. In this particular case, I guess maxItems would make
> more sense.

Fixed.

> > +
> > +  clock-names:
> > +    items:
> > +      - const: iahb
> > +      - const: isfr
> > +
> > +  interrupts: true
> > +
> > +  ports:
> > +    type: object
> > +    description: |
> > +      This device has three video ports. Their connections are modelled using the
> > +      OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > +      Each port shall have a single endpoint.
> > +
> > +    properties:
> > +      '#address-cells':
> > +        const: 1
> > +
> > +      '#size-cells':
> > +        const: 0
> > +
> > +      port@0:
> > +        type: object
> > +        description: Parallel RGB input port
> > +
> > +      port@1:
> > +        type: object
> > +        description: HDMI output port
> > +
> > +      port@2:
> > +        type: object
> > +        description: Sound input port
> > +
> > +    required:
> > +      - port@0
> > +      - port@1
> > +      - port@2
> > +
> > +    additionalProperties: false
> > +
> > +  power-domains:
> > +    maxItems: 1
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - clocks
> > +  - clock-names
> > +  - interrupts
> > +  - ports
> > +
> > +additionalProperties: false
> 
> In the case where you have some kind of generic schema and then a more
> specific one like you have here, unevaluatedProperties make more sense
> that additionalProperties.
> 
> additionalProperties checks that there are no extra properties on the
> current schema, which is a problem here since you have to duplicate
> the entire list of properties found in the generic schema, while
> unevaluatedProperties checks that there are no extra properties in the
> entire set of all schemas that apply to this node.
> 
> This way, you can just put what is different from the generic schema,
> and you don't have to keep it in sync.
> 
> It's a feature that has been added in the spec of the schemas that
> went on right after the one we support in the tools, so for now the
> kernel meta-schemas only allows that property to be there (just like
> deprecated) but won't do anything.
> 
> This should be fixed quite soon however, the library we depend on
> has started to work on that spec apparently.

Should I postpone this series until support for unevaluatedProperties is
available, to be able to test this ?
Laurent Pinchart April 6, 2020, 11:32 a.m. UTC | #4
Hallo again,

On Mon, Apr 06, 2020 at 02:28:57PM +0300, Laurent Pinchart wrote:
> On Mon, Apr 06, 2020 at 09:57:05AM +0200, Maxime Ripard wrote:
> > On Mon, Apr 06, 2020 at 02:39:31AM +0300, Laurent Pinchart wrote:
> > > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
> > > new file mode 100644
> > > index 000000000000..9a543740c81d
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
> > > @@ -0,0 +1,142 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/display/bridge/renesas,dw-hdmi.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Renesas R-Car DWC HDMI TX Encoder
> > > +
> > > +maintainers:
> > > +  - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > > +
> > > +description: |
> > > +  The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
> > > +  with a companion PHY IP.
> > > +
> > > +allOf:
> > > +  - $ref: synopsys,dw-hdmi.yaml#
> > > +
> > > +properties:
> > > +  compatible:
> > > +    items:
> > > +      - enum:
> > > +        - renesas,r8a774a1-hdmi # for R8A774A1 (RZ/G2M) compatible HDMI TX
> > > +        - renesas,r8a774b1-hdmi # for R8A774B1 (RZ/G2N) compatible HDMI TX
> > > +        - renesas,r8a7795-hdmi # for R8A7795 (R-Car H3) compatible HDMI TX
> > > +        - renesas,r8a7796-hdmi # for R8A7796 (R-Car M3-W) compatible HDMI TX
> > > +        - renesas,r8a77965-hdmi # for R8A77965 (R-Car M3-N) compatible HDMI TX
> > > +      - const: renesas,rcar-gen3-hdmi
> > > +
> > > +  reg: true
> > > +
> > > +  reg-io-width:
> > > +    const: 1
> > > +
> > > +  clocks:
> > > +    minItems: 2
> > > +    maxItems: 2
> > 
> > You don't need both, if one is missing the other will be filled by the
> > dt-schema tools. In this particular case, I guess maxItems would make
> > more sense.
> 
> Fixed.
> 
> > > +
> > > +  clock-names:
> > > +    items:
> > > +      - const: iahb
> > > +      - const: isfr
> > > +
> > > +  interrupts: true
> > > +
> > > +  ports:
> > > +    type: object
> > > +    description: |
> > > +      This device has three video ports. Their connections are modelled using the
> > > +      OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > > +      Each port shall have a single endpoint.
> > > +
> > > +    properties:
> > > +      '#address-cells':
> > > +        const: 1
> > > +
> > > +      '#size-cells':
> > > +        const: 0
> > > +
> > > +      port@0:
> > > +        type: object
> > > +        description: Parallel RGB input port
> > > +
> > > +      port@1:
> > > +        type: object
> > > +        description: HDMI output port
> > > +
> > > +      port@2:
> > > +        type: object
> > > +        description: Sound input port
> > > +
> > > +    required:
> > > +      - port@0
> > > +      - port@1
> > > +      - port@2
> > > +
> > > +    additionalProperties: false

Would it also make sense to use unevaluatedProperties here, and drop
#address-cells and #size-cells above as they're already evaluated in
synopsys,dw-hdmi.yaml ?

> > > +
> > > +  power-domains:
> > > +    maxItems: 1
> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +  - clocks
> > > +  - clock-names
> > > +  - interrupts
> > > +  - ports
> > > +
> > > +additionalProperties: false
> > 
> > In the case where you have some kind of generic schema and then a more
> > specific one like you have here, unevaluatedProperties make more sense
> > that additionalProperties.
> > 
> > additionalProperties checks that there are no extra properties on the
> > current schema, which is a problem here since you have to duplicate
> > the entire list of properties found in the generic schema, while
> > unevaluatedProperties checks that there are no extra properties in the
> > entire set of all schemas that apply to this node.
> > 
> > This way, you can just put what is different from the generic schema,
> > and you don't have to keep it in sync.
> > 
> > It's a feature that has been added in the spec of the schemas that
> > went on right after the one we support in the tools, so for now the
> > kernel meta-schemas only allows that property to be there (just like
> > deprecated) but won't do anything.
> > 
> > This should be fixed quite soon however, the library we depend on
> > has started to work on that spec apparently.
> 
> Should I postpone this series until support for unevaluatedProperties is
> available, to be able to test this ?

Also, to make sure I understand this correctly, does it mean I can drop
"reg: true" and "interrupts: true" ?
Maxime Ripard April 6, 2020, 5:04 p.m. UTC | #5
On Mon, Apr 06, 2020 at 02:32:47PM +0300, Laurent Pinchart wrote:
> > > > +
> > > > +  clock-names:
> > > > +    items:
> > > > +      - const: iahb
> > > > +      - const: isfr
> > > > +
> > > > +  interrupts: true
> > > > +
> > > > +  ports:
> > > > +    type: object
> > > > +    description: |
> > > > +      This device has three video ports. Their connections are modelled using the
> > > > +      OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > > > +      Each port shall have a single endpoint.
> > > > +
> > > > +    properties:
> > > > +      '#address-cells':
> > > > +        const: 1
> > > > +
> > > > +      '#size-cells':
> > > > +        const: 0
> > > > +
> > > > +      port@0:
> > > > +        type: object
> > > > +        description: Parallel RGB input port
> > > > +
> > > > +      port@1:
> > > > +        type: object
> > > > +        description: HDMI output port
> > > > +
> > > > +      port@2:
> > > > +        type: object
> > > > +        description: Sound input port
> > > > +
> > > > +    required:
> > > > +      - port@0
> > > > +      - port@1
> > > > +      - port@2
> > > > +
> > > > +    additionalProperties: false
>
> Would it also make sense to use unevaluatedProperties here, and drop
> #address-cells and #size-cells above as they're already evaluated in
> synopsys,dw-hdmi.yaml ?

Yup :)

> > > > +
> > > > +  power-domains:
> > > > +    maxItems: 1
> > > > +
> > > > +required:
> > > > +  - compatible
> > > > +  - reg
> > > > +  - clocks
> > > > +  - clock-names
> > > > +  - interrupts
> > > > +  - ports
> > > > +
> > > > +additionalProperties: false
> > >
> > > In the case where you have some kind of generic schema and then a more
> > > specific one like you have here, unevaluatedProperties make more sense
> > > that additionalProperties.
> > >
> > > additionalProperties checks that there are no extra properties on the
> > > current schema, which is a problem here since you have to duplicate
> > > the entire list of properties found in the generic schema, while
> > > unevaluatedProperties checks that there are no extra properties in the
> > > entire set of all schemas that apply to this node.
> > >
> > > This way, you can just put what is different from the generic schema,
> > > and you don't have to keep it in sync.
> > >
> > > It's a feature that has been added in the spec of the schemas that
> > > went on right after the one we support in the tools, so for now the
> > > kernel meta-schemas only allows that property to be there (just like
> > > deprecated) but won't do anything.
> > >
> > > This should be fixed quite soon however, the library we depend on
> > > has started to work on that spec apparently.
> >
> > Should I postpone this series until support for unevaluatedProperties is
> > available, to be able to test this ?
>
> Also, to make sure I understand this correctly, does it mean I can drop
> "reg: true" and "interrupts: true" ?

Ditto :)

Maxime
Maxime Ripard April 6, 2020, 5:06 p.m. UTC | #6
On Mon, Apr 06, 2020 at 02:28:56PM +0300, Laurent Pinchart wrote:
> > > +
> > > +  clock-names:
> > > +    items:
> > > +      - const: iahb
> > > +      - const: isfr
> > > +
> > > +  interrupts: true
> > > +
> > > +  ports:
> > > +    type: object
> > > +    description: |
> > > +      This device has three video ports. Their connections are modelled using the
> > > +      OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > > +      Each port shall have a single endpoint.
> > > +
> > > +    properties:
> > > +      '#address-cells':
> > > +        const: 1
> > > +
> > > +      '#size-cells':
> > > +        const: 0
> > > +
> > > +      port@0:
> > > +        type: object
> > > +        description: Parallel RGB input port
> > > +
> > > +      port@1:
> > > +        type: object
> > > +        description: HDMI output port
> > > +
> > > +      port@2:
> > > +        type: object
> > > +        description: Sound input port
> > > +
> > > +    required:
> > > +      - port@0
> > > +      - port@1
> > > +      - port@2
> > > +
> > > +    additionalProperties: false
> > > +
> > > +  power-domains:
> > > +    maxItems: 1
> > > +
> > > +required:
> > > +  - compatible
> > > +  - reg
> > > +  - clocks
> > > +  - clock-names
> > > +  - interrupts
> > > +  - ports
> > > +
> > > +additionalProperties: false
> >
> > In the case where you have some kind of generic schema and then a more
> > specific one like you have here, unevaluatedProperties make more sense
> > that additionalProperties.
> >
> > additionalProperties checks that there are no extra properties on the
> > current schema, which is a problem here since you have to duplicate
> > the entire list of properties found in the generic schema, while
> > unevaluatedProperties checks that there are no extra properties in the
> > entire set of all schemas that apply to this node.
> >
> > This way, you can just put what is different from the generic schema,
> > and you don't have to keep it in sync.
> >
> > It's a feature that has been added in the spec of the schemas that
> > went on right after the one we support in the tools, so for now the
> > kernel meta-schemas only allows that property to be there (just like
> > deprecated) but won't do anything.
> >
> > This should be fixed quite soon however, the library we depend on
> > has started to work on that spec apparently.
>
> Should I postpone this series until support for unevaluatedProperties is
> available, to be able to test this ?

There's no need to wait, just put it in and it will eventually be
checked. And the time between now and then won't be worse than the
current situation of not checking anything at all anyway :)

Maxime
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
deleted file mode 100644
index 819f3e31013c..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
+++ /dev/null
@@ -1,86 +0,0 @@ 
-Renesas Gen3 DWC HDMI TX Encoder
-================================
-
-The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
-with a companion PHY IP.
-
-These DT bindings follow the Synopsys DWC HDMI TX bindings defined in
-Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the
-following device-specific properties.
-
-
-Required properties:
-
-- compatible : Shall contain one or more of
-  - "renesas,r8a774a1-hdmi" for R8A774A1 (RZ/G2M) compatible HDMI TX
-  - "renesas,r8a774b1-hdmi" for R8A774B1 (RZ/G2N) compatible HDMI TX
-  - "renesas,r8a7795-hdmi" for R8A7795 (R-Car H3) compatible HDMI TX
-  - "renesas,r8a7796-hdmi" for R8A7796 (R-Car M3-W) compatible HDMI TX
-  - "renesas,r8a77965-hdmi" for R8A77965 (R-Car M3-N) compatible HDMI TX
-  - "renesas,rcar-gen3-hdmi" for the generic R-Car Gen3 and RZ/G2 compatible
-			     HDMI TX
-
-    When compatible with generic versions, nodes must list the SoC-specific
-    version corresponding to the platform first, followed by the
-    family-specific version.
-
-- reg: See dw_hdmi.txt.
-- interrupts: HDMI interrupt number
-- clocks: See dw_hdmi.txt.
-- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt.
-- ports: See dw_hdmi.txt. The DWC HDMI shall have one port numbered 0
-  corresponding to the video input of the controller and one port numbered 1
-  corresponding to its HDMI output, and one port numbered 2 corresponding to
-  sound input of the controller. Each port shall have a single endpoint.
-
-Optional properties:
-
-- power-domains: Shall reference the power domain that contains the DWC HDMI,
-  if any.
-
-
-Example:
-
-	hdmi0: hdmi@fead0000 {
-		compatible = "renesas,r8a7795-dw-hdmi";
-		reg = <0 0xfead0000 0 0x10000>;
-		interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
-		clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>;
-		clock-names = "iahb", "isfr";
-		power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
-
-		ports {
-			#address-cells = <1>;
-			#size-cells = <0>;
-			port@0 {
-				reg = <0>;
-				dw_hdmi0_in: endpoint {
-					remote-endpoint = <&du_out_hdmi0>;
-				};
-			};
-			port@1 {
-				reg = <1>;
-				rcar_dw_hdmi0_out: endpoint {
-					remote-endpoint = <&hdmi0_con>;
-				};
-			};
-			port@2 {
-				reg = <2>;
-				rcar_dw_hdmi0_sound_in: endpoint {
-					remote-endpoint = <&hdmi_sound_out>;
-				};
-			};
-		};
-	};
-
-	hdmi0-out {
-		compatible = "hdmi-connector";
-		label = "HDMI0 OUT";
-		type = "a";
-
-		port {
-			hdmi0_con: endpoint {
-				remote-endpoint = <&rcar_dw_hdmi0_out>;
-			};
-		};
-	};
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
new file mode 100644
index 000000000000..9a543740c81d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.yaml
@@ -0,0 +1,142 @@ 
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/renesas,dw-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car DWC HDMI TX Encoder
+
+maintainers:
+  - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
+
+description: |
+  The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
+  with a companion PHY IP.
+
+allOf:
+  - $ref: synopsys,dw-hdmi.yaml#
+
+properties:
+  compatible:
+    items:
+      - enum:
+        - renesas,r8a774a1-hdmi # for R8A774A1 (RZ/G2M) compatible HDMI TX
+        - renesas,r8a774b1-hdmi # for R8A774B1 (RZ/G2N) compatible HDMI TX
+        - renesas,r8a7795-hdmi # for R8A7795 (R-Car H3) compatible HDMI TX
+        - renesas,r8a7796-hdmi # for R8A7796 (R-Car M3-W) compatible HDMI TX
+        - renesas,r8a77965-hdmi # for R8A77965 (R-Car M3-N) compatible HDMI TX
+      - const: renesas,rcar-gen3-hdmi
+
+  reg: true
+
+  reg-io-width:
+    const: 1
+
+  clocks:
+    minItems: 2
+    maxItems: 2
+
+  clock-names:
+    items:
+      - const: iahb
+      - const: isfr
+
+  interrupts: true
+
+  ports:
+    type: object
+    description: |
+      This device has three video ports. Their connections are modelled using the
+      OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+      Each port shall have a single endpoint.
+
+    properties:
+      '#address-cells':
+        const: 1
+
+      '#size-cells':
+        const: 0
+
+      port@0:
+        type: object
+        description: Parallel RGB input port
+
+      port@1:
+        type: object
+        description: HDMI output port
+
+      port@2:
+        type: object
+        description: Sound input port
+
+    required:
+      - port@0
+      - port@1
+      - port@2
+
+    additionalProperties: false
+
+  power-domains:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - interrupts
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/r8a7795-cpg-mssr.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/power/r8a7795-sysc.h>
+
+    hdmi@fead0000 {
+        compatible = "renesas,r8a7795-hdmi", "renesas,rcar-gen3-hdmi";
+        reg = <0 0xfead0000 0 0x10000>;
+        interrupts = <0 389 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&cpg CPG_CORE R8A7795_CLK_S0D4>, <&cpg CPG_MOD 729>;
+        clock-names = "iahb", "isfr";
+        power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+
+        ports {
+            #address-cells = <1>;
+            #size-cells = <0>;
+            port@0 {
+                reg = <0>;
+                dw_hdmi0_in: endpoint {
+                    remote-endpoint = <&du_out_hdmi0>;
+                };
+            };
+            port@1 {
+                reg = <1>;
+                rcar_dw_hdmi0_out: endpoint {
+                    remote-endpoint = <&hdmi0_con>;
+                };
+            };
+            port@2 {
+                reg = <2>;
+                rcar_dw_hdmi0_sound_in: endpoint {
+                    remote-endpoint = <&hdmi_sound_out>;
+                };
+            };
+        };
+    };
+
+    hdmi0-out {
+        compatible = "hdmi-connector";
+        label = "HDMI0 OUT";
+        type = "a";
+
+        port {
+            hdmi0_con: endpoint {
+                remote-endpoint = <&rcar_dw_hdmi0_out>;
+            };
+        };
+    };
+
+...