Message-ID: <462b3b7a-c228-456a-84bf-0e6103be61b7@ideasonboard.com>
Date: Mon, 19 Jan 2026 12:10:17 +0200
From: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>
To: Swamil Jain <s-jain1@...com>, jyri.sarha@....fi, airlied@...il.com,
 simona@...ll.ch, maarten.lankhorst@...ux.intel.com, mripard@...nel.org,
 tzimmermann@...e.de, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, aradhya.bhatia@...ux.dev, mwalle@...nel.org
Cc: dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, devarsht@...com, praneeth@...com,
 u-kumar1@...com, Nishanth Menon <nm@...com>
Subject: Re: [PATCH v4 1/3] dt-bindings: display: ti,am65x-dss: Add am62p dss
 compatible

Hi,

On 16/01/2026 11:54, Swamil Jain wrote:
> TI's AM62P SoC contains two instances of the TI Keystone Display
> SubSystem (DSS), each with two video ports and two video planes. These
> instances support up to three independent video streams through OLDI,
> DPI, and DSI interfaces. The OLDI interfaces utilizes two OLDI
> transmitters OLDI0 and OLDI1.
> 
> DSS0 (first instance) supports:
>  - With respect to OLDI Tx interfaces, DSS0 instance can either drive
>    both OLDI0 Tx and OLDI1 Tx together (e.g. dual link mode or clone
>    mode) or can only drive OLDI0 Tx in single link mode with OLDI1 being
>    utilized by DSS1 or left unused.
>  - DPI output from video port 2.
> 
> DSS1 (second instance) supports:
>  - With respect to OLDI Tx interfaces, DSS1 instance can only drive
>    OLDI1 Tx given DSS0 is not utilizing that as described above.
>  - DSI controller output from video port 2.
> 
> The two OLDI transmitters can be configured in clone mode to drive a
> pair of identical OLDI single-link displays. DPI outputs from
> DSS0 VP2, DSS1 VP1, and DSS1 VP2 are multiplexed, allowing only one
> DPI output at a time.
> 
> Add the compatible string "ti,am62p-dss" and update related
> description accordingly.
> 
> AM62P has different power domains for DSS and OLDI compared to other
> Keystone SoCs. DSS0 can have up to 3 power-domains for DSS0, OLDI0 and
> OLDI1, and DSS1 can have up to 2 power-domains for DSS1 and OLDI1.
> 
> Signed-off-by: Swamil Jain <s-jain1@...com>
> ---
>  .../bindings/display/ti/ti,am65x-dss.yaml     | 37 ++++++++++++++++++-
>  1 file changed, 35 insertions(+), 2 deletions(-)
I think we have a bad design issue here, and I don't know how to fix it.

The OLDIs have been a bit difficult to model, as they are not full
devices: they are not on a control bus, and don't have registers, yet
they need configuration. Part of the config is done via separate IO
controls with syscon, part of the config is done via DSS's registers.
It's not documented, but I assume the OLDI registers in the DSS IP are
wired somewhat directly to the OLDI IP.

So currently we just consider OLDIs to be part of the DSS. We do model
them as separate custom DSS child nodes in the DT, so that we can model
the pipelines correctly. For example, to support dual-link OLDI, we have
two OLDI TX nodes, which get their pixel stream from a single DSS port.
The power-domains for the OLDIs were just set as DSS power-domains, as
OLDIs were part of DSS in this design.

This felt perhaps slightly hacky, but it also made sense and allowed us
to model the HW.

Now, with AM62P, it gets a bit interesting. We have two independent DSS
IPs, each of which have two output ports, and we have two OLDI TX
instances. The OLDI TX instances are shared between the DSS instances,
and the first output port on both DSS can be muxed to an OLDI. The first
DSS can be connected to both OLDI TXes, the second DSS can be connected
only to the second OLDI.

This DSS application note has a bit more info and some pics:
https://www.ti.com/lit/pdf/sprads3

Now, both DSS instances have identical registers for configuring both
OLDI instances. This is not documented, but I'm guessing that when
configuring the clock muxes (the clock tree is also "interesting"), it
will also mux the configuration wires coming from the DSS instances. So
when you change the parent clocks for DSS & OLDI to be the right ones to
use, say, OLDI TX1 on DSS1, you also change where the OLDI configuration
is coming from.

So the OLDIs are now shared, and the configuration registers are
duplicated and routed based on clock setup (afaiu). Clearly the OLDIs
can not be considered being part of DSS0 or DSS1 anymore, nor can we set
the OLDI power-domains in the DSS node.

What this series does is that it adds three OLDI nodes, two for DSS0 (as
DSS0 can use either one or two OLDIs) and one for DSS1. And then,
depending on which OLDIs you happen to use, you're supposed to set the
DSS power-domains accordingly, so that the DSS being used for OLDI has
the necessary OLDI power-domains. And connect the media graph so that if
your panel uses OLDI TX1 with the DSS0, you connect to that OLDI DT
node, but if you use the same OLDI TX1 with the DSS1, you connect to
another OLDI DT node. I don't think that's right at all...

I don't right away have a good idea (well, not even a bad idea) how this
should be designed.

 Tomi

Powered by blists - more mailing lists