Re: [PATCH v3 01/10] dt-bindings: gpu: mali-valhall-csf: add mediatek,mt8196-mali variant

[Krzysztof Kozlowski <krzk@kernel.org>]

On 18/09/2025 23:01, Nicolas Frattaroli wrote:
> On Thursday, 18 September 2025 02:30:09 Central European Summer Time Krzysztof Kozlowski wrote:
>> On Wed, Sep 17, 2025 at 02:22:32PM +0200, Nicolas Frattaroli wrote:
>>> The Mali-based GPU on the MediaTek MT8196 SoC uses a separate MCU to
>>> control the power and frequency of the GPU.
>>>
>>> It lets us omit the OPP tables from the device tree, as those can now be
>>> enumerated at runtime from the MCU. It also means the mali GPU node
>>> described in this binding does not have any clocks in this case, as all
>>> clock control is delegated to the MCU.
>>>
>>> Add the mediatek,mt8196-mali compatible, and a performance-domains
>>> property which points to the MCU's device tree node in this case. It's
>>> required on mt8196 devices.
>>>
>>> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>>> ---
>>>  .../bindings/gpu/arm,mali-valhall-csf.yaml         | 32 ++++++++++++++++++++--
>>>  1 file changed, 30 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> index 7ad5a3ffc5f5c753322eda9e74cc65de89d11c73..ccab2dd0ea852187e3ab75923e19739622b2b3b8 100644
>>> --- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> @@ -38,7 +38,6 @@ properties:
>>>        - const: gpu
>>>  
>>>    clocks:
>>> -    minItems: 1
>>
>> I don't understand why.
>>
>> Best regards,
>> Krzysztof
>>
>>
> 
> I am executing a Convex hull algorithm on the 3D space of "dt-bindings
> maintainer opinions" to get a convex hull of acceptable dt-bindings
> choices where two different choices are functionally equivalent.
> 
> With this additional opinion on the krzk axis, I now know that having
> the base properties accurate for the general case is not required if
> the per-compatible case sets the property to false anyway.
> 
> I hope no two opinions are collinear, as this would surely be my
> undoing.
> 
> You get to pick which axis (X, Y, Z) you are. Right-hand rule, of
> course.


This piece of code is wrong and I could not deduce the reason. That's
why I asked why you need that change. If you intend to waste my time, I
will don't bother with this, but code is still wrong.

Best regards,
Krzysztof