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

[Dmitry Baryshkov]

On Thu, May 14, 2026 at 12:24:16AM +0530, Vishnu Reddy wrote:
> 
> 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@xxxxxxxxxxxxxxxx/
> 
> 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.

The latter one is the most typical approach.

> 
> >>>> 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@xxxxxxxxxxxxxxxx>
> >>>> @@ -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
> >>>>

-- 
With best wishes
Dmitry