linux-kernel - RE: [PATCH/RFC 02/12] dt-bindings: display: renesas: lvds: Document renesas,swap-data

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <TY1PR01MB17706A4FF4C26CD4BDA1A5DAC0DA0@TY1PR01MB1770.jpnprd01.prod.outlook.com>
Date:   Mon, 5 Aug 2019 08:59:51 +0000
From:   Fabrizio Castro <fabrizio.castro@...renesas.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>
CC:     Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Simon Horman <horms@...ge.net.au>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Chris Paterson <Chris.Paterson2@...esas.com>,
        Biju Das <biju.das@...renesas.com>
Subject: RE: [PATCH/RFC 02/12] dt-bindings: display: renesas: lvds: Document
 renesas,swap-data

Hi Laurent,

Thank you for your feedback!

> From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> Sent: 02 August 2019 08:44
> Subject: Re: [PATCH/RFC 02/12] dt-bindings: display: renesas: lvds: Document renesas,swap-data
> 
> Hi Fabrizio,
> 
> Thank you for the patch.
> 
> On Fri, Aug 02, 2019 at 08:33:59AM +0100, Fabrizio Castro wrote:
> > R-Car D3, R-Car E3, and RZ/G2E support dual-link mode.
> > In such a mode, the first LVDS encoder emits even data, and the
> > second LVDS encoder emits odd data. This patch documents property
> > renesas,swap-data, used to swap even and odd data around.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@...renesas.com>
> > ---
> >  Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > index dece79e..8980179 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> > @@ -52,6 +52,11 @@ Optional properties:
> >    mandatory for the first LVDS encoder on R-Car D3, R-Car E3, and RZ/G2E SoCs,
> >    and shall point to the second encoder to be used as a companion in dual-link
> >    mode. It shall not be set for any other LVDS encoder.
> > +- renesas,swap-data : when in dual-link mode, the first LVDS encoder normally
> > +  emits even data, and the second LVDS encoder emits odd data. When property
> > +  renesas,swap-data is specified, the data emitted by the two encoders will be
> > +  swapped around. This property can only be used in conjunction with property
> > +  renesas,companion.
> 
> From an LVDS encoder point of view this is more a configuration option
> than a description of the hardware. Wouldn't it be better for the LVDS
> sink to report which of the odd or even pixels it expects on each of its
> endpoints ?

Yes, that would be my preference too, and it would be better, I am just not entirely
what's the best place for this information though

> The LVDS encoder driver could then query that at runtime and
> configure itself accordingly. Ideally this should be queried through the
> drm_bridge_timings structure (or through a similar mean), not through
> DT. An LVDS sink that has a fixed mapping of odd/even pixels to
> endpoints wouldn't need the information to be specified in DT at all.

Isn't drm_bridge_timings specific for bridges?

Thanks!
Fab

> 
> >
> >
> >  Example:
> 
> --
> Regards,
> 
> Laurent Pinchart