From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Nishanth Menon <nm@ti.com>, Rob Herring <robh@kernel.org>
Cc: Devicetree List <devicetree@vger.kernel.org>,
Aradhya Bhatia <a-bhatia1@ti.com>,
David Airlie <airlied@linux.ie>,
Linux Kernel List <linux-kernel@vger.kernel.org>,
DRI Development List <dri-devel@lists.freedesktop.org>,
Krunal Bhargav <k-bhargav@ti.com>,
Darren Etheridge <detheridge@ti.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Devarsh Thakkar <devarsht@ti.com>, Jyri Sarha <jyri.sarha@iki.fi>,
Rahul T R <r-ravikumar@ti.com>,
Vignesh Raghavendra <vigneshr@ti.com>
Subject: Re: [PATCH 1/8] dt-bindings: display: ti,am65x-dss: Add port properties for DSS
Date: Thu, 28 Jul 2022 09:28:12 +0300 [thread overview]
Message-ID: <d10cd3c6-ff3c-ee0e-9363-f0b71fe7e2c2@ideasonboard.com> (raw)
In-Reply-To: <20220722161621.p35apy5mstpgqhef@reverence>
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
next prev parent reply other threads:[~2022-07-28 6:28 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-19 8:08 sFrom b69208b75f7ae8e223c81783afb04fecd2f5faf8 Mon Sep 17 00:00:00 2001 Aradhya Bhatia
2022-07-19 8:08 ` [PATCH 1/8] dt-bindings: display: ti, am65x-dss: Add port properties for DSS Aradhya Bhatia
2022-07-20 23:28 ` [PATCH 1/8] dt-bindings: display: ti,am65x-dss: " Rob Herring
2022-07-22 16:16 ` Nishanth Menon
2022-07-28 6:28 ` Tomi Valkeinen [this message]
2022-07-25 11:26 ` Aradhya Bhatia
2022-07-25 22:14 ` Francesco Dolcini
2022-08-10 17:48 ` Rob Herring
2022-07-28 11:16 ` Tomi Valkeinen
2022-07-19 8:08 ` [PATCH 2/8] dt-bindings: display: ti, am65x-dss: Add IO CTRL property for AM625 OLDI Aradhya Bhatia
2022-07-20 23:32 ` [PATCH 2/8] dt-bindings: display: ti,am65x-dss: " Rob Herring
2022-07-25 11:34 ` Aradhya Bhatia
2022-07-19 8:08 ` [PATCH 3/8] drm/tidss: Add support for DSS port properties Aradhya Bhatia
2022-07-28 12:07 ` Tomi Valkeinen
2022-07-19 8:08 ` [PATCH 4/8] drm/tidss: Add support for Dual Link LVDS Bus Format Aradhya Bhatia
2022-07-28 11:03 ` Tomi Valkeinen
2022-07-28 11:45 ` Tomi Valkeinen
2022-08-09 5:58 ` Aradhya Bhatia
2022-08-09 6:28 ` Tomi Valkeinen
2022-08-09 9:06 ` Aradhya Bhatia
2022-08-09 9:51 ` Tomi Valkeinen
2022-08-09 13:34 ` Aradhya Bhatia
2022-07-19 8:08 ` [PATCH 5/8] drm/tidss: dt property to force 16bit VP output to a 24bit bridge Aradhya Bhatia
2022-07-19 8:08 ` [PATCH 6/8] drm/tidss: Add IO CTRL and Power support for OLDI TX in AM625 Aradhya Bhatia
2022-07-19 8:08 ` [PATCH 7/8] drm/tidss: Fix clock request value for OLDI videoports Aradhya Bhatia
2022-07-28 10:05 ` Tomi Valkeinen
2022-07-29 3:56 ` Aradhya Bhatia
2022-07-29 8:13 ` Tomi Valkeinen
2022-07-19 8:08 ` [PATCH 8/8] drm/tidss: Enable Dual and Duplicate Modes for OLDI Aradhya Bhatia
2022-07-27 13:22 ` Tomi Valkeinen
2022-07-28 6:46 ` Tomi Valkeinen
2022-07-28 8:49 ` Aradhya Bhatia
2022-07-28 11:29 ` Tomi Valkeinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d10cd3c6-ff3c-ee0e-9363-f0b71fe7e2c2@ideasonboard.com \
--to=tomi.valkeinen@ideasonboard.com \
--cc=a-bhatia1@ti.com \
--cc=airlied@linux.ie \
--cc=detheridge@ti.com \
--cc=devarsht@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jyri.sarha@iki.fi \
--cc=k-bhargav@ti.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=r-ravikumar@ti.com \
--cc=robh@kernel.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).