dt-bindings: gpu: img, powervr-rogue: add spacemit, k3-gpu
Subsystems (2)
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
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.
> 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.
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.
> Why isn't this part of other enum (and remember about the alphabetical > order of entries)?
>
> > + - items:
> > + - enum:
> > + - spacemit,k3-gpu
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,
Baihui Liang
Re: [PATCH v3 1/2] dt-bindings: gpu: img,powervr-rogue: add spacemit,k3-gpu
Quoted 33 lines · Baihui Liang
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:
Quoted 9 lines
- 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
Re: [PATCH v3 1/2] dt-bindings: gpu: img,powervr-rogue: add spacemit,k3-gpu
Quoted 44 lines · Krzysztof Kozlowski
Quoted 33 lines · Baihui Liang
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:
Quoted 9 lines
- if:
properties:
compatible:
contains:
const: spacemit,k3-gpu then:
properties:
power-domains: false power-domain-names: false
Quoted 5 lines
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?
Sorry -- that went out through a webmail client which sent HTML, so the quoting and the YAML indentation were destroyed, and it composed a new message instead of replying in place, which is why it lost the thread. I have switched to git send-email over our own SMTP; this reply should be plain text and properly threaded.
Quoted 2 lines
So your name is presented here as "Baihui Liang" then why do you use some fake company name?
[email protected] is my real work address at SpacemiT. It is now sent through the company's own mail server.
Quoted 2 lines
Best regards,
Krzysztof
Re: [PATCH v3 1/2] dt-bindings: gpu: img,powervr-rogue: add spacemit,k3-gpu
Quoted 57 lines · Baihui Liang
Quoted 44 lines · Krzysztof Kozlowski
Quoted 33 lines · Baihui Liang
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:
Quoted 9 lines
- if:
properties:
compatible:
contains:
const: spacemit,k3-gpu then:
properties:
power-domains: false power-domain-names: falseQuoted 5 lines
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?
Sorry -- that went out through a webmail client which sent HTML, so the quoting and the YAML indentation were destroyed, and it composed a new message instead of replying in place, which is why it lost the thread. I have switched to git send-email over our own SMTP; this reply should be plain text and properly threaded.
Quoted 5 lines
Quoted 2 lines
So your name is presented here as "Baihui Liang" then why do you use some fake company name?
[email protected] is my real work address at SpacemiT. It is now sent through the company's own mail server.
Again: then why do you use fake company name as name? Actually not a company name, but laminated product of some company?
What is Sterling-Ash?
Best regards,
Krzysztof
Re: [PATCH v3 1/2] dt-bindings: gpu: img,powervr-rogue: add spacemit,k3-gpu
Quoted 64 lines · Krzysztof Kozlowski
Quoted 57 lines · Baihui Liang
Quoted 44 lines · Krzysztof Kozlowski
Quoted 33 lines · Baihui Liang
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:
Quoted 9 lines
- if:
properties:
compatible:
contains:
const: spacemit,k3-gpu then:
properties:
power-domains: false power-domain-names: falseQuoted 5 lines
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?
Sorry -- that went out through a webmail client which sent HTML, so the quoting and the YAML indentation were destroyed, and it composed a new message instead of replying in place, which is why it lost the thread. I have switched to git send-email over our own SMTP; this reply should be plain text and properly threaded.
Quoted 5 lines
Quoted 2 lines
So your name is presented here as "Baihui Liang" then why do you use some fake company name?
[email protected] is my real work address at SpacemiT. It is now sent through the company's own mail server.
Quoted 7 lines
Again: then why do you use fake company name as name? Actually not a company name, but laminated product of some company?
What is Sterling-Ash?
Best regards,
Krzysztof
Sorry, I misread what you were asking and answered the wrong question.
"Sterling-Ash" is not a company and not a product name. It was a personal nickname left over in my git config, and I did not notice it was being used as the author name on the patches until you asked. It is not my name and should not have appeared there.
The git config is fixed, and v4 will be sent with:
From: Baihui Liang <[email protected]>
Best regards,
Baihui Liang