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(-)

diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 38fcee91211e..b1cec5383160 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -24,6 +24,19 @@ description: |
   DPI signals are also routed internally to DSI Tx controller present within the
   SoC. Due to clocking limitations only one of the interface i.e. either DSI or
   DPI can be used at once.
+  The AM62P has two instances of TI Keystone Display SubSystem, each with two
+  video ports and two video planes. These instances can support up to 3
+  independent video streams through OLDI, DPI, and DSI interfaces.
+  DSS0 (first instance) supports:
+    - Two OLDI TXes on video port 1, configurable in dual-link or
+      single link clone mode
+    - DPI output on video port 2
+  DSS1 (second instance) supports:
+    - One OLDI TX on video port 1 (single-link mode only)
+    - DSI controller output on video port 2
+  The two OLDI TXes 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 muxed, allowing only one DPI output at a time.
 
 properties:
   compatible:
@@ -31,6 +44,7 @@ properties:
       - ti,am625-dss
       - ti,am62a7-dss
       - ti,am62l-dss
+      - ti,am62p-dss
       - ti,am65x-dss
 
   reg:
@@ -81,8 +95,13 @@ properties:
     maxItems: 1
 
   power-domains:
-    maxItems: 1
-    description: phandle to the associated power domain
+    minItems: 1
+    description:
+      phandle to the associated power domain(s).
+    items:
+      - description: DSS controller power domain
+      - description: OLDI0 power domain
+      - description: OLDI1 power domain
 
   dma-coherent: true
 
@@ -196,6 +215,20 @@ allOf:
               properties:
                 endpoint@1: false
 
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: ti,am62p-dss
+    then:
+      properties:
+        power-domains:
+          maxItems: 3
+    else:
+      properties:
+        power-domains:
+          maxItems: 1
+
 required:
   - compatible
   - reg

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.

 Tomi

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

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:

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
https://ti.com/opensource

On 16/01/2026 10: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(-)
> 
> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> index 38fcee91211e..b1cec5383160 100644
> --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> @@ -24,6 +24,19 @@ description: |
>    DPI signals are also routed internally to DSI Tx controller present within the
>    SoC. Due to clocking limitations only one of the interface i.e. either DSI or
>    DPI can be used at once.
> +  The AM62P has two instances of TI Keystone Display SubSystem, each with two
> +  video ports and two video planes. These instances can support up to 3
> +  independent video streams through OLDI, DPI, and DSI interfaces.
> +  DSS0 (first instance) supports:
> +    - Two OLDI TXes on video port 1, configurable in dual-link or
> +      single link clone mode
> +    - DPI output on video port 2
> +  DSS1 (second instance) supports:
> +    - One OLDI TX on video port 1 (single-link mode only)
> +    - DSI controller output on video port 2
> +  The two OLDI TXes 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 muxed, allowing only one DPI output at a time.
>  
>  properties:
>    compatible:
> @@ -31,6 +44,7 @@ properties:
>        - ti,am625-dss
>        - ti,am62a7-dss
>        - ti,am62l-dss
> +      - ti,am62p-dss
>        - ti,am65x-dss
>  
>    reg:
> @@ -81,8 +95,13 @@ properties:
>      maxItems: 1
>  
>    power-domains:
> -    maxItems: 1
> -    description: phandle to the associated power domain
> +    minItems: 1
> +    description:
> +      phandle to the associated power domain(s).
> +    items:
> +      - description: DSS controller power domain
> +      - description: OLDI0 power domain
> +      - description: OLDI1 power domain

No, I already rejected this.


This is not how review works. Look:

1. You wrote patch on 7th Jan.
2. I replied ONE DAY LATER.
3. You waited one week to give reply.
4. Then two days later you send new version not waiting for my reply.

If you have one week to reply, then so do I.

NAK, go to v3 and implement comments.

>  
>    dma-coherent: true
>  
> @@ -196,6 +215,20 @@ allOf:
>                properties:
>                  endpoint@1: false
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: ti,am62p-dss
> +    then:
> +      properties:
> +        power-domains:
> +          maxItems: 3

That's pointless. It's already 3.

Best regards,
Krzysztof

Hi Krzysztof,

On 1/16/26 15:57, Krzysztof Kozlowski wrote:
> On 16/01/2026 10: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(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
>> index 38fcee91211e..b1cec5383160 100644
>> --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
>> +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
>> @@ -24,6 +24,19 @@ description: |
>>     DPI signals are also routed internally to DSI Tx controller present within the
>>     SoC. Due to clocking limitations only one of the interface i.e. either DSI or
>>     DPI can be used at once.
>> +  The AM62P has two instances of TI Keystone Display SubSystem, each with two
>> +  video ports and two video planes. These instances can support up to 3
>> +  independent video streams through OLDI, DPI, and DSI interfaces.
>> +  DSS0 (first instance) supports:
>> +    - Two OLDI TXes on video port 1, configurable in dual-link or
>> +      single link clone mode
>> +    - DPI output on video port 2
>> +  DSS1 (second instance) supports:
>> +    - One OLDI TX on video port 1 (single-link mode only)
>> +    - DSI controller output on video port 2
>> +  The two OLDI TXes 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 muxed, allowing only one DPI output at a time.
>>   
>>   properties:
>>     compatible:
>> @@ -31,6 +44,7 @@ properties:
>>         - ti,am625-dss
>>         - ti,am62a7-dss
>>         - ti,am62l-dss
>> +      - ti,am62p-dss
>>         - ti,am65x-dss
>>   
>>     reg:
>> @@ -81,8 +95,13 @@ properties:
>>       maxItems: 1
>>   
>>     power-domains:
>> -    maxItems: 1
>> -    description: phandle to the associated power domain
>> +    minItems: 1
>> +    description:
>> +      phandle to the associated power domain(s).
>> +    items:
>> +      - description: DSS controller power domain
>> +      - description: OLDI0 power domain
>> +      - description: OLDI1 power domain
> 
> No, I already rejected this.

Isn't it better to add items to the top level and have a min/max
constraint for different compatibles? For newer compatibles we will
have to again add items description if we go with your approach?

> 
> 
> This is not how review works. Look:
> 
> 1. You wrote patch on 7th Jan.
> 2. I replied ONE DAY LATER.
> 3. You waited one week to give reply.
> 4. Then two days later you send new version not waiting for my reply.
> 
> If you have one week to reply, then so do I.
> 
> NAK, go to v3 and implement comments.

Sorry, we weren't aligned then.

Regards,
Swamil.

> 
>>   
>>     dma-coherent: true
>>   
>> @@ -196,6 +215,20 @@ allOf:
>>                 properties:
>>                   endpoint@1: false
>>   
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            const: ti,am62p-dss
>> +    then:
>> +      properties:
>> +        power-domains:
>> +          maxItems: 3
> 
> That's pointless. It's already 3.
> 
> Best regards,
> Krzysztof

On 16/01/2026 12:09, Swamil Jain wrote:
>>
>>
>> This is not how review works. Look:
>>
>> 1. You wrote patch on 7th Jan.
>> 2. I replied ONE DAY LATER.
>> 3. You waited one week to give reply.
>> 4. Then two days later you send new version not waiting for my reply.
>>
>> If you have one week to reply, then so do I.
>>
>> NAK, go to v3 and implement comments.
> 
> Sorry, we weren't aligned then.

Aligned on what? Did I respond? No. How much time you gave me to respond?

Best regards,
Krzysztof