[RFC PATCH 0/4] dt-bindings: Introduce dual-link panels & panel-vendors

[RFC PATCH 0/4] dt-bindings: Introduce dual-link panels & panel-vendors

[Aradhya Bhatia]

Hi all,

Microtips Technology Solutions USA, and Lincoln Technology Solutions are
2 display panel vendors, and the first 2 patches add their vendor
prefixes.

The fourth patch, simply introduces the new compatible for the generic
dual-link panels in the panel-lvds driver. This new compatible is based
from a new DT binding added in the third patch explained below.

The third patch introduces a dt-binding for generic dual-link LVDS
panels. These panels do not have any documented constraints, except for
their timing characteristics. Further, these panels have 2 pixel-sinks.
In a dual-link connection between an LVDS encoder and the panel, one
sink accepts the odd set of LVDS pixels and the other, the even set.

A lot of this has been based from the Advantech,idk-2121wr dual-link
panel[1] and Maxime's patches for generic LVDS panels[2] (which are
single-link by default.) and the discussions that happened before they
were finally merged.

Below are some notes and points that I want to bring forward.

  - The advantech,idk-2121wr panel binding uses 2 boolean properties
    dual-link-odd/even-pixels, to signify which port sink is being used
    for which set of LVDS pixels. I too have added similar support and
    introduced constraints around those properties, so as to not break
    the ABI... but I believe there is a better way to achieve this.

    A "pixel-type" enum property could be introduced in their stead,
    which can accept one of the 2 options <dual-lvds-odd-pixels> or
    <dual-lvds-even-pixels>.

    This method, in my opinion, is more accurate and cleaner to
    implement in the bindings as well.

    If this does sound a better I can push out a new revision where the
    driver supports both these methods (to not break the ABI) and the
    advantech,2121wr panel can remain as an exception.


  - As an alternative to the previous point, if that method is not
    preferred for some reason, the advantech,2121wtr panel binding
    could then be merged in the panel-dual-lvds binding as part of
    future work.


  - Another tweak, I am looking forward to do as part of future work and
    would like all your comments is to introduce driver-based
    implementation of the panel timing parameters, like it is with
    "panel-simple". The driver can then support both the panel-timing
    sources (DT node or hard-coded driver structure) and the binding
    can remove this from the "required" section.

Thank you!

[1]: https://patchwork.freedesktop.org/patch/357122/
[2]: https://patchwork.freedesktop.org/patch/471228/

Aradhya Bhatia (4):
  dt-bindings: vendor-prefixes: Add microtips
  dt-bindings: vendor-prefixes: Add lincolntech
  dt-bindings: panel: Introduce dual-link LVDS panel
  drm: panel-lvds: Introduce dual-link panels

 .../display/panel/panel-dual-lvds.yaml        | 157 ++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.yaml  |   4 +
 MAINTAINERS                                   |   1 +
 drivers/gpu/drm/panel/panel-lvds.c            |   1 +
 4 files changed, 163 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml

-- 
2.39.0

[RFC PATCH 1/4] dt-bindings: vendor-prefixes: Add microtips

[Aradhya Bhatia]

Add document vendor prefix for Microtips Technology USA (microtips).

Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 70ffb3780621..516134cbcb3c 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -821,6 +821,8 @@ patternProperties:
     description: Microsoft Corporation
   "^microsys,.*":
     description: MicroSys Electronics GmbH
+  "^microtips,.*":
+    description: Microtips Technology USA
   "^mikroe,.*":
     description: MikroElektronika d.o.o.
   "^mikrotik,.*":
-- 
2.39.0

Re: [RFC PATCH 1/4] dt-bindings: vendor-prefixes: Add microtips

[Krzysztof Kozlowski]

On 03/01/2023 07:46, Aradhya Bhatia wrote:
> Add document vendor prefix for Microtips Technology USA (microtips).
> 
> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [RFC PATCH 1/4] dt-bindings: vendor-prefixes: Add microtips

[Laurent Pinchart]

Hi Aradhya,

Thank you for the patch.

On Tue, Jan 03, 2023 at 12:16:12PM +0530, Aradhya Bhatia wrote:
> Add document vendor prefix for Microtips Technology USA (microtips).
> 
> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 70ffb3780621..516134cbcb3c 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -821,6 +821,8 @@ patternProperties:
>      description: Microsoft Corporation
>    "^microsys,.*":
>      description: MicroSys Electronics GmbH
> +  "^microtips,.*":
> +    description: Microtips Technology USA
>    "^mikroe,.*":
>      description: MikroElektronika d.o.o.
>    "^mikrotik,.*":

-- 
Regards,

Laurent Pinchart

[RFC PATCH 2/4] dt-bindings: vendor-prefixes: Add lincolntech

[Aradhya Bhatia]

Add document vendor prefix for Lincoln Technology Solutions
(lincolntech).

Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 516134cbcb3c..82427a6ddf97 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -729,6 +729,8 @@ patternProperties:
     description: Lichee Pi
   "^linaro,.*":
     description: Linaro Limited
+  "^lincolntech,.*":
+    description: Lincoln Technology Solutions
   "^linksprite,.*":
     description: LinkSprite Technologies, Inc.
   "^linksys,.*":
-- 
2.39.0

Re: [RFC PATCH 2/4] dt-bindings: vendor-prefixes: Add lincolntech

[Krzysztof Kozlowski]

On 03/01/2023 07:46, Aradhya Bhatia wrote:
> Add document vendor prefix for Lincoln Technology Solutions
> (lincolntech).
> 
> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++


Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [RFC PATCH 2/4] dt-bindings: vendor-prefixes: Add lincolntech

[Laurent Pinchart]

Hi Aradhya,

Thank you for the patch.

On Tue, Jan 03, 2023 at 12:16:13PM +0530, Aradhya Bhatia wrote:
> Add document vendor prefix for Lincoln Technology Solutions
> (lincolntech).
> 
> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>

Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 516134cbcb3c..82427a6ddf97 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -729,6 +729,8 @@ patternProperties:
>      description: Lichee Pi
>    "^linaro,.*":
>      description: Linaro Limited
> +  "^lincolntech,.*":
> +    description: Lincoln Technology Solutions
>    "^linksprite,.*":
>      description: LinkSprite Technologies, Inc.
>    "^linksys,.*":

-- 
Regards,

Laurent Pinchart

[RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel

[Aradhya Bhatia]

Dual-link LVDS interfaces have 2 links, with even pixels traveling on
one link, and odd pixels on the other. These panels are also generic in
nature, with no documented constraints, much like their single-link
counterparts, "panel-lvds".

Add a new compatible, "panel-dual-lvds", and a dt-binding document for
these panels.

Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
---
 .../display/panel/panel-dual-lvds.yaml        | 157 ++++++++++++++++++
 MAINTAINERS                                   |   1 +
 2 files changed, 158 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml

diff --git a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
new file mode 100644
index 000000000000..88a7aa2410be
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
@@ -0,0 +1,157 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Generic Dual-Link LVDS Display Panel
+
+maintainers:
+  - Aradhya Bhatia <a-bhatia1@ti.com>
+  - Thierry Reding <thierry.reding@gmail.com>
+
+description: |
+  A dual-LVDS interface is a dual-link connection with the even pixels
+  traveling on one link, and the odd pixels traveling on the other.
+
+allOf:
+  - $ref: panel-common.yaml#
+  - $ref: /schemas/display/lvds.yaml/#
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - lincolntech,lcd185-101ct
+              - microtips,13-101hieb0hf0-s
+          - const: panel-dual-lvds
+      - const: panel-dual-lvds
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port@0:
+        $ref: /schemas/graph.yaml#/$defs/port-base
+        unevaluatedProperties: false
+        description: The sink for first set of LVDS pixels.
+
+        properties:
+          dual-lvds-odd-pixels:
+            type: boolean
+
+          dual-lvds-even-pixels:
+            type: boolean
+
+        oneOf:
+          - required: [dual-lvds-odd-pixels]
+          - required: [dual-lvds-even-pixels]
+
+      port@1:
+        $ref: /schemas/graph.yaml#/$defs/port-base
+        unevaluatedProperties: false
+        description: The sink for second set of LVDS pixels.
+
+        properties:
+          dual-lvds-even-pixels:
+            type: boolean
+
+          dual-lvds-odd-pixels:
+            type: boolean
+
+        oneOf:
+          - required: [dual-lvds-even-pixels]
+          - required: [dual-lvds-odd-pixels]
+
+    allOf:
+      - if:
+          properties:
+            port@0:
+              properties:
+                dual-lvds-odd-pixels: true
+              required:
+                - dual-lvds-odd-pixels
+        then:
+          properties:
+            port@1:
+              properties:
+                dual-lvds-even-pixels: true
+                dual-lvds-odd-pixels: false
+
+      - if:
+          properties:
+            port@0:
+              properties:
+                dual-lvds-even-pixels: true
+              required:
+                - dual-lvds-even-pixels
+        then:
+          properties:
+            port@1:
+              properties:
+                dual-lvds-odd-pixels: true
+                dual-lvds-even-pixels: false
+
+    required:
+      - port@0
+      - port@1
+
+  port: false
+
+unevaluatedProperties: false
+
+required:
+  - compatible
+  - width-mm
+  - height-mm
+  - data-mapping
+  - panel-timing
+  - ports
+
+examples:
+  - |+
+    panel-dual-lvds {
+      compatible = "microtips,13-101hieb0hf0-s", "panel-dual-lvds";
+
+      width-mm = <217>;
+      height-mm = <136>;
+
+      data-mapping = "vesa-24";
+
+      panel-timing {
+        clock-frequency = <150275000>;
+        hactive = <1920>;
+        vactive = <1200>;
+        hfront-porch = <32>;
+        hsync-len = <52>;
+        hback-porch = <24>;
+        vfront-porch = <24>;
+        vsync-len = <8>;
+        vback-porch = <3>;
+        de-active = <1>;
+      };
+
+      ports {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        port@0 {
+          reg = <0>;
+          dual-lvds-odd-pixels;
+          lcd_in0: endpoint {
+            remote-endpoint = <&oldi_out0>;
+          };
+        };
+
+        port@1 {
+          reg = <1>;
+          dual-lvds-even-pixels;
+          lcd_in1: endpoint {
+            remote-endpoint = <&oldi_out1>;
+          };
+        };
+      };
+    };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 7f86d02cb427..c13f24293ab1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6595,6 +6595,7 @@ T:	git git://anongit.freedesktop.org/drm/drm-misc
 S:	Maintained
 F:	drivers/gpu/drm/panel/panel-lvds.c
 F:	Documentation/devicetree/bindings/display/lvds.yaml
+F:	Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
 F:	Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
 
 DRM DRIVER FOR MANTIX MLAF057WE51 PANELS
-- 
2.39.0

Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel

[Krzysztof Kozlowski]

On 03/01/2023 07:46, Aradhya Bhatia wrote:
> Dual-link LVDS interfaces have 2 links, with even pixels traveling on
> one link, and odd pixels on the other. These panels are also generic in
> nature, with no documented constraints, much like their single-link
> counterparts, "panel-lvds".
> 
> Add a new compatible, "panel-dual-lvds", and a dt-binding document for
> these panels.
> 
> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
> ---
>  .../display/panel/panel-dual-lvds.yaml        | 157 ++++++++++++++++++
>  MAINTAINERS                                   |   1 +
>  2 files changed, 158 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
> new file mode 100644
> index 000000000000..88a7aa2410be
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
> @@ -0,0 +1,157 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic Dual-Link LVDS Display Panel
> +
> +maintainers:
> +  - Aradhya Bhatia <a-bhatia1@ti.com>
> +  - Thierry Reding <thierry.reding@gmail.com>
> +
> +description: |
> +  A dual-LVDS interface is a dual-link connection with the even pixels
> +  traveling on one link, and the odd pixels traveling on the other.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +  - $ref: /schemas/display/lvds.yaml/#

Drop trailing /

> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - items:
> +          - enum:
> +              - lincolntech,lcd185-101ct
> +              - microtips,13-101hieb0hf0-s
> +          - const: panel-dual-lvds
> +      - const: panel-dual-lvds

You cannot have this compatible alone.

> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: The sink for first set of LVDS pixels.
> +
> +        properties:
> +          dual-lvds-odd-pixels:
> +            type: boolean
> +
> +          dual-lvds-even-pixels:
> +            type: boolean
> +
> +        oneOf:
> +          - required: [dual-lvds-odd-pixels]
> +          - required: [dual-lvds-even-pixels]
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: The sink for second set of LVDS pixels.
> +
> +        properties:
> +          dual-lvds-even-pixels:
> +            type: boolean
> +
> +          dual-lvds-odd-pixels:
> +            type: boolean
> +
> +        oneOf:
> +          - required: [dual-lvds-even-pixels]
> +          - required: [dual-lvds-odd-pixels]
> +
> +    allOf:
> +      - if:
> +          properties:
> +            port@0:
> +              properties:
> +                dual-lvds-odd-pixels: true

That's not correct clause. It has no effect.

> +              required:
> +                - dual-lvds-odd-pixels
> +        then:
> +          properties:
> +            port@1:
> +              properties:
> +                dual-lvds-even-pixels: true
> +                dual-lvds-odd-pixels: false

Why do you need this? Your oneOf before already solves it.

> +
> +      - if:
> +          properties:
> +            port@0:
> +              properties:
> +                dual-lvds-even-pixels: true
> +              required:
> +                - dual-lvds-even-pixels
> +        then:
> +          properties:
> +            port@1:
> +              properties:
> +                dual-lvds-odd-pixels: true
> +                dual-lvds-even-pixels: false
> +
> +    required:
> +      - port@0
> +      - port@1
> +
> +  port: false
> +
> +unevaluatedProperties: false
> +
> +required:
> +  - compatible
> +  - width-mm
> +  - height-mm
> +  - data-mapping
> +  - panel-timing
> +  - ports
> +
> +examples:
> +  - |+

Drop +

> +    panel-dual-lvds {

Just "panel". Node names should be generic.

> +      compatible = "microtips,13-101hieb0hf0-s", "panel-dual-lvds";
> +
> +      width-mm = <217>;
> +      height-mm = <136>;
> +

Best regards,
Krzysztof

Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel

[Aradhya Bhatia]

Hi Krzysztof,

Thank you for reviewing the patches!

On 03-Jan-23 14:02, Krzysztof Kozlowski wrote:
> On 03/01/2023 07:46, Aradhya Bhatia wrote:
>> Dual-link LVDS interfaces have 2 links, with even pixels traveling on
>> one link, and odd pixels on the other. These panels are also generic in
>> nature, with no documented constraints, much like their single-link
>> counterparts, "panel-lvds".
>>
>> Add a new compatible, "panel-dual-lvds", and a dt-binding document for
>> these panels.
>>
>> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
>> ---
>>   .../display/panel/panel-dual-lvds.yaml        | 157 ++++++++++++++++++
>>   MAINTAINERS                                   |   1 +
>>   2 files changed, 158 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>> new file mode 100644
>> index 000000000000..88a7aa2410be
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>> @@ -0,0 +1,157 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Generic Dual-Link LVDS Display Panel
>> +
>> +maintainers:
>> +  - Aradhya Bhatia <a-bhatia1@ti.com>
>> +  - Thierry Reding <thierry.reding@gmail.com>
>> +
>> +description: |
>> +  A dual-LVDS interface is a dual-link connection with the even pixels
>> +  traveling on one link, and the odd pixels traveling on the other.
>> +
>> +allOf:
>> +  - $ref: panel-common.yaml#
>> +  - $ref: /schemas/display/lvds.yaml/#
> 
> Drop trailing /

Okay, will do!

> 
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      - items:
>> +          - enum:
>> +              - lincolntech,lcd185-101ct
>> +              - microtips,13-101hieb0hf0-s
>> +          - const: panel-dual-lvds
>> +      - const: panel-dual-lvds
> 
> You cannot have this compatible alone
Okay, will make the change!

> 
>> +
>> +  ports:
>> +    $ref: /schemas/graph.yaml#/properties/ports
>> +
>> +    properties:
>> +      port@0:
>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>> +        unevaluatedProperties: false
>> +        description: The sink for first set of LVDS pixels.
>> +
>> +        properties:
>> +          dual-lvds-odd-pixels:
>> +            type: boolean
>> +
>> +          dual-lvds-even-pixels:
>> +            type: boolean
>> +
>> +        oneOf:
>> +          - required: [dual-lvds-odd-pixels]
>> +          - required: [dual-lvds-even-pixels]
>> +
>> +      port@1:
>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>> +        unevaluatedProperties: false
>> +        description: The sink for second set of LVDS pixels.
>> +
>> +        properties:
>> +          dual-lvds-even-pixels:
>> +            type: boolean
>> +
>> +          dual-lvds-odd-pixels:
>> +            type: boolean
>> +
>> +        oneOf:
>> +          - required: [dual-lvds-even-pixels]
>> +          - required: [dual-lvds-odd-pixels]
>> +
>> +    allOf:
>> +      - if:
>> +          properties:
>> +            port@0:
>> +              properties:
>> +                dual-lvds-odd-pixels: true
> 
> That's not correct clause. It has no effect.

The idea behind this is to check the presence of the boolean property.

if (dual-lvds-odd-pixels is present)
then
[..]


I tried implementing this:

	[..]
	  dual-lvds-odd-pixels:
	    - const: true
	[..]

But this is throwing an error. I am confused what else could be done.
Can you please suggest what might be a more accurate check here?

> 
>> +              required:
>> +                - dual-lvds-odd-pixels
>> +        then:
>> +          properties:
>> +            port@1:
>> +              properties:
>> +                dual-lvds-even-pixels: true
>> +                dual-lvds-odd-pixels: false
> 
> Why do you need this? Your oneOf before already solves it.

I agree with your comment here. It makes sense to only have

	dual-lvds-even-pixels: true

and have the oneOf condition take care of the other. But, I just tested
this and it was unable to pick-up this intentionally-added error.

I added 'dual-lvds-odd-pixels' property to both the nodes, and
dt_binding_check passes successfully (which it should have not.)

Instead, if I only keep this,

	dual-lvds-odd-pixels: false

then the dt_binding_check detects the error as it should.

Regardless, I am curious why the first method doesn't work. Will try to
explore more on that.

> 
>> +
>> +      - if:
>> +          properties:
>> +            port@0:
>> +              properties:
>> +                dual-lvds-even-pixels: true
>> +              required:
>> +                - dual-lvds-even-pixels
>> +        then:
>> +          properties:
>> +            port@1:
>> +              properties:
>> +                dual-lvds-odd-pixels: true
>> +                dual-lvds-even-pixels: false
>> +
>> +    required:
>> +      - port@0
>> +      - port@1
>> +
>> +  port: false
>> +
>> +unevaluatedProperties: false
>> +
>> +required:
>> +  - compatible
>> +  - width-mm
>> +  - height-mm
>> +  - data-mapping
>> +  - panel-timing
>> +  - ports
>> +
>> +examples:
>> +  - |+
> 
> Drop +

Okay!

> 
>> +    panel-dual-lvds {
> 
> Just "panel". Node names should be generic.

Alright. Will make the change!

> 
>> +      compatible = "microtips,13-101hieb0hf0-s", "panel-dual-lvds";
>> +
>> +      width-mm = <217>;
>> +      height-mm = <136>;
>> +
> 
Regards
Aradhya

Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel

[Krzysztof Kozlowski]

On 03/01/2023 12:02, Aradhya Bhatia wrote:
> But this is throwing an error. I am confused what else could be done.
> Can you please suggest what might be a more accurate check here?
> 
>>
>>> +              required:
>>> +                - dual-lvds-odd-pixels
>>> +        then:
>>> +          properties:
>>> +            port@1:
>>> +              properties:
>>> +                dual-lvds-even-pixels: true
>>> +                dual-lvds-odd-pixels: false
>>
>> Why do you need this? Your oneOf before already solves it.
> 
> I agree with your comment here. It makes sense to only have
> 
> 	dual-lvds-even-pixels: true
> 
> and have the oneOf condition take care of the other. But, I just tested
> this and it was unable to pick-up this intentionally-added error.
> 
> I added 'dual-lvds-odd-pixels' property to both the nodes, and
> dt_binding_check passes successfully (which it should have not.)
> 
> Instead, if I only keep this,
> 
> 	dual-lvds-odd-pixels: false
> 
> then the dt_binding_check detects the error as it should.
> 
> Regardless, I am curious why the first method doesn't work. Will try to
> explore more on that.

The check for presence of properties is only against required:, but you
added there properties. Like this:

https://elixir.bootlin.com/linux/v5.17-rc2/source/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml#L155


Other way is to drop your both oneOf and entire allOf from ports and use:

oneOf:
  - properties:
      ports:
        $ref: /schemas/graph.yaml#/properties/ports
        properties:
          port@0:
            required:
              - dual-lvds-odd-pixels
          port@1:
            required:
              - dual-lvds-even-pixels
  - properties:
      ports:
        $ref: /schemas/graph.yaml#/properties/ports
        properties:
          port@1:
            required:
              - dual-lvds-odd-pixels
          port@0:
            required:
              - dual-lvds-even-pixels


Best regards,
Krzysztof

Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel

[Aradhya Bhatia]

Hi Krzysztof,

On 03-Jan-23 16:58, Krzysztof Kozlowski wrote:
> On 03/01/2023 12:02, Aradhya Bhatia wrote:
>> But this is throwing an error. I am confused what else could be done.
>> Can you please suggest what might be a more accurate check here?
>>
>>>
>>>> +              required:
>>>> +                - dual-lvds-odd-pixels
>>>> +        then:
>>>> +          properties:
>>>> +            port@1:
>>>> +              properties:
>>>> +                dual-lvds-even-pixels: true
>>>> +                dual-lvds-odd-pixels: false
>>>
>>> Why do you need this? Your oneOf before already solves it.
>>
>> I agree with your comment here. It makes sense to only have
>>
>> 	dual-lvds-even-pixels: true
>>
>> and have the oneOf condition take care of the other. But, I just tested
>> this and it was unable to pick-up this intentionally-added error.
>>
>> I added 'dual-lvds-odd-pixels' property to both the nodes, and
>> dt_binding_check passes successfully (which it should have not.)
>>
>> Instead, if I only keep this,
>>
>> 	dual-lvds-odd-pixels: false
>>
>> then the dt_binding_check detects the error as it should.
>>
>> Regardless, I am curious why the first method doesn't work. Will try to
>> explore more on that.
> 
> The check for presence of properties is only against required:, but you
> added there properties. Like this:
> 
> https://elixir.bootlin.com/linux/v5.17-rc2/source/Documentation/devicetree/bindings/mfd/samsung,s5m8767.yaml#L155
> 
> 
> Other way is to drop your both oneOf and entire allOf from ports and use:
> 
> oneOf:
>    - properties:
>        ports:
>          $ref: /schemas/graph.yaml#/properties/ports
>          properties:
>            port@0:
>              required:
>                - dual-lvds-odd-pixels
>            port@1:
>              required:
>                - dual-lvds-even-pixels
>    - properties:
>        ports:
>          $ref: /schemas/graph.yaml#/properties/ports
>          properties:
>            port@1:
>              required:
>                - dual-lvds-odd-pixels
>            port@0:
>              required:
>                - dual-lvds-even-pixels
> 

Thank you for the suggestions.
I tested the both of them, and they seem to be working as expected.

V2 will reflect all the required fixes.


Regards
Aradhya

Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel

[AngeloGioacchino Del Regno]

Il 03/01/23 07:46, Aradhya Bhatia ha scritto:
> Dual-link LVDS interfaces have 2 links, with even pixels traveling on
> one link, and odd pixels on the other. These panels are also generic in
> nature, with no documented constraints, much like their single-link
> counterparts, "panel-lvds".
> 
> Add a new compatible, "panel-dual-lvds", and a dt-binding document for
> these panels.
> 
> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
> ---
>   .../display/panel/panel-dual-lvds.yaml        | 157 ++++++++++++++++++
>   MAINTAINERS                                   |   1 +
>   2 files changed, 158 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
> new file mode 100644
> index 000000000000..88a7aa2410be
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
> @@ -0,0 +1,157 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic Dual-Link LVDS Display Panel
> +
> +maintainers:
> +  - Aradhya Bhatia <a-bhatia1@ti.com>
> +  - Thierry Reding <thierry.reding@gmail.com>
> +
> +description: |
> +  A dual-LVDS interface is a dual-link connection with the even pixels
> +  traveling on one link, and the odd pixels traveling on the other.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +  - $ref: /schemas/display/lvds.yaml/#
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - items:
> +          - enum:
> +              - lincolntech,lcd185-101ct
> +              - microtips,13-101hieb0hf0-s
> +          - const: panel-dual-lvds
> +      - const: panel-dual-lvds
> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: The sink for first set of LVDS pixels.
> +
> +        properties:
> +          dual-lvds-odd-pixels:
> +            type: boolean
> +
> +          dual-lvds-even-pixels:
> +            type: boolean
> +
> +        oneOf:
> +          - required: [dual-lvds-odd-pixels]

One question: why do we need a "panel-dual-lvds" compatible?
A Dual-LVDS panel is a LVDS panel using two ports, hence still a panel-lvds.

If you're doing this to clearly distinguish, for human readability purposes,
single-link vs dual-link panels, I think that this would still be clear even
if we use panel-lvds alone because dual-link panels, as you wrote in this
binding, does *require* two ports, with "dual-lvds-{odd,even}-pixels" properties.

So... the devicetree node would look like this:

panel {
	compatible = "vendor,panel", "panel-lvds";
	....
	ports {
		port@0 {
			.....
			-> dual-lvds-odd-pixels <-
		}

		port@1 {
			.....
			-> dual-lvds-even-pixels <-
		};
	};
};

> +          - required: [dual-lvds-even-pixels]

...Though, if you expect dual-lvds panels to get other quirks in the future,
that's a whole different story and you may actually need the panel-dual-lvds
compatible.

Regards,
Angelo

Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel

[Aradhya Bhatia]

Hi Angelo,

Thanks for taking a look at the patches!

On 03-Jan-23 17:21, AngeloGioacchino Del Regno wrote:
> Il 03/01/23 07:46, Aradhya Bhatia ha scritto:
>> Dual-link LVDS interfaces have 2 links, with even pixels traveling on
>> one link, and odd pixels on the other. These panels are also generic in
>> nature, with no documented constraints, much like their single-link
>> counterparts, "panel-lvds".
>>
>> Add a new compatible, "panel-dual-lvds", and a dt-binding document for
>> these panels.
>>
>> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
>> ---
>>   .../display/panel/panel-dual-lvds.yaml        | 157 ++++++++++++++++++
>>   MAINTAINERS                                   |   1 +
>>   2 files changed, 158 insertions(+)
>>   create mode 100644 
>> Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml 
>> b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>> new file mode 100644
>> index 000000000000..88a7aa2410be
>> --- /dev/null
>> +++ 
>> b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>> @@ -0,0 +1,157 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Generic Dual-Link LVDS Display Panel
>> +
>> +maintainers:
>> +  - Aradhya Bhatia <a-bhatia1@ti.com>
>> +  - Thierry Reding <thierry.reding@gmail.com>
>> +
>> +description: |
>> +  A dual-LVDS interface is a dual-link connection with the even pixels
>> +  traveling on one link, and the odd pixels traveling on the other.
>> +
>> +allOf:
>> +  - $ref: panel-common.yaml#
>> +  - $ref: /schemas/display/lvds.yaml/#
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      - items:
>> +          - enum:
>> +              - lincolntech,lcd185-101ct
>> +              - microtips,13-101hieb0hf0-s
>> +          - const: panel-dual-lvds
>> +      - const: panel-dual-lvds
>> +
>> +  ports:
>> +    $ref: /schemas/graph.yaml#/properties/ports
>> +
>> +    properties:
>> +      port@0:
>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>> +        unevaluatedProperties: false
>> +        description: The sink for first set of LVDS pixels.
>> +
>> +        properties:
>> +          dual-lvds-odd-pixels:
>> +            type: boolean
>> +
>> +          dual-lvds-even-pixels:
>> +            type: boolean
>> +
>> +        oneOf:
>> +          - required: [dual-lvds-odd-pixels]
> 
> One question: why do we need a "panel-dual-lvds" compatible?
> A Dual-LVDS panel is a LVDS panel using two ports, hence still a panel-lvds.
> 
> If you're doing this to clearly distinguish, for human readability purposes,
> single-link vs dual-link panels, I think that this would still be clear even
> if we use panel-lvds alone because dual-link panels, as you wrote in this
> binding, does *require* two ports, with "dual-lvds-{odd,even}-pixels" properties.

Yes, while they are both LVDS based panels the extra LVDS sink in these
panels, and the capability to decode and display the 2 sets of signals
are enough hardware differences that warrant for an addition of a new
compatible.

> 
> So... the devicetree node would look like this:
> 
> panel {
>      compatible = "vendor,panel", "panel-lvds";
>      ....
>      ports {
>          port@0 {
>              .....
>              -> dual-lvds-odd-pixels <-
>          }
> 
>          port@1 {
>              .....
>              -> dual-lvds-even-pixels <-
>          };
>      };
> };
> 
>> +          - required: [dual-lvds-even-pixels]
> 
> ...Though, if you expect dual-lvds panels to get other quirks in the future,
> that's a whole different story and you may actually need the panel-dual-lvds
> compatible.

Yes, exactly. Even while being non-smart, there are going to be more
quirks in future. And it would be better if they have their own
compatible/binding, and are not getting appended in an ever-growing
if-else ladder. :)


Regards
Aradhya

Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel

[Tomi Valkeinen]

On 09/01/2023 18:21, Aradhya Bhatia wrote:
> Hi Angelo,
> 
> Thanks for taking a look at the patches!
> 
> On 03-Jan-23 17:21, AngeloGioacchino Del Regno wrote:
>> Il 03/01/23 07:46, Aradhya Bhatia ha scritto:
>>> Dual-link LVDS interfaces have 2 links, with even pixels traveling on
>>> one link, and odd pixels on the other. These panels are also generic in
>>> nature, with no documented constraints, much like their single-link
>>> counterparts, "panel-lvds".
>>>
>>> Add a new compatible, "panel-dual-lvds", and a dt-binding document for
>>> these panels.
>>>
>>> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
>>> ---
>>>   .../display/panel/panel-dual-lvds.yaml        | 157 ++++++++++++++++++
>>>   MAINTAINERS                                   |   1 +
>>>   2 files changed, 158 insertions(+)
>>>   create mode 100644 
>>> Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>> new file mode 100644
>>> index 000000000000..88a7aa2410be
>>> --- /dev/null
>>> +++ 
>>> b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>> @@ -0,0 +1,157 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Generic Dual-Link LVDS Display Panel
>>> +
>>> +maintainers:
>>> +  - Aradhya Bhatia <a-bhatia1@ti.com>
>>> +  - Thierry Reding <thierry.reding@gmail.com>
>>> +
>>> +description: |
>>> +  A dual-LVDS interface is a dual-link connection with the even pixels
>>> +  traveling on one link, and the odd pixels traveling on the other.
>>> +
>>> +allOf:
>>> +  - $ref: panel-common.yaml#
>>> +  - $ref: /schemas/display/lvds.yaml/#
>>> +
>>> +properties:
>>> +  compatible:
>>> +    oneOf:
>>> +      - items:
>>> +          - enum:
>>> +              - lincolntech,lcd185-101ct
>>> +              - microtips,13-101hieb0hf0-s
>>> +          - const: panel-dual-lvds
>>> +      - const: panel-dual-lvds
>>> +
>>> +  ports:
>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>> +
>>> +    properties:
>>> +      port@0:
>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>> +        unevaluatedProperties: false
>>> +        description: The sink for first set of LVDS pixels.
>>> +
>>> +        properties:
>>> +          dual-lvds-odd-pixels:
>>> +            type: boolean
>>> +
>>> +          dual-lvds-even-pixels:
>>> +            type: boolean
>>> +
>>> +        oneOf:
>>> +          - required: [dual-lvds-odd-pixels]
>>
>> One question: why do we need a "panel-dual-lvds" compatible?
>> A Dual-LVDS panel is a LVDS panel using two ports, hence still a 
>> panel-lvds.
>>
>> If you're doing this to clearly distinguish, for human readability 
>> purposes,
>> single-link vs dual-link panels, I think that this would still be 
>> clear even
>> if we use panel-lvds alone because dual-link panels, as you wrote in this
>> binding, does *require* two ports, with "dual-lvds-{odd,even}-pixels" 
>> properties.
> 
> Yes, while they are both LVDS based panels the extra LVDS sink in these
> panels, and the capability to decode and display the 2 sets of signals
> are enough hardware differences that warrant for an addition of a new
> compatible.
> 
>>
>> So... the devicetree node would look like this:
>>
>> panel {
>>      compatible = "vendor,panel", "panel-lvds";
>>      ....
>>      ports {
>>          port@0 {
>>              .....
>>              -> dual-lvds-odd-pixels <-
>>          }
>>
>>          port@1 {
>>              .....
>>              -> dual-lvds-even-pixels <-
>>          };
>>      };
>> };
>>
>>> +          - required: [dual-lvds-even-pixels]
>>
>> ...Though, if you expect dual-lvds panels to get other quirks in the 
>> future,
>> that's a whole different story and you may actually need the 
>> panel-dual-lvds
>> compatible.
> 
> Yes, exactly. Even while being non-smart, there are going to be more
> quirks in future. And it would be better if they have their own
> compatible/binding, and are not getting appended in an ever-growing
> if-else ladder. :)

I can imagine a panel which you can use with a single LVDS link if the 
clock is high enough, or two LVDS links if the clock has to be lower. Is 
that a dual-lvds panel? =)

