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

[Aradhya Bhatia <a-bhatia1@ti.com>]

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