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

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

[Baihui Liang]

[-- Attachment #1: Type: text/plain, Size: 3526 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4276 bytes --]

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

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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Baihui Liang]

On Wed Jul 29, 2026 at 3:57 PM CST, Krzysztof Kozlowski wrote:
> 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?

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.

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

liangbaihui@linux.spacemit.com is my real work address at SpacemiT. It is
now sent through the company's own mail server.

> Best regards,
> Krzysztof

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

[Baihui Liang]

On Wed Jul 29, 2026 at 3:57 PM CST, Krzysztof Kozlowski wrote:
> 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?

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.

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

liangbaihui@linux.spacemit.com is my real work address at SpacemiT. It is
now sent through the company's own mail server.

> Best regards,
> Krzysztof

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Krzysztof Kozlowski]

On 29/07/2026 11:14, Baihui Liang wrote:
> On Wed Jul 29, 2026 at 3:57 PM CST, Krzysztof Kozlowski wrote:
>> 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?
> 
> 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.
> 
>> So your name is presented here as "Baihui Liang" then why do you use
>> some fake company name?
> 
> liangbaihui@linux.spacemit.com 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

[Krzysztof Kozlowski]

On 29/07/2026 11:14, Baihui Liang wrote:
> On Wed Jul 29, 2026 at 3:57 PM CST, Krzysztof Kozlowski wrote:
>> 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?
> 
> 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.
> 
>> So your name is presented here as "Baihui Liang" then why do you use
>> some fake company name?
> 
> liangbaihui@linux.spacemit.com 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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Baihui Liang]

On Wed Jul 29, 2026 at 5:16 PM CST, Krzysztof Kozlowski wrote:
> On 29/07/2026 11:14, Baihui Liang wrote:
> > On Wed Jul 29, 2026 at 3:57 PM CST, Krzysztof Kozlowski wrote:
> >> 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?
> > 
> > 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.
> > 
> >> So your name is presented here as "Baihui Liang" then why do you use
> >> some fake company name?
> > 
> > liangbaihui@linux.spacemit.com 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

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

Best regards,
Baihui Liang

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

[Baihui Liang]

On Wed Jul 29, 2026 at 5:16 PM CST, Krzysztof Kozlowski wrote:
> On 29/07/2026 11:14, Baihui Liang wrote:
> > On Wed Jul 29, 2026 at 3:57 PM CST, Krzysztof Kozlowski wrote:
> >> 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?
> > 
> > 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.
> > 
> >> So your name is presented here as "Baihui Liang" then why do you use
> >> some fake company name?
> > 
> > liangbaihui@linux.spacemit.com 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

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

Best regards,
Baihui Liang

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH] drm/imagination: allow probe when no power-domains are described

[Alessio Belle]

Hi Sterling-Ash,

On Tue, 2026-07-21 at 09:49 +0800, Sterling-Ash wrote:
> pvr_power_domains_init() currently fails probe with -ENOENT when the
> device tree node has no "power-domains" property. On some platforms
> (e.g. SpacemiT K3) the GPU power domain is brought up by the bootloader
> and is not modeled or managed by Linux, so there is legitimately no
> power-domains phandle to attach.

Out of curiosity, does this mean no power domain controller driver in the
kernel, not even to talk to the firmware? Does the platform still switch GPU
power at runtime?

> 
> Treat a missing "power-domains" property as "nothing to attach" and
> continue probing, rather than failing.

At the moment the device tree bindings for this driver in img,powervr-rogue.yaml
require at least one power domain.

To allow this behaviour, the bindings should first be updated to drop the
minimum requirement for this SoC/platform while keeping it for everything else,
which in turn requires a new compatible string for this SoC/platform.

The SGX bindings (img,powervr-sgx.yaml) have a pattern for required/optional
power domains that could be reused here.

Thanks,
Alessio