But probably that situation is no different than a panel that can work 
with DSI or DPI input.

Still, I'm agree with Angelo in that a new compatible string for dual 
link lvds feels a bit odd. That said, it's possible the panel-lvds 
bindings might get rather confusing. So I don't have a strong feeling here.

  Tomi

Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel

[Aradhya Bhatia]

Hi Tomi,

Thank you for taking a look at the patches!

On 17-Jan-23 18:08, Tomi Valkeinen wrote:
> On 09/01/2023 18:21, Aradhya Bhatia wrote:
>> Hi Angelo,
>>
>> Thanks for taking a look at the patches!
>>
>> On 03-Jan-23 17:21, AngeloGioacchino Del Regno wrote:
>>> Il 03/01/23 07:46, Aradhya Bhatia ha scritto:
>>>> Dual-link LVDS interfaces have 2 links, with even pixels traveling on
>>>> one link, and odd pixels on the other. These panels are also generic in
>>>> nature, with no documented constraints, much like their single-link
>>>> counterparts, "panel-lvds".
>>>>
>>>> Add a new compatible, "panel-dual-lvds", and a dt-binding document for
>>>> these panels.
>>>>
>>>> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
>>>> ---
>>>>   .../display/panel/panel-dual-lvds.yaml        | 157 
>>>> ++++++++++++++++++
>>>>   MAINTAINERS                                   |   1 +
>>>>   2 files changed, 158 insertions(+)
>>>>   create mode 100644 
>>>> Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>>>
>>>> diff --git 
>>>> a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>>> new file mode 100644
>>>> index 000000000000..88a7aa2410be
>>>> --- /dev/null
>>>> +++ 
>>>> b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>>> @@ -0,0 +1,157 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Generic Dual-Link LVDS Display Panel
>>>> +
>>>> +maintainers:
>>>> +  - Aradhya Bhatia <a-bhatia1@ti.com>
>>>> +  - Thierry Reding <thierry.reding@gmail.com>
>>>> +
>>>> +description: |
>>>> +  A dual-LVDS interface is a dual-link connection with the even pixels
>>>> +  traveling on one link, and the odd pixels traveling on the other.
>>>> +
>>>> +allOf:
>>>> +  - $ref: panel-common.yaml#
>>>> +  - $ref: /schemas/display/lvds.yaml/#
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    oneOf:
>>>> +      - items:
>>>> +          - enum:
>>>> +              - lincolntech,lcd185-101ct
>>>> +              - microtips,13-101hieb0hf0-s
>>>> +          - const: panel-dual-lvds
>>>> +      - const: panel-dual-lvds
>>>> +
>>>> +  ports:
>>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>>> +
>>>> +    properties:
>>>> +      port@0:
>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>>> +        unevaluatedProperties: false
>>>> +        description: The sink for first set of LVDS pixels.
>>>> +
>>>> +        properties:
>>>> +          dual-lvds-odd-pixels:
>>>> +            type: boolean
>>>> +
>>>> +          dual-lvds-even-pixels:
>>>> +            type: boolean
>>>> +
>>>> +        oneOf:
>>>> +          - required: [dual-lvds-odd-pixels]
>>>
>>> One question: why do we need a "panel-dual-lvds" compatible?
>>> A Dual-LVDS panel is a LVDS panel using two ports, hence still a 
>>> panel-lvds.
>>>
>>> If you're doing this to clearly distinguish, for human readability purposes,
>>> single-link vs dual-link panels, I think that this would still be clear even
>>> if we use panel-lvds alone because dual-link panels, as you wrote in this
>>> binding, does *require* two ports, with "dual-lvds-{odd,even}-pixels" properties.
>>
>> Yes, while they are both LVDS based panels the extra LVDS sink in these
>> panels, and the capability to decode and display the 2 sets of signals
>> are enough hardware differences that warrant for an addition of a new
>> compatible.
>>
>>>
>>> So... the devicetree node would look like this:
>>>
>>> panel {
>>>      compatible = "vendor,panel", "panel-lvds";
>>>      ....
>>>      ports {
>>>          port@0 {
>>>              .....
>>>              -> dual-lvds-odd-pixels <-
>>>          }
>>>
>>>          port@1 {
>>>              .....
>>>              -> dual-lvds-even-pixels <-
>>>          };
>>>      };
>>> };
>>>
>>>> +          - required: [dual-lvds-even-pixels]
>>>
>>> ...Though, if you expect dual-lvds panels to get other quirks in the future,
>>> that's a whole different story and you may actually need the panel-dual-lvds
>>> compatible.
>>
>> Yes, exactly. Even while being non-smart, there are going to be more
>> quirks in future. And it would be better if they have their own
>> compatible/binding, and are not getting appended in an ever-growing
>> if-else ladder. :)
> 
> I can imagine a panel which you can use with a single LVDS link if the 
> clock is high enough, or two LVDS links if the clock has to be lower. Is 
> that a dual-lvds panel? =)

Hmm, I can see what you are saying here.

If one wants to run a dual-link panel, with 1 link (given enough clock
frequency), then the bindings here will *not* allow for a single port
with the odd/even properties absent.

In such a case, the compatible will indeed need to be changed to
"panel-lvds".

While it does feel a tad bit odd, I believe it is still worth
maintaining the clarity and HW differences between the single and dual
link panels. :)

> 
> But probably that situation is no different than a panel that can work 
> with DSI or DPI input.
> 
> Still, I'm agree with Angelo in that a new compatible string for dual 
> link lvds feels a bit odd. That said, it's possible the panel-lvds  > bindings might get rather confusing. So I don't have a strong feeling 
here.

Regards
Aradhya

Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel

[Laurent Pinchart]

Hi Aradhya,

Thank you for the patch.

On Tue, Jan 03, 2023 at 12:16:14PM +0530, Aradhya Bhatia wrote:
> Dual-link LVDS interfaces have 2 links, with even pixels traveling on
> one link, and odd pixels on the other. These panels are also generic in
> nature, with no documented constraints, much like their single-link
> counterparts, "panel-lvds".
> 
> Add a new compatible, "panel-dual-lvds", and a dt-binding document for
> these panels.
> 
> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
> ---
>  .../display/panel/panel-dual-lvds.yaml        | 157 ++++++++++++++++++
>  MAINTAINERS                                   |   1 +
>  2 files changed, 158 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
> new file mode 100644
> index 000000000000..88a7aa2410be
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
> @@ -0,0 +1,157 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic Dual-Link LVDS Display Panel
> +
> +maintainers:
> +  - Aradhya Bhatia <a-bhatia1@ti.com>
> +  - Thierry Reding <thierry.reding@gmail.com>
> +
> +description: |
> +  A dual-LVDS interface is a dual-link connection with the even pixels
> +  traveling on one link, and the odd pixels traveling on the other.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +  - $ref: /schemas/display/lvds.yaml/#
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - items:
> +          - enum:
> +              - lincolntech,lcd185-101ct
> +              - microtips,13-101hieb0hf0-s
> +          - const: panel-dual-lvds
> +      - const: panel-dual-lvds

