From: Swamil Jain <s-jain1@ti.com>
To: Krzysztof Kozlowski <krzk@kernel.org>, <jyri.sarha@iki.fi>,
<tomi.valkeinen@ideasonboard.com>, <airlied@gmail.com>,
<simona@ffwll.ch>, <maarten.lankhorst@linux.intel.com>,
<mripard@kernel.org>, <tzimmermann@suse.de>, <robh@kernel.org>,
<krzk+dt@kernel.org>, <conor+dt@kernel.org>,
<aradhya.bhatia@linux.dev>, <mwalle@kernel.org>
Cc: <dri-devel@lists.freedesktop.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <devarsht@ti.com>,
<praneeth@ti.com>, <u-kumar1@ti.com>
Subject: Re: [PATCH v4 1/3] dt-bindings: display: ti,am65x-dss: Add am62p dss compatible
Date: Fri, 16 Jan 2026 16:39:51 +0530 [thread overview]
Message-ID: <1cc5e036-12b6-4b0d-9393-21bbb0dd3f48@ti.com> (raw)
In-Reply-To: <34759368-6b0f-421f-81dd-20006ee19a1b@kernel.org>
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
next prev parent reply other threads:[~2026-01-16 11:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-16 9:54 [PATCH v4 0/3] Add Display support for AM62P SoC Swamil Jain
2026-01-16 9:54 ` [PATCH v4 1/3] dt-bindings: display: ti,am65x-dss: Add am62p dss compatible Swamil Jain
2026-01-16 10:27 ` Krzysztof Kozlowski
2026-01-16 11:09 ` Swamil Jain [this message]
2026-01-16 11:24 ` Krzysztof Kozlowski
2026-02-13 12:43 ` Swamil Jain
2026-01-19 10:10 ` Tomi Valkeinen
2026-01-30 12:00 ` Tomi Valkeinen
2026-01-30 12:27 ` Nishanth Menon
2026-02-13 12:47 ` Swamil Jain
2026-02-13 12:32 ` Swamil Jain
2026-01-16 9:54 ` [PATCH v4 2/3] drm/tidss: Power up attached PM domains on probe Swamil Jain
2026-01-16 10:04 ` Tomi Valkeinen
2026-01-16 9:54 ` [PATCH v4 3/3] drm: tidss: tidss_drv: Add support for AM62P display subsystem Swamil Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1cc5e036-12b6-4b0d-9393-21bbb0dd3f48@ti.com \
--to=s-jain1@ti.com \
--cc=airlied@gmail.com \
--cc=aradhya.bhatia@linux.dev \
--cc=conor+dt@kernel.org \
--cc=devarsht@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jyri.sarha@iki.fi \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=mwalle@kernel.org \
--cc=praneeth@ti.com \
--cc=robh@kernel.org \
--cc=simona@ffwll.ch \
--cc=tomi.valkeinen@ideasonboard.com \
--cc=tzimmermann@suse.de \
--cc=u-kumar1@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®