[PATCH 0/4] Start using rpmpd for power domains on MSM8974

[PATCH 0/4] Start using rpmpd for power domains on MSM8974

[Luca Weiss]

Switch over the ADSP PIL to use power-domains instead of a regulator,
and have one commit switching over the MSM8974 SoC plus all the devices
to use power-domains.

Note, that I'm aware that these changes are not backwards compatible and
not really bisectable, but since it only affects the ADSP on these
pretty old boards, I say it's fine to have this. Get all the patches
into the same release (6.17?) and then we're good again.

Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
---
Luca Weiss (4):
      dt-bindings: remoteproc: qcom,adsp: Make msm8974 use CX as power domain
      remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974
      ARM: dts: qcom: msm8974: Sort header includes alphabetically
      ARM: dts: qcom: msm8974: Start using rpmpd for power domains

 .../devicetree/bindings/remoteproc/qcom,adsp.yaml  | 18 ++------
 .../arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts | 13 ------
 .../qcom/qcom-msm8974-lge-nexus5-hammerhead.dts    | 12 ------
 .../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts    | 12 ------
 .../dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi   | 12 ------
 arch/arm/boot/dts/qcom/qcom-msm8974.dtsi           | 50 ++++++++++++++++++++--
 .../dts/qcom/qcom-msm8974pro-fairphone-fp2.dts     |  8 ----
 arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts  | 11 -----
 .../dts/qcom/qcom-msm8974pro-oneplus-bacon.dts     |  9 ----
 .../qcom/qcom-msm8974pro-samsung-klte-common.dtsi  | 11 ++---
 ...qcom-msm8974pro-sony-xperia-shinano-common.dtsi | 12 ------
 drivers/remoteproc/qcom_q6v5_pas.c                 |  2 +-
 12 files changed, 56 insertions(+), 114 deletions(-)
---
base-commit: 7fa2fb97cd28e1d9670da538095565b6fba83977
change-id: 20250621-msm8974-rpmpd-switch-b19b166c02be

Best regards,
-- 
Luca Weiss <luca@lucaweiss.eu>

[PATCH 1/4] dt-bindings: remoteproc: qcom,adsp: Make msm8974 use CX as power domain

[Luca Weiss]

Using CX as a regulator is an artifact of earlier times. Instead use CX
power rail as power domain from rpmpd.

Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
---
 .../devicetree/bindings/remoteproc/qcom,adsp.yaml      | 18 ++++--------------
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
index 661c2b425da35c3756965fd1c47a485fe15a3f83..03e28d77da50912fe0e3106aef26cb93eb2d4142 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml
@@ -31,9 +31,6 @@ properties:
   reg:
     maxItems: 1
 
-  cx-supply:
-    description: Phandle to the CX regulator
-
   px-supply:
     description: Phandle to the PX regulator
 
@@ -103,16 +100,6 @@ allOf:
         interrupt-names:
           maxItems: 5
 
-  - if:
-      properties:
-        compatible:
-          contains:
-            enum:
-              - qcom,msm8974-adsp-pil
-    then:
-      required:
-        - cx-supply
-
   - if:
       properties:
         compatible:
@@ -120,6 +107,7 @@ allOf:
             enum:
               - qcom,msm8226-adsp-pil
               - qcom,msm8953-adsp-pil
+              - qcom,msm8974-adsp-pil
               - qcom,msm8996-adsp-pil
               - qcom,msm8998-adsp-pas
     then:
@@ -187,6 +175,7 @@ examples:
     #include <dt-bindings/clock/qcom,rpmcc.h>
     #include <dt-bindings/interrupt-controller/arm-gic.h>
     #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/power/qcom-rpmpd.h>
     adsp {
         compatible = "qcom,msm8974-adsp-pil";
 
@@ -204,7 +193,8 @@ examples:
         clocks = <&rpmcc RPM_CXO_CLK>;
         clock-names = "xo";
 
-        cx-supply = <&pm8841_s2>;
+        power-domains = <&rpmpd MSM8974_VDDCX>;
+        power-domain-names = "cx";
 
         memory-region = <&adsp_region>;
 

-- 
2.50.0

[PATCH 2/4] remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974

[Luca Weiss]

MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
which has cx under proxy_pd_names and is otherwise equivalent.

Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
---
 drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index b306f223127c452f8f2d85aa0fc98db2d684feae..b1ba5a2381c396e0ee071df1426dc610affbc6a8 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -1437,7 +1437,7 @@ static const struct adsp_data sm8750_mpss_resource = {
 static const struct of_device_id adsp_of_match[] = {
 	{ .compatible = "qcom,msm8226-adsp-pil", .data = &msm8996_adsp_resource},
 	{ .compatible = "qcom,msm8953-adsp-pil", .data = &msm8996_adsp_resource},
-	{ .compatible = "qcom,msm8974-adsp-pil", .data = &adsp_resource_init},
+	{ .compatible = "qcom,msm8974-adsp-pil", .data = &msm8996_adsp_resource},
 	{ .compatible = "qcom,msm8996-adsp-pil", .data = &msm8996_adsp_resource},
 	{ .compatible = "qcom,msm8996-slpi-pil", .data = &msm8996_slpi_resource_init},
 	{ .compatible = "qcom,msm8998-adsp-pas", .data = &msm8996_adsp_resource},

-- 
2.50.0

Re: [PATCH 2/4] remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974

[Dmitry Baryshkov]

On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
> MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
> which has cx under proxy_pd_names and is otherwise equivalent.
> 
> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> ---
>  drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Hmm. You are modifying the ADSP configuration in the driver, but at the
same time you've dropped CX supply from the MSS remoteproc.

-- 
With best wishes
Dmitry

Re: [PATCH 2/4] remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974

[Luca Weiss]

On 05-07-2025 10:57 p.m., Dmitry Baryshkov wrote:
> On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
>> MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
>> which has cx under proxy_pd_names and is otherwise equivalent.
>>
>> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
>> ---
>>   drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Hmm. You are modifying the ADSP configuration in the driver, but at the
> same time you've dropped CX supply from the MSS remoteproc.

The qcom_q6v5_mss driver has this support for .fallback_proxy_supply, 
which are used in case the power domain is not specified.

So no driver change is necessary in the mss driver for both old and new 
devicetrees, but the adsp driver does not have this fallback, so that's 
why the adsp config is updated.

Does that make it clear?

Regards
Luca

Re: [PATCH 2/4] remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974

[Dmitry Baryshkov]

On Sun, Jul 06, 2025 at 10:31:38AM +0200, Luca Weiss wrote:
> On 05-07-2025 10:57 p.m., Dmitry Baryshkov wrote:
> > On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
> > > MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
> > > which has cx under proxy_pd_names and is otherwise equivalent.
> > > 
> > > Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> > > ---
> > >   drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Hmm. You are modifying the ADSP configuration in the driver, but at the
> > same time you've dropped CX supply from the MSS remoteproc.
> 
> The qcom_q6v5_mss driver has this support for .fallback_proxy_supply, which
> are used in case the power domain is not specified.
> 
> So no driver change is necessary in the mss driver for both old and new
> devicetrees, but the adsp driver does not have this fallback, so that's why
> the adsp config is updated.
> 
> Does that make it clear?

Yes. Would it make sense to implement fallback_proxy_supply for ADSP
too?

> 
> Regards
> Luca

-- 
With best wishes
Dmitry

Re: [PATCH 2/4] remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974

[Luca Weiss]

On 06-07-2025 12:08 p.m., Dmitry Baryshkov wrote:
> On Sun, Jul 06, 2025 at 10:31:38AM +0200, Luca Weiss wrote:
>> On 05-07-2025 10:57 p.m., Dmitry Baryshkov wrote:
>>> On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
>>>> MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
>>>> which has cx under proxy_pd_names and is otherwise equivalent.
>>>>
>>>> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
>>>> ---
>>>>    drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> Hmm. You are modifying the ADSP configuration in the driver, but at the
>>> same time you've dropped CX supply from the MSS remoteproc.
>>
>> The qcom_q6v5_mss driver has this support for .fallback_proxy_supply, which
>> are used in case the power domain is not specified.
>>
>> So no driver change is necessary in the mss driver for both old and new
>> devicetrees, but the adsp driver does not have this fallback, so that's why
>> the adsp config is updated.
>>
>> Does that make it clear?
> 
> Yes. Would it make sense to implement fallback_proxy_supply for ADSP
> too?

Definitely would be possible, but I don't see the point in doing the 
work to implement this, to then carry around a bunch of legacy 
compatibility code that (very likely) won't really be used in practice.
I don't think any platform apart from msm8974 are going to be affected 
by this anyways.

Still same argument from my side, I think breaking compatibility here 
for this one driver outweighs the effort/code of implementing compatibility.

Regards
Luca

> 
>>
>> Regards
>> Luca
> 

Re: [PATCH 2/4] remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974

[Dmitry Baryshkov]

On Sun, Jul 06, 2025 at 02:32:26PM +0200, Luca Weiss wrote:
> On 06-07-2025 12:08 p.m., Dmitry Baryshkov wrote:
> > On Sun, Jul 06, 2025 at 10:31:38AM +0200, Luca Weiss wrote:
> > > On 05-07-2025 10:57 p.m., Dmitry Baryshkov wrote:
> > > > On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
> > > > > MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
> > > > > which has cx under proxy_pd_names and is otherwise equivalent.
> > > > > 
> > > > > Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> > > > > ---
> > > > >    drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
> > > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > Hmm. You are modifying the ADSP configuration in the driver, but at the
> > > > same time you've dropped CX supply from the MSS remoteproc.
> > > 
> > > The qcom_q6v5_mss driver has this support for .fallback_proxy_supply, which
> > > are used in case the power domain is not specified.
> > > 
> > > So no driver change is necessary in the mss driver for both old and new
> > > devicetrees, but the adsp driver does not have this fallback, so that's why
> > > the adsp config is updated.
> > > 
> > > Does that make it clear?
> > 
> > Yes. Would it make sense to implement fallback_proxy_supply for ADSP
> > too?
> 
> Definitely would be possible, but I don't see the point in doing the work to
> implement this, to then carry around a bunch of legacy compatibility code
> that (very likely) won't really be used in practice.
> I don't think any platform apart from msm8974 are going to be affected by
> this anyways.
> 
> Still same argument from my side, I think breaking compatibility here for
> this one driver outweighs the effort/code of implementing compatibility.

Ack. You have my r-b for the series anyways.

-- 
With best wishes
Dmitry

Re: [PATCH 2/4] remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974

[Luca Weiss]

On 06-07-2025 3:17 p.m., Dmitry Baryshkov wrote:
> On Sun, Jul 06, 2025 at 02:32:26PM +0200, Luca Weiss wrote:
>> On 06-07-2025 12:08 p.m., Dmitry Baryshkov wrote:
>>> On Sun, Jul 06, 2025 at 10:31:38AM +0200, Luca Weiss wrote:
>>>> On 05-07-2025 10:57 p.m., Dmitry Baryshkov wrote:
>>>>> On Sat, Jun 21, 2025 at 03:19:57PM +0200, Luca Weiss wrote:
>>>>>> MSM8974 requires the CX power domain, so use the msm8996_adsp_resource
>>>>>> which has cx under proxy_pd_names and is otherwise equivalent.
>>>>>>
>>>>>> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
>>>>>> ---
>>>>>>     drivers/remoteproc/qcom_q6v5_pas.c | 2 +-
>>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> Hmm. You are modifying the ADSP configuration in the driver, but at the
>>>>> same time you've dropped CX supply from the MSS remoteproc.
>>>>
>>>> The qcom_q6v5_mss driver has this support for .fallback_proxy_supply, which
>>>> are used in case the power domain is not specified.
>>>>
>>>> So no driver change is necessary in the mss driver for both old and new
>>>> devicetrees, but the adsp driver does not have this fallback, so that's why
>>>> the adsp config is updated.
>>>>
>>>> Does that make it clear?
>>>
>>> Yes. Would it make sense to implement fallback_proxy_supply for ADSP
>>> too?
>>
>> Definitely would be possible, but I don't see the point in doing the work to
>> implement this, to then carry around a bunch of legacy compatibility code
>> that (very likely) won't really be used in practice.
>> I don't think any platform apart from msm8974 are going to be affected by
>> this anyways.
>>
>> Still same argument from my side, I think breaking compatibility here for
>> this one driver outweighs the effort/code of implementing compatibility.
> 
> Ack. You have my r-b for the series anyways.

Thanks!

[PATCH 3/4] ARM: dts: qcom: msm8974: Sort header includes alphabetically

[Luca Weiss]

Before adding more headers in a random order, let's sort the includes
once so that's done.

Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
---
 arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
index 7e119370f3375573e284587d48aef6dca3ed707f..8459a840d9ffee9da2f9a4ad8fd5a1419a3eb5a7 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
@@ -1,14 +1,14 @@
 // SPDX-License-Identifier: GPL-2.0
 /dts-v1/;
 
-#include <dt-bindings/interconnect/qcom,msm8974.h>
-#include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/qcom,dsi-phy-28nm.h>
 #include <dt-bindings/clock/qcom,gcc-msm8974.h>
 #include <dt-bindings/clock/qcom,mmcc-msm8974.h>
 #include <dt-bindings/clock/qcom,rpmcc.h>
-#include <dt-bindings/reset/qcom,gcc-msm8974.h>
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interconnect/qcom,msm8974.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/reset/qcom,gcc-msm8974.h>
 
 / {
 	#address-cells = <1>;

-- 
2.50.0

Re: [PATCH 3/4] ARM: dts: qcom: msm8974: Sort header includes alphabetically

[Konrad Dybcio]

On 6/21/25 3:19 PM, Luca Weiss wrote:
> Before adding more headers in a random order, let's sort the includes
> once so that's done.
> 
> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

[PATCH 4/4] ARM: dts: qcom: msm8974: Start using rpmpd for power domains

[Luca Weiss]

Due to historical reasons all msm8974 boards have used the CX power rail
as regulator instead of going through the power domain framework.

Since rpmpd has gained msm8974 support quite a bit ago, let's start
using it and replace all usages of pm8841_s2 (CX), pm8841_s4 (GFX) and
for the boards using pma8084 pma8084_s2 (CX), pma8084_s7 (GFX).

For reference, downstream is using GFX power rail as parent-supply for
mmcc's OXILI_GDSC GDSC which then is used for GPU, but nothing there is
modelled upstream.

Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
---
 .../arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts | 13 -------
 .../qcom/qcom-msm8974-lge-nexus5-hammerhead.dts    | 12 ------
 .../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts    | 12 ------
 .../dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi   | 12 ------
 arch/arm/boot/dts/qcom/qcom-msm8974.dtsi           | 44 ++++++++++++++++++++++
 .../dts/qcom/qcom-msm8974pro-fairphone-fp2.dts     |  8 ----
 arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts  | 11 ------
 .../dts/qcom/qcom-msm8974pro-oneplus-bacon.dts     |  9 -----
 .../qcom/qcom-msm8974pro-samsung-klte-common.dtsi  | 11 ++----
 ...qcom-msm8974pro-sony-xperia-shinano-common.dtsi | 12 ------
 10 files changed, 48 insertions(+), 96 deletions(-)

diff --git a/arch/arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts
index 34b0cf35fdac8b0bc34ffd27f70f900878a15ff7..d3ae6c6a6f83e2b77849eeeb0c348a8efd9464dd 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts
+++ b/arch/arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts
@@ -198,15 +198,12 @@ &pm8941_wled {
 };
 
 &remoteproc_adsp {
-	cx-supply = <&pm8841_s2>;
-
 	firmware-name = "qcom/apq8074/adsp.mbn";
 
 	status = "okay";
 };
 
 &remoteproc_mss {
-	cx-supply = <&pm8841_s2>;
 	mss-supply = <&pm8841_s3>;
 	mx-supply = <&pm8841_s1>;
 	pll-supply = <&pm8941_l12>;
@@ -225,20 +222,10 @@ pm8841_s1: s1 {
 			regulator-max-microvolt = <1050000>;
 		};
 
-		pm8841_s2: s2 {
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1050000>;
-		};
-
 		pm8841_s3: s3 {
 			regulator-min-microvolt = <500000>;
 			regulator-max-microvolt = <1050000>;
 		};
-
-		pm8841_s4: s4 {
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1050000>;
-		};
 	};
 
 	regulators-1 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
index 261044fdfee866449e9d9d62cef5aea10d88e874..b60a45f5c34193daffe982ecab132315e4b12865 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -368,12 +368,10 @@ led@5 {
 };
 
 &remoteproc_adsp {
-	cx-supply = <&pm8841_s2>;
 	status = "okay";
 };
 
 &remoteproc_mss {
-	cx-supply = <&pm8841_s2>;
 	mss-supply = <&pm8841_s3>;
 	mx-supply = <&pm8841_s1>;
 	pll-supply = <&pm8941_l12>;
@@ -389,20 +387,10 @@ pm8841_s1: s1 {
 			regulator-max-microvolt = <1050000>;
 		};
 
-		pm8841_s2: s2 {
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1050000>;
-		};
-
 		pm8841_s3: s3 {
 			regulator-min-microvolt = <1050000>;
 			regulator-max-microvolt = <1050000>;
 		};
-
-		pm8841_s4: s4 {
-			regulator-min-microvolt = <815000>;
-			regulator-max-microvolt = <900000>;
-		};
 	};
 
 	regulators-1 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dts b/arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dts
index 903bb4d125135771504281df50aa11c9b6576a28..214cbcbd21cd18554d83f3c8569cd788868c71b0 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-samsung-hlte.dts
@@ -152,12 +152,10 @@ touch_ldo_pin: touchscreen-ldo-state {
 };
 
 &remoteproc_adsp {
-	cx-supply = <&pm8841_s2>;
 	status = "okay";
 };
 
 &remoteproc_mss {
-	cx-supply = <&pm8841_s2>;
 	mss-supply = <&pm8841_s3>;
 	mx-supply = <&pm8841_s1>;
 	pll-supply = <&pm8941_l12>;
@@ -173,20 +171,10 @@ pm8841_s1: s1 {
 			regulator-max-microvolt = <1050000>;
 		};
 
-		pm8841_s2: s2 {
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1050000>;
-		};
-
 		pm8841_s3: s3 {
 			regulator-min-microvolt = <1050000>;
 			regulator-max-microvolt = <1050000>;
 		};
-
-		pm8841_s4: s4 {
-			regulator-min-microvolt = <815000>;
-			regulator-max-microvolt = <900000>;
-		};
 	};
 
 	regulators-1 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi
index d34659ebac22e65a511994ef201fe04f12089781..02a64cea280875a91db8ee70b6b8de683327de50 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi
@@ -216,12 +216,10 @@ &pm8941_wled {
 };
 
 &remoteproc_adsp {
-	cx-supply = <&pm8841_s2>;
 	status = "okay";
 };
 
 &remoteproc_mss {
-	cx-supply = <&pm8841_s2>;
 	mss-supply = <&pm8841_s3>;
 	mx-supply = <&pm8841_s1>;
 	pll-supply = <&pm8941_l12>;
@@ -237,20 +235,10 @@ pm8841_s1: s1 {
 			regulator-max-microvolt = <1050000>;
 		};
 
-		pm8841_s2: s2 {
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1050000>;
-		};
-
 		pm8841_s3: s3 {
 			regulator-min-microvolt = <500000>;
 			regulator-max-microvolt = <1050000>;
 		};
-
-		pm8841_s4: s4 {
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1050000>;
-		};
 	};
 
 	regulators-1 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
index 8459a840d9ffee9da2f9a4ad8fd5a1419a3eb5a7..2a82ddce94a28eb1b50fdaffd5ba5de86e165156 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi
@@ -8,6 +8,7 @@
 #include <dt-bindings/gpio/gpio.h>
 #include <dt-bindings/interconnect/qcom,msm8974.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/power/qcom-rpmpd.h>
 #include <dt-bindings/reset/qcom,gcc-msm8974.h>
 
 / {
@@ -146,6 +147,40 @@ rpmcc: clock-controller {
 					clocks = <&xo_board>;
 					clock-names = "xo";
 				};
+
+				rpmpd: power-controller {
+					compatible = "qcom,msm8974-rpmpd";
+					#power-domain-cells = <1>;
+					operating-points-v2 = <&rpmpd_opp_table>;
+
+					rpmpd_opp_table: opp-table {
+						compatible = "operating-points-v2";
+
+						rpmpd_opp_ret: opp1 {
+							opp-level = <1>;
+						};
+
+						rpmpd_opp_svs_krait: opp2 {
+							opp-level = <2>;
+						};
+
+						rpmpd_opp_svs_soc: opp3 {
+							opp-level = <3>;
+						};
+
+						rpmpd_opp_nom: opp4 {
+							opp-level = <4>;
+						};
+
+						rpmpd_opp_turbo: opp5 {
+							opp-level = <5>;
+						};
+
+						rpmpd_opp_super_turbo: opp6 {
+							opp-level = <6>;
+						};
+					};
+				};
 			};
 		};
 	};
@@ -743,6 +778,9 @@ pronto: remoteproc@fb204000 {
 					      <&wcnss_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
 			interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
 
+			power-domains = <&rpmpd MSM8974_VDDCX>;
+			power-domain-names = "cx";
+
 			qcom,smem-states = <&wcnss_smp2p_out 0>;
 			qcom,smem-state-names = "stop";
 
@@ -1545,6 +1583,9 @@ remoteproc_mss: remoteproc@fc880000 {
 			resets = <&gcc GCC_MSS_RESTART>;
 			reset-names = "mss_restart";
 
+			power-domains = <&rpmpd MSM8974_VDDCX>;
+			power-domain-names = "cx";
+
 			qcom,halt-regs = <&tcsr_mutex 0x1180 0x1200 0x1280>;
 
 			qcom,smem-states = <&modem_smp2p_out 0>;
@@ -2208,6 +2249,9 @@ remoteproc_adsp: remoteproc@fe200000 {
 			clocks = <&xo_board>;
 			clock-names = "xo";
 
+			power-domains = <&rpmpd MSM8974_VDDCX>;
+			power-domain-names = "cx";
+
 			memory-region = <&adsp_region>;
 
 			qcom,smem-states = <&adsp_smp2p_out 0>;
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts
index fe227fd3f908e219e20bffe3561390ca6568468e..a081aeadd1d4d9539d38588811be8ac5ba0b79a4 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dts
@@ -156,7 +156,6 @@ &pronto {
 	status = "okay";
 
 	vddmx-supply = <&pm8841_s1>;
-	vddcx-supply = <&pm8841_s2>;
 	vddpx-supply = <&pm8941_s3>;
 
 	pinctrl-names = "default";
@@ -181,12 +180,10 @@ wcnss {
 
 &remoteproc_adsp {
 	status = "okay";
-	cx-supply = <&pm8841_s2>;
 };
 
 &remoteproc_mss {
 	status = "okay";
-	cx-supply = <&pm8841_s2>;
 	mss-supply = <&pm8841_s3>;
 	mx-supply = <&pm8841_s1>;
 	pll-supply = <&pm8941_l12>;
@@ -201,11 +198,6 @@ pm8841_s1: s1 {
 			regulator-max-microvolt = <1050000>;
 		};
 
-		pm8841_s2: s2 {
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1050000>;
-		};
-
 		pm8841_s3: s3 {
 			regulator-min-microvolt = <1050000>;
 			regulator-max-microvolt = <1050000>;
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
index b896cc1ad6f7d4b3f8e70ad4460867b04519a6d9..402372834c53d6ef71a72156d1be7d30ff1feee5 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts
@@ -70,7 +70,6 @@ &pm8941_vib {
 
 &pronto {
 	vddmx-supply = <&pm8841_s1>;
-	vddcx-supply = <&pm8841_s2>;
 	vddpx-supply = <&pm8941_s3>;
 
 	pinctrl-0 = <&wcnss_pin_a>;
@@ -104,20 +103,10 @@ pm8841_s1: s1 {
 			regulator-max-microvolt = <1050000>;
 		};
 
-		pm8841_s2: s2 {
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1050000>;
-		};
-
 		pm8841_s3: s3 {
 			regulator-min-microvolt = <1050000>;
 			regulator-max-microvolt = <1050000>;
 		};
-
-		pm8841_s4: s4 {
-			regulator-min-microvolt = <815000>;
-			regulator-max-microvolt = <900000>;
-		};
 	};
 
 	regulators-1 {
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts b/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts
index 4c8edadea0ac63db668dbd666fbb8d92e23232b7..090774e05451e1b5c7cd6d1049760da651cc83b4 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-oneplus-bacon.dts
@@ -213,7 +213,6 @@ &pm8941_vib {
 
 &pronto {
 	vddmx-supply = <&pm8841_s1>;
-	vddcx-supply = <&pm8841_s2>;
 	vddpx-supply = <&pm8941_s3>;
 
 	pinctrl-names = "default";
@@ -239,8 +238,6 @@ wcnss {
 };
 
 &remoteproc_adsp {
-	cx-supply = <&pm8841_s2>;
-
 	status = "okay";
 };
 
@@ -253,12 +250,6 @@ pm8841_s1: s1 {
 			regulator-max-microvolt = <1050000>;
 		};
 
-		pm8841_s2: s2 {
-			regulator-min-microvolt = <875000>;
-			regulator-max-microvolt = <1050000>;
-			regulator-always-on;
-		};
-
 		pm8841_s3: s3 {
 			regulator-min-microvolt = <1050000>;
 			regulator-max-microvolt = <1050000>;
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte-common.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte-common.dtsi
index d3959741d2ea9e2a3dace149034d42353fbe9828..56a1a25f3df38bf4a9ba5ea4ad9e8a2d1d1c0a95 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte-common.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-samsung-klte-common.dtsi
@@ -453,12 +453,10 @@ ramoops@3e8e0000 {
 
 &remoteproc_adsp {
 	status = "okay";
-	cx-supply = <&pma8084_s2>;
 };
 
 &remoteproc_mss {
 	status = "okay";
-	cx-supply = <&pma8084_s2>;
 	mss-supply = <&pma8084_s6>;
 	mx-supply = <&pma8084_s1>;
 	pll-supply = <&pma8084_l12>;
@@ -474,11 +472,6 @@ pma8084_s1: s1 {
 			regulator-always-on;
 		};
 
-		pma8084_s2: s2 {
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1050000>;
-		};
-
 		pma8084_s3: s3 {
 			regulator-min-microvolt = <1300000>;
 			regulator-max-microvolt = <1300000>;
@@ -648,6 +641,10 @@ pma8084_l27: l27 {
 	};
 };
 
+&rpmpd {
+	compatible = "qcom,msm8974pro-pma8084-rpmpd";
+};
+
 &sdhc_1 {
 	status = "okay";
 
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-common.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-common.dtsi
index 6af7c71c715847f137ec2da41d70f679a8e1c04b..3d2de30b495e6e6176eb38b95ec67634fbcb29ca 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-common.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974pro-sony-xperia-shinano-common.dtsi
@@ -207,12 +207,10 @@ &pm8941_vib {
 };
 
 &remoteproc_adsp {
-	cx-supply = <&pm8841_s2>;
 	status = "okay";
 };
 
 &remoteproc_mss {
-	cx-supply = <&pm8841_s2>;
 	mss-supply = <&pm8841_s3>;
 	mx-supply = <&pm8841_s1>;
 	pll-supply = <&pm8941_l12>;
@@ -228,20 +226,10 @@ pm8841_s1: s1 {
 			regulator-max-microvolt = <1050000>;
 		};
 
-		pm8841_s2: s2 {
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1050000>;
-		};
-
 		pm8841_s3: s3 {
 			regulator-min-microvolt = <500000>;
 			regulator-max-microvolt = <1050000>;
 		};
-
-		pm8841_s4: s4 {
-			regulator-min-microvolt = <500000>;
-			regulator-max-microvolt = <1050000>;
-		};
 	};
 
 	regulators-1 {

-- 
2.50.0

Re: [PATCH 4/4] ARM: dts: qcom: msm8974: Start using rpmpd for power domains

[Konrad Dybcio]

On 6/21/25 3:19 PM, Luca Weiss wrote:
> Due to historical reasons all msm8974 boards have used the CX power rail
> as regulator instead of going through the power domain framework.
> 
> Since rpmpd has gained msm8974 support quite a bit ago, let's start
> using it and replace all usages of pm8841_s2 (CX), pm8841_s4 (GFX) and
> for the boards using pma8084 pma8084_s2 (CX), pma8084_s7 (GFX).
> 
> For reference, downstream is using GFX power rail as parent-supply for
> mmcc's OXILI_GDSC GDSC which then is used for GPU, but nothing there is
> modelled upstream.

if you use an opp table with described rpmpd levels and bind the GFX
domain to gpucc, it should propagate - check it out

> 
> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 4/4] ARM: dts: qcom: msm8974: Start using rpmpd for power domains

[Luca Weiss]

On 23-06-2025 2:39 p.m., Konrad Dybcio wrote:
> On 6/21/25 3:19 PM, Luca Weiss wrote:
>> Due to historical reasons all msm8974 boards have used the CX power rail
>> as regulator instead of going through the power domain framework.
>>
>> Since rpmpd has gained msm8974 support quite a bit ago, let's start
>> using it and replace all usages of pm8841_s2 (CX), pm8841_s4 (GFX) and
>> for the boards using pma8084 pma8084_s2 (CX), pma8084_s7 (GFX).
>>
>> For reference, downstream is using GFX power rail as parent-supply for
>> mmcc's OXILI_GDSC GDSC which then is used for GPU, but nothing there is
>> modelled upstream.
> 
> if you use an opp table with described rpmpd levels and bind the GFX
> domain to gpucc, it should propagate - check it out

I don't *really* understand what you mean here. I'd be happy if you 
provided an example (or better yet, a patch) for this.

Also msm8974 does not have gpucc, only gcc and mmcc.

> 
>>
>> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
>> ---
> 
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Thanks!

Regards
Luca

> 
> Konrad

Re: [PATCH 4/4] ARM: dts: qcom: msm8974: Start using rpmpd for power domains

[Konrad Dybcio]

On 6/23/25 6:44 PM, Luca Weiss wrote:
> On 23-06-2025 2:39 p.m., Konrad Dybcio wrote:
>> On 6/21/25 3:19 PM, Luca Weiss wrote:
>>> Due to historical reasons all msm8974 boards have used the CX power rail
>>> as regulator instead of going through the power domain framework.
>>>
>>> Since rpmpd has gained msm8974 support quite a bit ago, let's start
>>> using it and replace all usages of pm8841_s2 (CX), pm8841_s4 (GFX) and
>>> for the boards using pma8084 pma8084_s2 (CX), pma8084_s7 (GFX).
>>>
>>> For reference, downstream is using GFX power rail as parent-supply for
>>> mmcc's OXILI_GDSC GDSC which then is used for GPU, but nothing there is
>>> modelled upstream.
>>
>> if you use an opp table with described rpmpd levels and bind the GFX
>> domain to gpucc, it should propagate - check it out
> 
> I don't *really* understand what you mean here. I'd be happy if you provided an example (or better yet, a patch) for this.

sm6115

> 
> Also msm8974 does not have gpucc, only gcc and mmcc.

*oh*... right

You would then have to somehow selectively bind the OXILI_GDSC to
VDD_GX, for which I don't know if we have a good interface today..

Konrad

Re: [PATCH 0/4] Start using rpmpd for power domains on MSM8974

[Dmitry Baryshkov]

On Sat, Jun 21, 2025 at 03:19:55PM +0200, Luca Weiss wrote:
> Switch over the ADSP PIL to use power-domains instead of a regulator,
> and have one commit switching over the MSM8974 SoC plus all the devices
> to use power-domains.
> 
> Note, that I'm aware that these changes are not backwards compatible and
> not really bisectable, but since it only affects the ADSP on these

Why? The cx-supply is handled unconditionally. A single-domain usecase
is also handled via a special code path. I think this might be
backwards-compatible, by the pure luck.

> pretty old boards, I say it's fine to have this. Get all the patches
> into the same release (6.17?) and then we're good again.
> 
> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
> ---
> Luca Weiss (4):
>       dt-bindings: remoteproc: qcom,adsp: Make msm8974 use CX as power domain
>       remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974
>       ARM: dts: qcom: msm8974: Sort header includes alphabetically
>       ARM: dts: qcom: msm8974: Start using rpmpd for power domains
> 
>  .../devicetree/bindings/remoteproc/qcom,adsp.yaml  | 18 ++------
>  .../arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts | 13 ------
>  .../qcom/qcom-msm8974-lge-nexus5-hammerhead.dts    | 12 ------
>  .../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts    | 12 ------
>  .../dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi   | 12 ------
>  arch/arm/boot/dts/qcom/qcom-msm8974.dtsi           | 50 ++++++++++++++++++++--
>  .../dts/qcom/qcom-msm8974pro-fairphone-fp2.dts     |  8 ----
>  arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts  | 11 -----
>  .../dts/qcom/qcom-msm8974pro-oneplus-bacon.dts     |  9 ----
>  .../qcom/qcom-msm8974pro-samsung-klte-common.dtsi  | 11 ++---
>  ...qcom-msm8974pro-sony-xperia-shinano-common.dtsi | 12 ------
>  drivers/remoteproc/qcom_q6v5_pas.c                 |  2 +-
>  12 files changed, 56 insertions(+), 114 deletions(-)
> ---
> base-commit: 7fa2fb97cd28e1d9670da538095565b6fba83977
> change-id: 20250621-msm8974-rpmpd-switch-b19b166c02be
> 
> Best regards,
> -- 
> Luca Weiss <luca@lucaweiss.eu>
> 

-- 
With best wishes
Dmitry

Re: [PATCH 0/4] Start using rpmpd for power domains on MSM8974

[Luca Weiss]

Hi Dmitry,

On 24-06-2025 2:59 a.m., Dmitry Baryshkov wrote:
> On Sat, Jun 21, 2025 at 03:19:55PM +0200, Luca Weiss wrote:
>> Switch over the ADSP PIL to use power-domains instead of a regulator,
>> and have one commit switching over the MSM8974 SoC plus all the devices
>> to use power-domains.
>>
>> Note, that I'm aware that these changes are not backwards compatible and
>> not really bisectable, but since it only affects the ADSP on these
> 
> Why? The cx-supply is handled unconditionally. A single-domain usecase
> is also handled via a special code path. I think this might be
> backwards-compatible, by the pure luck.

Honestly I have not tried and not looked much. I mostly added this 
paragraph to avoid the response that this change might break and is not 
really backwards compatible. If it does (by accident) work with the 
updated dts without the driver and the other way around, then even better.

Regards
Luca

> 
>> pretty old boards, I say it's fine to have this. Get all the patches
>> into the same release (6.17?) and then we're good again.
>>
>> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
>> ---
>> Luca Weiss (4):
>>        dt-bindings: remoteproc: qcom,adsp: Make msm8974 use CX as power domain
>>        remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974
>>        ARM: dts: qcom: msm8974: Sort header includes alphabetically
>>        ARM: dts: qcom: msm8974: Start using rpmpd for power domains
>>
>>   .../devicetree/bindings/remoteproc/qcom,adsp.yaml  | 18 ++------
>>   .../arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts | 13 ------
>>   .../qcom/qcom-msm8974-lge-nexus5-hammerhead.dts    | 12 ------
>>   .../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts    | 12 ------
>>   .../dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi   | 12 ------
>>   arch/arm/boot/dts/qcom/qcom-msm8974.dtsi           | 50 ++++++++++++++++++++--
>>   .../dts/qcom/qcom-msm8974pro-fairphone-fp2.dts     |  8 ----
>>   arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts  | 11 -----
>>   .../dts/qcom/qcom-msm8974pro-oneplus-bacon.dts     |  9 ----
>>   .../qcom/qcom-msm8974pro-samsung-klte-common.dtsi  | 11 ++---
>>   ...qcom-msm8974pro-sony-xperia-shinano-common.dtsi | 12 ------
>>   drivers/remoteproc/qcom_q6v5_pas.c                 |  2 +-
>>   12 files changed, 56 insertions(+), 114 deletions(-)
>> ---
>> base-commit: 7fa2fb97cd28e1d9670da538095565b6fba83977
>> change-id: 20250621-msm8974-rpmpd-switch-b19b166c02be
>>
>> Best regards,
>> -- 
>> Luca Weiss <luca@lucaweiss.eu>
>>
> 

Re: [PATCH 0/4] Start using rpmpd for power domains on MSM8974

[Dmitry Baryshkov]

On 24/06/2025 21:46, Luca Weiss wrote:
> Hi Dmitry,
> 
> On 24-06-2025 2:59 a.m., Dmitry Baryshkov wrote:
>> On Sat, Jun 21, 2025 at 03:19:55PM +0200, Luca Weiss wrote:
>>> Switch over the ADSP PIL to use power-domains instead of a regulator,
>>> and have one commit switching over the MSM8974 SoC plus all the devices
>>> to use power-domains.
>>>
>>> Note, that I'm aware that these changes are not backwards compatible and
>>> not really bisectable, but since it only affects the ADSP on these
>>
>> Why? The cx-supply is handled unconditionally. A single-domain usecase
>> is also handled via a special code path. I think this might be
>> backwards-compatible, by the pure luck.
> 
> Honestly I have not tried and not looked much. I mostly added this 
> paragraph to avoid the response that this change might break and is not 
> really backwards compatible. If it does (by accident) work with the 
> updated dts without the driver and the other way around, then even better.

I think it's worth checking that new kernel works with older DTS (that's 
the usual rule). The platform doesn't have many users upstream, but I 
think it has been used by some PmOS users, which might mean 
not-yet-upstreamed DT.

> 
> Regards
> Luca
> 
>>
>>> pretty old boards, I say it's fine to have this. Get all the patches
>>> into the same release (6.17?) and then we're good again.
>>>
>>> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
>>> ---
>>> Luca Weiss (4):
>>>        dt-bindings: remoteproc: qcom,adsp: Make msm8974 use CX as 
>>> power domain
>>>        remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974
>>>        ARM: dts: qcom: msm8974: Sort header includes alphabetically
>>>        ARM: dts: qcom: msm8974: Start using rpmpd for power domains
>>>
>>>   .../devicetree/bindings/remoteproc/qcom,adsp.yaml  | 18 ++------
>>>   .../arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts | 13 ------
>>>   .../qcom/qcom-msm8974-lge-nexus5-hammerhead.dts    | 12 ------
>>>   .../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts    | 12 ------
>>>   .../dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi   | 12 ------
>>>   arch/arm/boot/dts/qcom/qcom-msm8974.dtsi           | 50 +++++++++++ 
>>> +++++++++--
>>>   .../dts/qcom/qcom-msm8974pro-fairphone-fp2.dts     |  8 ----
>>>   arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts  | 11 -----
>>>   .../dts/qcom/qcom-msm8974pro-oneplus-bacon.dts     |  9 ----
>>>   .../qcom/qcom-msm8974pro-samsung-klte-common.dtsi  | 11 ++---
>>>   ...qcom-msm8974pro-sony-xperia-shinano-common.dtsi | 12 ------
>>>   drivers/remoteproc/qcom_q6v5_pas.c                 |  2 +-
>>>   12 files changed, 56 insertions(+), 114 deletions(-)
>>> ---
>>> base-commit: 7fa2fb97cd28e1d9670da538095565b6fba83977
>>> change-id: 20250621-msm8974-rpmpd-switch-b19b166c02be
>>>
>>> Best regards,
>>> -- 
>>> Luca Weiss <luca@lucaweiss.eu>
>>>
>>
> 


-- 
With best wishes
Dmitry

Re: [PATCH 0/4] Start using rpmpd for power domains on MSM8974

[Luca Weiss]

Hi Dmitry,

On 24-06-2025 11:03 p.m., Dmitry Baryshkov wrote:
> On 24/06/2025 21:46, Luca Weiss wrote:
>> Hi Dmitry,
>>
>> On 24-06-2025 2:59 a.m., Dmitry Baryshkov wrote:
>>> On Sat, Jun 21, 2025 at 03:19:55PM +0200, Luca Weiss wrote:
>>>> Switch over the ADSP PIL to use power-domains instead of a regulator,
>>>> and have one commit switching over the MSM8974 SoC plus all the devices
>>>> to use power-domains.
>>>>
>>>> Note, that I'm aware that these changes are not backwards compatible 
>>>> and
>>>> not really bisectable, but since it only affects the ADSP on these
>>>
>>> Why? The cx-supply is handled unconditionally. A single-domain usecase
>>> is also handled via a special code path. I think this might be
>>> backwards-compatible, by the pure luck.
>>
>> Honestly I have not tried and not looked much. I mostly added this 
>> paragraph to avoid the response that this change might break and is 
>> not really backwards compatible. If it does (by accident) work with 
>> the updated dts without the driver and the other way around, then even 
>> better.
> 
> I think it's worth checking that new kernel works with older DTS (that's 
> the usual rule). The platform doesn't have many users upstream, but I 
> think it has been used by some PmOS users, which might mean not-yet- 
> upstreamed DT.

I was finally able to test this, but the patches except the dts patch 
does not work.

[  170.802573] qcom_q6v5_pas fe200000.remoteproc: probe with driver 
qcom_q6v5_pas failed with error -61
[  170.803127] remoteproc remoteproc0: releasing adsp

I didn't take much more of a look but probably adsp_pds_attach fails there.

For postmarketOS users, all msm8974 mainline devices that are packaged 
as part of postmarketOS, come from the github.com/msm8974-mainline/linux 
fork, which included this patch already since a few releases. I'm taking 
care that all out-of-tree dts that are in that repo are updated.

Fortunately this is just breaking adsp probe, bootup still works as 
before. So from my side again: I think it's not worth the effort to add 
a bunch of complexity to the driver code and support this use case. I'm 
not aware of any msm8974 upstream users that would require that.

Regards
Luca

> 
>>
>> Regards
>> Luca
>>
>>>
>>>> pretty old boards, I say it's fine to have this. Get all the patches
>>>> into the same release (6.17?) and then we're good again.
>>>>
>>>> Signed-off-by: Luca Weiss <luca@lucaweiss.eu>
>>>> ---
>>>> Luca Weiss (4):
>>>>        dt-bindings: remoteproc: qcom,adsp: Make msm8974 use CX as 
>>>> power domain
>>>>        remoteproc: qcom_q6v5_pas: Use resource with CX PD for MSM8974
>>>>        ARM: dts: qcom: msm8974: Sort header includes alphabetically
>>>>        ARM: dts: qcom: msm8974: Start using rpmpd for power domains
>>>>
>>>>   .../devicetree/bindings/remoteproc/qcom,adsp.yaml  | 18 ++------
>>>>   .../arm/boot/dts/qcom/qcom-apq8074-dragonboard.dts | 13 ------
>>>>   .../qcom/qcom-msm8974-lge-nexus5-hammerhead.dts    | 12 ------
>>>>   .../boot/dts/qcom/qcom-msm8974-samsung-hlte.dts    | 12 ------
>>>>   .../dts/qcom/qcom-msm8974-sony-xperia-rhine.dtsi   | 12 ------
>>>>   arch/arm/boot/dts/qcom/qcom-msm8974.dtsi           | 50 ++++++++++ 
>>>> + +++++++++--
>>>>   .../dts/qcom/qcom-msm8974pro-fairphone-fp2.dts     |  8 ----
>>>>   arch/arm/boot/dts/qcom/qcom-msm8974pro-htc-m8.dts  | 11 -----
>>>>   .../dts/qcom/qcom-msm8974pro-oneplus-bacon.dts     |  9 ----
>>>>   .../qcom/qcom-msm8974pro-samsung-klte-common.dtsi  | 11 ++---
>>>>   ...qcom-msm8974pro-sony-xperia-shinano-common.dtsi | 12 ------
>>>>   drivers/remoteproc/qcom_q6v5_pas.c                 |  2 +-
>>>>   12 files changed, 56 insertions(+), 114 deletions(-)
>>>> ---
>>>> base-commit: 7fa2fb97cd28e1d9670da538095565b6fba83977
>>>> change-id: 20250621-msm8974-rpmpd-switch-b19b166c02be
>>>>
>>>> Best regards,
>>>> -- 
>>>> Luca Weiss <luca@lucaweiss.eu>
>>>>
>>>
>>
> 
> 

Re: [PATCH 0/4] Start using rpmpd for power domains on MSM8974

[Dmitry Baryshkov]

On Sat, Jul 05, 2025 at 04:16:44PM +0200, Luca Weiss wrote:
> Hi Dmitry,
> 
> On 24-06-2025 11:03 p.m., Dmitry Baryshkov wrote:
> > On 24/06/2025 21:46, Luca Weiss wrote:
> > > Hi Dmitry,
> > > 
> > > On 24-06-2025 2:59 a.m., Dmitry Baryshkov wrote:
> > > > On Sat, Jun 21, 2025 at 03:19:55PM +0200, Luca Weiss wrote:
> > > > > Switch over the ADSP PIL to use power-domains instead of a regulator,
> > > > > and have one commit switching over the MSM8974 SoC plus all the devices
> > > > > to use power-domains.
> > > > > 
> > > > > Note, that I'm aware that these changes are not backwards
> > > > > compatible and
> > > > > not really bisectable, but since it only affects the ADSP on these
> > > > 
> > > > Why? The cx-supply is handled unconditionally. A single-domain usecase
> > > > is also handled via a special code path. I think this might be
> > > > backwards-compatible, by the pure luck.
> > > 
> > > Honestly I have not tried and not looked much. I mostly added this
> > > paragraph to avoid the response that this change might break and is
> > > not really backwards compatible. If it does (by accident) work with
> > > the updated dts without the driver and the other way around, then
> > > even better.
> > 
> > I think it's worth checking that new kernel works with older DTS (that's
> > the usual rule). The platform doesn't have many users upstream, but I
> > think it has been used by some PmOS users, which might mean not-yet-
> > upstreamed DT.
> 
> I was finally able to test this, but the patches except the dts patch does
> not work.
> 
> [  170.802573] qcom_q6v5_pas fe200000.remoteproc: probe with driver
> qcom_q6v5_pas failed with error -61
> [  170.803127] remoteproc remoteproc0: releasing adsp
> 
> I didn't take much more of a look but probably adsp_pds_attach fails there.
> 
> For postmarketOS users, all msm8974 mainline devices that are packaged as
> part of postmarketOS, come from the github.com/msm8974-mainline/linux fork,
> which included this patch already since a few releases. I'm taking care that
> all out-of-tree dts that are in that repo are updated.
> 
> Fortunately this is just breaking adsp probe, bootup still works as before.
> So from my side again: I think it's not worth the effort to add a bunch of
> complexity to the driver code and support this use case. I'm not aware of
> any msm8974 upstream users that would require that.

Ack.

For the series:

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry