[PATCH v4 0/3] Add Display support for AM62P SoC

[PATCH v4 0/3] Add Display support for AM62P SoC

[Swamil Jain]

Display Controller Overview:
TI's AM62P[1] SoC has two instances of TI's Display Subsystem (DSS).
Each instance contains two video ports. Combined, both instances support
up to three independent video streams: OLDI, DPI, and DSI.

This series:
  1. Updates bindings (PATCH 1/3)
    - Adds "ti,am62p-dss" compatible string
    - Modifies power-domain requirements
  2. Updates driver (PATCH 2/3 and 3/3)
    - Adds power management for attached PM domains
    - Enables AM62P DSS support by adding compatible to the driver

Note:
  - Device-tree changes will be submitted after this series is merged.  
  - The device-tree patches are available here[2]

[1]: https://www.ti.com/product/AM62P
[2]: https://github.com/swamiljain/linux-next/tree/AM62P_J722S_DSS_v1
---
Changelog:
v3->v4:
  - PATCH 1/3 - Cosmetic changes in commit message
              - Explain why 2 power-domains can be used in am62p-dss
              - Remove redundant explanation
              - Add item description for power-domains property
              - Define constraints properly by removing min/maxItems
  - PATCH 2/3 - Remove err_oldi_deinit if tidss_oldi_init() fails
              - Pick up T-By tag
  - PATCH 3/3 - No change

Link to v3: 
https://lore.kernel.org/all/20260107174525.1702585-1-s-jain1@ti.com/

v2->v3:
  - PATCH 1/3 - Add a broader range for top-level constraints in the 
                bindings to resolve dt_biniding_check conflicts
  - PATCH 2/3 - Remove and modify some comments
              - Use IS_ERR_OR_NULL() instead od checking for both NULL
                and IS_ERR()
              - Changes in error handling paths
  - PATCH 3/3 - Pick R-by tag

Link to v2:
https://lore.kernel.org/all/20251125165942.2586341-1-s-jain1@ti.com/

v1->v2:
  - PATCH 1/3: - Remove unnecessary example
               - Use "am62p-dss" compatible check for multiple
                 power-domains
  - PATCH 2/3:   Add Signed-off-by tag

Link to v1:
https://lore.kernel.org/all/20251114064336.3683731-1-s-jain1@ti.com/
---

Devarsh Thakkar (1):
  drm/tidss: Power up attached PM domains on probe

Swamil Jain (2):
  dt-bindings: display: ti,am65x-dss: Add am62p dss compatible
  drm: tidss: tidss_drv: Add support for AM62P display subsystem

 .../bindings/display/ti/ti,am65x-dss.yaml     | 37 ++++++++-
 drivers/gpu/drm/tidss/tidss_drv.c             | 83 ++++++++++++++++++-
 drivers/gpu/drm/tidss/tidss_drv.h             |  4 +
 3 files changed, 118 insertions(+), 6 deletions(-)

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

[Swamil Jain]

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

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

[Krzysztof Kozlowski]

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

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

[Swamil Jain]

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

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

[Krzysztof Kozlowski]

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

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

[Swamil Jain]

Hi Krzysztof,

On 1/16/26 16:54, Krzysztof Kozlowski wrote:
> 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?
>

Sorry, I should have waited for your reply.
As per Tomi's suggestion, we should move the OLDI power-domins to 
respective OLDI-TX nodes, then DSS will have a single power-domain.
This doesn't require dt-bindings change for power-domains property.
I will re-spin the series with required changes.

Regards,
Swamil.


> Best regards,
> Krzysztof

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

[Tomi Valkeinen]

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

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

[Tomi Valkeinen]

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

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

[Nishanth Menon]

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

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

[Swamil Jain]

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.

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

[Swamil Jain]

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.

[PATCH v4 2/3] drm/tidss: Power up attached PM domains on probe

[Swamil Jain]

From: Devarsh Thakkar <devarsht@ti.com>

Some SoC's such as AM62P have dedicated power domains
for OLDI which need to be powered on separately along
with display controller.

So during driver probe, power up all attached PM domains
enumerated in devicetree node for DSS.

This also prepares base to add display support for AM62P.

Tested-by: Michael Walle <mwalle@kernel.org>
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
[j-choudhary@ti.com: fix PM call sequence causing kernel crash in OLDI]
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Swamil Jain <s-jain1@ti.com>
---
 drivers/gpu/drm/tidss/tidss_drv.c | 82 +++++++++++++++++++++++++++++--
 drivers/gpu/drm/tidss/tidss_drv.h |  4 ++
 2 files changed, 82 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
index 1c8cc18bc53c..93e0c34c73aa 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -8,6 +8,7 @@
 #include <linux/of.h>
 #include <linux/module.h>
 #include <linux/pm_runtime.h>
+#include <linux/pm_domain.h>
 #include <linux/aperture.h>
 
 #include <drm/clients/drm_client_setup.h>
@@ -107,6 +108,68 @@ static const struct drm_driver tidss_driver = {
 	.minor			= 0,
 };
 
+static void tidss_detach_pm_domains(struct tidss_device *tidss)
+{
+	int i;
+
+	if (tidss->num_domains <= 1)
+		return;
+
+	for (i = 0; i < tidss->num_domains; i++) {
+		if (!IS_ERR_OR_NULL(tidss->pd_link[i]))
+			device_link_del(tidss->pd_link[i]);
+		if (!IS_ERR_OR_NULL(tidss->pd_dev[i]))
+			dev_pm_domain_detach(tidss->pd_dev[i], true);
+		tidss->pd_dev[i] = NULL;
+		tidss->pd_link[i] = NULL;
+	}
+}
+
+static int tidss_attach_pm_domains(struct tidss_device *tidss)
+{
+	struct device *dev = tidss->dev;
+	int i;
+	int ret;
+	struct platform_device *pdev = to_platform_device(dev);
+	struct device_node *np = pdev->dev.of_node;
+
+	tidss->num_domains = of_count_phandle_with_args(np, "power-domains",
+							"#power-domain-cells");
+	if (tidss->num_domains <= 1)
+		return 0;
+
+	tidss->pd_dev = devm_kmalloc_array(dev, tidss->num_domains,
+					   sizeof(*tidss->pd_dev), GFP_KERNEL);
+	if (!tidss->pd_dev)
+		return -ENOMEM;
+
+	tidss->pd_link = devm_kmalloc_array(dev, tidss->num_domains,
+					    sizeof(*tidss->pd_link), GFP_KERNEL);
+	if (!tidss->pd_link)
+		return -ENOMEM;
+
+	for (i = 0; i < tidss->num_domains; i++) {
+		tidss->pd_dev[i] = dev_pm_domain_attach_by_id(dev, i);
+		if (IS_ERR(tidss->pd_dev[i])) {
+			ret = PTR_ERR(tidss->pd_dev[i]);
+			goto fail;
+		}
+
+		tidss->pd_link[i] = device_link_add(dev, tidss->pd_dev[i],
+						    DL_FLAG_STATELESS |
+						    DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE);
+		if (!tidss->pd_link[i]) {
+			ret = -EINVAL;
+			goto fail;
+		}
+	}
+
+	return 0;
+fail:
+	tidss_detach_pm_domains(tidss);
+	return ret;
+}
+
 static int tidss_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -129,15 +192,21 @@ static int tidss_probe(struct platform_device *pdev)
 
 	spin_lock_init(&tidss->irq_lock);
 
+	ret = tidss_attach_pm_domains(tidss);
+	if (ret < 0)
+		return dev_err_probe(dev, ret, "failed to attach power domains\n");
+
 	ret = dispc_init(tidss);
 	if (ret) {
-		dev_err(dev, "failed to initialize dispc: %d\n", ret);
-		return ret;
+		dev_err_probe(dev, ret, "failed to initialize dispc\n");
+		goto err_detach_pm_domains;
 	}
 
 	ret = tidss_oldi_init(tidss);
-	if (ret)
-		return dev_err_probe(dev, ret, "failed to init OLDI\n");
+	if (ret) {
+		dev_err_probe(dev, ret, "failed to init OLDI\n");
+		goto err_detach_pm_domains;
+	}
 
 	pm_runtime_enable(dev);
 
@@ -205,6 +274,9 @@ static int tidss_probe(struct platform_device *pdev)
 
 	tidss_oldi_deinit(tidss);
 
+err_detach_pm_domains:
+	tidss_detach_pm_domains(tidss);
+
 	return ret;
 }
 
@@ -232,6 +304,8 @@ static void tidss_remove(struct platform_device *pdev)
 	/* devm allocated dispc goes away with the dev so mark it NULL */
 	dispc_remove(tidss);
 
+	tidss_detach_pm_domains(tidss);
+
 	dev_dbg(dev, "%s done\n", __func__);
 }
 
diff --git a/drivers/gpu/drm/tidss/tidss_drv.h b/drivers/gpu/drm/tidss/tidss_drv.h
index e1c1f41d8b4b..6625b989b815 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.h
+++ b/drivers/gpu/drm/tidss/tidss_drv.h
@@ -41,6 +41,10 @@ struct tidss_device {
 	/* protects the irq masks field and irqenable/irqstatus registers */
 	spinlock_t irq_lock;
 	dispc_irq_t irq_mask;	/* enabled irqs */
+
+	int num_domains; /* Count of PM domains to be handled */
+	struct device **pd_dev;
+	struct device_link **pd_link;
 };
 
 #define to_tidss(__dev) container_of(__dev, struct tidss_device, ddev)

Re: [PATCH v4 2/3] drm/tidss: Power up attached PM domains on probe

[Tomi Valkeinen]

Hi,

On 16/01/2026 11:54, Swamil Jain wrote:
> From: Devarsh Thakkar <devarsht@ti.com>
> 
> Some SoC's such as AM62P have dedicated power domains
> for OLDI which need to be powered on separately along
> with display controller.
> 
> So during driver probe, power up all attached PM domains
> enumerated in devicetree node for DSS.
> 
> This also prepares base to add display support for AM62P.
> 
> Tested-by: Michael Walle <mwalle@kernel.org>
> Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
> [j-choudhary@ti.com: fix PM call sequence causing kernel crash in OLDI]
> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
> Signed-off-by: Swamil Jain <s-jain1@ti.com>
> ---
>  drivers/gpu/drm/tidss/tidss_drv.c | 82 +++++++++++++++++++++++++++++--
>  drivers/gpu/drm/tidss/tidss_drv.h |  4 ++
>  2 files changed, 82 insertions(+), 4 deletions(-)
> 

Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

 Tomi

[PATCH v4 3/3] drm: tidss: tidss_drv: Add support for AM62P display subsystem

[Swamil Jain]

The DSS controller on TI's AM62P SoC features two instances of the TI
DSS. Each DSS instance supports two video ports, similar to the DSS
controller found on the TI AM62X SoC. This allows three independent
video streams to be supported: OLDI, DPI, and DSI.

Since the DSS instances on AM62P are architecturally similar to those
on the AM62X DSS controller, the existing dispc_am625_feats
configuration can be reused for the AM62P DSS support.

This patch adds the necessary device tree compatibility entry for
"ti,am62p-dss" in the tidss driver, pointing to dispc_am625_feats,
thereby enabling DSS support on AM62P devices.

Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Swamil Jain <s-jain1@ti.com>
---
 drivers/gpu/drm/tidss/tidss_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
index 93e0c34c73aa..ff6d0adf89e8 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -319,6 +319,7 @@ static const struct of_device_id tidss_of_table[] = {
 	{ .compatible = "ti,am625-dss", .data = &dispc_am625_feats, },
 	{ .compatible = "ti,am62a7-dss", .data = &dispc_am62a7_feats, },
 	{ .compatible = "ti,am62l-dss", .data = &dispc_am62l_feats, },
+	{ .compatible = "ti,am62p-dss", .data = &dispc_am625_feats, },
 	{ .compatible = "ti,am65x-dss", .data = &dispc_am65x_feats, },
 	{ .compatible = "ti,j721e-dss", .data = &dispc_j721e_feats, },
 	{ }