From: Krzysztof Kozlowski <krzk@kernel.org>
To: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Cc: linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org,
Rob Clark <robin.clark@oss.qualcomm.com>,
Sean Paul <sean@poorly.run>,
Konrad Dybcio <konradybcio@kernel.org>,
Dmitry Baryshkov <lumag@kernel.org>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Jessica Zhang <jessica.zhang@oss.qualcomm.com>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bjorn Andersson <andersson@kernel.org>
Subject: Re: [PATCH 3/6] dt-bindings: display/msm/gmu: Document A612 RGMU
Date: Tue, 21 Oct 2025 21:19:14 +0200 [thread overview]
Message-ID: <ff37b635-b3dc-4180-8eae-e798ef6ce55a@kernel.org> (raw)
In-Reply-To: <181af756-09a1-4694-98c4-53cea556e172@oss.qualcomm.com>
On 21/10/2025 17:51, Akhil P Oommen wrote:
> On 10/19/2025 2:43 PM, Krzysztof Kozlowski wrote:
>> On 17/10/2025 19:08, Akhil P Oommen wrote:
>>> RGMU a.k.a Reduced Graphics Management Unit is a small state machine
>>> with the sole purpose of providing IFPC (Inter Frame Power Collapse)
>>> support. Compared to GMU, it doesn't manage GPU clock, voltage
>>> scaling, bw voting or any other functionalities. All it does is detect
>>> an idle GPU and toggle the GDSC switch. As it doesn't access DDR space,
>>> it doesn't require iommu.
>>>
>>> So far, only Adreno 612 GPU has an RGMU core. Document RGMU in the GMU's
>>> schema.
>>>
>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>> ---
>>> .../devicetree/bindings/display/msm/gmu.yaml | 98 +++++++++++++++++-----
>>> 1 file changed, 79 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml
>>> index afc1879357440c137cadeb2d9a74ae8459570a25..a262d41755f09f21f607bf7a1fd567f386595f39 100644
>>> --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml
>>> +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml
>>> @@ -26,6 +26,9 @@ properties:
>>> - items:
>>> - pattern: '^qcom,adreno-gmu-x[1-9][0-9][0-9]\.[0-9]$'
>>> - const: qcom,adreno-gmu
>>> + - items:
>>> + - const: qcom,adreno-rgmu-612.0
>>> + - const: qcom,adreno-rgmu
>>> - const: qcom,adreno-gmu-wrapper
>>>
>>> reg:
>>> @@ -45,24 +48,30 @@ properties:
>>> maxItems: 7
>>>
>>> interrupts:
>>> - items:
>>> - - description: GMU HFI interrupt
>>> - - description: GMU interrupt
>>
>>
>> Both stay, just explain what is the first interrupt. You should not drop
>> descriptions here. Look at every other binding - of course except that
>> terrible Adreno GPU which is anti-example.
>
> Do you mean we should use a OneOf and list both combo? Or elaborate the
> description of the first interrupt to include OOB too? Something like:
>
> - description: HFI interrupt on GMU and OOB interrupt on RGMU.
Yes, like that.
>
> Sorry, I am a bit confused.
>
>>
>>> + minItems: 2
>>> + maxItems: 2
>>>
>>> interrupt-names:
>>> - items:
>>> - - const: hfi
>>> - - const: gmu
>>> + oneOf:
>>> + - items:
>>> + - const: hfi
>>> + description: GMU HFI interrupt
>>
>> No, descriptions never go to xxx-names, but to xxx.
>>
>>> + - const: gmu
>>> + description: GMU interrupt
>>> + - items:
>>> + - const: oob
>>> + description: GMU OOB interrupt
>>> + - const: gmu
>>> + description: GMU interrupt
>>> +
>>>
>>> power-domains:
>>> - items:
>>> - - description: CX power domain
>>> - - description: GX power domain
>>> + minItems: 2
>>> + maxItems: 3
>>
>> No.
> I will keep the 'description'. Here, RGMU has 3 power domains instead of
> 2. I suppose we should add the description for the 3rd power domain here
> and keep 'minItems: 2' property to override the default 3?
Yes.
>
>>
>>>
>>> power-domain-names:
>>> - items:
>>> - - const: cx
>>> - - const: gx
>>> + minItems: 2
>>> + maxItems: 3
>>
>>
>> No. Why?
> Same as above.
>
>>
>>>
>>> iommus:
>>> maxItems: 1
>>> @@ -86,6 +95,44 @@ required:
>>> additionalProperties: false
>>>
>>> allOf:
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: qcom,adreno-rgmu-612.0
>>> + then:
>>> + properties:
>>> + reg:
>>> + items:
>>> + - description: Core RGMU registers
>>> + reg-names:
>>> + items:
>>> + - const: gmu
>>> + clocks:
>>> + items:
>>> + - description: GMU clock
>>> + - description: GPU CX clock
>>> + - description: GPU AXI clock
>>> + - description: GPU MEMNOC clock
>>> + - description: GPU SMMU vote clock
>>> + clock-names:
>>> + items:
>>> + - const: gmu
>>> + - const: cxo
>>> + - const: axi
>>> + - const: memnoc
>>> + - const: smmu_vote
>>> + power-domains:
>>> + items:
>>> + - description: CX power domain
>>> + - description: GX power domain
>>> + - description: VDD_CX power domain
>>> + power-domain-names:
>>> + items:
>>> + - const: cx
>>> + - const: gx
>>> + - const: vdd_cx
>>
>> This does not make even sense. Why did you remove the the common list
>> from power-domain-names?
>>
>>> +
>>> - if:
>>> properties:
>>> compatible:
>>> @@ -313,13 +360,26 @@ allOf:
>>> items:
>>> - const: gmu
>>> else:
>>> - required:
>>> - - clocks
>>> - - clock-names
>>> - - interrupts
>>> - - interrupt-names
>>> - - iommus
>>> - - operating-points-v2
>>> + if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: qcom,adreno-rgmu
>>> + then:
>>> + required:
>>> + - clocks
>>> + - clock-names
>>> + - interrupts
>>> + - interrupt-names
>>> + - operating-points-v2
>>> + else:
>>
>> No. Don't nest multiple ifs.
>
> I guess we should split this. I will add a 'required' constraint to the
> rgmu constraints above. And apply the below 'required' constraint
> specifically to 'qcom,adreno-gmu' instead of the 'else' fallback case.
>
> Please let me know if you have any suggestion.
Maybe the binding is getting to complicated and RGMU should have its own.
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-10-21 19:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-17 17:08 [PATCH 0/6] Support for Adreno 612 GPU - Respin Akhil P Oommen
2025-10-17 17:08 ` [PATCH 1/6] drm/msm/a6xx: Add support for Adreno 612 Akhil P Oommen
2025-10-21 14:15 ` Dan Carpenter
2025-10-23 22:59 ` Akhil P Oommen
2025-10-22 15:13 ` Konrad Dybcio
2025-10-23 22:57 ` Akhil P Oommen
2025-10-24 7:55 ` Konrad Dybcio
2025-10-24 13:16 ` Rob Clark
2025-10-24 14:23 ` Akhil P Oommen
2025-11-03 11:44 ` Konrad Dybcio
2025-11-03 11:44 ` Konrad Dybcio
2025-10-17 17:08 ` [PATCH 2/6] dt-bindings: display/msm: gpu: Document A612 GPU Akhil P Oommen
2025-10-19 9:10 ` Krzysztof Kozlowski
2025-10-21 14:39 ` Akhil P Oommen
2025-10-17 17:08 ` [PATCH 3/6] dt-bindings: display/msm/gmu: Document A612 RGMU Akhil P Oommen
2025-10-19 9:13 ` Krzysztof Kozlowski
2025-10-21 15:51 ` Akhil P Oommen
2025-10-21 19:19 ` Krzysztof Kozlowski [this message]
2025-10-23 23:03 ` Akhil P Oommen
2025-10-24 9:28 ` Dmitry Baryshkov
2025-10-24 14:10 ` Akhil P Oommen
2025-10-17 17:08 ` [PATCH 4/6] arm64: dts: qcom: qcs615: add the GPU SMMU node Akhil P Oommen
2025-11-03 11:54 ` Konrad Dybcio
2025-10-17 17:08 ` [PATCH 5/6] arm64: dts: qcom: qcs615: Add gpu and rgmu nodes Akhil P Oommen
2025-10-22 15:27 ` Konrad Dybcio
2025-10-23 22:17 ` Akhil P Oommen
2025-10-24 7:40 ` Konrad Dybcio
2025-10-17 17:08 ` [PATCH 6/6] arm64: dts: qcom: qcs615-ride: Enable Adreno 612 GPU Akhil P Oommen
2025-10-20 7:57 ` Konrad Dybcio
2025-10-17 21:53 ` [PATCH 0/6] Support for Adreno 612 GPU - Respin Rob Herring (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ff37b635-b3dc-4180-8eae-e798ef6ce55a@kernel.org \
--to=krzk@kernel.org \
--cc=abhinav.kumar@linux.dev \
--cc=airlied@gmail.com \
--cc=akhilpo@oss.qualcomm.com \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jessica.zhang@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lumag@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=marijn.suijten@somainline.org \
--cc=mripard@kernel.org \
--cc=robh@kernel.org \
--cc=robin.clark@oss.qualcomm.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox