Hi Tomi,
On 09-Aug-22 15:21, Tomi Valkeinen wrote:
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.
Okay, I now understand what you are saying. Indeed, I was mapping the
DSS VP and DT DSS port as 1:1 in my mind, which should not be the case.
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.
Right. There has to be 2 ports for OLDI in DSS, to be connected to 2
ports of a single panel (dual link) or 2 ports of 2 panels (cloning).
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
Yeah, they are indeed on the sink side. I was misunderstood about this.
And the onus for properties is not on DSS nodes anymore.
This probably is a different discussion, but since the sink is now
responsible for those properties, these should get introduced in the
panel-common bindings, right?
The above example has a separate binding, but many dumb dual-link panels
will require those properties in panel-common.
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.
Agreed.
Moreover, I will update the binding to reflect 3 ports for am625-dss.
Regards
Aradhya
