Hi, On Tue, 2020-12-22 at 09:09 +0200, Laurent Pinchart wrote: > Hi Liu, > > Thank you for the patch. > > On Thu, Dec 17, 2020 at 05:59:25PM +0800, Liu Ying wrote: > > This patch adds bindings for i.MX8qm/qxp display pixel link. > > > > Signed-off-by: Liu Ying <victor.liu@xxxxxxx> > > --- > > .../display/bridge/fsl,imx8qxp-pixel-link.yaml | 128 +++++++++++++++++++++ > > 1 file changed, 128 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml > > new file mode 100644 > > index 00000000..fd24a0e > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8qxp-pixel-link.yaml > > @@ -0,0 +1,128 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fdisplay%2Fbridge%2Ffsl%2Cimx8qxp-pixel-link.yaml%23&data=04%7C01%7Cvictor.liu%40nxp.com%7C2a48e2bf99364191d8c508d8a6487e41%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637442177591124452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=T0GTZ7sjDeVGb52%2Bo4V%2BgL5FZ0OVbJcf95F5fqzm9tg%3D&reserved=0 > > +$schema: https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23&data=04%7C01%7Cvictor.liu%40nxp.com%7C2a48e2bf99364191d8c508d8a6487e41%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637442177591124452%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k0gxlP9o6T1AORaXXGH9fW5o9EeOTFGPAEDjoltrEuQ%3D&reserved=0 > > + > > +title: Freescale i.MX8qm/qxp Display Pixel Link > > + > > +maintainers: > > + - Liu Ying <victor.liu@xxxxxxx> > > + > > +description: | > > + The Freescale i.MX8qm/qxp Display Pixel Link(DPL) forms a standard > > + asynchronous linkage between pixel sources(display controller or > > + camera module) and pixel consumers(imaging or displays). > > + It consists of two distinct functions, a pixel transfer function and a > > + control interface. Multiple pixel channels can exist per one control channel. > > + This binding documentation is only for pixel links whose pixel sources are > > + display controllers. > > + > > +properties: > > + compatible: > > + enum: > > + - fsl,imx8qm-dc-pixel-link > > + - fsl,imx8qxp-dc-pixel-link > > + > > + ports: > > + type: object > > + description: | > > + A node containing pixel link input & output port nodes with endpoint > > + definitions as documented in > > + Documentation/devicetree/bindings/media/video-interfaces.txt > > + Documentation/devicetree/bindings/graph.txt > > With Rob's patch that convert both of these to YAML, I think you can > drop the references to these documents, and use > > $ref: /schemas/graph.yaml#/properties/ports > > in the ports node, and > > $ref: /schemas/graph.yaml#/$defs/port-base > unevaluatedProperties: false > > in the port nodes, dropping the type property. You will also be able to > drop > > additionalProperties: false > > for the ports node. Thanks for the suggestion. Rob looked this binding and provided some comments without requiring to reference the new graph.yaml. Rob, do you think it is needed for now? > > > + > > + properties: > > + '#address-cells': > > + const: 1 > > + > > + '#size-cells': > > + const: 0 > > + > > + port@0: > > + type: object > > + description: The pixel link input port node from upstream video source. > > + > > + properties: > > + reg: > > + const: 0 > > + > > + required: > > + - reg > > + > > + patternProperties: > > + "^port@[1-4]$": > > + type: object > > + description: The pixel link output port node to downstream bridge. > > + > > + properties: > > + reg: > > + enum: [ 1, 2, 3, 4 ] > > + > > + required: > > + - reg > > + > > + required: > > + - "#address-cells" > > + - "#size-cells" > > + - port@0 > > + > > + anyOf: > > + - required: > > + - port@1 > > + - required: > > + - port@2 > > + - required: > > + - port@3 > > + - required: > > + - port@4 > > Do all DPL instances have four output ports ? If so I would make all of > them mandatory, as they describe the hardware. They can be left without > any endpoing if they're not connected to anything. Yes, I think all DPL instances have 4 output ports and some don't connect to anything. I'll require all of them in the next version. Thanks, Liu Ying > > > + > > + additionalProperties: false > > + > > +required: > > + - compatible > > + - ports > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + dc0-pixel-link0 { > > + compatible = "fsl,imx8qxp-dc-pixel-link"; > > + > > + ports { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + /* from dc0 pixel combiner channel0 */ > > + port@0 { > > + reg = <0>; > > + > > + dc0_pixel_link0_dc0_pixel_combiner_ch0: endpoint { > > + remote-endpoint = <&dc0_pixel_combiner_ch0_dc0_pixel_link0>; > > + }; > > + }; > > + > > + /* to PXL2DPIs in MIPI/LVDS combo subsystems */ > > + port@1 { > > + #address-cells = <1>; > > + #size-cells = <0>; > > + reg = <1>; > > + > > + dc0_pixel_link0_mipi_lvds_0_pxl2dpi: endpoint@0 { > > + reg = <0>; > > + remote-endpoint = <&mipi_lvds_0_pxl2dpi_dc0_pixel_link0>; > > + }; > > + > > + dc0_pixel_link0_mipi_lvds_1_pxl2dpi: endpoint@1 { > > + reg = <1>; > > + remote-endpoint = <&mipi_lvds_1_pxl2dpi_dc0_pixel_link0>; > > + }; > > + }; > > + > > + /* to imaging subsystem */ > > + port@4 { > > + reg = <4>; > > + }; > > + }; > > + };
