Re: [PATCH v4 1/3] dt-bindings: display: ti,am65x-dss: Add am62p dss compatible

[Swamil Jain <s-jain1@ti.com>]

Hi Tomi,

On 1/30/26 17:30, Tomi Valkeinen wrote:
> 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@ti.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
> 

Thanks for the suggestions, Tomi. With this approach we don't have to 
make #power-domains flexible. Will respin the series with the required 
changes.

Regards,
Swamil.