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

[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

_______________________________________________
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

_______________________________________________
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

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

[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


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

[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


_______________________________________________
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

_______________________________________________
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


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