Message-ID: <5f0d509b-f1e4-44c8-80f4-74c3f4b61b28@ideasonboard.com>
Date: Fri, 30 Jan 2026 14:00:16 +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 19/01/2026 12:10, Tomi Valkeinen wrote:
> 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.
I still don't have a binding-idea that I would be satisfied with, but I
guess there's just no sensible way to represent this hardware. How to
model an IP that has its control bus changing based on a clock mux...

I think one thing we can do is move the OLDI power-domains into the OLDI
nodes. That feels like a more correct place for them. Earlier the OLDI
PDs were in the DSS node, as the OLDI was considered an internal part of
the DSS. But now that the OLDIs can move from one DSS to another, this
"OLDI is part of a DSS" model doesn't work.

However, even if it looks fine on DT side, I wonder if this will cause
problems on the Linux side: OLDI is not a device, so I guess we still
need to associate those PDs somehow with the DSS device.

For the issue with the control bus, I don't see a solution, so I propose
doing what the patch here does: The two OLDIs are represented by three
OLDI nodes in the DT: OLDI TX0 and TX1 under DSS0, OLDI TX1 under DSS1.
Only one of the TX1s should be enabled at a time, of course.

So the DT structure would be something like this:

dss0 {
  power-domains = <dss0 pd>;

  ports {
    ports for DSS videoports
  };

  oldi-transmitters {
    oldi0: oldi@0 {
      power-domains = <oldi0 pd>;
        ports {
          ports for OLDI TX0
        }
    };
    oldi1: oldi@1 {
      power-domains = <oldi1 pd>;
        ports {
          ports for OLDI TX1
        }
    };
};

dss1 {
  power-domains = <dss1 pd>;

  ports {
    ports for DSS videoports
  };

  oldi-transmitters {
    oldi1: oldi@1 {
      power-domains = <oldi1 pd>;
      ports {
        ports for OLDI TX1
      }
    };
};

 Tomi

Powered by blists - more mailing lists