Re: [PATCH v3 02/12] dt-bindings: media: qcom,glymur-iris: Add glymur video codec

[Vishnu Reddy]

On 4/28/2026 2:48 PM, Krzysztof Kozlowski wrote:
> On 28/04/2026 11:12, Vishnu Reddy wrote:
>> On 4/28/2026 1:58 PM, Krzysztof Kozlowski wrote:
>>> On 28/04/2026 10:08, Vishnu Reddy wrote:
>>>> On 4/28/2026 11:44 AM, Krzysztof Kozlowski wrote:
>>>>> On Tue, Apr 28, 2026 at 09:24:08AM +0530, Vishnu Reddy wrote:
>>>>>> Add device tree binding for the Qualcomm Glymur Iris video codec. Glymur
>>>>>> is a new generation of video IP that introduces a dual-core architecture.
>>>>>> The second core brings its own power domain, clocks, and reset lines,
>>>>>> requiring additional power domains and clocks in the power sequence.
>>>>>>
>>>>>> To accommodate glymur clock and power resources requirement, the maxItems
>>>>>> constraints in qcom,venus-common.yaml are relaxed. This allows the glymur
>>>>> This is a very confusing part of commit msg. You cannot relax the
>>>>> constraints. Each device MUST have a specific, fixed constraint. It is
>>>>> your task to be sure they are not relaxed.
>>>>>
>>>>>
>>>>>> binding to inherit from the common venus schema without duplicating shared
>>>>>> properties.
>>>>> That's obvious. Why would new iris device schema not use common venus
>>>>> schema? What is different here then that such possibility exists?
>>>> Glymur platform has a dual-core video codec architecture (vcodec0 + vcodec1),
>>>> requiring 9 clocks and 5 power domains. The stricter maxItems from the
>>>> qcom,venus-common.yaml takes precedence, making it impossible to accommodate
>>>> glymur requirements without updating the common schema.
>>> But so does every other device, no? So what is different here?
>> The difference is in the resource count relative to what qcom,venus-common.yaml
>> permits. Existing platforms like SM8750 have 6 clocks and 4 power domains,
> So it is EXACTLY the same?
>
> Again, what is different between devices that it should not use common
> schema?
>
>> which fall within the maxItems limits defined in the common schema (clocks: 7,
>> power domains: 4). So for those platforms, referencing qcom,venus-common.yaml
>> via allOf works fine, their resource counts are within range.
>>
>> Glymur dual core architecture (vcodec0 + vcodec1) requires 9 clocks and 5 power
>> domains, both of which exceed the common schema maxItems. Even if
>> qcom,glymur-iris.yaml explicitly defines maxItems: 9 for clocks and maxItems: 5
>> for power domains, the stricter limit from qcom,venus-common.yaml takes the
>> precedence, causing schema validation to fail.
>>
>> Glymur is the first platform where the common schema limits become a hard
>> blocker, unlike all prior platforms that happened to stay within those limits.
> Hard blocker? What? How? you are imagining some problems here which do
> not exist in any other devices, any other IP blocks.
>
> Why is this special and GPU is not? Or display is not? Or anything else?
> Why standard rules of writing bindings do not apply here? What is
> exactly different? Write like this:

The intent is not to treat Glymur as “special” in the sense of resource
count alone. The key difference is architectural:

The existing qcom,venus-common.yaml was originally written with single
Venus/Iris video core and its maxItems for clocks and power domains were
defined accordingly. All existing platforms fit within that assumption,
even if their exact counts differ slightly.

Glymur is a multiple vcodec cores platform, each core requiring its own
set clocks and power domains. This breaks the implicit single-core assumption
encoded in the common schema, which is why the existing maxItems become
insufficient.

I agree that simply relaxing common constraints to fit a single outlier is
might not be ideal and not scalable.

So one another approach to handle this requirement could be to remove the
maxItems entries for clocks and power domains from qcom,venus-common.yaml,
and let each platform specific binding declare its own maxItems. This keeps
the common schema reusable across both single core and multi core platforms.

> "The standard rule of <foo bar> from writing bindings does not apply,
> because <baz fab>.".
>
> Best regards,
> Krzysztof