From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Aradhya Bhatia <a-bhatia1@ti.com>
Cc: Nishanth Menon <nm@ti.com>,
Devicetree List <devicetree@vger.kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Vignesh Raghavendra <vigneshr@ti.com>,
Devarsh Thakkar <devarsht@ti.com>,
David Airlie <airlied@linux.ie>,
Linux Kernel List <linux-kernel@vger.kernel.org>,
DRI Development List <dri-devel@lists.freedesktop.org>,
Darren Etheridge <detheridge@ti.com>,
Rob Herring <robh+dt@kernel.org>, Jyri Sarha <jyri.sarha@iki.fi>,
Rahul T R <r-ravikumar@ti.com>, Krunal Bhargav <k-bhargav@ti.com>
Subject: Re: [PATCH 4/8] drm/tidss: Add support for Dual Link LVDS Bus Format
Date: Tue, 9 Aug 2022 12:51:10 +0300 [thread overview]
Message-ID: <ff7448fd-e50c-1c6d-ad28-ea7e555cdd24@ideasonboard.com> (raw)
In-Reply-To: <09682120-632a-1bfb-c0d7-034f5f076421@ti.com>
On 09/08/2022 12:06, Aradhya Bhatia wrote:
>>> Even in DT, the dss port (for OLDI) connects to the panel port's
>>> endpoint directly. Even in cases of dual link or cloning, it's only a
>>> singular remote-to-endpoint connection between the (OLDI) VP and the
>>> panel port. Hence the requirement of the properties in the earlier
>>> patches of the series.
>>
>> Sorry, I don't follow. If you use cloning, you have two TX outputs,
>> going to two panels, right? So you need two panel DT nodes, and those
>> would connect to two OLDI TX ports in the DSS.
>> > Afaics the existing dual link bridge/panel drivers also use two ports
>> for the connection, so to use the dual link you need two ports in the
>> DSS.
>>
>> I admit I'm not familiar with LVDS dual link, but it's not clear to me
>> how you see the dual OLDI TX being used with other drivers if you have
>> only one port. What kind of setups have you tested?
>>
> In the DTs, the OLDIs are not modeled at all. Since the DSS only has a
> single VP for OLDI, the DT dss port (for OLDI) is connected to a single
> simple-panel node for dual link, bypassing the OLDI TX in DT. I have
> this same OLDI setup and have been testing on this.
A DSS VP is a DSS internal port, whereas a port node in the DT is an
external port. There doesn't have to be a 1:1 match between those.
The port in the DT represents some kind of "connector" to the outside
world, which is usually a collection of pins that provide a video bus.
Here, as far as I can see, the DSS clearly has three external ports, two
OLDI ports and one DPI port.
> I do not have a cloning display setup with me, but I have seen DT DSS
> port connected to one of 2 panel nodes while the other panel (remains as
> a companion panel to the first) without any endpoint connections. Since,
> the OLDI TXes (0 and 1), receive the same clocks and inputs from DSS
> OLDI VP, this 'method' has worked too.
This, and using simple-panel for dual link with single port connection,
sounds like a hack.
A practical example: TI's customer wants to use AM625 and THC63LVD1024
bridge. How does it work? THC63LVD1024 driver uses two LVDS ports for
input, both of which are used in dual-link mode.
>>> The use of lvds helper functions does not seem feasible in this case,
>>> because even they read DT properties to determine the dual link
>>> connection and those properties need to be a part of a lvds bridge
>>> device.
>>
>> Can you elaborate a bit more why the DRM helpers couldn't be used here?
>>
> The drm_of.c helpers use DT properties to ascertain the presence of a
> dual-link connection. While there wasn't a specific helper to determine
> dual-link or not, the drivers use the odd/even pixel order helper which
> is based on the properties "dual-lvds-odd-pixels" and "dual-lvds-odd-
> pixels". If either of the properties are absent, the helper returns an
> error making the driver to use single link.
>
> These properties are LVDS specific, but they could not be added in the
> DT because there is no OLDI TX DT node for our case.
If I'm not mistaken, those properties are in the port node, not the
device node, and also, I believe those properties are on the sink side,
so they wouldn't even be in the AM625 data. See, for example:
arch/arm64/boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts
>>> I have also been considering the idea of implementing a new device
>>> driver for the OLDI TXes, not unlike the renesas' one. That way the
>>> driver could have the properties and the lvds helper functions at their
>>> disposal. I am just slightly unsure if that would allow space for any
>>> conflicts because of the shared register space.
>>
>> No, I don't think new devices are needed here.
> Okay...
>
> I am not quite sure I understand completely what you are recommending
> the OLDI to be. It seems to me that you want the OLDI TXes to be modeled
> as nodes, right? Wouldn't that automatically require some sort of
> standalone driver arrangement for them? Or am I missing something
> important here?
No, I'm only talking about the DT port nodes. At the moment the AM65x DT
bindings doc says that there are two ports, port@0 for OLDI and port@1
for DPI. I'm saying AM625 needs three ports.
Tomi
next prev parent reply other threads:[~2022-08-09 9:51 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
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 [this message]
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=ff7448fd-e50c-1c6d-ad28-ea7e555cdd24@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+dt@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).