On Wed, Jan 6, 2021 at 7:17 AM Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Philipp,
On Wed, Jan 06, 2021 at 03:10:32PM +0100, Philipp Zabel wrote:
On Tue, 2021-01-05 at 13:50 +0200, Laurent Pinchart wrote:
On Tue, Jan 05, 2021 at 10:32:01AM +0100, Philipp Zabel wrote:
On Tue, 2021-01-05 at 07:49 +0200, Laurent Pinchart wrote:
On Mon, Jan 04, 2021 at 04:30:36PM +0100, Philipp Zabel wrote:
On Sun, 2020-12-20 at 21:50 +0200, Laurent Pinchart wrote: > Convert the i.MX6 HDMI TX text binding to YAML. > > Signed-off-by: Laurent Pinchart laurent.pinchart+renesas@ideasonboard.com > --- > Changes since v1: > > - Only specify maxItems for clocks > - Drop reg and interrupts as they're checked in the base schema > - Rebase on top of OF graph schema, dropped redundant properties > - Fix identation for enum entries > - Drop clock-names items, use maxItems only > --- > .../bindings/display/imx/fsl,imx6-hdmi.yaml | 130 ++++++++++++++++++ > .../devicetree/bindings/display/imx/hdmi.txt | 65 --------- > 2 files changed, 130 insertions(+), 65 deletions(-) > create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml > delete mode 100644 Documentation/devicetree/bindings/display/imx/hdmi.txt > > diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml > new file mode 100644 > index 000000000000..f9b131bb3339 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx6-hdmi.yaml > @@ -0,0 +1,130 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/imx/fsl,imx6-hdmi.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Freescale i.MX6 DWC HDMI TX Encoder > + > +maintainers: > + - Philipp Zabel p.zabel@pengutronix.de > + > +description: | > + The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP > + with a companion PHY IP. > + > +allOf: > + - $ref: ../bridge/synopsys,dw-hdmi.yaml# > + > +properties: > + compatible: > + enum: > + - fsl,imx6dl-hdmi > + - fsl,imx6q-hdmi > + > + reg-io-width: > + const: 1 > + > + clocks: > + maxItems: 2 > + > + clock-names: > + maxItems: 2 > + > + ddc-i2c-bus: > + $ref: /schemas/types.yaml#/definitions/phandle > + description: > + The HDMI DDC bus can be connected to either a system I2C master or the > + functionally-reduced I2C master contained in the DWC HDMI. When connected > + to a system I2C master this property contains a phandle to that I2C > + master controller. > + > + gpr: > + $ref: /schemas/types.yaml#/definitions/phandle > + description: > + phandle to the iomuxc-gpr region containing the HDMI multiplexer control > + register. > + > + ports: > + $ref: /schemas/graph.yaml#/properties/ports > + description: | > + This device has four video ports, corresponding to the four inputs of the > + HDMI multiplexer. Each port shall have a single endpoint. > + > + properties: > + port@0: > + $ref: /schemas/graph.yaml#/$defs/port-base > + unevaluatedProperties: false > + description: First input of the HDMI multiplexer > + > + port@1: > + $ref: /schemas/graph.yaml#/$defs/port-base > + unevaluatedProperties: false > + description: Second input of the HDMI multiplexer > + > + port@2: > + $ref: /schemas/graph.yaml#/$defs/port-base > + unevaluatedProperties: false > + description: Third input of the HDMI multiplexer > + > + port@3: > + $ref: /schemas/graph.yaml#/$defs/port-base > + unevaluatedProperties: false > + description: Fourth input of the HDMI multiplexer > + > + anyOf: > + - required: > + - port@0 > + - required: > + - port@1 > + - required: > + - port@2 > + - required: > + - port@3 > + > +required: > + - compatible > + - reg > + - clocks > + - clock-names > + - gpr > + - interrupts > + - ports
The binding marks the "ports" container node as required.
Won't this break validation of current i.MX6 DTs, which don't use the ports node (in imx6q(dl).dtsi)?
I may be missing something, but in imx6qdl.dtsi, we have
[...]
and in imx6q.dtsi,
&hdmi { compatible = "fsl,imx6q-hdmi";
port@2 { reg = <2>; hdmi_mux_2: endpoint { remote-endpoint = <&ipu2_di0_hdmi>; }; }; port@3 { reg = <3>; hdmi_mux_3: endpoint { remote-endpoint = <&ipu2_di1_hdmi>; }; };};
There are no other occurrences of "fsl,imx6q-hdmi" than in imx6q.dtsi (and no occurrences of "fsl,imx6qdl-hdmi" at all).
The port@[0-3] nodes are currently direct children of the &hdmi node, without the "ports" container node.
Of course. Sorry, I've missed that that was the point.
I can include a patch to update imx6q(dl).dtsi in the series. Would that work for you ?
Yes, that would work, thank you. Is the goal to slowly phase out all uses of multi-port bindings without the ports node?
I'm not sure there's an explicit effort in that direction, but I think it would make sense as otherwise DT bindings would be too cumbersome to express in YAML.
There's no requirement for 'ports'. The device's node can be the container. If there's not 'ports', we simply don't have any $ref to graph.yaml#/properties/ports. There was at least one case in the conversions I did. What we don't want is a given binding doing both ways.
Though generally for new bindings, I'd recommend having 'ports' if there's more than one.
Rob