A device-specific compatible string should be required,
"panel-dual-lvds" alone shouldn't be allowed. Otherwise it won't be
possible to tell different models apart later should this be required.

> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: The sink for first set of LVDS pixels.
> +
> +        properties:
> +          dual-lvds-odd-pixels:
> +            type: boolean
> +
> +          dual-lvds-even-pixels:
> +            type: boolean
> +
> +        oneOf:
> +          - required: [dual-lvds-odd-pixels]
> +          - required: [dual-lvds-even-pixels]
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: The sink for second set of LVDS pixels.
> +
> +        properties:
> +          dual-lvds-even-pixels:
> +            type: boolean
> +
> +          dual-lvds-odd-pixels:
> +            type: boolean
> +
> +        oneOf:
> +          - required: [dual-lvds-even-pixels]
> +          - required: [dual-lvds-odd-pixels]
> +
> +    allOf:
> +      - if:
> +          properties:
> +            port@0:
> +              properties:
> +                dual-lvds-odd-pixels: true
> +              required:
> +                - dual-lvds-odd-pixels
> +        then:
> +          properties:
> +            port@1:
> +              properties:
> +                dual-lvds-even-pixels: true
> +                dual-lvds-odd-pixels: false
> +
> +      - if:
> +          properties:
> +            port@0:
> +              properties:
> +                dual-lvds-even-pixels: true
> +              required:
> +                - dual-lvds-even-pixels
> +        then:
> +          properties:
> +            port@1:
> +              properties:
> +                dual-lvds-odd-pixels: true
> +                dual-lvds-even-pixels: false
> +
> +    required:
> +      - port@0
> +      - port@1
> +
> +  port: false
> +
> +unevaluatedProperties: false
> +
> +required:
> +  - compatible
> +  - width-mm
> +  - height-mm
> +  - data-mapping
> +  - panel-timing
> +  - ports
> +
> +examples:
> +  - |+
> +    panel-dual-lvds {
> +      compatible = "microtips,13-101hieb0hf0-s", "panel-dual-lvds";
> +
> +      width-mm = <217>;
> +      height-mm = <136>;
> +
> +      data-mapping = "vesa-24";
> +
> +      panel-timing {
> +        clock-frequency = <150275000>;
> +        hactive = <1920>;
> +        vactive = <1200>;
> +        hfront-porch = <32>;
> +        hsync-len = <52>;
> +        hback-porch = <24>;
> +        vfront-porch = <24>;
> +        vsync-len = <8>;
> +        vback-porch = <3>;
> +        de-active = <1>;
> +      };
> +
> +      ports {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        port@0 {
> +          reg = <0>;
> +          dual-lvds-odd-pixels;
> +          lcd_in0: endpoint {
> +            remote-endpoint = <&oldi_out0>;
> +          };
> +        };
> +
> +        port@1 {
> +          reg = <1>;
> +          dual-lvds-even-pixels;
> +          lcd_in1: endpoint {
> +            remote-endpoint = <&oldi_out1>;
> +          };
> +        };
> +      };
> +    };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7f86d02cb427..c13f24293ab1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6595,6 +6595,7 @@ T:	git git://anongit.freedesktop.org/drm/drm-misc
>  S:	Maintained
>  F:	drivers/gpu/drm/panel/panel-lvds.c
>  F:	Documentation/devicetree/bindings/display/lvds.yaml
> +F:	Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>  F:	Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
>  
>  DRM DRIVER FOR MANTIX MLAF057WE51 PANELS

