Re: [PATCH v3 1/2] dt-bindings: gpu: img,powervr-rogue: add spacemit,k3-gpu

["Baihui Liang" <liangbaihui@linux.spacemit.com>]

On Tue Jul 28, 2026 at 4:07 PM CST, Krzysztof Kozlowski wrote:
> On Tue, Jul 28, 2026 at 09:05:12AM +0800, Sterling-Ash wrote:
> > Add a compatible string for the IMG BXM-4-64 GPU integrated into the
> > SpacemiT K3 SoC. It shares the same core as thead,th1520-gpu but is
> > kept as a separate compatible entry, since the K3 integration differs
> > from TH1520 in its clock and power-domain requirements: K3 has a
> > single "core" clock rather than three, and its GPU power domain is
> > enabled by the bootloader before Linux boots rather than being
> > modelled and switched by Linux, so no power-domains property is
> > required for this platform (unlike the other img,img-bxm-4-64 user).
> > 
> > spacemit,k3-gpu is added to the existing ti,am62-gpu/ti,am62p-gpu/
> > ti,j721s2-gpu "if" block that restricts clocks to a single entry,
> > since K3 has the same single-clock requirement. It does not match any
> > "if" block that constrains power-domains, so that property falls back
>
> I don't get this explanation. Are you explaining what the patch is doing
> or explaining WHY you did this that way?

That paragraph was describing schema mechanics, which does not belong in
a commit message. v4 will drop it and state only the hardware facts: the
K3 integration of the BXM-4-64 has a single "core" clock, and it has no
software-controllable GPU power domain.

> > to this schema's general constraints, where it is optional. This
> > leaves room for a power-domains provider to be added later without a
> > further binding change, should one ever be modelled in Linux for this
> > SoC.
>
> No, you need to provide constraints now. Please read carefully
> writing-bindings.

Understood. spacemit,k3-gpu currently matches no power-domains "if"
block, so it falls back to the top-level 1-2 domains with
power-domain-names "a"/"b". That would let a K3 DT with two power
domains pass validation, which does not describe this hardware. v4 will
add an explicit "if" block:

    - if:
        properties:
          compatible:
            contains:
              const: spacemit,k3-gpu
      then:
        properties:
          power-domains: false
          power-domain-names: false

The K3 integration of the BXM-4-64 has no software-controllable GPU
power domain, so both properties are disallowed rather than constrained.
This is the one place K3 differs from the other bxm-4-64 user: on
TH1520 the GPU sits in a single unified domain, and that block stays as
it is.

> > 
> > Signed-off-by: Sterling-Ash <liangbaihui@linux.spacemit.com>
> > ---
>
> Do not attach (thread) your patchsets to some other threads (unrelated
> or older versions). This buries them deep in the mailbox and might
> interfere with applying entire sets. See also:
> https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830

Sorry about that -- v2 and v3 were both sent in reply to the v1 review
thread. v4 will be sent as its own top-level thread.

> > v3: also add spacemit,k3-gpu to the existing ti,am62-gpu/ti,am62p-gpu/
> >     ti,j721s2-gpu "if" block restricting clocks to a single entry --
> >     previously it fell back to this schema's general clocks constraint
> >     (1-3 items), which would have let an invalid DT with 2 or 3 clocks
> >     pass validation (found by automated review on v2).
> > 
> >  .../devicetree/bindings/gpu/img,powervr-rogue.yaml          | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> > index a1f54dbae3f3..d29f0d163b91 100644
> > --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> > +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> > @@ -38,6 +38,11 @@ properties:
> >                - thead,th1520-gpu
> >            - const: img,img-bxm-4-64
> >            - const: img,img-rogue
> > +      - items:
> > +          - enum:
> > +              - spacemit,k3-gpu
>
> Why isn't this part of other enum (and remember about the alphabetical
> order of entries)?

No reason -- it was simply wrong. That block is identical to the
thead,th1520-gpu one apart from the SoC compatible, and the differing
clock/power-domain constraints live in "allOf", not here. v4 will fold
it in, in alphabetical order:

      - items:
          - enum:
              - spacemit,k3-gpu
              - thead,th1520-gpu
          - const: img,img-bxm-4-64
          - const: img,img-rogue

The DTS user, and the drm/imagination change it depends on, will be sent
separately once a boot issue on the K3 board is resolved.

> Best regards,
> Krzysztof

Best regards,
Baihui Liang