Re: [PATCH v5 04/14] dt-bindings: media: qcom,venus: Remove clock, power-domain, and iommus from common schema

[Vishnu Reddy <busanna.reddy@oss.qualcomm.com>]

On 5/13/2026 6:59 PM, Dmitry Baryshkov wrote:
> On Sat, May 09, 2026 at 10:34:15PM +0530, Vishnu Reddy wrote:
>> On 5/9/2026 12:52 AM, Dmitry Baryshkov wrote:
>>> On Sat, May 09, 2026 at 12:29:53AM +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.
>>> It really doesn't. It provides common definitions, while individual
>>> platform schemas tighten those.
>> If a new platform requires more resources than the current maxItems listed in
>> the common-schema (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.
>>
>> I am fine with increasing maxItems in the common schema instead of removing.
>> 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.
>>
>> Could you please let me know which one you would prefer going forward?
> Just touch venus-common when new platform requires bigger lists.

In the v3 series, I followed same approach — bumping maxItems in venus-common
schema to accommodate the Glymur platform while keeping fixed constraints in
the Glymur-specific schema:
https://lore.kernel.org/all/20260428-glymur-v3-2-8f28930f47d3@oss.qualcomm.com/

I'm fine with bumping it only when a new platform requires it.
However, I'd like to understand your preference a bit more:

Would you prefer setting it to a slightly larger value (e.g., ~20) upfront, so
that it accommodates a few future platforms without needing frequent changes to
the common schema?
Or
would you rather we bump it conservatively each time a new platform exceeds the
current limit?

I'm fine with either way — just wanted to align on the preferred approach before
the next revision.

>>>> Remove these constraints from the common schema. Each platform specific
>>>> schema already defines its own exact fixed constraints for these
>>>> properties. Additionally, remove these from the required list and update
>>>> all schemas that reference this common schema.
>>>>
>>>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>>>> @@ -64,10 +44,7 @@ properties:
>>>>  
>>>>  required:
>>>>    - reg
>>>> -  - clocks
>>>> -  - clock-names
>>>>    - interrupts
>>>>    - memory-region
>>>> -  - power-domains
>>> Do we expect the platforms with Venus / Iris not having either clocks or
>>> power domains.
>> All Venus / Iris platforms have clocks and power-domains. These removed from here
>> and added in each platform schema.
> This is a sign that this is wrong.
>
>>>>  
>>>>  additionalProperties: true
>>>>
>>>> -- 
>>>> 2.34.1
>>>>