Message-ID: <Y8UZQHvVT2VQcQ33@pendragon.ideasonboard.com>
Date:   Mon, 16 Jan 2023 11:30:40 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Aradhya Bhatia <a-bhatia1@...com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Tomi Valkeinen <tomba@...nel.org>,
        Jyri Sarha <jyri.sarha@....fi>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        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>, Nishanth Menon <nm@...com>,
        Devicetree List <devicetree@...r.kernel.org>,
        Jayesh Choudhary <j-choudhary@...com>,
        Jai Luthra <j-luthra@...com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Devarsh Thakkar <devarsht@...com>,
        Linux Kernel List <linux-kernel@...r.kernel.org>,
        DRI Development List <dri-devel@...ts.freedesktop.org>,
        Linux Mediatek List <linux-mediatek@...ts.infradead.org>,
        Linux C-SKY Arch List <linux-csky@...r.kernel.org>,
        Linux RISC-V List <linux-riscv@...ts.infradead.org>,
        Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>,
        Rahul T R <r-ravikumar@...com>
Subject: Re: [RFC PATCH 0/4] dt-bindings: Introduce dual-link panels &
 panel-vendors

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

Powered by blists - more mailing lists