-- 
Regards,

Laurent Pinchart

Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS panel

[Aradhya Bhatia]

Hi Laurent,

Thank you for reviewing the patches!

On 08-Jan-23 12:26, Laurent Pinchart wrote:
> Hi Aradhya,
> 
> Thank you for the patch.
> 
> On Tue, Jan 03, 2023 at 12:16:14PM +0530, Aradhya Bhatia wrote:
>> Dual-link LVDS interfaces have 2 links, with even pixels traveling on
>> one link, and odd pixels on the other. These panels are also generic in
>> nature, with no documented constraints, much like their single-link
>> counterparts, "panel-lvds".
>>
>> Add a new compatible, "panel-dual-lvds", and a dt-binding document for
>> these panels.
>>
>> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
>> ---
>>   .../display/panel/panel-dual-lvds.yaml        | 157 ++++++++++++++++++
>>   MAINTAINERS                                   |   1 +
>>   2 files changed, 158 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>> new file mode 100644
>> index 000000000000..88a7aa2410be
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>> @@ -0,0 +1,157 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/panel/panel-dual-lvds.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Generic Dual-Link LVDS Display Panel
>> +
>> +maintainers:
>> +  - Aradhya Bhatia <a-bhatia1@ti.com>
>> +  - Thierry Reding <thierry.reding@gmail.com>
>> +
>> +description: |
>> +  A dual-LVDS interface is a dual-link connection with the even pixels
>> +  traveling on one link, and the odd pixels traveling on the other.
>> +
>> +allOf:
>> +  - $ref: panel-common.yaml#
>> +  - $ref: /schemas/display/lvds.yaml/#
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      - items:
>> +          - enum:
>> +              - lincolntech,lcd185-101ct
>> +              - microtips,13-101hieb0hf0-s
>> +          - const: panel-dual-lvds
>> +      - const: panel-dual-lvds
> 
> A device-specific compatible string should be required,
> "panel-dual-lvds" alone shouldn't be allowed. Otherwise it won't be
> possible to tell different models apart later should this be required.
> 

