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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <36fe032b-a00c-dad1-a3db-bea1f15726c0@ti.com>
Date:   Fri, 20 Jan 2023 10:28:48 +0530
From:   Aradhya Bhatia <a-bhatia1@...com>
To:     Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jyri Sarha <jyri.sarha@....fi>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Sam Ravnborg <sam@...nborg.org>,
        Maxime Ripard <maxime@...no.tech>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Guo Ren <guoren@...nel.org>
CC:     DRI Development List <dri-devel@...ts.freedesktop.org>,
        Devicetree List <devicetree@...r.kernel.org>,
        Linux Kernel List <linux-kernel@...r.kernel.org>,
        Linux RISC-V List <linux-riscv@...ts.infradead.org>,
        Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>,
        Linux Mediatek List <linux-mediatek@...ts.infradead.org>,
        Linux C-SKY Arch List <linux-csky@...r.kernel.org>,
        Nishanth Menon <nm@...com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Rahul T R <r-ravikumar@...com>,
        Devarsh Thakkar <devarsht@...com>,
        Jai Luthra <j-luthra@...com>,
        Jayesh Choudhary <j-choudhary@...com>
Subject: Re: [RFC PATCH 3/4] dt-bindings: panel: Introduce dual-link LVDS
 panel

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@...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@...com>
>>>> +  - Thierry Reding <thierry.reding@...il.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