[PATCH v3 0/7] MSM8953/SDM632 rpmpd/mss fixes

[PATCH v3 0/7] MSM8953/SDM632 rpmpd/mss fixes

[Barnabás Czémán]

SDM632 pm domains are different from MSM8953 because MSM8953
is defining pm8953_s1 as regulator but SDM632 is defining it
as pm domain.

This patch series correcting the pm domains defined in rpmpd
driver and splitting the MSS resources for the both SoC to match
the reality.

These changes was discussed in a previous threads:
https://lore.kernel.org/all/2b057aa5-4416-4fd4-aeab-6bc23acbb53d@oss.qualcomm.com/

Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
Changes in v3:
- Change RPMPD_VDDMD from 10 to 5.
- Add back MSM8953_VDDMD_AO and MSM8953_VDDMD.
- Split qcom,sdm632-rpmpd compatible documentation from VDDMD definition.
- Link to v2: https://patch.msgid.link/20260929-sdm632-rpmpd-v2-0-97ef8858161b@mainlining.org

Changes in v2:
- Define RPMPD_VDDMD
- Remove unused MSM8953_VDDMD and MSM8953_VDDMD_AO
- Squash MSM8953 mss related commits.
- Rebase on latest next.
- Link to v1: https://patch.msgid.link/20260327-sdm632-rpmpd-v1-0-6098dc997d66@mainlining.org

To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Bjorn Andersson <andersson@kernel.org>
To: Ulf Hansson <ulfh@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
To: Abel Vesa <abelvesa@kernel.org>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Stephan Gerhold <stephan@gerhold.net>
Cc: linux-arm-msm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-remoteproc@vger.kernel.org

---
Barnabás Czémán (7):
      dt-bindings: power: qcom-rpmpd: define RPMPD_VDDMD
      dt-bindings: power: qcom,rpmpd: Add SDM632
      pmdomain: qcom: rpmpd: Split SDM632 pm domains from MSM8953
      remoteproc: qcom_q6v5_mss: Use mss as regulator for MSM8953
      dt-bindings: remoteproc: qcom,msm8916-mss-pil: Add SDM632
      remoteproc: qcom_q6v5_mss: Add SDM632 MSS
      arm64: dts: qcom: sdm632: Correct power domains

 .../devicetree/bindings/power/qcom,rpmpd.yaml      |  1 +
 .../bindings/remoteproc/qcom,msm8916-mss-pil.yaml  |  9 ++--
 arch/arm64/boot/dts/qcom/msm8953.dtsi              |  5 +-
 arch/arm64/boot/dts/qcom/sdm632.dtsi               | 34 +++++++++++++
 drivers/pmdomain/qcom/rpmpd.c                      | 29 ++++++-----
 drivers/remoteproc/qcom_q6v5_mss.c                 | 56 ++++++++++++++++++++--
 include/dt-bindings/power/qcom-rpmpd.h             |  1 +
 7 files changed, 113 insertions(+), 22 deletions(-)
---
base-commit: 6375e61c01e93e35ee7acd336a689ac1fae4b509
change-id: 20260319-sdm632-rpmpd-c0e3eb548f58

Best regards,
--  
Barnabás Czémán <barnabas.czeman@mainlining.org>

[PATCH v3 1/7] dt-bindings: power: qcom-rpmpd: define RPMPD_VDDMD

[Barnabás Czémán]

Define RPMPD_VDDMD can be used for SDM439 and SDM632 MSS.

Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
 include/dt-bindings/power/qcom-rpmpd.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
index 4371ac941f29..beb066b3aa8c 100644
--- a/include/dt-bindings/power/qcom-rpmpd.h
+++ b/include/dt-bindings/power/qcom-rpmpd.h
@@ -15,6 +15,7 @@
 #define RPMPD_VDDMX		3
 #define RPMPD_VDDMX_AO		4
 #define RPMPD_VDDMX_VFL		5
+#define RPMPD_VDDMD		5
 #define RPMPD_SSCCX		6
 #define RPMPD_SSCCX_VFL		7
 #define RPMPD_SSCMX		8

-- 
2.56.0

[PATCH v3 2/7] dt-bindings: power: qcom,rpmpd: Add SDM632

[Barnabás Czémán]

Add compatible for SDM632 RPM.

Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
 Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index a70bfacbc5d1..4b263a982fca 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -51,6 +51,7 @@ properties:
           - qcom,sc7280-rpmhpd
           - qcom,sc8180x-rpmhpd
           - qcom,sc8280xp-rpmhpd
+          - qcom,sdm632-rpmpd
           - qcom,sdm660-rpmpd
           - qcom,sdm670-rpmhpd
           - qcom,sdm845-rpmhpd

-- 
2.56.0

[PATCH v3 3/7] pmdomain: qcom: rpmpd: Split SDM632 pm domains from MSM8953

[Barnabás Czémán]

Remove modem related pm domains from MSM8953 rpmpd because MSM8953 MSS
is using mss-supply as regulator.
Split SDM632 rpmpd from MSM8953 because SDM632 MSS is using mss-supply
as pm domain.

Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
 drivers/pmdomain/qcom/rpmpd.c | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/pmdomain/qcom/rpmpd.c b/drivers/pmdomain/qcom/rpmpd.c
index 5f55fc791131..c37a79d6bc43 100644
--- a/drivers/pmdomain/qcom/rpmpd.c
+++ b/drivers/pmdomain/qcom/rpmpd.c
@@ -503,19 +503,8 @@ static struct rpmpd md_s1a_corner_ao = {
 	.key = KEY_CORNER,
 };
 