Understood! Will make the fix in the next revision.

>> +
>> +  ports:
>> +    $ref: /schemas/graph.yaml#/properties/ports
>> +
>> +    properties:
>> +      port@0:
>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>> +        unevaluatedProperties: false
>> +        description: The sink for first set of LVDS pixels.
>> +
>> +        properties:
>> +          dual-lvds-odd-pixels:
>> +            type: boolean
>> +
>> +          dual-lvds-even-pixels:
>> +            type: boolean
>> +
>> +        oneOf:
>> +          - required: [dual-lvds-odd-pixels]
>> +          - required: [dual-lvds-even-pixels]
>> +
>> +      port@1:
>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>> +        unevaluatedProperties: false
>> +        description: The sink for second set of LVDS pixels.
>> +
>> +        properties:
>> +          dual-lvds-even-pixels:
>> +            type: boolean
>> +
>> +          dual-lvds-odd-pixels:
>> +            type: boolean
>> +
>> +        oneOf:
>> +          - required: [dual-lvds-even-pixels]
>> +          - required: [dual-lvds-odd-pixels]
>> +
>> +    allOf:
>> +      - if:
>> +          properties:
>> +            port@0:
>> +              properties:
>> +                dual-lvds-odd-pixels: true
>> +              required:
>> +                - dual-lvds-odd-pixels
>> +        then:
>> +          properties:
>> +            port@1:
>> +              properties:
>> +                dual-lvds-even-pixels: true
>> +                dual-lvds-odd-pixels: false
>> +
>> +      - if:
>> +          properties:
>> +            port@0:
>> +              properties:
>> +                dual-lvds-even-pixels: true
>> +              required:
>> +                - dual-lvds-even-pixels
>> +        then:
>> +          properties:
>> +            port@1:
>> +              properties:
>> +                dual-lvds-odd-pixels: true
>> +                dual-lvds-even-pixels: false
>> +
>> +    required:
>> +      - port@0
>> +      - port@1
>> +
>> +  port: false
>> +
>> +unevaluatedProperties: false
>> +
>> +required:
>> +  - compatible
>> +  - width-mm
>> +  - height-mm
>> +  - data-mapping
>> +  - panel-timing
>> +  - ports
>> +
>> +examples:
>> +  - |+
>> +    panel-dual-lvds {
>> +      compatible = "microtips,13-101hieb0hf0-s", "panel-dual-lvds";
>> +
>> +      width-mm = <217>;
>> +      height-mm = <136>;
>> +
>> +      data-mapping = "vesa-24";
>> +
>> +      panel-timing {
>> +        clock-frequency = <150275000>;
>> +        hactive = <1920>;
>> +        vactive = <1200>;
>> +        hfront-porch = <32>;
>> +        hsync-len = <52>;
>> +        hback-porch = <24>;
>> +        vfront-porch = <24>;
>> +        vsync-len = <8>;
>> +        vback-porch = <3>;
>> +        de-active = <1>;
>> +      };
>> +
>> +      ports {
>> +        #address-cells = <1>;
>> +        #size-cells = <0>;
>> +
>> +        port@0 {
>> +          reg = <0>;
>> +          dual-lvds-odd-pixels;
>> +          lcd_in0: endpoint {
>> +            remote-endpoint = <&oldi_out0>;
>> +          };
>> +        };
>> +
>> +        port@1 {
>> +          reg = <1>;
>> +          dual-lvds-even-pixels;
>> +          lcd_in1: endpoint {
>> +            remote-endpoint = <&oldi_out1>;
>> +          };
>> +        };
>> +      };
>> +    };
>> +
>> +...
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 7f86d02cb427..c13f24293ab1 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -6595,6 +6595,7 @@ T:	git git://anongit.freedesktop.org/drm/drm-misc
>>   S:	Maintained
>>   F:	drivers/gpu/drm/panel/panel-lvds.c
>>   F:	Documentation/devicetree/bindings/display/lvds.yaml
>> +F:	Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
>>   F:	Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
>>   
>>   DRM DRIVER FOR MANTIX MLAF057WE51 PANELS
> 

Regards
Aradhya

[RFC PATCH 4/4] drm: panel-lvds: Introduce dual-link panels

[Aradhya Bhatia]

Add a new compatible, "panel-dual-lvds".

Dual-link LVDS interfaces have 2 links, with even pixels traveling on
one link, and odd pixels on the other. These panels are also generic in
nature, with no documented constraints, much like their single-link
counterparts, "panel-lvds".

Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
---
 drivers/gpu/drm/panel/panel-lvds.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-lvds.c b/drivers/gpu/drm/panel/panel-lvds.c
index de8758c30e6e..bf6f84af0730 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -241,6 +241,7 @@ static int panel_lvds_remove(struct platform_device *pdev)
 
 static const struct of_device_id panel_lvds_of_table[] = {
 	{ .compatible = "panel-lvds", },
+	{ .compatible = "panel-dual-lvds", },
 	{ /* Sentinel */ },
 };
 
-- 
2.39.0

Re: [RFC PATCH 0/4] dt-bindings: Introduce dual-link panels & panel-vendors

[Laurent Pinchart]

Hi Aradhya,

On Tue, Jan 03, 2023 at 12:16:11PM +0530, Aradhya Bhatia wrote:
> Hi all,
> 
> Microtips Technology Solutions USA, and Lincoln Technology Solutions are
> 2 display panel vendors, and the first 2 patches add their vendor
> prefixes.
> 
> The fourth patch, simply introduces the new compatible for the generic
> dual-link panels in the panel-lvds driver. This new compatible is based
> from a new DT binding added in the third patch explained below.
> 
> The third patch introduces a dt-binding for generic dual-link LVDS
> panels. These panels do not have any documented constraints, except for
> their timing characteristics. Further, these panels have 2 pixel-sinks.
> In a dual-link connection between an LVDS encoder and the panel, one
> sink accepts the odd set of LVDS pixels and the other, the even set.
> 
> A lot of this has been based from the Advantech,idk-2121wr dual-link
> panel[1] and Maxime's patches for generic LVDS panels[2] (which are
> single-link by default.) and the discussions that happened before they
> were finally merged.
> 
> Below are some notes and points that I want to bring forward.
> 
>   - The advantech,idk-2121wr panel binding uses 2 boolean properties
>     dual-link-odd/even-pixels, to signify which port sink is being used
>     for which set of LVDS pixels. I too have added similar support and
>     introduced constraints around those properties, so as to not break
>     the ABI... but I believe there is a better way to achieve this.
> 
>     A "pixel-type" enum property could be introduced in their stead,
>     which can accept one of the 2 options <dual-lvds-odd-pixels> or
>     <dual-lvds-even-pixels>.
> 
>     This method, in my opinion, is more accurate and cleaner to
>     implement in the bindings as well.
> 
>     If this does sound a better I can push out a new revision where the
>     driver supports both these methods (to not break the ABI) and the
>     advantech,2121wr panel can remain as an exception.

