Message-ID: <d895d42a-f027-4afd-bf62-2dde984e7f73@kernel.org>
Date: Fri, 16 Jan 2026 11:25:26 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Swamil Jain <s-jain1@...com>
Cc: jyri.sarha@....fi, tomi.valkeinen@...asonboard.com, airlied@...il.com,
 simona@...ll.ch, maarten.lankhorst@...ux.intel.com, mripard@...nel.org,
 tzimmermann@...e.de, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, aradhya.bhatia@...ux.dev,
 dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, devarsht@...com, praneeth@...com,
 h-shenoy@...com, u-kumar1@...com
Subject: Re: [PATCH v3 1/3] dt-bindings: display: ti,am65x-dss: Add am62p dss
 compatible

On 15/01/2026 17:54, Swamil Jain wrote:
> Hi Krzysztof,
> 
> On 1/8/26 14:21, Krzysztof Kozlowski wrote:
>> On Wed, Jan 07, 2026 at 11:15:23PM +0530, 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.
>>>
>>> DSS0 (first instance) supports:
>>>   - Two OLDI transmitters on video port 1, configurable in dual-link or
>>>     single-link mode.
>>>   - DPI output on video port 2.
>>>
>>> DSS1 (second instance) supports:
>>>   - One OLDI transmitter on video port 1 (single-link mode only).
>>>   - DSI controller output on 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. Therefore, add 'minItems' and set to 1 and 'maxItems'
>>> field in the power-domains property to 3 for the "ti,am62p-dss"
>>> compatible entry to reflect this hardware difference.
>>
>> Last sentence is redundant. You are again explain repeating the diff
>> which is pointless, but did not explain WHY you think 2 power domains is
>> correct.
>>
> 
> Will explain properly in the commit message why 2 power domains are 
> correct in v4.
> 
>>>
>>> Signed-off-by: Swamil Jain <s-jain1@...com>
>>> ---
>>>   .../bindings/display/ti/ti,am65x-dss.yaml     | 33 ++++++++++++++++++-
>>>   1 file changed, 32 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
>>> index 38fcee91211e..e74e710934fc 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,7 +95,8 @@ properties:
>>>       maxItems: 1
>>>   
>>>     power-domains:
>>> -    maxItems: 1
>>> +    minItems: 1
>>> +    maxItems: 3
>>>       description: phandle to the associated power domain
>>>   
>>>     dma-coherent: true
>>> @@ -196,6 +211,22 @@ allOf:
>>>                 properties:
>>>                   endpoint@1: false
>>>   
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>> +          contains:
>>> +            const: ti,am62p-dss
>>> +    then:
>>> +      properties:
>>> +        power-domains:
>>> +          minItems: 1
>>> +          maxItems: 3
>>
>> This is still not constrained enough. You need to define the items
>> instead. I still do not understand why number of power domains is
>> flexible.
> 
> Planning to add:
> ```
> power-domains:
>    minItems: 1
>    description:
>      phandle to the associated power domain(s).
>    items:
>      - description: DSS controller power domain
>      - description: OLDI0 power domain
>      - description: OLDI1 power domain
> ```
> 
> There can be up to 3 power-domains in a DSS instance on AM62P SoC.
> Please check the Technical Reference Manual for AM62P SoC[0].
> On page 542 it is mentioned LPSC_main_dss0 has a partial dependence
> on LPSC_main_oldi0 and LPSC_main_oldi1, and, similarly for
> LPSC_main_dss1 there is a partial dependence on LPSC_main_oldi1.
> This mean if you are only enabling DSS0 Video port 1 for HDMI output
> only you need not mention other power-domains and similarly for DSS1
> if you need OLDI1 output you need to use DSS1 and OLDI1 power-domains.
> So, we can use up to 3 power-domains depending on the use-case.

Still wrong. The block is still part of three power domains. They are
always there even if other connectors are disconnected.

And if some other than HDMI things are disconnected, then the outputs
remain off thus driver will turn off also the power domains.

Best regards,
Krzysztof

Powered by blists - more mailing lists