-static struct rpmpd md_s1a_lvl_ao;
 static struct rpmpd md_s1a_lvl = {
 	.pd = { .name = "md", },
-	.peer = &md_s1a_lvl_ao,
-	.res_type = RPMPD_SMPA,
-	.res_id = 1,
-	.key = KEY_LEVEL,
-};
-
-static struct rpmpd md_s1a_lvl_ao = {
-	.pd = { .name = "md_ao", },
-	.peer = &md_s1a_lvl,
-	.active_only = true,
 	.res_type = RPMPD_SMPA,
 	.res_id = 1,
 	.key = KEY_LEVEL,
@@ -703,8 +692,6 @@ static const struct rpmpd_desc msm8917_desc = {
 };
 
 static struct rpmpd *msm8953_rpmpds[] = {
-	[MSM8953_VDDMD] =	&md_s1a_lvl,
-	[MSM8953_VDDMD_AO] =	&md_s1a_lvl_ao,
 	[MSM8953_VDDCX] =	&cx_s2a_lvl,
 	[MSM8953_VDDCX_AO] =	&cx_s2a_lvl_ao,
 	[MSM8953_VDDCX_VFL] =	&cx_s2a_vfl,
@@ -844,6 +831,21 @@ static const struct rpmpd_desc qm215_desc = {
 	.max_state = RPM_SMD_LEVEL_TURBO,
 };
 
+static struct rpmpd *sdm632_rpmpds[] = {
+	[RPMPD_VDDMD] =		&md_s1a_lvl,
+	[RPMPD_VDDCX] =		&cx_s2a_lvl,
+	[RPMPD_VDDCX_AO] =	&cx_s2a_lvl_ao,
+	[RPMPD_VDDCX_VFL] =	&cx_s2a_vfl,
+	[RPMPD_VDDMX] =		&mx_s7a_lvl,
+	[RPMPD_VDDMX_AO] =	&mx_s7a_lvl_ao,
+};
+
+static const struct rpmpd_desc sdm632_desc = {
+	.rpmpds = sdm632_rpmpds,
+	.num_pds = ARRAY_SIZE(sdm632_rpmpds),
+	.max_state = RPM_SMD_LEVEL_TURBO,
+};
+
 static struct rpmpd *sdm660_rpmpds[] = {
 	[RPMPD_VDDCX] =		&cx_rwcx0_lvl,
 	[RPMPD_VDDCX_AO] =	&cx_rwcx0_lvl_ao,
@@ -954,6 +956,7 @@ static const struct of_device_id rpmpd_match_table[] = {
 	{ .compatible = "qcom,qcm2290-rpmpd", .data = &qcm2290_desc },
 	{ .compatible = "qcom,qcs404-rpmpd", .data = &qcs404_desc },
 	{ .compatible = "qcom,qm215-rpmpd", .data = &qm215_desc },
+	{ .compatible = "qcom,sdm632-rpmpd", .data = &sdm632_desc },
 	{ .compatible = "qcom,sdm660-rpmpd", .data = &sdm660_desc },
 	{ .compatible = "qcom,shikra-rpmpd", .data = &shikra_desc },
 	{ .compatible = "qcom,sm6115-rpmpd", .data = &sm6115_desc },

-- 
2.56.0

[PATCH v3 4/7] remoteproc: qcom_q6v5_mss: Use mss as regulator for MSM8953

[Barnabás Czémán]

On MSM8953 MSS regulators is controlled using the voltages rather than
performance levels. Correct DT definition and model the MSS as a
regulator rather than a power domain

Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
 arch/arm64/boot/dts/qcom/msm8953.dtsi | 5 ++---
 drivers/remoteproc/qcom_q6v5_mss.c    | 9 ++++++++-
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi b/arch/arm64/boot/dts/qcom/msm8953.dtsi
index 753167c3f861..c7dc08858d54 100644
--- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
@@ -1451,9 +1451,8 @@ mpss: remoteproc@4080000 {
 					  "handover", "stop-ack";
 
 			power-domains = <&rpmpd MSM8953_VDDCX>,
-					<&rpmpd MSM8953_VDDMX>,
-					<&rpmpd MSM8953_VDDMD>;
-			power-domain-names = "cx", "mx","mss";
+					<&rpmpd MSM8953_VDDMX>;
+			power-domain-names = "cx", "mx";
 
 			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
 				 <&gcc GCC_MSS_Q6_BIMC_AXI_CLK>,
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 2f71ed2feff6..8f6312213e1a 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -2728,6 +2728,14 @@ static const struct rproc_hexagon_res msm8953_mss = {
 		},
 		{}
 	},
+	.active_supply = (struct qcom_mss_reg_res[]) {
+		{
+			.supply = "mss",
+			.uV = 1050000,
+			.uA = 100000,
+		},
+		{}
+	},
 	.proxy_clk_names = (char*[]){
 		"xo",
 		NULL
@@ -2741,7 +2749,6 @@ static const struct rproc_hexagon_res msm8953_mss = {
 	.proxy_pd_names = (char*[]) {
 		"cx",
 		"mx",
-		"mss",
 		NULL
 	},
 	.need_mem_protection = false,

-- 
2.56.0

[PATCH v3 5/7] dt-bindings: remoteproc: qcom,msm8916-mss-pil: Add SDM632

[Barnabás Czémán]

SDM632 MSS is very similar for MSM8953 mss the difference is
mss-supply is a pm domain on SDM632, previously SDM632 MSS
was represented by MSM8953 MSS. Correct the bindings to
described it correctly.

Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
 .../devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml     | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
index 4049157dd83d..049191cad5f8 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
@@ -27,6 +27,7 @@ properties:
           - qcom,msm8940-mss-pil
           - qcom,msm8953-mss-pil
           - qcom,msm8974-mss-pil
+          - qcom,sdm632-mss-pil
 
       - const: qcom,q6v5-pil
         description: Deprecated, prefer using qcom,msm8916-mss-pil
@@ -79,14 +80,14 @@ properties:
                      (not valid for qcom,msm8226-mss-pil, qcom,msm8926-mss-pil
                      and qcom,msm8974-mss-pil)
       - description: MSS proxy power domain (control handed over after startup)
-                     (only valid for qcom,msm8953-mss-pil)
+                     (only valid for qcom,sdm632-mss-pil)
     minItems: 1
 
   power-domain-names:
     items:
       - const: cx
       - const: mx # not valid for qcom,msm8226-mss-pil, qcom-msm8926-mss-pil and qcom,msm8974-mss-pil
-      - const: mss # only valid for qcom,msm8953-mss-pil
+      - const: mss # only valid for qcom,sdm632-mss-pil
     minItems: 1
 
   pll-supply:
@@ -219,7 +220,7 @@ allOf:
   - if:
       properties:
         compatible:
-          const: qcom,msm8953-mss-pil
+          const: qcom,sdm632-mss-pil
     then:
       properties:
         power-domains:
@@ -241,6 +242,7 @@ allOf:
               - qcom,msm8917-mss-pil
               - qcom,msm8937-mss-pil
               - qcom,msm8940-mss-pil
+              - qcom,msm8953-mss-pil
     then:
       properties:
         power-domains:
@@ -287,6 +289,7 @@ allOf:
               - qcom,msm8917-mss-pil
               - qcom,msm8937-mss-pil
               - qcom,msm8940-mss-pil
+              - qcom,msm8953-mss-pil
               - qcom,msm8974-mss-pil
     then:
       required:

-- 
2.56.0

[PATCH v3 6/7] remoteproc: qcom_q6v5_mss: Add SDM632 MSS

[Barnabás Czémán]

Add support for SDM632 mss, it is very similar to MSM8953 mss only
difference SDM632 is using mss-supply as pm domain.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
 drivers/remoteproc/qcom_q6v5_mss.c | 47 ++++++++++++++++++++++++++++++++++++--
 1 file changed, 45 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 8f6312213e1a..79510cbfcb8f 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -273,6 +273,7 @@ enum {
 	MSS_MSM8998,
 	MSS_SC7180,
 	MSS_SC7280,
+	MSS_SDM632,
 	MSS_SDM660,
 	MSS_SDM845,
 };
@@ -762,6 +763,7 @@ static int q6v5proc_reset(struct q6v5 *qproc)
 		   qproc->version == MSS_MSM8953 ||
 		   qproc->version == MSS_MSM8996 ||
 		   qproc->version == MSS_MSM8998 ||
+		   qproc->version == MSS_SDM632 ||
 		   qproc->version == MSS_SDM660) {
 
 		/* Override the ACC value if required */
@@ -772,7 +774,8 @@ static int q6v5proc_reset(struct q6v5 *qproc)
 			writel(QDSP6SS_ACC_OVERRIDE_VAL_9607,
 			       qproc->reg_base + QDSP6SS_STRAP_ACC);
 		else if (qproc->version != MSS_MSM8909 &&
-			 qproc->version != MSS_MSM8953)
+			 qproc->version != MSS_MSM8953 &&
+			 qproc->version != MSS_SDM632)
 			writel(QDSP6SS_ACC_OVERRIDE_VAL,
 			       qproc->reg_base + QDSP6SS_STRAP_ACC);
 
@@ -832,7 +835,8 @@ static int q6v5proc_reset(struct q6v5 *qproc)
 			/* Turn on L1, L2, ETB and JU memories 1 at a time */
 			if (qproc->version == MSS_MSM8940 ||
 			    qproc->version == MSS_MSM8953 ||
-			    qproc->version == MSS_MSM8996) {
+			    qproc->version == MSS_MSM8996 ||
+			    qproc->version == MSS_SDM632) {
 				mem_pwr_ctl = QDSP6SS_MEM_PWR_CTL;
 				i = 19;
 				reverse = 0;
@@ -2316,6 +2320,44 @@ static const struct rproc_hexagon_res sc7280_mss = {
 	.ssctl_id = 0x12,
 };
 
+static const struct rproc_hexagon_res sdm632_mss = {
+	.hexagon_mba_image = "mba.mbn",
+	.proxy_supply = (struct qcom_mss_reg_res[]) {
+		{
+			.supply = "pll",
+			.uA = 100000,
+		},
+		{}
+	},
+	.proxy_clk_names = (char*[]){
+		"xo",
+		NULL
+	},
+	.active_clk_names = (char*[]){
+		"iface",
+		"bus",
+		"mem",
+		NULL
+	},
+	.proxy_pd_names = (char*[]) {
+		"cx",
+		"mx",
+		"mss",
+		NULL
+	},
+	.need_mem_protection = false,
+	.need_pas_mem_setup = true,
+	.has_alt_reset = false,
+	.has_mba_logs = false,
+	.has_spare_reg = false,
+	.has_qaccept_regs = false,
+	.has_ext_bhs_reg = false,
+	.has_ext_cntl_regs = false,
+	.has_vq6 = false,
+	.version = MSS_SDM632,
+	.ssctl_id = 0x12,
+};
+
 static const struct rproc_hexagon_res sdm660_mss = {
 	.hexagon_mba_image = "mba.mbn",
 	.proxy_clk_names = (char*[]){
@@ -2923,6 +2965,7 @@ static const struct of_device_id q6v5_of_match[] = {
 	{ .compatible = "qcom,msm8998-mss-pil", .data = &msm8998_mss },
 	{ .compatible = "qcom,sc7180-mss-pil", .data = &sc7180_mss },
 	{ .compatible = "qcom,sc7280-mss-pil", .data = &sc7280_mss },
+	{ .compatible = "qcom,sdm632-mss-pil", .data = &sdm632_mss},
 	{ .compatible = "qcom,sdm660-mss-pil", .data = &sdm660_mss },
 	{ .compatible = "qcom,sdm845-mss-pil", .data = &sdm845_mss },
 	{ },

-- 
2.56.0

[PATCH v3 7/7] arm64: dts: qcom: sdm632: Correct power domains

[Barnabás Czémán]

SDM632 is using different pm domains from MSM8953 override them
where it is needed.

Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
---
 arch/arm64/boot/dts/qcom/sdm632.dtsi | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm632.dtsi b/arch/arm64/boot/dts/qcom/sdm632.dtsi
index 40d86d91b67f..5a677da5afb0 100644
--- a/arch/arm64/boot/dts/qcom/sdm632.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm632.dtsi
@@ -87,3 +87,37 @@ opp-725000000 {
 		required-opps = <&rpmpd_opp_turbo>;
 	};
 };
+
+&lpass {
+	power-domains = <&rpmpd RPMPD_VDDCX>;
+	power-domain-names = "cx";
+};
+
+&mpss {
+	compatible = "qcom,sdm632-mss-pil";
+	power-domains = <&rpmpd RPMPD_VDDCX>,
+			<&rpmpd RPMPD_VDDMX>,
+			<&rpmpd RPMPD_VDDMD>;
+	power-domain-names = "cx",
+			     "mx",
+			     "mss";
+};
+
+&rpmpd {
+	compatible = "qcom,sdm632-rpmpd";
+};
+
+&sdhc_1 {
+	power-domains = <&rpmpd RPMPD_VDDCX>;
+};
+
+&sdhc_2 {
+	power-domains = <&rpmpd RPMPD_VDDCX>;
+};
+
+&wcnss {
+	power-domains = <&rpmpd RPMPD_VDDCX>,
+			<&rpmpd RPMPD_VDDMX>;
+	power-domain-names = "cx",
+			     "mx";
+};

-- 
2.56.0

Re: [PATCH v3 1/7] dt-bindings: power: qcom-rpmpd: define RPMPD_VDDMD

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dt-bindings: RPMPD_VDDMD incorrectly shares index 5 with RPMPD_VDDMX_VFL
--

commit 12f0f9a3ab8aa298b418ea38da861f57dfeb42fb
Author: Barnabás Czémán <barnabas.czeman@mainlining.org>

dt-bindings: power: qcom-rpmpd: define RPMPD_VDDMD

This commit adds a new generic power domain index, RPMPD_VDDMD, intended
for use with SDM439 and SDM632 MSS.

> diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
> index 4371ac941f29d..beb066b3aa8c6 100644
> --- a/include/dt-bindings/power/qcom-rpmpd.h
> +++ b/include/dt-bindings/power/qcom-rpmpd.h
> @@ -15,6 +15,7 @@
>  #define RPMPD_VDDMX		3
>  #define RPMPD_VDDMX_AO		4
>  #define RPMPD_VDDMX_VFL		5
> +#define RPMPD_VDDMD		5

[Severity: High]
Will this duplicate index cause a conflict for platforms that require both
the Modem Power Domain (RPMPD_VDDMD) and the Memory Voltage Floor Domain
(RPMPD_VDDMX_VFL)?

These values map directly to designated array initializers in the provider
driver (drivers/pmdomain/qcom/rpmpd.c). If a platform descriptor array
includes both, the duplicate index 5 could cause the compiler to silently
overwrite one of the array elements, rendering that domain unusable at
runtime.

Would it be possible to assign a globally unique ID (such as the next
available index) to prevent overlap?

>  #define RPMPD_SSCCX		6
>  #define RPMPD_SSCCX_VFL		7
>  #define RPMPD_SSCMX		8

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002-sdm632-rpmpd-v3-0-95c47d0f26cf@mainlining.org?part=1

Re: [PATCH v3 3/7] pmdomain: qcom: rpmpd: Split SDM632 pm domains from MSM8953

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] pmdomain: qcom: rpmpd: DT ABI break and log spam from removed domains
- [Low] dt-bindings: power: qcom-rpmpd: duplicate ID for RPMPD_VDDMD
--

commit 05d59e980f96866ae3745192a6b683fa44f5be8e
Author: Barnabás Czémán <barnabas.czeman@mainlining.org>

pmdomain: qcom: rpmpd: Split SDM632 pm domains from MSM8953

Remove modem related pm domains from MSM8953 rpmpd because MSM8953 MSS
is using mss-supply as regulator. Split SDM632 rpmpd from MSM8953 because
SDM632 MSS is using mss-supply as pm domain.

> diff --git a/drivers/pmdomain/qcom/rpmpd.c b/drivers/pmdomain/qcom/rpmpd.c
> index 5f55fc791131a..c37a79d6bc433 100644
> --- a/drivers/pmdomain/qcom/rpmpd.c
> +++ b/drivers/pmdomain/qcom/rpmpd.c

[ ... ]

> @@ -703,8 +692,6 @@ static const struct rpmpd_desc msm8917_desc = {
>  };
>  
>  static struct rpmpd *msm8953_rpmpds[] = {
> -	[MSM8953_VDDMD] =	&md_s1a_lvl,
> -	[MSM8953_VDDMD_AO] =	&md_s1a_lvl_ao,

[Severity: High]
Does removing these entries break ABI compatibility for older device trees?

By removing MSM8953_VDDMD (0) and MSM8953_VDDMD_AO (1), these array indices
become NULL. When rpmpd_probe() iterates over the array, it will encounter
these empty entries and trigger a warning:

	if (!rpmpds[i]) {
		dev_warn(&pdev->dev, "rpmpds[] with empty entry at index=%d\n",
			 i);
		continue;
	}

Will this cause unconditional boot log warnings on MSM8953 systems?

Additionally, if older device trees still reference <&rpmpd MSM8953_VDDMD>,
would of_genpd_xlate_onecell() return an error and cause consumer drivers
to indefinitely defer probing?

>  	[MSM8953_VDDCX] =	&cx_s2a_lvl,
>  	[MSM8953_VDDCX_AO] =	&cx_s2a_lvl_ao,
>  	[MSM8953_VDDCX_VFL] =	&cx_s2a_vfl,

[ ... ]

> @@ -844,6 +831,21 @@ static const struct rpmpd_desc qm215_desc = {
>  	.max_state = RPM_SMD_LEVEL_TURBO,
>  };
>  
> +static struct rpmpd *sdm632_rpmpds[] = {
> +	[RPMPD_VDDMD] =		&md_s1a_lvl,

[Severity: Low]
Is there a conflicting index assignment introduced by using RPMPD_VDDMD here?

Looking at include/dt-bindings/power/qcom-rpmpd.h, RPMPD_VDDMD is defined
as 5, which is the exact same ID assigned to RPMPD_VDDMX_VFL:

#define RPMPD_VDDMX_VFL		5
#define RPMPD_VDDMD		5

While SDM632 does not use VDDMX_VFL, could having two distinct generic PM
domains share the same integer ID break the uniqueness guarantee of generic
bindings and cause silent overwrites if a future SoC initializes both?

> +	[RPMPD_VDDCX] =		&cx_s2a_lvl,
> +	[RPMPD_VDDCX_AO] =	&cx_s2a_lvl_ao,
> +	[RPMPD_VDDCX_VFL] =	&cx_s2a_vfl,
> +	[RPMPD_VDDMX] =		&mx_s7a_lvl,
> +	[RPMPD_VDDMX_AO] =	&mx_s7a_lvl_ao,
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002-sdm632-rpmpd-v3-0-95c47d0f26cf@mainlining.org?part=3

Re: [PATCH v3 7/7] arm64: dts: qcom: sdm632: Correct power domains

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] remoteproc: qcom_q6v5_mss: probe failure due to missing mss-supply for MSM8953
- [Medium] dt-bindings: power: qcom-rpmpd: RPMPD_VDDMD conflicts with RPMPD_VDDMX_VFL
--

commit f5ae81644790ad18298d9d35e487c425be535c4d
Author: Barnabás Czémán <barnabas.czeman@mainlining.org>

arm64: dts: qcom: sdm632: Correct power domains

This commit adds power domain overrides for the SDM632. It specifies 
domains for various subsystems, acknowledging that SDM632 uses different 
power domains from the MSM8953 it is based on.

> diff --git a/arch/arm64/boot/dts/qcom/sdm632.dtsi b/arch/arm64/boot/dts/qcom/sdm632.dtsi
> index 40d86d91b67fa..5a677da5afb01 100644
> --- a/arch/arm64/boot/dts/qcom/sdm632.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm632.dtsi
[ ... ]
> @@ -87,3 +87,37 @@ opp-725000000 {
[ ... ]
> +&mpss {
> +	compatible = "qcom,sdm632-mss-pil";
> +	power-domains = <&rpmpd RPMPD_VDDCX>,
> +			<&rpmpd RPMPD_VDDMX>,
> +			<&rpmpd RPMPD_VDDMD>;

[Severity: Medium]
Does the use of RPMPD_VDDMD here conflict with RPMPD_VDDMX_VFL?

In include/dt-bindings/power/qcom-rpmpd.h, both are defined as 5:

#define RPMPD_VDDMX_VFL         5
#define RPMPD_VDDMD             5

A SoC that has both domains would have a conflict in the provider array,
or a user specifying RPMPD_VDDMD on a board that has VDDMX_VFL will scale
the wrong regulator.

[Severity: High]
While overriding the domains for SDM632 here, does this leave MSM8953 broken?

The mss power domain was removed in arch/arm64/boot/dts/qcom/msm8953.dtsi
at the mpss node, but the required mss-supply was not added.

The MSS driver now requires an mss-supply active regulator for MSM8953.
Consequently, the driver falls back to a dummy regulator.
When q6v5_regulator_enable() attempts to set 1.05V, regulator_set_voltage()
returns -EINVAL on the dummy regulator, causing a fatal start failure.

Furthermore, this breaks backward compatibility for older MSM8953 DTBs
because the MSM8953_VDDMD power domain was removed from the
msm8953_rpmpds[] provider array, causing genpd attach to fail.

> +	power-domain-names = "cx",
> +			     "mx",
> +			     "mss";
> +};
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002-sdm632-rpmpd-v3-0-95c47d0f26cf@mainlining.org?part=7

Re: [PATCH v3 4/7] remoteproc: qcom_q6v5_mss: Use mss as regulator for MSM8953

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] remoteproc: qcom_q6v5_mss: universal probe failure on MSM8953 due to missing mss-supply
--

commit 726993c6f2fb948fb92664f68a46c91f069ed760
Author: Barnabás Czémán <barnabas.czeman@mainlining.org>

remoteproc: qcom_q6v5_mss: Use mss as regulator for MSM8953

The commit modifies the MSM8953 MSS configuration to use an "mss" regulator
rather than a power domain. The device tree definition is updated to remove
the power domain, and the driver is updated to expect the new active supply.

> diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi b/arch/arm64/boot/dts/qcom/msm8953.dtsi
> index 753167c3f8619..c7dc08858d542 100644
> --- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
> @@ -1451,9 +1451,8 @@ mpss: remoteproc@4080000 {
>  					  "handover", "stop-ack";
>  
>  			power-domains = <&rpmpd MSM8953_VDDCX>,
> -					<&rpmpd MSM8953_VDDMX>,
> -					<&rpmpd MSM8953_VDDMD>;
> -			power-domain-names = "cx", "mx","mss";
> +					<&rpmpd MSM8953_VDDMX>;
> +			power-domain-names = "cx", "mx";

[Severity: High]
The old power domain is removed but the required mss-supply replacement to power
the MSS hardware is missing.

Is it expected that mss-supply is missing here?

Without mss-supply in the device tree, devm_regulator_get(dev, "mss") will
return either -ENODEV or a dummy regulator.

>  
>  			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
>  				 <&gcc GCC_MSS_Q6_BIMC_AXI_CLK>,

[ ... ]

> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index 2f71ed2feff69..8f6312213e1ab 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -2728,6 +2728,14 @@ static const struct rproc_hexagon_res msm8953_mss = {
>  		},
>  		{}
>  	},
> +	.active_supply = (struct qcom_mss_reg_res[]) {
> +		{
> +			.supply = "mss",
> +			.uV = 1050000,
> +			.uA = 100000,
> +		},

[Severity: High]
This makes the "mss" regulator mandatory and strictly requires a specific
voltage to be set.

Since a dummy regulator lacks voltage-setting operations, an unconditional call
to regulator_set_voltage() in q6v5_regulator_enable() will return -EINVAL,
causing the driver to unconditionally fail to probe:

drivers/remoteproc/qcom_q6v5_mss.c:q6v5_regulator_enable() {
    ...
			ret = regulator_set_voltage(regs[i].reg,
					regs[i].uV, INT_MAX);
			if (ret) {
    ...
}

Could this cause the modem driver to fail probing, making the modem unusable
on all MSM8953 devices (and SDM632 devices due to later patches in the series)?

> +		{}
> +	},

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002-sdm632-rpmpd-v3-0-95c47d0f26cf@mainlining.org?part=4

Re: [PATCH v3 5/7] dt-bindings: remoteproc: qcom,msm8916-mss-pil: Add SDM632

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dt-bindings: remoteproc: msm8953 device trees lack newly required mss-supply
--

commit 9361957c0df3f4f2db804dba4f7e53e9096f9d42
Author: Barnabás Czémán <barnabas.czeman@mainlining.org>

dt-bindings: remoteproc: qcom,msm8916-mss-pil: Add SDM632

This commit updates the dt-bindings for the MSM8916 MSS PIL to include
SDM632. It adjusts the schemas because SDM632 is similar to MSM8953 but
uses a power domain for the mss-supply instead of a regulator.

> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> index 4049157dd83d7..049191cad5f83 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml

[ ... ]

> @@ -287,6 +289,7 @@ allOf:
>                - qcom,msm8917-mss-pil
>                - qcom,msm8937-mss-pil
>                - qcom,msm8940-mss-pil
> +              - qcom,msm8953-mss-pil
>                - qcom,msm8974-mss-pil
>      then:
>        required:
>          - mss-supply

[Severity: High]
Does making mss-supply a required property for msm8953 break existing
device trees?

Looking at existing in-tree device trees for msm8953, such as
arch/arm64/boot/dts/qcom/msm8953.dtsi, the mpss node uses the compatible
string but does not provide an mss-supply property:

		mpss: remoteproc@4080000 {
			compatible = "qcom,msm8953-mss-pil";
			...
			power-domains = <&rpmpd MSM8953_VDDCX>,
					<&rpmpd MSM8953_VDDMX>;
			power-domain-names = "cx", "mx";

Earlier patches in this series removed the MSM8953_VDDMD power domain and
updated the driver to request an mss regulator, but the mss-supply
property was not actually added to the msm8953 device tree nodes.

Because the property is missing from the device tree nodes, merging this
series will cause schema validation to fail for all msm8953 boards.

Furthermore, at runtime, the qcom_q6v5_mss driver will silently receive a
dummy regulator for mss. Since the actual hardware regulator is never
enabled, will this cause the modem to silently fail to boot on msm8953
devices?

This issue does not appear to be resolved by any subsequent patches in the
series.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002-sdm632-rpmpd-v3-0-95c47d0f26cf@mainlining.org?part=5

Re: [PATCH v3 1/7] dt-bindings: power: qcom-rpmpd: define RPMPD_VDDMD

[Krzysztof Kozlowski]

On Fri, Oct 02, 2026 at 12:38:29AM +0200, Barnabás Czémán wrote:
> Define RPMPD_VDDMD can be used for SDM439 and SDM632 MSS.

There is no sdm439 RPMPD... The SDM632 is added later and bindings
header come with the compatible patch. Squash these.

> 
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
>  include/dt-bindings/power/qcom-rpmpd.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
> index 4371ac941f29..beb066b3aa8c 100644
> --- a/include/dt-bindings/power/qcom-rpmpd.h
> +++ b/include/dt-bindings/power/qcom-rpmpd.h
> @@ -15,6 +15,7 @@
>  #define RPMPD_VDDMX		3
>  #define RPMPD_VDDMX_AO		4
>  #define RPMPD_VDDMX_VFL		5
> +#define RPMPD_VDDMD		5

Problem is that it is platform specific and comment in that file says
"don't do it" yet you do it.

So the device has nbo MX? Why commit msg is silent on this? Explains
not much except repeating the diff and referencing users which are
almost obvious if this is properly squashed.

Best regards,
Krzysztof

Re: [PATCH v3 5/7] dt-bindings: remoteproc: qcom,msm8916-mss-pil: Add SDM632

[Krzysztof Kozlowski]

On Fri, Oct 02, 2026 at 12:38:33AM +0200, Barnabás Czémán wrote:
> SDM632 MSS is very similar for MSM8953 mss the difference is
> mss-supply is a pm domain on SDM632, previously SDM632 MSS
> was represented by MSM8953 MSS. Correct the bindings to
> described it correctly.
> 
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
>  .../devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml     | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> index 4049157dd83d..049191cad5f8 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> @@ -27,6 +27,7 @@ properties:
>            - qcom,msm8940-mss-pil
>            - qcom,msm8953-mss-pil
>            - qcom,msm8974-mss-pil
> +          - qcom,sdm632-mss-pil
>  
>        - const: qcom,q6v5-pil
>          description: Deprecated, prefer using qcom,msm8916-mss-pil
> @@ -79,14 +80,14 @@ properties:
>                       (not valid for qcom,msm8226-mss-pil, qcom,msm8926-mss-pil
>                       and qcom,msm8974-mss-pil)
>        - description: MSS proxy power domain (control handed over after startup)
> -                     (only valid for qcom,msm8953-mss-pil)
> +                     (only valid for qcom,sdm632-mss-pil)
>      minItems: 1
>  
>    power-domain-names:
>      items:
>        - const: cx
>        - const: mx # not valid for qcom,msm8226-mss-pil, qcom-msm8926-mss-pil and qcom,msm8974-mss-pil
> -      - const: mss # only valid for qcom,msm8953-mss-pil
> +      - const: mss # only valid for qcom,sdm632-mss-pil

So not valid for msm8953, but msm8953 has it, so you just introduced new
warnings, no?

Anyway, changing existing device needs its own rationale and usually own
commit.

Best regards,
Krzysztof

Re: [PATCH v3 1/7] dt-bindings: power: qcom-rpmpd: define RPMPD_VDDMD

[Barnabás Czémán]

On 2026-10-02 11:57, Krzysztof Kozlowski wrote:
> On Fri, Oct 02, 2026 at 12:38:29AM +0200, Barnabás Czémán wrote:
>> Define RPMPD_VDDMD can be used for SDM439 and SDM632 MSS.
> 
> There is no sdm439 RPMPD... The SDM632 is added later and bindings
There will be.
> header come with the compatible patch. Squash these.
You have previously commented how that is connected to the indices.
> 
>> 
>> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
>> ---
>>  include/dt-bindings/power/qcom-rpmpd.h | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/include/dt-bindings/power/qcom-rpmpd.h 
>> b/include/dt-bindings/power/qcom-rpmpd.h
>> index 4371ac941f29..beb066b3aa8c 100644
>> --- a/include/dt-bindings/power/qcom-rpmpd.h
>> +++ b/include/dt-bindings/power/qcom-rpmpd.h
>> @@ -15,6 +15,7 @@
>>  #define RPMPD_VDDMX		3
>>  #define RPMPD_VDDMX_AO		4
>>  #define RPMPD_VDDMX_VFL		5
>> +#define RPMPD_VDDMD		5
> 
> Problem is that it is platform specific and comment in that file says
> "don't do it" yet you do it.
It is not completely platform specific and if you have check the 
previous
reviews Dmitry was asking me to define it. If i set it 10 what will be
very safe for every platform i will get warning messages.
By the way 5 is fine for SDM429, SDM439 and SDM632.
> 
> So the device has nbo MX? Why commit msg is silent on this? Explains
> not much except repeating the diff and referencing users which are
> almost obvious if this is properly squashed.
> 
> Best regards,
> Krzysztof

Re: [PATCH v3 5/7] dt-bindings: remoteproc: qcom,msm8916-mss-pil: Add SDM632

[Barnabás Czémán]

On 2026-10-02 12:01, Krzysztof Kozlowski wrote:
> On Fri, Oct 02, 2026 at 12:38:33AM +0200, Barnabás Czémán wrote:
>> SDM632 MSS is very similar for MSM8953 mss the difference is
>> mss-supply is a pm domain on SDM632, previously SDM632 MSS
>> was represented by MSM8953 MSS. Correct the bindings to
>> described it correctly.
>> 
>> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
>> ---
>>  .../devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml     | 9 
>> ++++++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>> 
>> diff --git 
>> a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml 
>> b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
>> index 4049157dd83d..049191cad5f8 100644
>> --- 
>> a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
>> +++ 
>> b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
>> @@ -27,6 +27,7 @@ properties:
>>            - qcom,msm8940-mss-pil
>>            - qcom,msm8953-mss-pil
>>            - qcom,msm8974-mss-pil
>> +          - qcom,sdm632-mss-pil
>> 
>>        - const: qcom,q6v5-pil
>>          description: Deprecated, prefer using qcom,msm8916-mss-pil
>> @@ -79,14 +80,14 @@ properties:
>>                       (not valid for qcom,msm8226-mss-pil, 
>> qcom,msm8926-mss-pil
>>                       and qcom,msm8974-mss-pil)
>>        - description: MSS proxy power domain (control handed over 
>> after startup)
>> -                     (only valid for qcom,msm8953-mss-pil)
>> +                     (only valid for qcom,sdm632-mss-pil)
>>      minItems: 1
>> 
>>    power-domain-names:
>>      items:
>>        - const: cx
>>        - const: mx # not valid for qcom,msm8226-mss-pil, 
>> qcom-msm8926-mss-pil and qcom,msm8974-mss-pil
>> -      - const: mss # only valid for qcom,msm8953-mss-pil
>> +      - const: mss # only valid for qcom,sdm632-mss-pil
> 
> So not valid for msm8953, but msm8953 has it, so you just introduced 
> new
> warnings, no?
It was never valid for MSM8953.
> 
> Anyway, changing existing device needs its own rationale and usually 
> own
> commit.
> 
> Best regards,
> Krzysztof

Re: [PATCH v3 1/7] dt-bindings: power: qcom-rpmpd: define RPMPD_VDDMD

[Dmitry Baryshkov]

On Fri, Oct 02, 2026 at 04:04:50PM +0200, Barnabás Czémán wrote:
> On 2026-10-02 11:57, Krzysztof Kozlowski wrote:
> > On Fri, Oct 02, 2026 at 12:38:29AM +0200, Barnabás Czémán wrote:
> > > Define RPMPD_VDDMD can be used for SDM439 and SDM632 MSS.
> > 
> > There is no sdm439 RPMPD... The SDM632 is added later and bindings
> There will be.
> > header come with the compatible patch. Squash these.
> You have previously commented how that is connected to the indices.
> > 
> > > 
> > > Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> > > ---
> > >  include/dt-bindings/power/qcom-rpmpd.h | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/include/dt-bindings/power/qcom-rpmpd.h
> > > b/include/dt-bindings/power/qcom-rpmpd.h
> > > index 4371ac941f29..beb066b3aa8c 100644
> > > --- a/include/dt-bindings/power/qcom-rpmpd.h
> > > +++ b/include/dt-bindings/power/qcom-rpmpd.h
> > > @@ -15,6 +15,7 @@
> > >  #define RPMPD_VDDMX		3
> > >  #define RPMPD_VDDMX_AO		4
> > >  #define RPMPD_VDDMX_VFL		5
> > > +#define RPMPD_VDDMD		5
> > 
> > Problem is that it is platform specific and comment in that file says
> > "don't do it" yet you do it.
> It is not completely platform specific and if you have check the previous
> reviews Dmitry was asking me to define it. If i set it 10 what will be
> very safe for every platform i will get warning messages.
> By the way 5 is fine for SDM429, SDM439 and SDM632.

It's not fine, if we once get a platform which has both VDDMX_VFL and
VDDMD. THe whole point of having this generic RPMPD_ list is to have a
set of indices which can be used by any new platform being supported.
So, indeed, 10 is a correct value here.

> > 
> > So the device has nbo MX? Why commit msg is silent on this? Explains
> > not much except repeating the diff and referencing users which are
> > almost obvious if this is properly squashed.

-- 
With best wishes
Dmitry

Re: [PATCH v3 2/7] dt-bindings: power: qcom,rpmpd: Add SDM632

[Dmitry Baryshkov]

On Fri, Oct 02, 2026 at 12:38:30AM +0200, Barnabás Czémán wrote:
> Add compatible for SDM632 RPM.

Please write something more useful. For example, why do we need a new
compatible, what's the difference from MSM8953, etc.

> 
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
>  Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> index a70bfacbc5d1..4b263a982fca 100644
> --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
> @@ -51,6 +51,7 @@ properties:
>            - qcom,sc7280-rpmhpd
>            - qcom,sc8180x-rpmhpd
>            - qcom,sc8280xp-rpmhpd
> +          - qcom,sdm632-rpmpd
>            - qcom,sdm660-rpmpd
>            - qcom,sdm670-rpmhpd
>            - qcom,sdm845-rpmhpd
> 
> -- 
> 2.56.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH v3 3/7] pmdomain: qcom: rpmpd: Split SDM632 pm domains from MSM8953

[Dmitry Baryshkov]

On Fri, Oct 02, 2026 at 12:38:31AM +0200, Barnabás Czémán wrote:
> Remove modem related pm domains from MSM8953 rpmpd because MSM8953 MSS
> is using mss-supply as regulator.
> Split SDM632 rpmpd from MSM8953 because SDM632 MSS is using mss-supply
> as pm domain.
> 
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
>  drivers/pmdomain/qcom/rpmpd.c | 29 ++++++++++++++++-------------
>  1 file changed, 16 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/pmdomain/qcom/rpmpd.c b/drivers/pmdomain/qcom/rpmpd.c
> index 5f55fc791131..c37a79d6bc43 100644
> --- a/drivers/pmdomain/qcom/rpmpd.c
> +++ b/drivers/pmdomain/qcom/rpmpd.c
> @@ -503,19 +503,8 @@ static struct rpmpd md_s1a_corner_ao = {
>  	.key = KEY_CORNER,
>  };
>  
> -static struct rpmpd md_s1a_lvl_ao;

I'd rather see #define RPMPD_VDDMD_AO unless you have a good reason to
drop it.

>  static struct rpmpd md_s1a_lvl = {
>  	.pd = { .name = "md", },
> -	.peer = &md_s1a_lvl_ao,
> -	.res_type = RPMPD_SMPA,
> -	.res_id = 1,
> -	.key = KEY_LEVEL,
> -};
> -
> -static struct rpmpd md_s1a_lvl_ao = {
> -	.pd = { .name = "md_ao", },
> -	.peer = &md_s1a_lvl,
> -	.active_only = true,
>  	.res_type = RPMPD_SMPA,
>  	.res_id = 1,
>  	.key = KEY_LEVEL,
> @@ -703,8 +692,6 @@ static const struct rpmpd_desc msm8917_desc = {
>  };
>  
>  static struct rpmpd *msm8953_rpmpds[] = {
> -	[MSM8953_VDDMD] =	&md_s1a_lvl,
> -	[MSM8953_VDDMD_AO] =	&md_s1a_lvl_ao,
>  	[MSM8953_VDDCX] =	&cx_s2a_lvl,
>  	[MSM8953_VDDCX_AO] =	&cx_s2a_lvl_ao,
>  	[MSM8953_VDDCX_VFL] =	&cx_s2a_vfl,
> @@ -844,6 +831,21 @@ static const struct rpmpd_desc qm215_desc = {
>  	.max_state = RPM_SMD_LEVEL_TURBO,
>  };
>  
> +static struct rpmpd *sdm632_rpmpds[] = {
> +	[RPMPD_VDDMD] =		&md_s1a_lvl,
> +	[RPMPD_VDDCX] =		&cx_s2a_lvl,
> +	[RPMPD_VDDCX_AO] =	&cx_s2a_lvl_ao,
> +	[RPMPD_VDDCX_VFL] =	&cx_s2a_vfl,
> +	[RPMPD_VDDMX] =		&mx_s7a_lvl,
> +	[RPMPD_VDDMX_AO] =	&mx_s7a_lvl_ao,
> +};
> +
> +static const struct rpmpd_desc sdm632_desc = {
> +	.rpmpds = sdm632_rpmpds,
> +	.num_pds = ARRAY_SIZE(sdm632_rpmpds),
> +	.max_state = RPM_SMD_LEVEL_TURBO,
> +};
> +
>  static struct rpmpd *sdm660_rpmpds[] = {
>  	[RPMPD_VDDCX] =		&cx_rwcx0_lvl,
>  	[RPMPD_VDDCX_AO] =	&cx_rwcx0_lvl_ao,
> @@ -954,6 +956,7 @@ static const struct of_device_id rpmpd_match_table[] = {
>  	{ .compatible = "qcom,qcm2290-rpmpd", .data = &qcm2290_desc },
>  	{ .compatible = "qcom,qcs404-rpmpd", .data = &qcs404_desc },
>  	{ .compatible = "qcom,qm215-rpmpd", .data = &qm215_desc },
> +	{ .compatible = "qcom,sdm632-rpmpd", .data = &sdm632_desc },
>  	{ .compatible = "qcom,sdm660-rpmpd", .data = &sdm660_desc },
>  	{ .compatible = "qcom,shikra-rpmpd", .data = &shikra_desc },
>  	{ .compatible = "qcom,sm6115-rpmpd", .data = &sm6115_desc },
> 
> -- 
> 2.56.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH v3 4/7] remoteproc: qcom_q6v5_mss: Use mss as regulator for MSM8953

[Dmitry Baryshkov]

On Fri, Oct 02, 2026 at 12:38:32AM +0200, Barnabás Czémán wrote:
> On MSM8953 MSS regulators is controlled using the voltages rather than
> performance levels. Correct DT definition and model the MSS as a
> regulator rather than a power domain
> 
> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
> ---
>  arch/arm64/boot/dts/qcom/msm8953.dtsi | 5 ++---
>  drivers/remoteproc/qcom_q6v5_mss.c    | 9 ++++++++-

Two separate patches. Yes, one will be broken without another. Write
this in the commit message and explain why you can't provide backwards
compatibility. Don't forget Fixes tags (or explain the lack of them).
But I think it applies to the rest of the series too.

>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi b/arch/arm64/boot/dts/qcom/msm8953.dtsi
> index 753167c3f861..c7dc08858d54 100644
> --- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
> @@ -1451,9 +1451,8 @@ mpss: remoteproc@4080000 {
>  					  "handover", "stop-ack";
>  
>  			power-domains = <&rpmpd MSM8953_VDDCX>,
> -					<&rpmpd MSM8953_VDDMX>,
> -					<&rpmpd MSM8953_VDDMD>;
> -			power-domain-names = "cx", "mx","mss";
> +					<&rpmpd MSM8953_VDDMX>;
> +			power-domain-names = "cx", "mx";
>  
>  			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
>  				 <&gcc GCC_MSS_Q6_BIMC_AXI_CLK>,
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index 2f71ed2feff6..8f6312213e1a 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -2728,6 +2728,14 @@ static const struct rproc_hexagon_res msm8953_mss = {
>  		},
>  		{}
>  	},
> +	.active_supply = (struct qcom_mss_reg_res[]) {
> +		{
> +			.supply = "mss",
> +			.uV = 1050000,
> +			.uA = 100000,
> +		},
> +		{}
> +	},
>  	.proxy_clk_names = (char*[]){
>  		"xo",
>  		NULL
> @@ -2741,7 +2749,6 @@ static const struct rproc_hexagon_res msm8953_mss = {
>  	.proxy_pd_names = (char*[]) {
>  		"cx",
>  		"mx",
> -		"mss",
>  		NULL
>  	},
>  	.need_mem_protection = false,
> 
> -- 
> 2.56.0
> 

-- 
With best wishes
Dmitry

Re: [PATCH v3 4/7] remoteproc: qcom_q6v5_mss: Use mss as regulator for MSM8953

[Barnabás Czémán]

On 2026-10-05 09:06, Dmitry Baryshkov wrote:
> On Fri, Oct 02, 2026 at 12:38:32AM +0200, Barnabás Czémán wrote:
>> On MSM8953 MSS regulators is controlled using the voltages rather than
>> performance levels. Correct DT definition and model the MSS as a
>> regulator rather than a power domain
>> 
>> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
>> ---
>>  arch/arm64/boot/dts/qcom/msm8953.dtsi | 5 ++---
>>  drivers/remoteproc/qcom_q6v5_mss.c    | 9 ++++++++-
> 
> Two separate patches. Yes, one will be broken without another. Write
In the first revisions i was asked to squash it.
> this in the commit message and explain why you can't provide backwards
> compatibility. Don't forget Fixes tags (or explain the lack of them).
> But I think it applies to the rest of the series too.
> 
>>  2 files changed, 10 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi 
>> b/arch/arm64/boot/dts/qcom/msm8953.dtsi
>> index 753167c3f861..c7dc08858d54 100644
>> --- a/arch/arm64/boot/dts/qcom/msm8953.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
>> @@ -1451,9 +1451,8 @@ mpss: remoteproc@4080000 {
>>  					  "handover", "stop-ack";
>> 
>>  			power-domains = <&rpmpd MSM8953_VDDCX>,
>> -					<&rpmpd MSM8953_VDDMX>,
>> -					<&rpmpd MSM8953_VDDMD>;
>> -			power-domain-names = "cx", "mx","mss";
>> +					<&rpmpd MSM8953_VDDMX>;
>> +			power-domain-names = "cx", "mx";
>> 
>>  			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
>>  				 <&gcc GCC_MSS_Q6_BIMC_AXI_CLK>,
>> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
>> b/drivers/remoteproc/qcom_q6v5_mss.c
>> index 2f71ed2feff6..8f6312213e1a 100644
>> --- a/drivers/remoteproc/qcom_q6v5_mss.c
>> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
>> @@ -2728,6 +2728,14 @@ static const struct rproc_hexagon_res 
>> msm8953_mss = {
>>  		},
>>  		{}
>>  	},
>> +	.active_supply = (struct qcom_mss_reg_res[]) {
>> +		{
>> +			.supply = "mss",
>> +			.uV = 1050000,
>> +			.uA = 100000,
>> +		},
>> +		{}
>> +	},
>>  	.proxy_clk_names = (char*[]){
>>  		"xo",
>>  		NULL
>> @@ -2741,7 +2749,6 @@ static const struct rproc_hexagon_res 
>> msm8953_mss = {
>>  	.proxy_pd_names = (char*[]) {
>>  		"cx",
>>  		"mx",
>> -		"mss",
>>  		NULL
>>  	},
>>  	.need_mem_protection = false,
>> 
>> --
>> 2.56.0
>> 

Re: [PATCH v3 3/7] pmdomain: qcom: rpmpd: Split SDM632 pm domains from MSM8953

[Barnabás Czémán]

On 2026-10-05 09:04, Dmitry Baryshkov wrote:
> On Fri, Oct 02, 2026 at 12:38:31AM +0200, Barnabás Czémán wrote:
>> Remove modem related pm domains from MSM8953 rpmpd because MSM8953 MSS
>> is using mss-supply as regulator.
>> Split SDM632 rpmpd from MSM8953 because SDM632 MSS is using mss-supply
>> as pm domain.
>> 
>> Signed-off-by: Barnabás Czémán <barnabas.czeman@mainlining.org>
>> ---
>>  drivers/pmdomain/qcom/rpmpd.c | 29 ++++++++++++++++-------------
>>  1 file changed, 16 insertions(+), 13 deletions(-)
>> 
>> diff --git a/drivers/pmdomain/qcom/rpmpd.c 
>> b/drivers/pmdomain/qcom/rpmpd.c
>> index 5f55fc791131..c37a79d6bc43 100644
>> --- a/drivers/pmdomain/qcom/rpmpd.c
>> +++ b/drivers/pmdomain/qcom/rpmpd.c
>> @@ -503,19 +503,8 @@ static struct rpmpd md_s1a_corner_ao = {
>>  	.key = KEY_CORNER,
>>  };
>> 
>> -static struct rpmpd md_s1a_lvl_ao;
> 
> I'd rather see #define RPMPD_VDDMD_AO unless you have a good reason to
> drop it.
There is no AO defined here: 
https://git.codelinaro.org/clo/la/kernel/msm-4.9/-/blob/LA.UM.10.6.2.c26-01500-89xx.0/arch/arm64/boot/dts/qcom/msm8953-regulator.dtsi#L19
https://git.codelinaro.org/clo/la/kernel/msm-4.9/-/blob/LA.UM.10.6.2.c26-01500-89xx.0/arch/arm64/boot/dts/qcom/sdm439-regulator.dtsi#L19
> 
>>  static struct rpmpd md_s1a_lvl = {
>>  	.pd = { .name = "md", },
>> -	.peer = &md_s1a_lvl_ao,
>> -	.res_type = RPMPD_SMPA,
>> -	.res_id = 1,
>> -	.key = KEY_LEVEL,
>> -};
>> -
>> -static struct rpmpd md_s1a_lvl_ao = {
>> -	.pd = { .name = "md_ao", },
>> -	.peer = &md_s1a_lvl,
>> -	.active_only = true,
>>  	.res_type = RPMPD_SMPA,
>>  	.res_id = 1,
>>  	.key = KEY_LEVEL,
>> @@ -703,8 +692,6 @@ static const struct rpmpd_desc msm8917_desc = {
>>  };
>> 
>>  static struct rpmpd *msm8953_rpmpds[] = {
>> -	[MSM8953_VDDMD] =	&md_s1a_lvl,
>> -	[MSM8953_VDDMD_AO] =	&md_s1a_lvl_ao,
>>  	[MSM8953_VDDCX] =	&cx_s2a_lvl,
>>  	[MSM8953_VDDCX_AO] =	&cx_s2a_lvl_ao,
>>  	[MSM8953_VDDCX_VFL] =	&cx_s2a_vfl,
>> @@ -844,6 +831,21 @@ static const struct rpmpd_desc qm215_desc = {
>>  	.max_state = RPM_SMD_LEVEL_TURBO,
>>  };
>> 
>> +static struct rpmpd *sdm632_rpmpds[] = {
>> +	[RPMPD_VDDMD] =		&md_s1a_lvl,
>> +	[RPMPD_VDDCX] =		&cx_s2a_lvl,
>> +	[RPMPD_VDDCX_AO] =	&cx_s2a_lvl_ao,
>> +	[RPMPD_VDDCX_VFL] =	&cx_s2a_vfl,
>> +	[RPMPD_VDDMX] =		&mx_s7a_lvl,
>> +	[RPMPD_VDDMX_AO] =	&mx_s7a_lvl_ao,
>> +};
>> +
>> +static const struct rpmpd_desc sdm632_desc = {
>> +	.rpmpds = sdm632_rpmpds,
>> +	.num_pds = ARRAY_SIZE(sdm632_rpmpds),
>> +	.max_state = RPM_SMD_LEVEL_TURBO,
>> +};
>> +
>>  static struct rpmpd *sdm660_rpmpds[] = {
>>  	[RPMPD_VDDCX] =		&cx_rwcx0_lvl,
>>  	[RPMPD_VDDCX_AO] =	&cx_rwcx0_lvl_ao,
>> @@ -954,6 +956,7 @@ static const struct of_device_id 
>> rpmpd_match_table[] = {
>>  	{ .compatible = "qcom,qcm2290-rpmpd", .data = &qcm2290_desc },
>>  	{ .compatible = "qcom,qcs404-rpmpd", .data = &qcs404_desc },
>>  	{ .compatible = "qcom,qm215-rpmpd", .data = &qm215_desc },
>> +	{ .compatible = "qcom,sdm632-rpmpd", .data = &sdm632_desc },
>>  	{ .compatible = "qcom,sdm660-rpmpd", .data = &sdm660_desc },
>>  	{ .compatible = "qcom,shikra-rpmpd", .data = &shikra_desc },
>>  	{ .compatible = "qcom,sm6115-rpmpd", .data = &sm6115_desc },
>> 
>> --
>> 2.56.0
>>