Re: [PATCH v4 02/13] dt-bindings: media: qcom,venus: Remove clock, power-domain, and iommus from common schema
From: Vishnu Reddy
Date: Wed May 06 2026 - 12:28:45 EST
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