[RFT,5/5] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
diff mbox series

Message ID 20200501083227.10886-6-ricardo.canuelo@collabora.com
State New
Headers show
Series
  • Convert adi,adv7511.txt DT bindings to yaml
Related show

Commit Message

Ricardo Cañuelo May 1, 2020, 8:32 a.m. UTC
Convert the ADV7511/11w/13/33/35 DT bindings to json-schema.

Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
---
 .../bindings/display/bridge/adi,adv7511.txt   | 143 ---------
 .../bindings/display/bridge/adi,adv7511.yaml  | 293 ++++++++++++++++++
 2 files changed, 293 insertions(+), 143 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
 create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml

Comments

Rob Herring May 5, 2020, 6:56 p.m. UTC | #1
On Fri, May 01, 2020 at 10:32:27AM +0200, Ricardo Cañuelo wrote:
> Convert the ADV7511/11w/13/33/35 DT bindings to json-schema.
> 
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
>  .../bindings/display/bridge/adi,adv7511.txt   | 143 ---------
>  .../bindings/display/bridge/adi,adv7511.yaml  | 293 ++++++++++++++++++
>  2 files changed, 293 insertions(+), 143 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml


> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> new file mode 100644
> index 000000000000..0654c3a35281
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> @@ -0,0 +1,293 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADV7511(W)/13/33/35 HDMI Encoders
> +
> +maintainers:
> +  - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +description: |
> +  The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and
> +  video transmitters compatible with HDMI 1.4 and DVI 1.0. They support
> +  color space conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the
> +  DSI interface for input pixels, while the others support RGB
> +  interface.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - adi,adv7511
> +      - adi,adv7511w
> +      - adi,adv7513
> +      - adi,adv7533
> +      - adi,adv7535
> +
> +  reg:
> +    description: |
> +      I2C slave addresses.
> +
> +      The ADV7511 internal registers are split into four pages exposed
> +      through different I2C addresses, creating four register maps. Each
> +      map has it own I2C address and acts as a standard slave device on
> +      the I2C bus. The main address is mandatory, others are optional
> +      and revert to defaults if not specified.
> +    minItems: 1
> +    maxItems: 4
> +
> +  clocks:
> +    description: Reference to the CEC clock.
> +    maxItems: 1
> +
> +  clock-names:
> +    const: cec
> +
> +  reg-names:
> +    description:
> +      Names of maps with programmable addresses. It can contain any map
> +      needing a non-default address.
> +    minItems: 1
> +    items:
> +      - const: main
> +      - const: edid
> +      - const: cec
> +      - const: packet
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  pd-gpios:
> +    description: GPIO connected to the power down signal.
> +    maxItems: 1
> +
> +  avdd-supply:
> +    description: A 1.8V supply that powers up the AVDD pin.
> +    maxItems: 1

Drop. Supplies are always a single item.