It's usually best not to change an existing system if there are no good
reasons, so I'd ask why you think a pixel-type property would be better
(including when taking into account the fact that we would have to
maintain the advantech,2121wtr driver separately) if you want to go that
way. Otherwise, if we were developing this from scratch, I would have no
real preference.

>   - As an alternative to the previous point, if that method is not
>     preferred for some reason, the advantech,2121wtr panel binding
>     could then be merged in the panel-dual-lvds binding as part of
>     future work.
> 
> 
>   - Another tweak, I am looking forward to do as part of future work and
>     would like all your comments is to introduce driver-based
>     implementation of the panel timing parameters, like it is with
>     "panel-simple". The driver can then support both the panel-timing
>     sources (DT node or hard-coded driver structure) and the binding
>     can remove this from the "required" section.

There's been a very long discussion in the past (multiple discussions
actually) regarding whether timings should be set in DT or in drivers.
There were multiple arguments supporting both sides, without (it seems)
a clear winner. If you want driver-side timings for dual-link panels,
I'd like to understand why you think that's better. If the reasons are
the same as the ones expressed when we discussed simple panels, you
should also look at whether or not any of the fears expressed on either
side have materialized.

> Thank you!
> 
> [1]: https://patchwork.freedesktop.org/patch/357122/
> [2]: https://patchwork.freedesktop.org/patch/471228/
> 
> Aradhya Bhatia (4):
>   dt-bindings: vendor-prefixes: Add microtips
>   dt-bindings: vendor-prefixes: Add lincolntech
>   dt-bindings: panel: Introduce dual-link LVDS panel
>   drm: panel-lvds: Introduce dual-link panels
> 
>  .../display/panel/panel-dual-lvds.yaml        | 157 ++++++++++++++++++
>  .../devicetree/bindings/vendor-prefixes.yaml  |   4 +
>  MAINTAINERS                                   |   1 +
>  drivers/gpu/drm/panel/panel-lvds.c            |   1 +
>  4 files changed, 163 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml

-- 
Regards,

Laurent Pinchart

Re: [RFC PATCH 0/4] dt-bindings: Introduce dual-link panels & panel-vendors

[Aradhya Bhatia]

Hi Laurent,

Thank you for taking a look at this!

On 16-Jan-23 15:00, Laurent Pinchart wrote:
> Hi Aradhya,
> 
> On Tue, Jan 03, 2023 at 12:16:11PM +0530, Aradhya Bhatia wrote:
>> Hi all,
>>
>> Microtips Technology Solutions USA, and Lincoln Technology Solutions are
>> 2 display panel vendors, and the first 2 patches add their vendor
>> prefixes.
>>
>> The fourth patch, simply introduces the new compatible for the generic
>> dual-link panels in the panel-lvds driver. This new compatible is based
>> from a new DT binding added in the third patch explained below.
>>
>> The third patch introduces a dt-binding for generic dual-link LVDS
>> panels. These panels do not have any documented constraints, except for
>> their timing characteristics. Further, these panels have 2 pixel-sinks.
>> In a dual-link connection between an LVDS encoder and the panel, one
>> sink accepts the odd set of LVDS pixels and the other, the even set.
>>
>> A lot of this has been based from the Advantech,idk-2121wr dual-link
>> panel[1] and Maxime's patches for generic LVDS panels[2] (which are
>> single-link by default.) and the discussions that happened before they
>> were finally merged.
>>
>> Below are some notes and points that I want to bring forward.
>>
>>    - The advantech,idk-2121wr panel binding uses 2 boolean properties
>>      dual-link-odd/even-pixels, to signify which port sink is being used
>>      for which set of LVDS pixels. I too have added similar support and
>>      introduced constraints around those properties, so as to not break
>>      the ABI... but I believe there is a better way to achieve this.
>>
>>      A "pixel-type" enum property could be introduced in their stead,
>>      which can accept one of the 2 options <dual-lvds-odd-pixels> or
>>      <dual-lvds-even-pixels>.
>>
>>      This method, in my opinion, is more accurate and cleaner to
>>      implement in the bindings as well.
>>
>>      If this does sound a better I can push out a new revision where the
>>      driver supports both these methods (to not break the ABI) and the
>>      advantech,2121wr panel can remain as an exception.
> 
> It's usually best not to change an existing system if there are no good
> reasons, so I'd ask why you think a pixel-type property would be better
> (including when taking into account the fact that we would have to
> maintain the advantech,2121wtr driver separately) if you want to go that
> way. Otherwise, if we were developing this from scratch, I would have no
> real preference.
> 
Such a property would have been a more accurate representation of the
case here, voiding the need of a "oneOf:" clause, and simplifying the
overall binding implementation.

Furthermore, I saw this as a fair opportunity to introduce the new
property because there was only one other dual link panel which used the
original properties.
And, while the code delta shall be same in implementing the pixel-type
property irrespective of the number of existing dual-link panels that
support the original method, I believe with pixel-type, we can set a
fresh precedence for future scenarios (perhaps for "quad-link" LVDS, if
there ever will be one).

Having said that, this was merely a suggestion. If this does not seem to
be a strong enough reason to change the existing system, I can keep
using the original properties (as I have in the patches) and send a v2.

>>    - As an alternative to the previous point, if that method is not
>>      preferred for some reason, the advantech,2121wtr panel binding
>>      could then be merged in the panel-dual-lvds binding as part of
>>      future work.
>>
>>
>>    - Another tweak, I am looking forward to do as part of future work and
>>      would like all your comments is to introduce driver-based
>>      implementation of the panel timing parameters, like it is with
>>      "panel-simple". The driver can then support both the panel-timing
>>      sources (DT node or hard-coded driver structure) and the binding
>>      can remove this from the "required" section.
> 
> There's been a very long discussion in the past (multiple discussions
> actually) regarding whether timings should be set in DT or in drivers.
> There were multiple arguments supporting both sides, without (it seems)
> a clear winner. If you want driver-side timings for dual-link panels,
> I'd like to understand why you think that's better. If the reasons are
> the same as the ones expressed when we discussed simple panels, you
> should also look at whether or not any of the fears expressed on either
> side have materialized.

I went through the discussions that you mentioned above. For now, I will
stick to the status-quo that there is for LVDS panels. =)

> 
>> Thank you!
>>
>> [1]: https://patchwork.freedesktop.org/patch/357122/
>> [2]: https://patchwork.freedesktop.org/patch/471228/
>>
>> Aradhya Bhatia (4):
>>    dt-bindings: vendor-prefixes: Add microtips
>>    dt-bindings: vendor-prefixes: Add lincolntech
>>    dt-bindings: panel: Introduce dual-link LVDS panel
>>    drm: panel-lvds: Introduce dual-link panels
>>
>>   .../display/panel/panel-dual-lvds.yaml        | 157 ++++++++++++++++++
>>   .../devicetree/bindings/vendor-prefixes.yaml  |   4 +
>>   MAINTAINERS                                   |   1 +
>>   drivers/gpu/drm/panel/panel-lvds.c            |   1 +
>>   4 files changed, 163 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dual-lvds.yaml
> 

Regards
Aradhya