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

[Nicolas Frattaroli <nicolas.frattaroli@collabora.com>]

On Friday, 19 September 2025 06:28:54 Central European Summer Time Krzysztof Kozlowski wrote:
> 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
> 

The previous reply was in jest, I did not know that this was incorrect.
That's because it has no effect; there is no option for a bare
`arm,mali-valhall-csf` compatible with no other compatible preceding
it right now as far as I can parse the binding (which in of itself
seems wrong.) So minItems: 1 didn't do anything, because the RK3588
compatible would override it anyway, and the mt8196 compatible would
disable the property entirely.

Hence, this piece of code is not wrong, as it's functionally
equivalent to what was already there. Unless that is my reasoning
is erroneous, in which case I'd appreciate an explanation for how
it is wrong, rather than having to argue why I think you think
wrongly that it is wrong.

Kind regards,
Nicolas Frattaroli