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

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

[Sterling-Ash]

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
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.

Signed-off-by: Sterling-Ash <liangbaihui@linux.spacemit.com>
---
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
+          - const: img,img-bxm-4-64
+          - const: img,img-rogue
       - items:
           - enum:
               - ti,am62p-gpu
@@ -100,6 +105,7 @@ allOf:
         compatible:
           contains:
             enum:
+              - spacemit,k3-gpu
               - ti,am62-gpu
               - ti,am62p-gpu
               - ti,j721s2-gpu
-- 
2.34.1

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

[Krzysztof Kozlowski]

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?

> 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.

> 
> 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

> 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)?

Best regards,
Krzysztof

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

[Krzysztof Kozlowski]

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
> 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.
> 
> Signed-off-by: Sterling-Ash <liangbaihui@linux.spacemit.com>

Also, are you sure your Latin transliteration of your name includes a
hyphen? Email differs and we do not take anonymous contributions, so
this must much your name in the known identity.

Best regards,
Krzysztof

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

[Krzysztof Kozlowski]

On 29/07/2026 09:46, Baihui Liang wrote:
> On Tue, Jul 28, 2026, Krzysztof Kozlowski wrote:
> > > [...]
> > > 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

I understand only half of this. Please fix your email client.

And why this reply misses reply-to header which connects it to proper
thread? How am I supposed to find the thread now, among 200 I received
yesterday?

So your name is presented here as "Baihui Liang" then why do you use
some fake company name?



Best regards,
Krzysztof