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

[Krzysztof Kozlowski]

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 standard rule of <foo bar> from writing bindings does not apply,
because <baz fab>.".

Best regards,
Krzysztof