[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260108-expert-whippet-of-downpour-ba277f@quoll>
Date: Thu, 8 Jan 2026 09:51:08 +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 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.
>
> 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.
> + else:
> + properties:
> + power-domains:
> + minItems: 1
You can drop this one.
> + maxItems: 1
> +
> required:
> - compatible
> - reg
Powered by blists - more mailing lists