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

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

On 1/30/26 17:57, Nishanth Menon wrote:
> On 14:00-20260130, 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
>>        }
>>      };
>> };
> 
> I was discussing something similar on #devicetree yesterday:
> 
> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> index 8203ec5e5bb3..7902637587b4 100644
> --- a/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> +++ b/Documentation/devicetree/bindings/display/ti/ti,am625-oldi.yaml
> @@ -29,6 +29,11 @@ properties:
>     clock-names:
>       const: serial
>   
> +  power-domains:
> +    description: phandle to the associated OLDI power domain
> +    items:
> +      - description: OLDI power domain
> +
>     ti,companion-oldi:
>       $ref: /schemas/types.yaml#/definitions/phandle
>       description:
> 

Thanks Nishanth, will re-spin the series using the approach suggested by 
you and Tomi.

Regards,
Swamil.