Message-ID: <f25c1e7f-bef2-47b1-8fa8-14c9c51087a8@imgtec.com>
Date: Wed, 23 Jul 2025 09:45:42 +0000
From: Matt Coster <Matt.Coster@...tec.com>
To: Michal Wilczynski <m.wilczynski@...sung.com>,
        Krzysztof Kozlowski
	<krzk@...nel.org>
CC: Drew Fustini <drew@...7.com>, Guo Ren <guoren@...nel.org>,
        Fu Wei
	<wefu@...hat.com>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bartosz Golaszewski
	<brgl@...ev.pl>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Frank Binns
	<Frank.Binns@...tec.com>,
        Maarten Lankhorst
	<maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
        Alexandre Ghiti <alex@...ti.fr>, Ulf Hansson <ulf.hansson@...aro.org>,
        Marek
 Szyprowski <m.szyprowski@...sung.com>,
        Krzysztof Kozlowski
	<krzysztof.kozlowski@...aro.org>,
        Bartosz Golaszewski
	<bartosz.golaszewski@...aro.org>,
        "linux-riscv@...ts.infradead.org"
	<linux-riscv@...ts.infradead.org>,
        "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org"
	<linux-pm@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v6 5/8] dt-bindings: gpu: img,powervr-rogue: Add TH1520
 GPU compatible

On 25/06/2025 15:41, Krzysztof Kozlowski wrote:
> On 25/06/2025 16:18, Michal Wilczynski wrote:
>>
>>
>> On 6/25/25 15:55, Krzysztof Kozlowski wrote:
>>> On 25/06/2025 14:45, Michal Wilczynski wrote:
>>>>
>>>>
>>>> On 6/24/25 15:53, Matt Coster wrote:
>>>>> On 23/06/2025 12:42, Michal Wilczynski wrote:
>>>>>> Update the img,powervr-rogue.yaml to include the T-HEAD TH1520 SoC's
>>>>>> specific GPU compatible string.
>>>>>>
>>>>>> The thead,th1520-gpu compatible, along with its full chain
>>>>>> img,img-bxm-4-64, and img,img-rogue, is added to the
>>>>>> list of recognized GPU types.
>>>>>>
>>>>>> The power-domains property requirement for img,img-bxm-4-64 is also
>>>>>> ensured by adding it to the relevant allOf condition.
>>>>>>
>>>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>>>>> Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>
>>>>>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
>>>>>> Signed-off-by: Michal Wilczynski <m.wilczynski@...sung.com>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml | 9 ++++++++-
>>>>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
>>>>>> index 4450e2e73b3ccf74d29f0e31e2e6687d7cbe5d65..9b241a0c1f5941dc58a1e23970f6d3773d427c22 100644
>>>>>> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
>>>>>> @@ -21,6 +21,11 @@ properties:
>>>>>>            # work with newer dts.
>>>>>>            - const: img,img-axe
>>>>>>            - const: img,img-rogue
>>>>>> +      - items:
>>>>>> +          - enum:
>>>>>> +              - thead,th1520-gpu
>>>>>> +          - const: img,img-bxm-4-64
>>>>>> +          - const: img,img-rogue
>>>>>>        - items:
>>>>>>            - enum:
>>>>>>                - ti,j721s2-gpu
>>>>>> @@ -93,7 +98,9 @@ allOf:
>>>>>>        properties:
>>>>>>          compatible:
>>>>>>            contains:
>>>>>> -            const: img,img-axe-1-16m
>>>>>> +            enum:
>>>>>> +              - img,img-axe-1-16m
>>>>>> +              - img,img-bxm-4-64
>>>>>
>>>>> This isn't right – BXM-4-64 has two power domains like BXS-4-64. I don't
>>>>> really know what the right way to handle that in devicetree is given the
>>>>> TH1520 appears to expose only a top-level domain for the entire GPU, but
>>>>> there are definitely two separate domains underneath that as far as the
>>>>> GPU is concerned (see the attached snippet from integration guide).
>>>>>
>>>>> Since power nodes are ref-counted anyway, do we just use the same node
>>>>> for both domains and let the driver up/down-count it twice?
>>>>
>>>> Hi Matt,
>>>>
>>>> Thanks for the very helpful insight. That's a great point, it seems the
>>>> SoC's design presents a tricky case for the bindings.
>>>>
>>>> I see what you mean about potentially using the same power domain node
>>>> twice. My only hesitation is that it might be a bit unclear for someone
>>>> reading the devicetree later. Perhaps another option could be to relax
>>>> the constraint for this compatible?
>>>>
>>>> Krzysztof, we'd be grateful for your thoughts on how to best model this
>>>> situation.
>>>
>>>
>>> It's your hardware, you should tell us, not me. I don't know how many
>>> power domains you have there, but for sure it is not one AND two domains
>>> the same time. It is either one or two, because power domains are not
>>> the same as regulator supplies.
>>
>> Hi Krzysztof, Matt,
>>
>> The img,bxm-4-64 GPU IP itself is designed with two separate power
>> domains. The TH1520 SoC, which integrates this GPU, wires both of these
>> to a single OS controllable power gate (controlled via mailbox and E902
>> co-processor).
> 
> This helps... and also sounds a lot like regulator supplies, not power
> domains. :/

Apologies for taking so long to get back to you with this, I wanted to
make sure I had the whole picture from our side before commenting again.

From the GPU side, a "typical" integration of BXM-4-64 would use two
power domains.

Typically, these domains exist in silicon, regardless of whether they
are exposed to the host OS, because the SoC's power controller must have
control over them. As part of normal operation, the GPU firmware (always
in domain "a" on Rogue) will request the power-up/down of the other
domains, including during the initial boot sequence. This all happens
transparently to the OS. The GPU block itself has no power gating at
that level, it relies entirely on the SoC integration.

However, it turns out (unknown to me until very recently) that this
functionality is optional. The integrator can opt to forego the
power-saving functionality afforded by firmware-controlled power gating
and just throw everything into a single domain, which appears to be
what's happened here.

My only remaining issue here, then, is the naming. Since this
integration doesn't use discrete domains, saying it has one domain
called "a" isn't correct*. We should either:

 - Drop the name altogether for this integration (and others like it
   that don't use the low-power functionality, if there are any), or
 - Come up with a new domain name to signal this explicitly (perhaps
   simply "gpu")? Something that's unlikely to clash with the "real"
   names that are going to start appearing in the Volcanic bindings
   (where we finally ditched "a", "b", etc.).

Cheers,
Matt

*Yes, I know that's what we said for the AXE-1-16M, but that tiny GPU is
the exception to the rule; AFAIK it's the only one we've ever produced
that truly has only one power domain.

> 
>>
>> This means a devicetree for the TH1520 can only ever provide one power
>> domain for the GPU. However, a generic binding for img,bxm-4-64 should
> 
> If this was a supply, you would have two supplies. Anyway internal
> wirings of GPU do not matter in such case and more important what the
> SoC has wired. And it has one power domain.
> 
> 
>> account for a future SoC that might implement both power domains.
>>
>> That's why I proposed to relax the constraints on the img,bmx-4-64 GPU.
> 
> This should be constrained per each device, so 1 for you and 2 for
> everyone else.
> 
> Best regards,
> Krzysztof


-- 
Matt Coster
E: matt.coster@...tec.com


Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)

Powered by blists - more mailing lists