> +
> +  dvdd-supply:
> +    description: A 1.8V supply that powers up the DVDD pin.
> +    maxItems: 1
> +
> +  pvdd-supply:
> +    description: A 1.8V supply that powers up the PVDD pin.
> +    maxItems: 1
> +
> +  ports:
> +    description:
> +      The ADV7511 has two video ports and one audio port. This node
> +      models their connections as documented in
> +      Documentation/devicetree/bindings/media/video-interfaces.txt
> +      Documentation/devicetree/bindings/graph.txt
> +    type: object
> +    properties:
> +      port@0:
> +        description:
> +          Video port for the RGB, YUV or DSI input. In the case of
> +          ADV7533/5, the remote endpoint phandle should be a reference
> +          to a valid mipi_dsi_host_device.
> +        type: object
> +
> +      port@1:
> +        description: Video port for the HDMI output.
> +        type: object
> +
> +      port@2:
> +        description: Audio port for the HDMI output.
> +        type: object
> +
> +
> +allOf:
> +  # ADV7511/11w/13-specific parameters
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - adi,adv7511
> +              - adi,adv7511w
> +              - adi,adv7513
> +
> +    then:
> +      properties:
> +        dvdd-3v-supply:
> +          description: A 3.3V supply that powers up the DVDD_3V pin.
> +          maxItems: 1
> +
> +        bgvdd-supply:
> +          description: A 1.8V supply that powers up the BGVDD pin.
> +          maxItems: 1
> +
> +        adi,input-depth:
> +          description: Number of bits per color component at the input.
> +          allOf:
> +            - $ref: /schemas/types.yaml#/definitions/uint32
> +            - enum: [ 8, 10, 12 ]
> +
> +        adi,input-colorspace:
> +          description: Input color space.
> +          allOf:
> +            - $ref: /schemas/types.yaml#/definitions/string
> +            - enum: [ rgb, yuv422, yuv444 ]
> +
> +        adi,input-clock:
> +          description: |
> +            Input clock type.
> +              "1x": one clock cycle per pixel
> +              "2x": two clock cycles per pixel
> +              "dd": one clock cycle per pixel, data driven on both edges
> +          allOf:
> +            - $ref: /schemas/types.yaml#/definitions/string
> +            - enum: [ 1x, 2x, dd ]
> +
> +        adi,clock-delay:
> +          description:
> +            Video data clock delay relative to the pixel clock, in ps
> +            (-1200ps .. 1600 ps).
> +          allOf:
> +            - $ref: /schemas/types.yaml#/definitions/uint32
> +            - default: 0
> +
> +        adi,embedded-sync:
> +          description:
> +            The input uses synchronization signals embedded in the data
> +            stream (similar to BT.656). Defaults to 0 (separate H/V
> +            synchronization signals).
> +          allOf:
> +            - $ref: /schemas/types.yaml#/definitions/uint32
> +            - enum: [ 0, 1 ]
> +            - default: 0
> +
> +      required:
> +        - adi,input-depth
> +        - adi,input-colorspace
> +        - adi,input-clock
> +
> +  # adi,input-style and adi,input-justification are required except in
> +  # "rgb 1x" and "yuv444 1x" modes.
> +  - if:
> +      not:
> +        properties:
> +          adi,input-colorspace:
> +            contains:
> +              enum: [ rgb, yuv444 ]
> +          adi,input-clock:
> +            contains:
> +              const: 1x

I believe this will be true (before the not) if the properties are not 
present. You need 'required' if that's not what you want.

> +
> +    then:
> +      properties:
> +        adi,input-style:
> +          description:
> +            Input components arrangement variant as listed in the input
> +            format tables in the datasheet.
> +          allOf:
> +            - $ref: /schemas/types.yaml#/definitions/uint32
> +            - enum: [ 1, 2, 3 ]
> +
> +        adi,input-justification:
> +          description: Input bit justification.
> +          allOf:
> +            - $ref: /schemas/types.yaml#/definitions/string
> +            - enum: [ left, evenly, right ]
> +
> +      required:
> +        - adi,input-style
> +        - adi,input-justification
> +
> +  # ADV7533/35-specific parameters
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - adi,adv7533
> +              - adi,adv7535
> +
> +    then:
> +      properties:
> +        adi,disable-timing-generator:
> +          description:
> +            Disables the interal timing generator. The chip will rely on
> +            the sync signals in the DSI data lanes, rather than generate
> +            its own timings for HDMI output.
> +          type: boolean
> +
> +        adi,dsi-lanes:
> +          description: Number of DSI data lanes connected to the DSI host.
> +          allOf:
> +            - $ref: /schemas/types.yaml#/definitions/uint32
> +            - enum: [ 1, 2, 3, 4 ]
> +
> +        a2vdd-supply:
> +          description: A 1.8V supply that powers up the A2VDD pin.
> +          maxItems: 1
> +
> +        v3p3-supply:
> +          description: A 3.3V supply that powers up the V3P3 pin.
> +          maxItems: 1
> +
> +        v1p2-supply:
> +          description:
> +            A supply that powers up the V1P2 pin. It can be either 1.2V
> +            or 1.8V for ADV7533 but only 1.8V for ADV7535.
> +          maxItems: 1
> +
> +      required:
> +        - adi,dsi-lanes
> +
> +required:
> +  - compatible
> +  - reg
> +  - ports
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +
> +    adv7511w: hdmi@39 {
> +        compatible = "adi,adv7511w";
> +        /*
> +         * The EDID page will be accessible on address 0x66 on the I2C
> +         * bus. All other maps continue to use their default addresses.
> +         */
> +        reg = <0x39>, <0x66>;
> +        reg-names = "main", "edid";
> +        interrupt-parent = <&gpio3>;
> +        interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> +        clocks = <&cec_clock>;
> +        clock-names = "cec";
> +
> +        adi,input-depth = <8>;
> +        adi,input-colorspace = "rgb";
> +        adi,input-clock = "1x";
> +
> +        ports {
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            port@0 {
> +                reg = <0>;
> +                adv7511w_in: endpoint {
> +                    remote-endpoint = <&dpi_out>;
> +                };
> +            };
> +
> +            port@1 {
> +                reg = <1>;
> +                adv7511_out: endpoint {
> +                    remote-endpoint = <&hdmi_connector_in>;
> +                };
> +            };
> +
> +            port@2 {
> +                reg = <2>;
> +                codec_endpoint: endpoint {
> +                    remote-endpoint = <&i2s0_cpu_endpoint>;
> +                };
> +            };
> +        };
> +    };
> +
> +...
> -- 
> 2.18.0
>
Geert Uytterhoeven May 6, 2020, 7:44 a.m. UTC | #2
Hi Ricardo,

On Fri, May 1, 2020 at 10:33 AM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
> Convert the ADV7511/11w/13/33/35 DT bindings to json-schema.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> @@ -0,0 +1,293 @@

> +  reg-names:
> +    description:
> +      Names of maps with programmable addresses. It can contain any map
> +      needing a non-default address.
> +    minItems: 1
> +    items:
> +      - const: main
> +      - const: edid
> +      - const: cec
> +      - const: packet

Can't you avoid the need for patches
[RFT PATCH 1/5] arm64: dts: draak: Reorder hdmi-encoder@39 reg and
reg-names properties
[RFT PATCH 2/5] ARM: dts: wheat: reorder reg and reg-names properties
in hdmi bridges

by using

    items:
      enum:
        - main
        - edid
        - cec
        - packet

instead?

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Ricardo Cañuelo May 6, 2020, 8:23 a.m. UTC | #3
Hi Geert,

Thanks for reviewing the patches. Some comments below,

On mié 06-05-2020 09:44:19, Geert Uytterhoeven wrote: 
> Can't you avoid the need for patches
> [RFT PATCH 1/5] arm64: dts: draak: Reorder hdmi-encoder@39 reg and
> reg-names properties
> [RFT PATCH 2/5] ARM: dts: wheat: reorder reg and reg-names properties
> in hdmi bridges
> 
> by using
> 
>     items:
>       enum:
>         - main
>         - edid
>         - cec
>         - packet
> 
> instead?

Not really, because that defines a scalar property that can take any of
those values (if I'm not mistaken), and the core schema enforces that
reg-names must be an array.

I think the closest I can get to what you mean would be something like
this:

    items:
      - enum:
        - main
        - edid
        - cec
        - packet
      - enum:
        - main
        - edid
        - cec
        - packet
      - enum:
        - main
        - edid
        - cec
        - packet
      - enum:
        - main
        - edid
        - cec
        - packet

But then that wouldn't prevent anyone from defining duplicate reg-names
(eg. "main", "cec", edid", "cec"), which is even worse IMO.

Cheers,
Ricardo
Laurent Pinchart May 6, 2020, 10:57 a.m. UTC | #4
On Wed, May 06, 2020 at 10:23:32AM +0200, Ricardo Cañuelo wrote:
> Hi Geert,
> 
> Thanks for reviewing the patches. Some comments below,
> 
> On mié 06-05-2020 09:44:19, Geert Uytterhoeven wrote: 
> > Can't you avoid the need for patches
> > [RFT PATCH 1/5] arm64: dts: draak: Reorder hdmi-encoder@39 reg and
> > reg-names properties
> > [RFT PATCH 2/5] ARM: dts: wheat: reorder reg and reg-names properties
> > in hdmi bridges
> > 
> > by using
> > 
> >     items:
> >       enum:
> >         - main
> >         - edid
> >         - cec
> >         - packet
> > 
> > instead?
> 
> Not really, because that defines a scalar property that can take any of
> those values (if I'm not mistaken), and the core schema enforces that
> reg-names must be an array.
> 
> I think the closest I can get to what you mean would be something like
> this:
> 
>     items:
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
>       - enum:
>         - main
>         - edid
>         - cec
>         - packet
> 
> But then that wouldn't prevent anyone from defining duplicate reg-names
> (eg. "main", "cec", edid", "cec"), which is even worse IMO.

The direction DT bindings are taking is to enfore a particular order. It
will cause DT validation errors for old device trees, but it won't break
backward compatibility as the order won't be enforced at runtime, so I
think that's fine. Tidying up the existing DT sources to use a
consistent order seems best to me.
Rob Herring May 6, 2020, 12:59 p.m. UTC | #5
On Wed, May 6, 2020 at 5:57 AM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Wed, May 06, 2020 at 10:23:32AM +0200, Ricardo Cañuelo wrote:
> > Hi Geert,
> >
> > Thanks for reviewing the patches. Some comments below,
> >
> > On mié 06-05-2020 09:44:19, Geert Uytterhoeven wrote:
> > > Can't you avoid the need for patches
> > > [RFT PATCH 1/5] arm64: dts: draak: Reorder hdmi-encoder@39 reg and
> > > reg-names properties
> > > [RFT PATCH 2/5] ARM: dts: wheat: reorder reg and reg-names properties
> > > in hdmi bridges
> > >
> > > by using
> > >
> > >     items:
> > >       enum:
> > >         - main
> > >         - edid
> > >         - cec
> > >         - packet
> > >
> > > instead?
> >
> > Not really, because that defines a scalar property that can take any of
> > those values (if I'm not mistaken), and the core schema enforces that
> > reg-names must be an array.

No, 'items' as a schema rather than a list applies to every element in an array.

> >
> > I think the closest I can get to what you mean would be something like
> > this:
> >
> >     items:
> >       - enum:
> >         - main
> >         - edid
> >         - cec
> >         - packet
> >       - enum:
> >         - main
> >         - edid
> >         - cec
> >         - packet
> >       - enum:
> >         - main
> >         - edid
> >         - cec
> >         - packet
> >       - enum:
> >         - main
> >         - edid
> >         - cec
> >         - packet
> >
> > But then that wouldn't prevent anyone from defining duplicate reg-names
> > (eg. "main", "cec", edid", "cec"), which is even worse IMO.
>
> The direction DT bindings are taking is to enfore a particular order. It
> will cause DT validation errors for old device trees, but it won't break
> backward compatibility as the order won't be enforced at runtime, so I
> think that's fine. Tidying up the existing DT sources to use a
> consistent order seems best to me.

Yes.

It's not a new direction though. The order was always supposed to be
defined, it's just enforceable now.

Rob
Ricardo Cañuelo May 6, 2020, 1:10 p.m. UTC | #6
Hi Rob, thanks for taking the time to review the patch. Some comments
below:

On mar 05-05-2020 13:56:07, Rob Herring wrote:
> > +  # adi,input-style and adi,input-justification are required except in
> > +  # "rgb 1x" and "yuv444 1x" modes.
> > +  - if:
> > +      not:
> > +        properties:
> > +          adi,input-colorspace:
> > +            contains:
> > +              enum: [ rgb, yuv444 ]
> > +          adi,input-clock:
> > +            contains:
> > +              const: 1x
> 
> I believe this will be true (before the not) if the properties are not 
> present. You need 'required' if that's not what you want.

I'm not sure I understand what you mean, but dt_binding_check doesn't
say anything about adi,input-style and adi,input-justification being
required when adi,input-colorspace and adi,input-clock are not present.

I think I covered every possible case wrt those properties when running
dt_binding_check and I got the results I was looking for:

- When compatible is either "adi,adv7533" or "adi,adv7535",
  adi,input-colorspace and adi,input-clock aren't required

- For any of the other compatible strings, adi,input-colorspace and
  adi,input-clock are required.

- When adi,input-colorspace and adi,input-clock are defined and they are
  different than "rgb 1x" or "yuv444 1x", adi,input-style and
  adi,input-justification are required.

There's an issue I can't figure out, though. adi,input-colorspace and
adi,input-clock are defined only for devices other than "adi,adv7533"
and "adi,adv7535", but a DT for one of these devices can use those
properties and the binding check won't complain. Moreover, it will check
the above condition even if it doesn't make sense for them (ie. it may
complain that adi,input-style and adi,input-justification are required
even if they aren't defined for "adi,adv7533" and "adi,adv7535").

I think it's a minor issue, but do you know if there's a way to model
that? Are properties always unconditionally defined?

Cheers,
Ricardo
Rob Herring May 6, 2020, 6:43 p.m. UTC | #7
On Wed, May 6, 2020 at 8:11 AM Ricardo Cañuelo
<ricardo.canuelo@collabora.com> wrote:
>
> Hi Rob, thanks for taking the time to review the patch. Some comments
> below:
>
> On mar 05-05-2020 13:56:07, Rob Herring wrote:
> > > +  # adi,input-style and adi,input-justification are required except in
> > > +  # "rgb 1x" and "yuv444 1x" modes.
> > > +  - if:
> > > +      not:
> > > +        properties:
> > > +          adi,input-colorspace:
> > > +            contains:
> > > +              enum: [ rgb, yuv444 ]
> > > +          adi,input-clock:
> > > +            contains:
> > > +              const: 1x
> >
> > I believe this will be true (before the not) if the properties are not
> > present. You need 'required' if that's not what you want.
>
> I'm not sure I understand what you mean, but dt_binding_check doesn't
> say anything about adi,input-style and adi,input-justification being
> required when adi,input-colorspace and adi,input-clock are not present.
>
> I think I covered every possible case wrt those properties when running
> dt_binding_check and I got the results I was looking for:
>
> - When compatible is either "adi,adv7533" or "adi,adv7535",
>   adi,input-colorspace and adi,input-clock aren't required
>
> - For any of the other compatible strings, adi,input-colorspace and
>   adi,input-clock are required.
>
> - When adi,input-colorspace and adi,input-clock are defined and they are
>   different than "rgb 1x" or "yuv444 1x", adi,input-style and
>   adi,input-justification are required.
>
> There's an issue I can't figure out, though. adi,input-colorspace and
> adi,input-clock are defined only for devices other than "adi,adv7533"
> and "adi,adv7535", but a DT for one of these devices can use those
> properties and the binding check won't complain. Moreover, it will check
> the above condition even if it doesn't make sense for them (ie. it may
> complain that adi,input-style and adi,input-justification are required
> even if they aren't defined for "adi,adv7533" and "adi,adv7535").
>
> I think it's a minor issue, but do you know if there's a way to model
> that? Are properties always unconditionally defined?

I think you want something like this:

if:
  properties:
    compatible:
      contains:
        enum:
          - adi,adv7533
          - adi,adv7535
then:
  not:
    properties:
      adi,input-style: false
      adi,input-justification: false

Which means the schema fails if either property is present.

It may also just be easier to split this schema into 2. It's a
judgement call on how much is shared vs. how much if/then/else logic
there is.

Rob

Patch
diff mbox series

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
deleted file mode 100644
index 659523f538bf..000000000000
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ /dev/null
@@ -1,143 +0,0 @@ 
-Analog Devices ADV7511(W)/13/33/35 HDMI Encoders
-------------------------------------------------
-
-The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video
-transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
-conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for input
-pixels, while the others support RGB interface.
-
-Required properties:
-
-- compatible: Should be one of:
-		"adi,adv7511"
-		"adi,adv7511w"
-		"adi,adv7513"
-		"adi,adv7533"
-		"adi,adv7535"
-
-- reg: I2C slave addresses
-  The ADV7511 internal registers are split into four pages exposed through
-  different I2C addresses, creating four register maps. Each map has it own
-  I2C address and acts as a standard slave device on the I2C bus. The main
-  address is mandatory, others are optional and revert to defaults if not
-  specified.
-
-
-The ADV7511 supports a large number of input data formats that differ by their
-color depth, color format, clock mode, bit justification and random
-arrangement of components on the data bus. The combination of the following
-properties describe the input and map directly to the video input tables of the
-ADV7511 datasheet that document all the supported combinations.
-
-- adi,input-depth: Number of bits per color component at the input (8, 10 or
-  12).
-- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or
-  "yuv444".
-- adi,input-clock: The input clock type, one of "1x" (one clock cycle per
-  pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel,
-  data driven on both edges).
-
-The following input format properties are required except in "rgb 1x" and
-"yuv444 1x" modes, in which case they must not be specified.
-
-- adi,input-style: The input components arrangement variant (1, 2 or 3), as
-  listed in the input format tables in the datasheet.
-- adi,input-justification: The input bit justification ("left", "evenly",
-  "right").
-
-- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip.
-- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip.
-- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip.
-- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V
-  on the chip.
-- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
-  needed only for ADV7511.
-
-The following properties are required for ADV7533 and ADV7535:
-
-- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
-  be one of 1, 2, 3 or 4.
-- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
-- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
-- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
-  either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535.
-
-Optional properties:
-
-- interrupts: Specifier for the ADV7511 interrupt
-- pd-gpios: Specifier for the GPIO connected to the power down signal
-
-- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps
-  (-1200 ps .. 1600 ps). Defaults to no delay.
-- adi,embedded-sync: The input uses synchronization signals embedded in the
-  data stream (similar to BT.656). Defaults to separate H/V synchronization
-  signals.
-- adi,disable-timing-generator: Only for ADV7533 and ADV7535. Disables the
-  internal timing generator. The chip will rely on the sync signals in the
-  DSI data lanes, rather than generate its own timings for HDMI output.
-- clocks: from common clock binding: reference to the CEC clock.
-- clock-names: from common clock binding: must be "cec".
-- reg-names : Names of maps with programmable addresses.
-	It can contain any map needing a non-default address.
-	Possible maps names are : "main", "edid", "cec", "packet"
-
-Required nodes:
-
-The ADV7511 has two video ports. Their connections are modelled using the OF
-graph bindings specified in Documentation/devicetree/bindings/graph.txt.
-
-- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the
-  remote endpoint phandle should be a reference to a valid mipi_dsi_host device
-  node.
-- Video port 1 for the HDMI output
-- Audio port 2 for the HDMI audio input
-
-
-Example
--------
-
-	adv7511w: hdmi@39 {
-		compatible = "adi,adv7511w";
-		/*
-		 * The EDID page will be accessible on address 0x66 on the I2C
-		 * bus. All other maps continue to use their default addresses.
-		 */
-		reg = <0x39>, <0x66>;
-		reg-names = "main", "edid";
-		interrupt-parent = <&gpio3>;
-		interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
-		clocks = <&cec_clock>;
-		clock-names = "cec";
-
-		adi,input-depth = <8>;
-		adi,input-colorspace = "rgb";
-		adi,input-clock = "1x";
-		adi,input-style = <1>;
-		adi,input-justification = "evenly";
-
-		ports {
-			#address-cells = <1>;
-			#size-cells = <0>;
-
-			port@0 {
-				reg = <0>;
-				adv7511w_in: endpoint {
-					remote-endpoint = <&dpi_out>;
-				};
-			};
-
-			port@1 {
-				reg = <1>;
-				adv7511_out: endpoint {
-					remote-endpoint = <&hdmi_connector_in>;
-				};
-			};
-
-			port@2 {
-				reg = <2>;
-				codec_endpoint: endpoint {
-					remote-endpoint = <&i2s0_cpu_endpoint>;
-				};
-			};
-		};
-	};
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
new file mode 100644
index 000000000000..0654c3a35281
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
@@ -0,0 +1,293 @@ 
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices ADV7511(W)/13/33/35 HDMI Encoders
+
+maintainers:
+  - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+description: |
+  The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and
+  video transmitters compatible with HDMI 1.4 and DVI 1.0. They support
+  color space conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the
+  DSI interface for input pixels, while the others support RGB
+  interface.
+
+properties:
+  compatible:
+    enum:
+      - adi,adv7511
+      - adi,adv7511w
+      - adi,adv7513
+      - adi,adv7533
+      - adi,adv7535
+
+  reg:
+    description: |
+      I2C slave addresses.
+
+      The ADV7511 internal registers are split into four pages exposed
+      through different I2C addresses, creating four register maps. Each
+      map has it own I2C address and acts as a standard slave device on
+      the I2C bus. The main address is mandatory, others are optional
+      and revert to defaults if not specified.
+    minItems: 1
+    maxItems: 4
+
+  clocks:
+    description: Reference to the CEC clock.
+    maxItems: 1
+
+  clock-names:
+    const: cec
+
+  reg-names:
+    description:
+      Names of maps with programmable addresses. It can contain any map
+      needing a non-default address.
+    minItems: 1
+    items:
+      - const: main
+      - const: edid
+      - const: cec
+      - const: packet
+
+  interrupts:
+    maxItems: 1
+
+  pd-gpios:
+    description: GPIO connected to the power down signal.
+    maxItems: 1
+
+  avdd-supply:
+    description: A 1.8V supply that powers up the AVDD pin.
+    maxItems: 1
+
+  dvdd-supply:
+    description: A 1.8V supply that powers up the DVDD pin.
+    maxItems: 1
+
+  pvdd-supply:
+    description: A 1.8V supply that powers up the PVDD pin.
+    maxItems: 1
+
+  ports:
+    description:
+      The ADV7511 has two video ports and one audio port. This node
+      models their connections as documented in
+      Documentation/devicetree/bindings/media/video-interfaces.txt
+      Documentation/devicetree/bindings/graph.txt
+    type: object
+    properties:
+      port@0:
+        description:
+          Video port for the RGB, YUV or DSI input. In the case of
+          ADV7533/5, the remote endpoint phandle should be a reference
+          to a valid mipi_dsi_host_device.
+        type: object
+
+      port@1:
+        description: Video port for the HDMI output.
+        type: object
+
+      port@2:
+        description: Audio port for the HDMI output.
+        type: object
+
+
+allOf:
+  # ADV7511/11w/13-specific parameters
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - adi,adv7511
+              - adi,adv7511w
+              - adi,adv7513
+
+    then:
+      properties:
+        dvdd-3v-supply:
+          description: A 3.3V supply that powers up the DVDD_3V pin.
+          maxItems: 1
+
+        bgvdd-supply:
+          description: A 1.8V supply that powers up the BGVDD pin.
+          maxItems: 1
+
+        adi,input-depth:
+          description: Number of bits per color component at the input.
+          allOf:
+            - $ref: /schemas/types.yaml#/definitions/uint32
+            - enum: [ 8, 10, 12 ]
+
+        adi,input-colorspace:
+          description: Input color space.
+          allOf:
+            - $ref: /schemas/types.yaml#/definitions/string
+            - enum: [ rgb, yuv422, yuv444 ]
+
+        adi,input-clock:
+          description: |
+            Input clock type.
+              "1x": one clock cycle per pixel
+              "2x": two clock cycles per pixel
+              "dd": one clock cycle per pixel, data driven on both edges
+          allOf:
+            - $ref: /schemas/types.yaml#/definitions/string
+            - enum: [ 1x, 2x, dd ]
+
+        adi,clock-delay:
+          description:
+            Video data clock delay relative to the pixel clock, in ps
+            (-1200ps .. 1600 ps).
+          allOf:
+            - $ref: /schemas/types.yaml#/definitions/uint32
+            - default: 0
+
+        adi,embedded-sync:
+          description:
+            The input uses synchronization signals embedded in the data
+            stream (similar to BT.656). Defaults to 0 (separate H/V
+            synchronization signals).
+          allOf:
+            - $ref: /schemas/types.yaml#/definitions/uint32
+            - enum: [ 0, 1 ]
+            - default: 0
+
+      required:
+        - adi,input-depth
+        - adi,input-colorspace
+        - adi,input-clock
+
+  # adi,input-style and adi,input-justification are required except in
+  # "rgb 1x" and "yuv444 1x" modes.
+  - if:
+      not:
+        properties:
+          adi,input-colorspace:
+            contains:
+              enum: [ rgb, yuv444 ]
+          adi,input-clock:
+            contains:
+              const: 1x
+
+    then:
+      properties:
+        adi,input-style:
+          description:
+            Input components arrangement variant as listed in the input
+            format tables in the datasheet.
+          allOf:
+            - $ref: /schemas/types.yaml#/definitions/uint32
+            - enum: [ 1, 2, 3 ]
+
+        adi,input-justification:
+          description: Input bit justification.
+          allOf:
+            - $ref: /schemas/types.yaml#/definitions/string
+            - enum: [ left, evenly, right ]
+
+      required:
+        - adi,input-style
+        - adi,input-justification
+
+  # ADV7533/35-specific parameters
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - adi,adv7533
+              - adi,adv7535
+
+    then:
+      properties:
+        adi,disable-timing-generator:
+          description:
+            Disables the interal timing generator. The chip will rely on
+            the sync signals in the DSI data lanes, rather than generate
+            its own timings for HDMI output.
+          type: boolean
+
+        adi,dsi-lanes:
+          description: Number of DSI data lanes connected to the DSI host.
+          allOf:
+            - $ref: /schemas/types.yaml#/definitions/uint32
+            - enum: [ 1, 2, 3, 4 ]
+
+        a2vdd-supply:
+          description: A 1.8V supply that powers up the A2VDD pin.
+          maxItems: 1
+
+        v3p3-supply:
+          description: A 3.3V supply that powers up the V3P3 pin.
+          maxItems: 1
+
+        v1p2-supply:
+          description:
+            A supply that powers up the V1P2 pin. It can be either 1.2V
+            or 1.8V for ADV7533 but only 1.8V for ADV7535.
+          maxItems: 1
+
+      required:
+        - adi,dsi-lanes
+
+required:
+  - compatible
+  - reg
+  - ports
+
+examples:
+  - |
+    #include <dt-bindings/interrupt-controller/irq.h>
+
+    adv7511w: hdmi@39 {
+        compatible = "adi,adv7511w";
+        /*
+         * The EDID page will be accessible on address 0x66 on the I2C
+         * bus. All other maps continue to use their default addresses.
+         */
+        reg = <0x39>, <0x66>;
+        reg-names = "main", "edid";
+        interrupt-parent = <&gpio3>;
+        interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+        clocks = <&cec_clock>;
+        clock-names = "cec";
+
+        adi,input-depth = <8>;
+        adi,input-colorspace = "rgb";
+        adi,input-clock = "1x";
+
+        ports {
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            port@0 {
+                reg = <0>;
+                adv7511w_in: endpoint {
+                    remote-endpoint = <&dpi_out>;
+                };
+            };
+
+            port@1 {
+                reg = <1>;
+                adv7511_out: endpoint {
+                    remote-endpoint = <&hdmi_connector_in>;
+                };
+            };
+
+            port@2 {
+                reg = <2>;
+                codec_endpoint: endpoint {
+                    remote-endpoint = <&i2s0_cpu_endpoint>;
+                };
+            };
+        };
+    };
+
+...