linux-kernel - Re: [PATCH 1/8] dt-bindings: display: ti,am65x-dss: Add port properties for DSS

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: <d10cd3c6-ff3c-ee0e-9363-f0b71fe7e2c2@ideasonboard.com>
Date:   Thu, 28 Jul 2022 09:28:12 +0300
From:   Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To:     Nishanth Menon <nm@...com>, Rob Herring <robh@...nel.org>
Cc:     Aradhya Bhatia <a-bhatia1@...com>, Jyri Sarha <jyri.sarha@....fi>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Darren Etheridge <detheridge@...com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Rahul T R <r-ravikumar@...com>,
        Krunal Bhargav <k-bhargav@...com>,
        Devarsh Thakkar <devarsht@...com>,
        DRI Development List <dri-devel@...ts.freedesktop.org>,
        Devicetree List <devicetree@...r.kernel.org>,
        Linux Kernel List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/8] dt-bindings: display: ti,am65x-dss: Add port
 properties for DSS

On 22/07/2022 19:16, Nishanth Menon wrote:
> On 17:28-20220720, Rob Herring wrote:
>>> On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground.
>>> The bridge sees 24bits of data,  but the lsb's are always zero.
>>
>> Unless the bridge ignores the LSBs, that's not the right way to do 16 to
>> 24 bit. The LSBs should be connected to the MSB of the color component
>> to get full color range.
> 
> I unfortunately cannot point specifics without violating NDAs, so
> will just give a broad perspective.
> 
> Correct, this is not ideal, but in certain scenarios with limited
> pins (due to iovoltage groups), we are indeed starting to see this
> kind of usage model starting to pop up. Tradeoff is in a limit on
> image quality, but that tends to be acceptable in certain lower cost
> solutions.

It doesn't require more pins. If the lowest bits are tied to ground the 
image is always a bit darker than it should, and you do not get the full 
brightness. But if you wire e.g. the red component:

SoC : Bridge
R2 ->   R0
R3 ->   R1
R4 ->   R2
R0 ->   R3
R1 ->   R4
R2 ->   R5
R3 ->   R6
R4 ->   R7

or

R4 ->   R0
R4 ->   R1
R4 ->   R2
R0 ->   R3
R1 ->   R4
R2 ->   R5
R3 ->   R6
R4 ->   R7

You'll get the full range.

  Tomi