Recent discussions off-list highlighted that the GCC should vote for the
RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not
aggregate the correct load for the CX rail, potentially leading to voltage
drops and system instability.
Add the missing power-domains property to associate GCC with RPMHPD_CX.
Fixes: db7fe6963466 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/eliza.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
index 5dc3aede6842..fab603cd8e42 100644
--- a/arch/arm64/boot/dts/qcom/eliza.dtsi
+++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
@@ -617,6 +617,8 @@ gcc: clock-controller@100000 {
<&ufs_mem_phy 2>,
<0>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
--
2.48.1On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote:
> Recent discussions off-list highlighted that the GCC should vote for the
> RPMh CX power domain on Qualcomm platforms.
Your commit message should describe the problem that the patch is trying
to solve, not the story about how the patch came to be.
> Without this, RPMh may not aggregate the correct load for the CX rail,
"may not"?
In what case will it aggregate the client votes cast on the GDSCs
aggregate to anything without the power-domains property?
> potentially leading to voltage
> drops and system instability.
>
> Add the missing power-domains property to associate GCC with RPMHPD_CX.
>
I think the commit message should be something like:
"""
Unless CX is declared the power-domain of GCC votes (power and
performance) on the GDSCs provided by GCC will not propagate to the CX,
which might result in under-voltage conditions.
Add the missing power-domains property to associate GCC with RPMHPD_CX.
"""
Regards,
Bjorn
> Fixes: db7fe6963466 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
> index 5dc3aede6842..fab603cd8e42 100644
> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
> @@ -617,6 +617,8 @@ gcc: clock-controller@100000 {
> <&ufs_mem_phy 2>,
> <0>;
>
> + power-domains = <&rpmhpd RPMHPD_CX>;
> +
> #clock-cells = <1>;
> #reset-cells = <1>;
> #power-domain-cells = <1>;
>
> --
> 2.48.1
>
On 26-03-23 21:15:12, Bjorn Andersson wrote: > On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote: > > Recent discussions off-list highlighted that the GCC should vote for the > > RPMh CX power domain on Qualcomm platforms. > > Your commit message should describe the problem that the patch is trying > to solve, not the story about how the patch came to be. Sure. Will fix. > > > Without this, RPMh may not aggregate the correct load for the CX rail, > > "may not"? > > In what case will it aggregate the client votes cast on the GDSCs > aggregate to anything without the power-domains property? So my understanding was that RPMh firmware aggregates votes internally as it knows the actual parent-child relationship and we were supposed to replicate that exactly in kernel for reliability purposes. Meaning, in theory it should know to aggregate proper load for the CX based on GDSCs voting, it's just that it isn't always a sure thing. Maybe I missunderstood it though. > > > potentially leading to voltage > > drops and system instability. > > > > Add the missing power-domains property to associate GCC with RPMHPD_CX. > > > > I think the commit message should be something like: > > """ > Unless CX is declared the power-domain of GCC votes (power and > performance) on the GDSCs provided by GCC will not propagate to the CX, > which might result in under-voltage conditions. > > Add the missing power-domains property to associate GCC with RPMHPD_CX. > """ Sure, will respin with this commit message. Thanks for reviewing.
On 3/24/26 2:45 PM, Abel Vesa wrote: > On 26-03-23 21:15:12, Bjorn Andersson wrote: >> On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote: >>> Recent discussions off-list highlighted that the GCC should vote for the >>> RPMh CX power domain on Qualcomm platforms. >> >> Your commit message should describe the problem that the patch is trying >> to solve, not the story about how the patch came to be. > > Sure. Will fix. > >> >>> Without this, RPMh may not aggregate the correct load for the CX rail, >> >> "may not"? >> >> In what case will it aggregate the client votes cast on the GDSCs >> aggregate to anything without the power-domains property? > > So my understanding was that RPMh firmware aggregates votes > internally as it knows the actual parent-child relationship and we were > supposed to replicate that exactly in kernel for reliability purposes. > > Meaning, in theory it should know to aggregate proper load for the CX > based on GDSCs voting, it's just that it isn't always a sure thing. > > Maybe I missunderstood it though. GDSCs are fancy on/off switches RPMH votes must be carried out manually and in the kernel that's via RPMHPD/RPMHCC/ICC Konrad
On 26-03-24 16:14:34, Konrad Dybcio wrote: > On 3/24/26 2:45 PM, Abel Vesa wrote: > > On 26-03-23 21:15:12, Bjorn Andersson wrote: > >> On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote: > >>> Recent discussions off-list highlighted that the GCC should vote for the > >>> RPMh CX power domain on Qualcomm platforms. > >> > >> Your commit message should describe the problem that the patch is trying > >> to solve, not the story about how the patch came to be. > > > > Sure. Will fix. > > > >> > >>> Without this, RPMh may not aggregate the correct load for the CX rail, > >> > >> "may not"? > >> > >> In what case will it aggregate the client votes cast on the GDSCs > >> aggregate to anything without the power-domains property? > > > > So my understanding was that RPMh firmware aggregates votes > > internally as it knows the actual parent-child relationship and we were > > supposed to replicate that exactly in kernel for reliability purposes. > > > > Meaning, in theory it should know to aggregate proper load for the CX > > based on GDSCs voting, it's just that it isn't always a sure thing. > > > > Maybe I missunderstood it though. > > GDSCs are fancy on/off switches > > RPMH votes must be carried out manually and in the kernel that's via > RPMHPD/RPMHCC/ICC Right. Thanks.
On 3/22/26 5:08 PM, Abel Vesa wrote:
> Recent discussions off-list highlighted that the GCC should vote for the
> RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not
> aggregate the correct load for the CX rail, potentially leading to voltage
> drops and system instability.
>
> Add the missing power-domains property to associate GCC with RPMHPD_CX.
>
> Fixes: db7fe6963466 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote:
> Recent discussions off-list highlighted that the GCC should vote for the
> RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not
> aggregate the correct load for the CX rail, potentially leading to voltage
> drops and system instability.
>
> Add the missing power-domains property to associate GCC with RPMHPD_CX.
>
> Fixes: db7fe6963466 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote:
> Recent discussions off-list highlighted that the GCC should vote for the
> RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not
> aggregate the correct load for the CX rail, potentially leading to voltage
> drops and system instability.
Should we add it on other platforms too?
>
> Add the missing power-domains property to associate GCC with RPMHPD_CX.
>
> Fixes: db7fe6963466 ("arm64: dts: qcom: Introduce Eliza Soc base dtsi")
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
--
With best wishes
Dmitry
On 3/22/26 6:51 PM, Dmitry Baryshkov wrote: > On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote: >> Recent discussions off-list highlighted that the GCC should vote for the >> RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not >> aggregate the correct load for the CX rail, potentially leading to voltage >> drops and system instability. > > Should we add it on other platforms too? Things generally work better when powered on Konrad
On 26-03-23 11:50:37, Konrad Dybcio wrote: > On 3/22/26 6:51 PM, Dmitry Baryshkov wrote: > > On Sun, Mar 22, 2026 at 06:08:20PM +0200, Abel Vesa wrote: > >> Recent discussions off-list highlighted that the GCC should vote for the > >> RPMh CX power domain on Qualcomm platforms. Without this, RPMh may not > >> aggregate the correct load for the CX rail, potentially leading to voltage > >> drops and system instability. > > > > Should we add it on other platforms too? > > Things generally work better when powered on Yep, definitely.
© 2016 - 2026 Red Hat, Inc.