public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Vikash Garodia <vikash.garodia@oss.qualcomm.com>,
	Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>,
	Abhinav Kumar <abhinav.kumar@linux.dev>,
	Bryan O'Donoghue <bod@kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Hans Verkuil <hverkuil@kernel.org>,
	Stefan Schmidt <stefan.schmidt@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Stanimir Varbanov <stanimir.k.varbanov@gmail.com>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	iommu@lists.linux.dev
Subject: Re: [PATCH v4 02/13] dt-bindings: media: qcom,venus: Remove clock, power-domain, and iommus from common schema
Date: Wed, 6 May 2026 21:58:15 +0530	[thread overview]
Message-ID: <bb008913-1100-9b8a-c7f5-1194df33eea8@oss.qualcomm.com> (raw)
In-Reply-To: <333ba4cd-8168-41f1-afdc-348f99ed0611@kernel.org>


On 5/6/2026 6:39 PM, Krzysztof Kozlowski wrote:
> On 06/05/2026 11:32, Vishnu Reddy wrote:
>> On 5/6/2026 12:11 PM, Krzysztof Kozlowski wrote:
>>> On Tue, May 05, 2026 at 12:29:23PM +0530, Vishnu Reddy wrote:
>>>> The common schema defines minItems and maxItems for clocks, power-domains,
>>>> and iommus. This suggests that the number of these resources can vary,
>>>> while in reality they are fixed constraints per platform.
>>> OK, that's interesting approach. I am fine with it, but then you need to
>>> remove these from "required:" list as well, because requiring properties
>>> which are not defined here is not the most readable.
>> Ack, I will remove them from "required:" in the next revision.
>>
>>> I still do not understand though why you cannot just grow the properties
>>> here. The point of this schema is to define common set for range of
>>> devices, because all of these devices are supposed to be veri similar.
>> If a new platform schema uses this common schema but does not explicitly
>> re-declare clocks or power-domains, it will inherit minItems and maxItems
> But new platform MUST define them, because each platform has both clocks
> and power domains.
>
>> range from the common schema. This gives the false impression that the
>> resource count is flexible for that platform, when in reality it should
>> be a fixed constraints.
>>
>> If a new platform requires more resources than the current maxItems (e.g.,
>> Glymur due to its dual vcodec core design), we need to keep bumping maxItems
>> in the common schema every time a new platform exceeds the previous limit.
>> That makes the common schema a moving target driven by platform specific.
> That's pretty expected, I don't see a problem in that.

I am fine with increasing maxItems in the common schema. I can set it to a
reasonable value (for example, up to 20) so that it accommodates future
platforms without frequent changes. Anyway, each platform schema must define
fixed constraints, since clocks and power-domains are mandatory per platform.

At the same time, I am also fine with the alternative approach of removing
these properties from the common schema entirely, since the fixed constraints
are already defined in each platform schema.

I'm fine with both approaches.
Could you please let me know which one you would prefer going forward?

Thanks,
Vishnu Reddy

> Best regards,
> Krzysztof

  reply	other threads:[~2026-05-06 16:28 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-05  6:59 [PATCH v4 00/13] media: iris: Add support for glymur platform Vishnu Reddy
2026-05-05  6:59 ` [PATCH v4 01/13] media: iris: Fix VM count passed to firmware Vishnu Reddy
2026-05-05  6:59 ` [PATCH v4 02/13] dt-bindings: media: qcom,venus: Remove clock, power-domain, and iommus from common schema Vishnu Reddy
2026-05-06  6:41   ` Krzysztof Kozlowski
2026-05-06  9:32     ` Vishnu Reddy
2026-05-06 13:09       ` Krzysztof Kozlowski
2026-05-06 16:28         ` Vishnu Reddy [this message]
2026-05-05  6:59 ` [PATCH v4 03/13] dt-bindings: media: qcom,glymur-iris: Add glymur video codec Vishnu Reddy
2026-05-06  7:18   ` Krzysztof Kozlowski
2026-05-05  6:59 ` [PATCH v4 04/13] media: iris: Add iris vpu bus support Vishnu Reddy
2026-05-06 14:15   ` Vikash Garodia
2026-05-05  6:59 ` [PATCH v4 05/13] iommu: Add iris-vpu-bus to iommu_buses Vishnu Reddy
2026-05-05  6:59 ` [PATCH v4 06/13] media: iris: Add context bank hooks for platform specific initialization Vishnu Reddy
2026-05-06 14:26   ` Vikash Garodia
2026-05-05  6:59 ` [PATCH v4 07/13] media: iris: Enable Secure PAS support with IOMMU managed by Linux Vishnu Reddy
2026-05-06  5:21   ` Mukesh Ojha
2026-05-06 16:36     ` Vishnu Reddy
2026-05-05  6:59 ` [PATCH v4 08/13] media: iris: Rename clock and power domain macros to use vcodec prefix Vishnu Reddy
2026-05-06 14:42   ` Vikash Garodia
2026-05-05  6:59 ` [PATCH v4 09/13] media: iris: Use power domain type to look up pd_devs index Vishnu Reddy
2026-05-06 14:48   ` Vikash Garodia
2026-05-05  6:59 ` [PATCH v4 10/13] media: iris: Add power sequence for Glymur Vishnu Reddy
2026-05-06 15:15   ` Vikash Garodia
2026-05-05  6:59 ` [PATCH v4 11/13] media: iris: Add support to select core for dual core platforms Vishnu Reddy
2026-05-06 15:50   ` Vikash Garodia
2026-05-05  6:59 ` [PATCH v4 12/13] media: iris: Add platform data for glymur Vishnu Reddy
2026-05-06 15:56   ` Vikash Garodia
2026-05-05  6:59 ` [PATCH v4 13/13] arm64: dts: qcom: glymur: Add iris video node Vishnu Reddy
2026-05-06 16:02   ` Vikash Garodia
2026-05-06  6:44 ` [PATCH v4 00/13] media: iris: Add support for glymur platform Krzysztof Kozlowski

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=bb008913-1100-9b8a-c7f5-1194df33eea8@oss.qualcomm.com \
    --to=busanna.reddy@oss.qualcomm.com \
    --cc=abhinav.kumar@linux.dev \
    --cc=andersson@kernel.org \
    --cc=bod@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dikshita.agarwal@oss.qualcomm.com \
    --cc=hverkuil@kernel.org \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=stanimir.k.varbanov@gmail.com \
    --cc=stefan.schmidt@linaro.org \
    --cc=vikash.garodia@oss.qualcomm.com \
    --cc=will@kernel.org \
    /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