> 
> Signed-off-by: Sterling-Ash <baihui.liang@spacemit.com>
> ---
>  drivers/gpu/drm/imagination/pvr_power.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/imagination/pvr_power.c b/drivers/gpu/drm/imagination/pvr_power.c
> index a71d5b35601e..5751e2d814b0 100644
> --- a/drivers/gpu/drm/imagination/pvr_power.c
> +++ b/drivers/gpu/drm/imagination/pvr_power.c
> @@ -635,6 +635,15 @@ int pvr_power_domains_init(struct pvr_device *pvr_dev)
>  
>  	domain_count = of_count_phandle_with_args(dev->of_node, "power-domains",
>  						  "#power-domain-cells");
> +	if (domain_count == -ENOENT) {
> +		/*
> +		 * No "power-domains" property in the device tree: the platform
> +		 * handles power domains transparently or at the firmware/bootloader level,
> +		 * so there is no domain to attach. Treat this as non-fatal.
> +		 */
> +		err = 0;
> +		goto out;
> +	}
>  	if (domain_count < 0) {
>  		err = domain_count;
>  		goto out;
> -- 
> 2.34.1
> 
> This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this message, please delete it and any attachment from your system and notify the sender immediately by reply e-mail. Unintended recipients should not use, copy, disclose or take any action based on this message or any information contained in this message. Emails cannot be guaranteed to be secure or error free as they can be intercepted, amended, lost or destroyed, and you should take full responsibility for security checking. 
>  
> 本邮件及其任何附件具有保密性质，并可能受其他保护或不允许被披露给第三方。如阁下误收到本邮件，敬请立即以回复电子邮件的方式通知发件人，并将本邮件及其任何附件从阁下系统中予以删除。如阁下并非本邮件写明之收件人，敬请切勿使用、复制、披露本邮件或其任何内容，亦请切勿依本邮件或其任何内容而采取任何行动。电子邮件无法保证是一种安全和不会出现任何差错的通信方式，可能会被拦截、修改、丢失或损坏，收件人需自行负责做好安全检查。

[PATCH v3 0/2] drm/imagination: support GPU probe without power-domains

[Sterling-Ash]

This v3 addresses an automated ("Sashiko AI") review comment on v2 [2]:
spacemit,k3-gpu didn't match any "if" block constraining clocks, so it
fell back to this schema's general 1-3 item range, which would have
let an invalid DT with 2 or 3 clocks pass validation even though this
platform only ever has one. Patch 1 now also adds spacemit,k3-gpu 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 requirement.
See the v3 note under patch 1 for details.

v2 reordered and extended the earlier standalone pvr_power.c change
per Alessio's review [1].

On the SpacemiT K3 SoC, the GPU power domain is enabled once by the
bootloader before Linux boots and is neither modelled nor switched by
Linux at runtime.

As pointed out in review, img,powervr-rogue.yaml currently has no
compatible entry this platform's GPU can use, so patch 1 adds one
(spacemit,k3-gpu + img,img-bxm-4-64 + img,img-rogue) as its own oneOf
entry, distinct from thead,th1520-gpu since the two differ in clock
requirements. This new compatible doesn't match any "if" block that
constrains power-domains, so that property falls back to the schema's
default (optional) behaviour for it -- no additional required/false
override is needed.

Patch 2 is the previously-sent driver change: pvr_power_domains_init()
treats a missing "power-domains" property as "nothing to attach"
instead of failing probe with -ENOENT.

[1] https://lore.kernel.org/all/75c9382d2bda766aa459b00321153d715254d1a4.camel@imgtec.com/
[2] https://sashiko.dev/#/patchset/20260727012231.1025210-1-baihui.liang@spacemit.com?part=1

Sterling-Ash (2):
  dt-bindings: gpu: img,powervr-rogue: add spacemit,k3-gpu
  drm/imagination: allow probe when no power-domains are described

 .../devicetree/bindings/gpu/img,powervr-rogue.yaml       | 6 ++++++
 drivers/gpu/drm/imagination/pvr_power.c                  | 9 +++++++++
 2 files changed, 15 insertions(+)

-- 
2.34.1

[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

[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

[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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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

[Baihui Liang]

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

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

[Baihui Liang]

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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv