LKML Archive on lore.kernel.org
 help / color / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
						download: 
* [PATCH v4 4/8] remoteproc: qcom: q6v5-mss: Add missing clocks for MSM8996
      [irrelevant] <20181228185307.25645-1-sibis@codeaurora.org>
@ 2018-12-28 18:53 ` Sibi Sankar
  2018-12-28 18:53 ` [PATCH v4 5/8] dt-bindings: remoteproc: qcom: Fixup regulator dependencies Sibi Sankar
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2018-12-28 18:53 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, david.brown, dianders
  Cc: linux-arm-msm, linux-soc, devicetree, linux-kernel, tsoni, clew,
	akdwived, mark.rutland, linux-remoteproc, evgreen, briannorris,
	sricharan, Sibi Sankar

Proxy vote for QDSS clock and remove vote on handover interrupt
to provide MSS PBL with access to STM hardware registers during
boot. Add "snoc_axi" and "mnoc_axi" to the active clock list.
Rename "gpll0_mss_clk" to "gpll0_mss" for consistency across SoCs.

Fixes: 9f058fa2efb1 ("remoteproc: qcom: Add support for mss remoteproc
on msm8996")

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---

v4:
  * Rename "gpll0_mss_clk" to "gpll0_mss" for consistency across
    SoCs

 drivers/remoteproc/qcom_q6v5_mss.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 01be7314e176..cb5f0d3ac6a3 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1398,13 +1398,16 @@ static const struct rproc_hexagon_res msm8996_mss = {
 	.proxy_clk_names = (char*[]){
 			"xo",
 			"pnoc",
+			"qdss",
 			NULL
 	},
 	.active_clk_names = (char*[]){
 			"iface",
 			"bus",
 			"mem",
-			"gpll0_mss_clk",
+			"gpll0_mss",
+			"snoc_axi",
+			"mnoc_axi",
 			NULL
 	},
 	.need_mem_protection = true,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 22%]

* [PATCH v4 5/8] dt-bindings: remoteproc: qcom: Fixup regulator dependencies
      [irrelevant] <20181228185307.25645-1-sibis@codeaurora.org>
  2018-12-28 18:53 ` [PATCH v4 4/8] remoteproc: qcom: q6v5-mss: Add missing clocks for MSM8996 Sibi Sankar
@ 2018-12-28 18:53 ` Sibi Sankar
  2018-12-28 18:53 ` [PATCH v4 6/8] remoteproc: qcom: q6v5-mss: Add missing regulator for MSM8996 Sibi Sankar
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2018-12-28 18:53 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, david.brown, dianders
  Cc: linux-arm-msm, linux-soc, devicetree, linux-kernel, tsoni, clew,
	akdwived, mark.rutland, linux-remoteproc, evgreen, briannorris,
	sricharan, Sibi Sankar

Fixup regulator supply dependencies for Q6V5 MSS on MSM996 SoCs.

Fixes: 9f058fa2efb1 ("remoteproc: qcom: Add support for mss remoteproc
on msm8996")

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---

v3:
  * Fixup dt-binding documentation as suggested by Doug

 .../bindings/remoteproc/qcom,q6v5.txt         | 21 +++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
index bba3d6be71c0..9db371da4897 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
@@ -76,6 +76,19 @@ on the Qualcomm Hexagon core.
 		    must be "mss_restart", "pdc_reset" for the modem
 		    sub-system on SDM845 SoCs
 
+For the compatible strings below the following supplies are required:
+  "qcom,q6v5-pil"
+  "qcom,msm8916-mss-pil",
+- cx-supply:
+- mx-supply:
+- pll-supply:
+	Usage: required
+	Value type: <phandle>
+	Definition: reference to the regulators to be held on behalf of the
+		    booting of the Hexagon core
+
+For the compatible string below the following supplies are required:
+  "qcom,msm8974-mss-pil"
 - cx-supply:
 - mss-supply:
 - mx-supply:
@@ -85,6 +98,14 @@ on the Qualcomm Hexagon core.
 	Definition: reference to the regulators to be held on behalf of the
 		    booting of the Hexagon core
 
+For the compatible string below the following supplies are required:
+  "qcom,msm8996-mss-pil"
+- pll-supply:
+	Usage: required
+	Value type: <phandle>
+	Definition: reference to the regulators to be held on behalf of the
+		    booting of the Hexagon core
+
 - qcom,smem-states:
 	Usage: required
 	Value type: <phandle>
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 20%]

* [PATCH v4 6/8] remoteproc: qcom: q6v5-mss: Add missing regulator for MSM8996
      [irrelevant] <20181228185307.25645-1-sibis@codeaurora.org>
  2018-12-28 18:53 ` [PATCH v4 4/8] remoteproc: qcom: q6v5-mss: Add missing clocks for MSM8996 Sibi Sankar
  2018-12-28 18:53 ` [PATCH v4 5/8] dt-bindings: remoteproc: qcom: Fixup regulator dependencies Sibi Sankar
@ 2018-12-28 18:53 ` Sibi Sankar
  2018-12-28 18:53 ` [PATCH v4 7/8] dt-bindings: remoteproc: qcom: Add power-domain bindings for Q6V5 Sibi Sankar
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2018-12-28 18:53 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, david.brown, dianders
  Cc: linux-arm-msm, linux-soc, devicetree, linux-kernel, tsoni, clew,
	akdwived, mark.rutland, linux-remoteproc, evgreen, briannorris,
	sricharan, Sibi Sankar

Add proxy vote for pll supply on MSM8996 SoC.

Fixes: 9f058fa2efb1 ("remoteproc: qcom: Add support for mss remoteproc
on msm8996")

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/remoteproc/qcom_q6v5_mss.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index cb5f0d3ac6a3..c86dc40cfb8c 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1395,6 +1395,13 @@ static const struct rproc_hexagon_res sdm845_mss = {
 
 static const struct rproc_hexagon_res msm8996_mss = {
 	.hexagon_mba_image = "mba.mbn",
+	.proxy_supply = (struct qcom_mss_reg_res[]) {
+		{
+			.supply = "pll",
+			.uA = 100000,
+		},
+		{}
+	},
 	.proxy_clk_names = (char*[]){
 			"xo",
 			"pnoc",
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 22%]

* [PATCH v4 7/8] dt-bindings: remoteproc: qcom: Add power-domain bindings for Q6V5
      [irrelevant] <20181228185307.25645-1-sibis@codeaurora.org>
                   ` (2 preceding siblings ...)
  2018-12-28 18:53 ` [PATCH v4 6/8] remoteproc: qcom: q6v5-mss: Add missing regulator for MSM8996 Sibi Sankar
@ 2018-12-28 18:53 ` Sibi Sankar
  2018-12-28 18:53 ` [PATCH v4 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Sibi Sankar
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2018-12-28 18:53 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, david.brown, dianders
  Cc: linux-arm-msm, linux-soc, devicetree, linux-kernel, tsoni, clew,
	akdwived, mark.rutland, linux-remoteproc, evgreen, briannorris,
	sricharan, Sibi Sankar

Add power-domain bindings for Q6V5 MSS on MSM8996 and SDM845 SoCs.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---

v3:
  * Fixup dt-binding documentation as suggested by Doug
  * Dropping Rob's Reviewed-by due to documentation style
    change

v2:
  * Add load_state power-domain
  * List cx and mx power-domains for MSM8996

 .../bindings/remoteproc/qcom,q6v5.txt         | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
index 9db371da4897..36e91c9d76e0 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
@@ -106,6 +106,25 @@ For the compatible string below the following supplies are required:
 	Definition: reference to the regulators to be held on behalf of the
 		    booting of the Hexagon core
 
+- power-domains:
+	Usage: required
+	Value type: <phandle>
+	Definition: reference to power-domains that match power-domain-names
+
+- power-domain-names:
+	Usage: required
+	Value type: <stringlist>
+	Definition: The power-domains needed depend on the compatible string:
+	qcom,q6v5-pil:
+	qcom,ipq8074-wcss-pil:
+	qcom,msm8916-mss-pil:
+	qcom,msm8974-mss-pil:
+		    no power-domain names required
+	qcom,msm8996-mss-pil:
+		    must be "cx", "mx"
+	qcom,sdm845-mss-pil:
+		    must be "cx", "mx", "mss", "load_state"
+
 - qcom,smem-states:
 	Usage: required
 	Value type: <phandle>
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* [PATCH v4 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
      [irrelevant] <20181228185307.25645-1-sibis@codeaurora.org>
                   ` (3 preceding siblings ...)
  2018-12-28 18:53 ` [PATCH v4 7/8] dt-bindings: remoteproc: qcom: Add power-domain bindings for Q6V5 Sibi Sankar
@ 2018-12-28 18:53 ` Sibi Sankar
      [irrelevant] ` <20181228185307.25645-2-sibis@codeaurora.org>
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2018-12-28 18:53 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, david.brown, dianders
  Cc: linux-arm-msm, linux-soc, devicetree, linux-kernel, tsoni, clew,
	akdwived, mark.rutland, linux-remoteproc, evgreen, briannorris,
	sricharan, Sibi Sankar

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
---

v3:
  * with shutdown-ack irq redesign make it mandatory,
    merge multiple patches into a single one

v2:
  * Fixed style changes
  * Added missing clocks in the dt-bindings
  * Split mss remoteproc node into a number of patches

This patch depends on the following bindings:
https://patchwork.kernel.org/patch/10662089/ - mba/mpss reserved regions
https://patchwork.kernel.org/patch/10657325/ - pdc reset node
https://patchwork.kernel.org/patch/10740127/ - rpmhpd dt bindings
https://patchwork.kernel.org/patch/10740109/ - rpmhpd dt node
https://patchwork.kernel.org/patch/10678301/ - AOP QMP dt bindings
https://patchwork.kernel.org/patch/10742083/ - shutdown-irq binding

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 60 ++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 5da9fa1feb8a..db17216a5bce 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1366,6 +1366,66 @@
 			};
 		};
 
+		remoteproc@4080000 {
+			compatible = "qcom,sdm845-mss-pil";
+			reg = <0x04080000 0x408>, <0x04180000 0x48>;
+			reg-names = "qdsp6", "rmb";
+
+			interrupts-extended =
+				<&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog", "fatal", "ready",
+					  "handover", "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+				 <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+				 <&gcc GCC_BOOT_ROM_AHB_CLK>,
+				 <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+				 <&gcc GCC_MSS_SNOC_AXI_CLK>,
+				 <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+				 <&gcc GCC_PRNG_AHB_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "iface", "bus", "mem", "gpll0_mss",
+				      "snoc_axi", "mnoc_axi", "prng", "xo";
+
+			qcom,smem-states = <&modem_smp2p_out 0>;
+			qcom,smem-state-names = "stop";
+
+			resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+				 <&pdc_reset PDC_MODEM_SYNC_RESET>;
+			reset-names = "mss_restart", "pdc_reset";
+
+			qcom,halt-regs = <&tcsr_mutex_regs
+						0x23000 0x25000 0x24000>;
+
+			power-domains = <&aoss_qmp_pd AOSS_QMP_LS_MODEM>,
+					<&rpmhpd SDM845_CX>,
+					<&rpmhpd SDM845_MX>,
+					<&rpmhpd SDM845_MSS>;
+			power-domain-names = "load_state", "cx", "mx", "mss";
+
+			mba {
+				memory-region = <&mba_region>;
+			};
+
+			mpss {
+				memory-region = <&mpss_region>;
+			};
+
+			glink-edge {
+				interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+				label = "modem";
+				qcom,remote-pid = <1>;
+				mboxes = <&apss_shared 12>;
+				mbox-names = "mpss_smem";
+			};
+		};
+
 		usb_1_hsphy: phy@88e2000 {
 			compatible = "qcom,sdm845-qusb2-phy";
 			reg = <0x88e2000 0x400>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 19%]

* Re: [PATCH v4 2/8] dt-bindings: remoteproc: qcom: Add missing clocks for SDM845
      [irrelevant] ` <20181228185307.25645-2-sibis@codeaurora.org>
@ 2018-12-28 22:13   ` Rob Herring
  0 siblings, 0 replies; 200+ results
From: Rob Herring @ 2018-12-28 22:13 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: bjorn.andersson, robh+dt, andy.gross, david.brown, dianders,
	linux-arm-msm, linux-soc, devicetree, linux-kernel, tsoni, clew,
	akdwived, mark.rutland, linux-remoteproc, evgreen, briannorris,
	sricharan, Sibi Sankar

On Sat, 29 Dec 2018 00:23:01 +0530, Sibi Sankar wrote:
> Add missing clock bindings for Q6V5 MSS on SDM845 SoCs.
> 
> Fixes: fb22022ff63d ("dt-bindings: remoteproc: Add Q6v5 Modem PIL
> binding for SDM845")
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
> 
> v4:
>   * Re-order clocks for consistency as suggested by Rob
> 
> v3:
>   * Fixup dt-binding documentation as suggested by Doug
> 
>  .../devicetree/bindings/remoteproc/qcom,q6v5.txt   | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v4 3/8] dt-bindings: remoteproc: qcom: Add missing clocks for MSM8996
      [irrelevant] ` <20181228185307.25645-3-sibis@codeaurora.org>
@ 2018-12-28 22:13   ` Rob Herring
  0 siblings, 0 replies; 200+ results
From: Rob Herring @ 2018-12-28 22:13 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: bjorn.andersson, robh+dt, andy.gross, david.brown, dianders,
	linux-arm-msm, linux-soc, devicetree, linux-kernel, tsoni, clew,
	akdwived, mark.rutland, linux-remoteproc, evgreen, briannorris,
	sricharan, Sibi Sankar

On Sat, 29 Dec 2018 00:23:02 +0530, Sibi Sankar wrote:
> Add missing clock bindings for Q6V5 MSS on MSM8996 SoCs.
> 
> Fixes: 9f058fa2efb1 ("remoteproc: qcom: Add support for mss remoteproc
> on msm8996")
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
> 
> v4:
>   * Re-order clocks for consistency as suggested by Rob
> 
> v3:
>   * Fixup dt-binding documentation as suggested by Doug
> 
>  Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 1/2] dt-bindings: remoteproc: qcom: Add firmware bindings for Q6V5
      [irrelevant] ` <20181228044819.5697-2-sibis@codeaurora.org>
@ 2018-12-28 22:17   ` Rob Herring
  2019-01-03 23:30   ` Brian Norris
  1 sibling, 0 replies; 200+ results
From: Rob Herring @ 2018-12-28 22:17 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: bjorn.andersson, david.brown, robh+dt, mark.rutland, andy.gross,
	briannorris, akdwived, clew, linux-kernel, linux-arm-msm-owner,
	ohad, linux-remoteproc, devicetree, Sibi Sankar

On Fri, 28 Dec 2018 10:18:18 +0530, Sibi Sankar wrote:
> Add optional "firmware-name" bindings for Q6V5 MSS and PAS based
> remoteprocs. For Q6V5 MSS/PAS the two/one relative firmware
> paths/path are to be listed respectively. Fallback to the default
> images for mba/modem for Q6V5 MSS or the default Hexagon image
> for Q6V5 PAS if the "firmware-name" binding is not present.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt | 6 ++++++
>  Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 7 +++++++
>  2 files changed, 13 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v4 1/8] dt-bindings: soc: qcom: Add remote-pid binding for GLINK SMEM
      [irrelevant] <20181228185307.25645-1-sibis@codeaurora.org>
                   ` (6 preceding siblings ...)
      [irrelevant] ` <20181228185307.25645-3-sibis@codeaurora.org>
@ 2019-01-03 20:17 ` Bjorn Andersson
  2019-01-08 10:26   ` Sibi Sankar
  7 siblings, 1 reply; 200+ results
From: Bjorn Andersson @ 2019-01-03 20:17 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: robh+dt, andy.gross, david.brown, dianders, linux-arm-msm,
	linux-soc, devicetree, linux-kernel, tsoni, clew, akdwived,
	mark.rutland, linux-remoteproc, evgreen, briannorris, sricharan

On Fri 28 Dec 10:53 PST 2018, Sibi Sankar wrote:

> Add missing qcom,remote-pid dt binding required for GLINK SMEM
> which specifies the remote endpoint of the GLINK edge.
> 
> Fixes: 2b41d6c8e696 ("dt-bindings: soc: qcom: Extend GLINK to cover
> SMEM")
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> Reviewed-by: Doug Anderson <dianders@chromium.org>
> Reviewed-by: Rob Herring <robh@kernel.org>

Thanks for the updates Sibi!

@Andy, as this relates to rpmsg I'll take this (patch 1/8) through the
rpmsg tree.

And I'm picking 2-7 through the remoteproc tree.


PS. Please use a --cover-letter when sending a series of patches.

Regards,
Bjorn

> ---
> 
> v3:
>   * Fixed typo
> 
>  Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> index 0b8cc533ca83..587bb1ddc8cc 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
> @@ -21,6 +21,11 @@ edge.
>  	Definition: should specify the IRQ used by the remote processor to
>  		    signal this processor about communication related events
>  
> +- qcom,remote-pid:
> +	Usage: required for glink-smem
> +	Value type: <u32>
> +	Definition: specifies the identifier of the remote endpoint of this edge
> +
>  - qcom,rpm-msg-ram:
>  	Usage: required for glink-rpm
>  	Value type: <prop-encoded-array>
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 2/2] remoteproc: qcom: Add support for parsing fw dt bindings
      [irrelevant] ` <20181228044819.5697-3-sibis@codeaurora.org>
@ 2019-01-03 23:09   ` Bjorn Andersson
  2019-01-03 23:44   ` Brian Norris
  1 sibling, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-03 23:09 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: david.brown, robh+dt, mark.rutland, andy.gross, briannorris,
	akdwived, clew, linux-kernel, linux-arm-msm-owner, ohad,
	linux-remoteproc, devicetree

On Thu 27 Dec 20:48 PST 2018, Sibi Sankar wrote:

> Add support for parsing "firmware-name" dt bindings which specifies
> the relative paths of mba/modem/pas image as strings. Fallback to
> the default paths for mba/modem/pas image on -EINVAL.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>

Thanks Sibi, just some minor style issues I would prefer to have fixed.

I picked patch 1, so no need to resend that.

> ---
>  drivers/remoteproc/qcom_q6v5_mss.c | 46 +++++++++++++++++++++++-------
>  drivers/remoteproc/qcom_q6v5_pas.c | 11 ++++++-
>  2 files changed, 46 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index 01be7314e176..c75179006e24 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -188,6 +188,7 @@ struct q6v5 {
>  	bool has_alt_reset;
>  	int mpss_perm;
>  	int mba_perm;
> +	const char *hexagon_mdt_image;
>  	int version;
>  };
>  
> @@ -860,17 +861,27 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>  	phys_addr_t min_addr = PHYS_ADDR_MAX;
>  	phys_addr_t max_addr = 0;
>  	bool relocate = false;
> -	char seg_name[10];
> +	char *fw_name;
> +	size_t fw_name_len;
>  	ssize_t offset;
>  	size_t size = 0;
>  	void *ptr;
>  	int ret;
>  	int i;
>  
> -	ret = request_firmware(&fw, "modem.mdt", qproc->dev);
> +	fw_name_len = strlen(qproc->hexagon_mdt_image);
> +	if (fw_name_len <= 4)
> +		return -EINVAL;
> +
> +	fw_name = kstrdup(qproc->hexagon_mdt_image, GFP_KERNEL);
> +	if (!fw_name)
> +		return -ENOMEM;
> +
> +	ret = request_firmware(&fw, qproc->hexagon_mdt_image, qproc->dev);

Use fw_name here.

>  	if (ret < 0) {
> -		dev_err(qproc->dev, "unable to load modem.mdt\n");
> -		return ret;
> +		dev_err(qproc->dev, "unable to load %s\n",
> +			qproc->hexagon_mdt_image);
> +		goto out;
>  	}
>  
>  	/* Initialize the RMB validator */
> @@ -918,10 +929,12 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>  		ptr = qproc->mpss_region + offset;
>  
>  		if (phdr->p_filesz) {
> -			snprintf(seg_name, sizeof(seg_name), "modem.b%02d", i);
> -			ret = request_firmware(&seg_fw, seg_name, qproc->dev);
> +			snprintf(fw_name + fw_name_len - 3, fw_name_len,
> +				 "b%02d", i);
> +			ret = request_firmware(&seg_fw, fw_name, qproc->dev);
>  			if (ret) {
> -				dev_err(qproc->dev, "failed to load %s\n", seg_name);
> +				dev_err(qproc->dev, "failed to load %s\n",
> +					fw_name);

Follow my lead and break the 80-char limit.

>  				goto release_firmware;
>  			}
>  
> @@ -960,6 +973,8 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>  
>  release_firmware:
>  	release_firmware(fw);
> +out:
> +	kfree(fw_name);
>  
>  	return ret < 0 ? ret : 0;
>  }
> @@ -1075,9 +1090,10 @@ static int qcom_q6v5_register_dump_segments(struct rproc *rproc,
>  	unsigned long i;
>  	int ret;
>  
> -	ret = request_firmware(&fw, "modem.mdt", qproc->dev);
> +	ret = request_firmware(&fw, qproc->hexagon_mdt_image, qproc->dev);
>  	if (ret < 0) {
> -		dev_err(qproc->dev, "unable to load modem.mdt\n");
> +		dev_err(qproc->dev, "unable to load %s\n",
> +			qproc->hexagon_mdt_image);
>  		return ret;
>  	}
>  
> @@ -1253,6 +1269,8 @@ static int q6v5_probe(struct platform_device *pdev)
>  	const struct rproc_hexagon_res *desc;
>  	struct q6v5 *qproc;
>  	struct rproc *rproc;
> +	const char *mba_image;
> +	const char *fw_name[2];
>  	int ret;
>  
>  	desc = of_device_get_match_data(&pdev->dev);
> @@ -1262,8 +1280,15 @@ static int q6v5_probe(struct platform_device *pdev)
>  	if (desc->need_mem_protection && !qcom_scm_is_available())
>  		return -EPROBE_DEFER;
>  
> +	ret = of_property_read_string_array(pdev->dev.of_node, "firmware-name",
> +					    fw_name, 2);
> +	if (ret != -EINVAL && ret != 2)
> +		return ret > 0 ? -EINVAL : ret;
> +
> +	mba_image = (ret != 2) ? desc->hexagon_mba_image : fw_name[0];

Use the fact that of_property_read_string_index() leaves the output
parameter untouched if it doesn't succeed in parsing the property.

I.e. do:

mba_image = desc->hexagon_mba_image;
ret = of_property_read_string_index(pdev->dev.of_node, "firmware-name",
				    0, &mba_image);
if (ret < 0 && ret != -EINVAL)
	fail();

and

qproc->hexagon_mdt_image = "modem.mdt";
ret = of_property_read_string_index(pdev->dev.of_node, "firmware-name",
				    1, &qproc->hexagon_mdt_image);
if (ret < 0 && ret != -EINVAL)
	fail();

> +
>  	rproc = rproc_alloc(&pdev->dev, pdev->name, &q6v5_ops,
> -			    desc->hexagon_mba_image, sizeof(*qproc));
> +			    mba_image, sizeof(*qproc));
>  	if (!rproc) {
>  		dev_err(&pdev->dev, "failed to allocate rproc\n");
>  		return -ENOMEM;
> @@ -1272,6 +1297,7 @@ static int q6v5_probe(struct platform_device *pdev)
>  	qproc = (struct q6v5 *)rproc->priv;
>  	qproc->dev = &pdev->dev;
>  	qproc->rproc = rproc;
> +	qproc->hexagon_mdt_image = (ret != 2) ? "modem.mdt" : fw_name[1];
>  	platform_set_drvdata(pdev, qproc);
>  
>  	ret = q6v5_init_mem(qproc, pdev);
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index b1e63fcd5fdf..141c7da29e9a 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -258,6 +258,8 @@ static int adsp_probe(struct platform_device *pdev)
>  	const struct adsp_data *desc;
>  	struct qcom_adsp *adsp;
>  	struct rproc *rproc;
> +	const char *fw_name;
> +	const char *of_fw_name;
>  	int ret;
>  
>  	desc = of_device_get_match_data(&pdev->dev);
> @@ -267,8 +269,15 @@ static int adsp_probe(struct platform_device *pdev)
>  	if (!qcom_scm_is_available())
>  		return -EPROBE_DEFER;
>  
> +	ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
> +				      &of_fw_name);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +
> +	fw_name = ret ? desc->firmware_name : of_fw_name;

As above, please use the fact that the last parameter of
of_property_read_string() doesn't modify the output if it fails.

> +
>  	rproc = rproc_alloc(&pdev->dev, pdev->name, &adsp_ops,
> -			    desc->firmware_name, sizeof(*adsp));
> +			    fw_name, sizeof(*adsp));
>  	if (!rproc) {
>  		dev_err(&pdev->dev, "unable to allocate remoteproc\n");
>  		return -ENOMEM;

Regards,
Bjorn

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 1/2] dt-bindings: remoteproc: qcom: Add firmware bindings for Q6V5
      [irrelevant] ` <20181228044819.5697-2-sibis@codeaurora.org>
  2018-12-28 22:17   ` [PATCH v2 1/2] dt-bindings: remoteproc: qcom: Add firmware bindings for Q6V5 Rob Herring
@ 2019-01-03 23:30   ` Brian Norris
      [irrelevant]     ` <20190103235043.GA195759@google.com>
  1 sibling, 1 reply; 200+ results
From: Brian Norris @ 2019-01-03 23:30 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: bjorn.andersson, david.brown, robh+dt, mark.rutland, andy.gross,
	akdwived, clew, linux-kernel, linux-arm-msm-owner, ohad,
	linux-remoteproc, devicetree

Hi Sibi,

On Fri, Dec 28, 2018 at 10:18:18AM +0530, Sibi Sankar wrote:
> Add optional "firmware-name" bindings for Q6V5 MSS and PAS based
> remoteprocs. For Q6V5 MSS/PAS the two/one relative firmware
> paths/path are to be listed respectively. Fallback to the default
> images for mba/modem for Q6V5 MSS or the default Hexagon image
> for Q6V5 PAS if the "firmware-name" binding is not present.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt | 6 ++++++
>  Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 7 +++++++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> index 9c0cff3a5ed8..60ee0f73071a 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
> @@ -27,6 +27,12 @@ on the Qualcomm ADSP Hexagon core.
>  	Value type: <stringlist>
>  	Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
>  
> +- firmware-name:
> +	Usage: optional
> +	Value type: <string>
> +	Definition: must list the relative firmware image path for the
> +		    Hexagon Core.

Relative to what? I still think it's a terrible idea that your driver
looks for files at the top-level /lib/firmware/ directory, but now
you're leaking this into the device tree. This should at a bare minimum
be namespaced to something like the qcom/ sub-directory. But ideally,
the driver would automatically be deriving a further sub-directory of
qcom/ based on the chipset or something, and then the only thing you'd
describe here is some kind of variant string -- something akin to
ath10k's qcom,ath10k-calibration-variant (see
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt), which
doesn't require a full path-name or any hierarchy.

Brian

> +
>  - clocks:
>  	Usage: required
>  	Value type: <prop-encoded-array>
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> index 9ff5b0309417..3a99e7379d8c 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
> @@ -36,6 +36,13 @@ on the Qualcomm Hexagon core.
>  	Value type: <stringlist>
>  	Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
>  
> +- firmware-name:
> +	Usage: optional
> +	Value type: <stringlist>
> +	Definition: must list the relative firmware image paths for mba and
> +		    modem. They are used for booting and authenticating the
> +		    Hexagon core.
> +
>  - clocks:
>  	Usage: required
>  	Value type: <phandle>
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 3/4] remoteproc: qcom: Wait for shutdown-ack/ind on sysmon shutdown
      [irrelevant] ` <20181224084824.25193-3-sibis@codeaurora.org>
@ 2019-01-03 23:33   ` Bjorn Andersson
  2019-01-08 10:14     ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Bjorn Andersson @ 2019-01-03 23:33 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: robh+dt, andy.gross, david.brown, linux-arm-msm, linux-soc,
	devicetree, linux-kernel, tsoni, clew, akdwived, ohad,
	mark.rutland, linux-remoteproc, dianders

On Mon 24 Dec 00:48 PST 2018, Sibi Sankar wrote:

> After sending a sysmon shutdown request to the SSCTL service on the
> subsystem, wait for the service to send shutdown-ack interrupt or
> an indication message to signal the completion of graceful shutdown.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>

I prefer something closer to v1, where you kept the handling of the
interrupt within the sysmon driver.

What I didn't like was the fact that you resolved the mss
platform_device to get to the irq, not that you grabbed the irq from the
parent's DT node from within the sysmon device.


You can get the remoteproc's DT node by rproc->dev.parent->of_node and
use of_irq_get_byname() to get an irq number, which you can request in
the sysmon device - which will work regardless of the remoteproc driver
being a platform_driver or something else.

All the logic looks sound, but by shuffling things around we should get
less coupling of the implementation (DT binding looks good).

Regards,
Bjorn

> ---
>  drivers/remoteproc/qcom_sysmon.c | 40 +++++++++++++++++++++++++++++++-
>  1 file changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
> index c0d6ee8de995..0da83638ca99 100644
> --- a/drivers/remoteproc/qcom_sysmon.c
> +++ b/drivers/remoteproc/qcom_sysmon.c
> @@ -36,6 +36,7 @@ struct qcom_sysmon {
>  
>  	struct rpmsg_endpoint *ept;
>  	struct completion comp;
> +	struct completion ind_comp;
>  	struct mutex lock;
>  
>  	bool ssr_ack;
> @@ -139,6 +140,7 @@ static int sysmon_callback(struct rpmsg_device *rpdev, void *data, int count,
>  }
>  
>  #define SSCTL_SHUTDOWN_REQ		0x21
> +#define SSCTL_SHUTDOWN_READY_IND	0x21
>  #define SSCTL_SUBSYS_EVENT_REQ		0x23
>  
>  #define SSCTL_MAX_MSG_LEN		7
> @@ -254,6 +256,29 @@ static struct qmi_elem_info ssctl_subsys_event_resp_ei[] = {
>  	{}
>  };
>  
> +static struct qmi_elem_info ssctl_shutdown_ind_ei[] = {
> +	{}
> +};
> +
> +static void sysmon_ind_cb(struct qmi_handle *qmi, struct sockaddr_qrtr *sq,
> +			  struct qmi_txn *txn, const void *data)
> +{
> +	struct qcom_sysmon *sysmon = container_of(qmi, struct qcom_sysmon, qmi);
> +
> +	complete(&sysmon->ind_comp);
> +}
> +
> +static struct qmi_msg_handler qmi_indication_handler[] = {
> +	{
> +		.type = QMI_INDICATION,
> +		.msg_id = SSCTL_SHUTDOWN_READY_IND,
> +		.ei = ssctl_shutdown_ind_ei,
> +		.decoded_size = 0,
> +		.fn = sysmon_ind_cb
> +	},
> +	{}
> +};
> +
>  /**
>   * ssctl_request_shutdown() - request shutdown via SSCTL QMI service
>   * @sysmon:	sysmon context
> @@ -264,6 +289,7 @@ static void ssctl_request_shutdown(struct qcom_sysmon *sysmon)
>  	struct qmi_txn txn;
>  	int ret;
>  
> +	reinit_completion(&sysmon->ind_comp);
>  	ret = qmi_txn_init(&sysmon->qmi, &txn, ssctl_shutdown_resp_ei, &resp);
>  	if (ret < 0) {
>  		dev_err(sysmon->dev, "failed to allocate QMI txn\n");
> @@ -285,6 +311,16 @@ static void ssctl_request_shutdown(struct qcom_sysmon *sysmon)
>  		dev_err(sysmon->dev, "shutdown request failed\n");
>  	else
>  		dev_dbg(sysmon->dev, "shutdown request completed\n");
> +
> +	if (sysmon->q6v5) {
> +		ret = qcom_q6v5_wait_for_shutdown(sysmon->q6v5, 10 * HZ);
> +		if (ret) {
> +			ret = try_wait_for_completion(&sysmon->ind_comp);
> +			if (!ret)
> +				dev_err(sysmon->dev,
> +					"timeout waiting for shutdown ack\n");
> +		}
> +	}
>  }
>  
>  /**
> @@ -462,9 +498,11 @@ struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
>  	sysmon->q6v5 = q6v5;
>  
>  	init_completion(&sysmon->comp);
> +	init_completion(&sysmon->ind_comp);
>  	mutex_init(&sysmon->lock);
>  
> -	ret = qmi_handle_init(&sysmon->qmi, SSCTL_MAX_MSG_LEN, &ssctl_ops, NULL);
> +	ret = qmi_handle_init(&sysmon->qmi, SSCTL_MAX_MSG_LEN, &ssctl_ops,
> +			      qmi_indication_handler);
>  	if (ret < 0) {
>  		dev_err(sysmon->dev, "failed to initialize qmi handle\n");
>  		kfree(sysmon);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 2/2] remoteproc: qcom: Add support for parsing fw dt bindings
      [irrelevant] ` <20181228044819.5697-3-sibis@codeaurora.org>
  2019-01-03 23:09   ` [PATCH v2 2/2] remoteproc: qcom: Add support for parsing fw dt bindings Bjorn Andersson
@ 2019-01-03 23:44   ` Brian Norris
  2019-01-08 10:32     ` Sibi Sankar
  1 sibling, 1 reply; 200+ results
From: Brian Norris @ 2019-01-03 23:44 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: bjorn.andersson, david.brown, robh+dt, mark.rutland, andy.gross,
	akdwived, clew, linux-kernel, linux-arm-msm-owner, ohad,
	linux-remoteproc, devicetree

On Fri, Dec 28, 2018 at 10:18:19AM +0530, Sibi Sankar wrote:
> Add support for parsing "firmware-name" dt bindings which specifies
> the relative paths of mba/modem/pas image as strings. Fallback to
> the default paths for mba/modem/pas image on -EINVAL.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  drivers/remoteproc/qcom_q6v5_mss.c | 46 +++++++++++++++++++++++-------
>  drivers/remoteproc/qcom_q6v5_pas.c | 11 ++++++-
>  2 files changed, 46 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index 01be7314e176..c75179006e24 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -188,6 +188,7 @@ struct q6v5 {
>  	bool has_alt_reset;
>  	int mpss_perm;
>  	int mba_perm;
> +	const char *hexagon_mdt_image;
>  	int version;
>  };
>  
> @@ -860,17 +861,27 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>  	phys_addr_t min_addr = PHYS_ADDR_MAX;
>  	phys_addr_t max_addr = 0;
>  	bool relocate = false;
> -	char seg_name[10];
> +	char *fw_name;
> +	size_t fw_name_len;
>  	ssize_t offset;
>  	size_t size = 0;
>  	void *ptr;
>  	int ret;
>  	int i;
>  
> -	ret = request_firmware(&fw, "modem.mdt", qproc->dev);
> +	fw_name_len = strlen(qproc->hexagon_mdt_image);
> +	if (fw_name_len <= 4)
> +		return -EINVAL;
> +
> +	fw_name = kstrdup(qproc->hexagon_mdt_image, GFP_KERNEL);
> +	if (!fw_name)
> +		return -ENOMEM;
> +
> +	ret = request_firmware(&fw, qproc->hexagon_mdt_image, qproc->dev);
>  	if (ret < 0) {
> -		dev_err(qproc->dev, "unable to load modem.mdt\n");
> -		return ret;
> +		dev_err(qproc->dev, "unable to load %s\n",
> +			qproc->hexagon_mdt_image);
> +		goto out;
>  	}
>  
>  	/* Initialize the RMB validator */
> @@ -918,10 +929,12 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>  		ptr = qproc->mpss_region + offset;
>  
>  		if (phdr->p_filesz) {
> -			snprintf(seg_name, sizeof(seg_name), "modem.b%02d", i);
> -			ret = request_firmware(&seg_fw, seg_name, qproc->dev);
> +			snprintf(fw_name + fw_name_len - 3, fw_name_len,
> +				 "b%02d", i);

So, you're assuming that 'fw_name' ends in '.XXX' (for some 3-char value
of 'XXX')? Seems a bit odd. But if you really want this, it feels like
you should enforce this, and either comment on what you're doing or else
use a proper computation that makes it clear (e.g., strlen("bin")).

Brian

> +			ret = request_firmware(&seg_fw, fw_name, qproc->dev);
>  			if (ret) {
> -				dev_err(qproc->dev, "failed to load %s\n", seg_name);
> +				dev_err(qproc->dev, "failed to load %s\n",
> +					fw_name);
>  				goto release_firmware;
>  			}
>  
> @@ -960,6 +973,8 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>  
>  release_firmware:
>  	release_firmware(fw);
> +out:
> +	kfree(fw_name);
>  
>  	return ret < 0 ? ret : 0;
>  }
> @@ -1075,9 +1090,10 @@ static int qcom_q6v5_register_dump_segments(struct rproc *rproc,
>  	unsigned long i;
>  	int ret;
>  
> -	ret = request_firmware(&fw, "modem.mdt", qproc->dev);
> +	ret = request_firmware(&fw, qproc->hexagon_mdt_image, qproc->dev);
>  	if (ret < 0) {
> -		dev_err(qproc->dev, "unable to load modem.mdt\n");
> +		dev_err(qproc->dev, "unable to load %s\n",
> +			qproc->hexagon_mdt_image);
>  		return ret;
>  	}
>  
> @@ -1253,6 +1269,8 @@ static int q6v5_probe(struct platform_device *pdev)
>  	const struct rproc_hexagon_res *desc;
>  	struct q6v5 *qproc;
>  	struct rproc *rproc;
> +	const char *mba_image;
> +	const char *fw_name[2];
>  	int ret;
>  
>  	desc = of_device_get_match_data(&pdev->dev);
> @@ -1262,8 +1280,15 @@ static int q6v5_probe(struct platform_device *pdev)
>  	if (desc->need_mem_protection && !qcom_scm_is_available())
>  		return -EPROBE_DEFER;
>  
> +	ret = of_property_read_string_array(pdev->dev.of_node, "firmware-name",
> +					    fw_name, 2);
> +	if (ret != -EINVAL && ret != 2)
> +		return ret > 0 ? -EINVAL : ret;
> +
> +	mba_image = (ret != 2) ? desc->hexagon_mba_image : fw_name[0];
> +
>  	rproc = rproc_alloc(&pdev->dev, pdev->name, &q6v5_ops,
> -			    desc->hexagon_mba_image, sizeof(*qproc));
> +			    mba_image, sizeof(*qproc));
>  	if (!rproc) {
>  		dev_err(&pdev->dev, "failed to allocate rproc\n");
>  		return -ENOMEM;
> @@ -1272,6 +1297,7 @@ static int q6v5_probe(struct platform_device *pdev)
>  	qproc = (struct q6v5 *)rproc->priv;
>  	qproc->dev = &pdev->dev;
>  	qproc->rproc = rproc;
> +	qproc->hexagon_mdt_image = (ret != 2) ? "modem.mdt" : fw_name[1];
>  	platform_set_drvdata(pdev, qproc);
>  
>  	ret = q6v5_init_mem(qproc, pdev);
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index b1e63fcd5fdf..141c7da29e9a 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -258,6 +258,8 @@ static int adsp_probe(struct platform_device *pdev)
>  	const struct adsp_data *desc;
>  	struct qcom_adsp *adsp;
>  	struct rproc *rproc;
> +	const char *fw_name;
> +	const char *of_fw_name;
>  	int ret;
>  
>  	desc = of_device_get_match_data(&pdev->dev);
> @@ -267,8 +269,15 @@ static int adsp_probe(struct platform_device *pdev)
>  	if (!qcom_scm_is_available())
>  		return -EPROBE_DEFER;
>  
> +	ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
> +				      &of_fw_name);
> +	if (ret && ret != -EINVAL)
> +		return ret;
> +
> +	fw_name = ret ? desc->firmware_name : of_fw_name;
> +
>  	rproc = rproc_alloc(&pdev->dev, pdev->name, &adsp_ops,
> -			    desc->firmware_name, sizeof(*adsp));
> +			    fw_name, sizeof(*adsp));
>  	if (!rproc) {
>  		dev_err(&pdev->dev, "unable to allocate remoteproc\n");
>  		return -ENOMEM;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 3/4] remoteproc: qcom: Wait for shutdown-ack/ind on sysmon shutdown
  2019-01-03 23:33   ` [PATCH v2 3/4] remoteproc: qcom: Wait for shutdown-ack/ind on sysmon shutdown Bjorn Andersson
@ 2019-01-08 10:14     ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-08 10:14 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: robh+dt, andy.gross, david.brown, linux-arm-msm, linux-soc,
	devicetree, linux-kernel, tsoni, clew, akdwived, ohad,
	mark.rutland, linux-remoteproc, dianders, linux-kernel-owner

Hi Bjorn,
Thanks for the review!

On 2019-01-04 05:03, Bjorn Andersson wrote:
> On Mon 24 Dec 00:48 PST 2018, Sibi Sankar wrote:
> 
>> After sending a sysmon shutdown request to the SSCTL service on the
>> subsystem, wait for the service to send shutdown-ack interrupt or
>> an indication message to signal the completion of graceful shutdown.
>> 
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> 
> I prefer something closer to v1, where you kept the handling of the
> interrupt within the sysmon driver.
> 
> What I didn't like was the fact that you resolved the mss
> platform_device to get to the irq, not that you grabbed the irq from 
> the
> parent's DT node from within the sysmon device.
> 
> 
> You can get the remoteproc's DT node by rproc->dev.parent->of_node and
> use of_irq_get_byname() to get an irq number, which you can request in
> the sysmon device - which will work regardless of the remoteproc driver
> being a platform_driver or something else.
> 
> All the logic looks sound, but by shuffling things around we should get
> less coupling of the implementation (DT binding looks good).
> 

will make it closer to v1 in the next re-spin

> Regards,
> Bjorn
> 
>> ---
>>  drivers/remoteproc/qcom_sysmon.c | 40 
>> +++++++++++++++++++++++++++++++-
>>  1 file changed, 39 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/remoteproc/qcom_sysmon.c 
>> b/drivers/remoteproc/qcom_sysmon.c
>> index c0d6ee8de995..0da83638ca99 100644
>> --- a/drivers/remoteproc/qcom_sysmon.c
>> +++ b/drivers/remoteproc/qcom_sysmon.c
>> @@ -36,6 +36,7 @@ struct qcom_sysmon {
>> 
>>  	struct rpmsg_endpoint *ept;
>>  	struct completion comp;
>> +	struct completion ind_comp;
>>  	struct mutex lock;
>> 
>>  	bool ssr_ack;
>> @@ -139,6 +140,7 @@ static int sysmon_callback(struct rpmsg_device 
>> *rpdev, void *data, int count,
>>  }
>> 
>>  #define SSCTL_SHUTDOWN_REQ		0x21
>> +#define SSCTL_SHUTDOWN_READY_IND	0x21
>>  #define SSCTL_SUBSYS_EVENT_REQ		0x23
>> 
>>  #define SSCTL_MAX_MSG_LEN		7
>> @@ -254,6 +256,29 @@ static struct qmi_elem_info 
>> ssctl_subsys_event_resp_ei[] = {
>>  	{}
>>  };
>> 
>> +static struct qmi_elem_info ssctl_shutdown_ind_ei[] = {
>> +	{}
>> +};
>> +
>> +static void sysmon_ind_cb(struct qmi_handle *qmi, struct 
>> sockaddr_qrtr *sq,
>> +			  struct qmi_txn *txn, const void *data)
>> +{
>> +	struct qcom_sysmon *sysmon = container_of(qmi, struct qcom_sysmon, 
>> qmi);
>> +
>> +	complete(&sysmon->ind_comp);
>> +}
>> +
>> +static struct qmi_msg_handler qmi_indication_handler[] = {
>> +	{
>> +		.type = QMI_INDICATION,
>> +		.msg_id = SSCTL_SHUTDOWN_READY_IND,
>> +		.ei = ssctl_shutdown_ind_ei,
>> +		.decoded_size = 0,
>> +		.fn = sysmon_ind_cb
>> +	},
>> +	{}
>> +};
>> +
>>  /**
>>   * ssctl_request_shutdown() - request shutdown via SSCTL QMI service
>>   * @sysmon:	sysmon context
>> @@ -264,6 +289,7 @@ static void ssctl_request_shutdown(struct 
>> qcom_sysmon *sysmon)
>>  	struct qmi_txn txn;
>>  	int ret;
>> 
>> +	reinit_completion(&sysmon->ind_comp);
>>  	ret = qmi_txn_init(&sysmon->qmi, &txn, ssctl_shutdown_resp_ei, 
>> &resp);
>>  	if (ret < 0) {
>>  		dev_err(sysmon->dev, "failed to allocate QMI txn\n");
>> @@ -285,6 +311,16 @@ static void ssctl_request_shutdown(struct 
>> qcom_sysmon *sysmon)
>>  		dev_err(sysmon->dev, "shutdown request failed\n");
>>  	else
>>  		dev_dbg(sysmon->dev, "shutdown request completed\n");
>> +
>> +	if (sysmon->q6v5) {
>> +		ret = qcom_q6v5_wait_for_shutdown(sysmon->q6v5, 10 * HZ);
>> +		if (ret) {
>> +			ret = try_wait_for_completion(&sysmon->ind_comp);
>> +			if (!ret)
>> +				dev_err(sysmon->dev,
>> +					"timeout waiting for shutdown ack\n");
>> +		}
>> +	}
>>  }
>> 
>>  /**
>> @@ -462,9 +498,11 @@ struct qcom_sysmon *qcom_add_sysmon_subdev(struct 
>> rproc *rproc,
>>  	sysmon->q6v5 = q6v5;
>> 
>>  	init_completion(&sysmon->comp);
>> +	init_completion(&sysmon->ind_comp);
>>  	mutex_init(&sysmon->lock);
>> 
>> -	ret = qmi_handle_init(&sysmon->qmi, SSCTL_MAX_MSG_LEN, &ssctl_ops, 
>> NULL);
>> +	ret = qmi_handle_init(&sysmon->qmi, SSCTL_MAX_MSG_LEN, &ssctl_ops,
>> +			      qmi_indication_handler);
>>  	if (ret < 0) {
>>  		dev_err(sysmon->dev, "failed to initialize qmi handle\n");
>>  		kfree(sysmon);
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* [PATCH v3 1/3] dt-bindings: remoteproc: qcom: Introduce shutdown-ack irq for Q6V5
@ 2019-01-08 10:23 Sibi Sankar
  2019-01-08 10:23 ` [PATCH v3 2/3] remoteproc: qcom: Add shutdown-ack irq Sibi Sankar
  2019-01-08 10:23 ` [PATCH v3 3/3] remoteproc: qcom: Wait for shutdown-ack/ind on sysmon shutdown Sibi Sankar
  0 siblings, 2 replies; 200+ results
From: Sibi Sankar @ 2019-01-08 10:23 UTC (permalink / raw)
  To: bjorn.andersson
  Cc: robh+dt, andy.gross, david.brown, linux-arm-msm, linux-soc,
	devicetree, linux-kernel, tsoni, clew, akdwived, ohad,
	mark.rutland, linux-remoteproc, dianders, Sibi Sankar

Introduce shutdown-irq binding required for sysmon shutdown for Q6V5 MSS
on SDM845/MSM8996 SoCs and for WCSS Q6V5 on QCS404 SoC.

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---

v2:
  * Make shutdown-ack mandatory for MSS on SDM845/MSM8996 and
    for WCSS on QCS404 (Dropping Rob's reviewed-by due to this)

 .../bindings/remoteproc/qcom,adsp.txt           | 17 ++++++++++++++---
 .../bindings/remoteproc/qcom,q6v5.txt           | 15 ++++++++++++---
 2 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
index 60ee0f73071a..292dfda9770d 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt
@@ -19,13 +19,24 @@ on the Qualcomm ADSP Hexagon core.
 - interrupts-extended:
 	Usage: required
 	Value type: <prop-encoded-array>
-	Definition: must list the watchdog, fatal IRQs ready, handover and
-		    stop-ack IRQs
+	Definition: reference to the interrupts that match interrupt-names
 
 - interrupt-names:
 	Usage: required
 	Value type: <stringlist>
-	Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
+	Definition: The interrupts needed depends on the compatible
+		    string:
+	qcom,msm8974-adsp-pil:
+	qcom,msm8996-adsp-pil:
+	qcom,msm8996-slpi-pil:
+	qcom,qcs404-adsp-pas:
+	qcom,qcs404-cdsp-pas:
+	qcom,sdm845-adsp-pas:
+	qcom,sdm845-cdsp-pas:
+		    must be "wdog", "fatal", "ready", "handover", "stop-ack"
+	qcom,qcs404-wcss-pas:
+		    must be "wdog", "fatal", "ready", "handover", "stop-ack",
+		    "shutdown-ack"
 
 - firmware-name:
 	Usage: optional
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
index 401e49ebee39..41ca5df5be5a 100644
--- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt
@@ -28,13 +28,22 @@ on the Qualcomm Hexagon core.
 - interrupts-extended:
 	Usage: required
 	Value type: <prop-encoded-array>
-	Definition: must list the watchdog, fatal IRQs ready, handover and
-		    stop-ack IRQs
+	Definition: reference to the interrupts that match interrupt-names
 
 - interrupt-names:
 	Usage: required
 	Value type: <stringlist>
-	Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack"
+	Definition: The interrupts needed depends on the the compatible
+		    string:
+	qcom,q6v5-pil:
+	qcom,ipq8074-wcss-pil:
+	qcom,msm8916-mss-pil:
+	qcom,msm8974-mss-pil:
+		    must be "wdog", "fatal", "ready", "handover", "stop-ack"
+	qcom,msm8996-mss-pil:
+	qcom,sdm845-mss-pil:
+		    must be "wdog", "fatal", "ready", "handover", "stop-ack",
+		    "shutdown-ack"
 
 - firmware-name:
 	Usage: optional
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 19%]

* [PATCH v3 2/3] remoteproc: qcom: Add shutdown-ack irq
  2019-01-08 10:23 [PATCH v3 1/3] dt-bindings: remoteproc: qcom: Introduce shutdown-ack irq for Q6V5 Sibi Sankar
@ 2019-01-08 10:23 ` Sibi Sankar
  2019-01-08 10:23 ` [PATCH v3 3/3] remoteproc: qcom: Wait for shutdown-ack/ind on sysmon shutdown Sibi Sankar
  1 sibling, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-08 10:23 UTC (permalink / raw)
  To: bjorn.andersson
  Cc: robh+dt, andy.gross, david.brown, linux-arm-msm, linux-soc,
	devicetree, linux-kernel, tsoni, clew, akdwived, ohad,
	mark.rutland, linux-remoteproc, dianders, Sibi Sankar

Add shutdown-ack irq handling required for sysmon shutdown for
Q6V5 MSS on SDM845/MSM8996 and for WCSS Q6V5 on QCS404 SoC.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---

v3:
   * Move shutdown-irq handling back to sysmon and
     modify qcom_add_sysmon_subdev to handle -EPROBE_DEFER
   * Dropped has_shutdown_irq flag

v2:
   * Move shutdown-irq get to Q6V5 from sysmon to handle
     -EPROBE_DEFER cases

 drivers/remoteproc/qcom_common.h    | 16 +++++----
 drivers/remoteproc/qcom_q6v5_adsp.c |  9 +++--
 drivers/remoteproc/qcom_q6v5_mss.c  |  4 ++-
 drivers/remoteproc/qcom_q6v5_pas.c  |  9 +++--
 drivers/remoteproc/qcom_sysmon.c    | 52 +++++++++++++++++++++++++----
 drivers/remoteproc/qcom_wcnss.c     |  5 ++-
 6 files changed, 73 insertions(+), 22 deletions(-)

diff --git a/drivers/remoteproc/qcom_common.h b/drivers/remoteproc/qcom_common.h
index 58de71e4781c..afea598fdc9d 100644
--- a/drivers/remoteproc/qcom_common.h
+++ b/drivers/remoteproc/qcom_common.h
@@ -43,16 +43,18 @@ void qcom_add_ssr_subdev(struct rproc *rproc, struct qcom_rproc_ssr *ssr,
 void qcom_remove_ssr_subdev(struct rproc *rproc, struct qcom_rproc_ssr *ssr);
 
 #if IS_ENABLED(CONFIG_QCOM_SYSMON)
-struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
-					   const char *name,
-					   int ssctl_instance);
+int qcom_add_sysmon_subdev(struct rproc *rproc,
+			   struct qcom_sysmon *rproc_sysmon,
+			   const char *name,
+			   int ssctl_instance);
 void qcom_remove_sysmon_subdev(struct qcom_sysmon *sysmon);
 #else
-static inline struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
-							 const char *name,
-							 int ssctl_instance)
+static inline int qcom_add_sysmon_subdev(struct rproc *rproc,
+					 struct qcom_sysmon *rproc_sysmon,
+					 const char *name,
+					 int ssctl_instance)
 {
-	return NULL;
+	return 0;
 }
 
 static inline void qcom_remove_sysmon_subdev(struct qcom_sysmon *sysmon)
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c b/drivers/remoteproc/qcom_q6v5_adsp.c
index 79374d1de311..e1db2c7a08bd 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -436,9 +436,12 @@ static int adsp_probe(struct platform_device *pdev)
 
 	qcom_add_glink_subdev(rproc, &adsp->glink_subdev);
 	qcom_add_ssr_subdev(rproc, &adsp->ssr_subdev, desc->ssr_name);
-	adsp->sysmon = qcom_add_sysmon_subdev(rproc,
-					      desc->sysmon_name,
-					      desc->ssctl_id);
+	ret = qcom_add_sysmon_subdev(rproc,
+				     adsp->sysmon,
+				     desc->sysmon_name,
+				     desc->ssctl_id);
+	if (ret)
+		goto disable_pm;
 
 	ret = rproc_add(rproc);
 	if (ret)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index c86dc40cfb8c..7a256fdb2f64 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1340,7 +1340,9 @@ static int q6v5_probe(struct platform_device *pdev)
 	qcom_add_glink_subdev(rproc, &qproc->glink_subdev);
 	qcom_add_smd_subdev(rproc, &qproc->smd_subdev);
 	qcom_add_ssr_subdev(rproc, &qproc->ssr_subdev, "mpss");
-	qproc->sysmon = qcom_add_sysmon_subdev(rproc, "modem", 0x12);
+	ret = qcom_add_sysmon_subdev(rproc, qproc->sysmon, "modem", 0x12);
+	if (ret)
+		goto free_rproc;
 
 	ret = rproc_add(rproc);
 	if (ret)
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index b1e63fcd5fdf..942804b5fafa 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -301,9 +301,12 @@ static int adsp_probe(struct platform_device *pdev)
 	qcom_add_glink_subdev(rproc, &adsp->glink_subdev);
 	qcom_add_smd_subdev(rproc, &adsp->smd_subdev);
 	qcom_add_ssr_subdev(rproc, &adsp->ssr_subdev, desc->ssr_name);
-	adsp->sysmon = qcom_add_sysmon_subdev(rproc,
-					      desc->sysmon_name,
-					      desc->ssctl_id);
+	ret = qcom_add_sysmon_subdev(rproc,
+				     adsp->sysmon,
+				     desc->sysmon_name,
+				     desc->ssctl_id);
+	if (ret)
+		goto free_rproc;
 
 	ret = rproc_add(rproc);
 	if (ret)
diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
index e976a602b015..b17727dfc271 100644
--- a/drivers/remoteproc/qcom_sysmon.c
+++ b/drivers/remoteproc/qcom_sysmon.c
@@ -6,8 +6,10 @@
 #include <linux/module.h>
 #include <linux/notifier.h>
 #include <linux/slab.h>
+#include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/notifier.h>
+#include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
 #include <linux/remoteproc/qcom_rproc.h>
@@ -25,6 +27,7 @@ struct qcom_sysmon {
 
 	const char *name;
 
+	int shutdown_irq;
 	int ssctl_version;
 	int ssctl_instance;
 
@@ -34,6 +37,7 @@ struct qcom_sysmon {
 
 	struct rpmsg_endpoint *ept;
 	struct completion comp;
+	struct completion shutdown_comp;
 	struct mutex lock;
 
 	bool ssr_ack;
@@ -432,24 +436,35 @@ static int sysmon_notify(struct notifier_block *nb, unsigned long event,
 	return NOTIFY_DONE;
 }
 
+static irqreturn_t sysmon_shutdown_interrupt(int irq, void *data)
+{
+	struct qcom_sysmon *sysmon = data;
+
+	complete(&sysmon->shutdown_comp);
+
+	return IRQ_HANDLED;
+}
+
 /**
  * qcom_add_sysmon_subdev() - create a sysmon subdev for the given remoteproc
  * @rproc:	rproc context to associate the subdev with
+ * @rproc_sysmon: update sysmon context with a new qcom_sysmon object
  * @name:	name of this subdev, to use in SSR
  * @ssctl_instance: instance id of the ssctl QMI service
  *
- * Return: A new qcom_sysmon object, or NULL on failure
+ * Return: 0 on success, negative errno on failure
  */
-struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
-					   const char *name,
-					   int ssctl_instance)
+int qcom_add_sysmon_subdev(struct rproc *rproc,
+			   struct qcom_sysmon *rproc_sysmon,
+			   const char *name,
+			   int ssctl_instance)
 {
 	struct qcom_sysmon *sysmon;
 	int ret;
 
 	sysmon = kzalloc(sizeof(*sysmon), GFP_KERNEL);
 	if (!sysmon)
-		return NULL;
+		return -ENOMEM;
 
 	sysmon->dev = rproc->dev.parent;
 	sysmon->rproc = rproc;
@@ -458,13 +473,35 @@ struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
 	sysmon->ssctl_instance = ssctl_instance;
 
 	init_completion(&sysmon->comp);
+	init_completion(&sysmon->shutdown_comp);
 	mutex_init(&sysmon->lock);
 
+	sysmon->shutdown_irq = of_irq_get_byname(sysmon->dev->of_node,
+						 "shutdown-ack");
+	if (sysmon->shutdown_irq < 0) {
+		if (sysmon->shutdown_irq != -ENODATA) {
+			dev_err(sysmon->dev,
+				"failed to retrieve shutdown-ack IRQ\n");
+			return sysmon->shutdown_irq;
+		}
+	} else {
+		ret = devm_request_threaded_irq(sysmon->dev,
+						sysmon->shutdown_irq,
+						NULL, sysmon_shutdown_interrupt,
+						IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+						"q6v5 shutdown-ack", sysmon);
+		if (ret) {
+			dev_err(sysmon->dev,
+				"failed to acquire shutdown-ack IRQ\n");
+			return ret;
+		}
+	}
+
 	ret = qmi_handle_init(&sysmon->qmi, SSCTL_MAX_MSG_LEN, &ssctl_ops, NULL);
 	if (ret < 0) {
 		dev_err(sysmon->dev, "failed to initialize qmi handle\n");
 		kfree(sysmon);
-		return NULL;
+		return ret;
 	}
 
 	qmi_add_lookup(&sysmon->qmi, 43, 0, 0);
@@ -480,8 +517,9 @@ struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
 	mutex_lock(&sysmon_lock);
 	list_add(&sysmon->node, &sysmon_list);
 	mutex_unlock(&sysmon_lock);
+	rproc_sysmon = sysmon;
 
-	return sysmon;
+	return 0;
 }
 EXPORT_SYMBOL_GPL(qcom_add_sysmon_subdev);
 
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index 1152da49a18a..920e85202c5e 100644
--- a/drivers/remoteproc/qcom_wcnss.c
+++ b/drivers/remoteproc/qcom_wcnss.c
@@ -552,7 +552,10 @@ static int wcnss_probe(struct platform_device *pdev)
 	}
 
 	qcom_add_smd_subdev(rproc, &wcnss->smd_subdev);
-	wcnss->sysmon = qcom_add_sysmon_subdev(rproc, "wcnss", WCNSS_SSCTL_ID);
+	ret = qcom_add_sysmon_subdev(rproc, wcnss->sysmon,
+				     "wcnss", WCNSS_SSCTL_ID);
+	if (ret)
+		goto free_rproc;
 
 	ret = rproc_add(rproc);
 	if (ret)
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 16%]

* [PATCH v3 3/3] remoteproc: qcom: Wait for shutdown-ack/ind on sysmon shutdown
  2019-01-08 10:23 [PATCH v3 1/3] dt-bindings: remoteproc: qcom: Introduce shutdown-ack irq for Q6V5 Sibi Sankar
  2019-01-08 10:23 ` [PATCH v3 2/3] remoteproc: qcom: Add shutdown-ack irq Sibi Sankar
@ 2019-01-08 10:23 ` Sibi Sankar
  1 sibling, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-08 10:23 UTC (permalink / raw)
  To: bjorn.andersson
  Cc: robh+dt, andy.gross, david.brown, linux-arm-msm, linux-soc,
	devicetree, linux-kernel, tsoni, clew, akdwived, ohad,
	mark.rutland, linux-remoteproc, dianders, Sibi Sankar

After sending a sysmon shutdown request to the SSCTL service on the
subsystem, wait for the service to send shutdown-ack interrupt or
an indication message to signal the completion of graceful shutdown.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---

v2:
   * Correct the shutdown-irq wait time to 10 * HZ

 drivers/remoteproc/qcom_sysmon.c | 42 +++++++++++++++++++++++++++++++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
index b17727dfc271..19b732e1427d 100644
--- a/drivers/remoteproc/qcom_sysmon.c
+++ b/drivers/remoteproc/qcom_sysmon.c
@@ -37,6 +37,7 @@ struct qcom_sysmon {
 
 	struct rpmsg_endpoint *ept;
 	struct completion comp;
+	struct completion ind_comp;
 	struct completion shutdown_comp;
 	struct mutex lock;
 
@@ -141,6 +142,7 @@ static int sysmon_callback(struct rpmsg_device *rpdev, void *data, int count,
 }
 
 #define SSCTL_SHUTDOWN_REQ		0x21
+#define SSCTL_SHUTDOWN_READY_IND	0x21
 #define SSCTL_SUBSYS_EVENT_REQ		0x23
 
 #define SSCTL_MAX_MSG_LEN		7
@@ -256,6 +258,29 @@ static struct qmi_elem_info ssctl_subsys_event_resp_ei[] = {
 	{}
 };
 
+static struct qmi_elem_info ssctl_shutdown_ind_ei[] = {
+	{}
+};
+
+static void sysmon_ind_cb(struct qmi_handle *qmi, struct sockaddr_qrtr *sq,
+			  struct qmi_txn *txn, const void *data)
+{
+	struct qcom_sysmon *sysmon = container_of(qmi, struct qcom_sysmon, qmi);
+
+	complete(&sysmon->ind_comp);
+}
+
+static struct qmi_msg_handler qmi_indication_handler[] = {
+	{
+		.type = QMI_INDICATION,
+		.msg_id = SSCTL_SHUTDOWN_READY_IND,
+		.ei = ssctl_shutdown_ind_ei,
+		.decoded_size = 0,
+		.fn = sysmon_ind_cb
+	},
+	{}
+};
+
 /**
  * ssctl_request_shutdown() - request shutdown via SSCTL QMI service
  * @sysmon:	sysmon context
@@ -266,6 +291,8 @@ static void ssctl_request_shutdown(struct qcom_sysmon *sysmon)
 	struct qmi_txn txn;
 	int ret;
 
+	reinit_completion(&sysmon->ind_comp);
+	reinit_completion(&sysmon->shutdown_comp);
 	ret = qmi_txn_init(&sysmon->qmi, &txn, ssctl_shutdown_resp_ei, &resp);
 	if (ret < 0) {
 		dev_err(sysmon->dev, "failed to allocate QMI txn\n");
@@ -287,6 +314,17 @@ static void ssctl_request_shutdown(struct qcom_sysmon *sysmon)
 		dev_err(sysmon->dev, "shutdown request failed\n");
 	else
 		dev_dbg(sysmon->dev, "shutdown request completed\n");
+
+	if (sysmon->shutdown_irq > 0) {
+		ret = wait_for_completion_timeout(&sysmon->shutdown_comp,
+						  10 * HZ);
+		if (!ret) {
+			ret = try_wait_for_completion(&sysmon->ind_comp);
+			if (!ret)
+				dev_err(sysmon->dev,
+					"timeout waiting for shutdown ack\n");
+		}
+	}
 }
 
 /**
@@ -473,6 +511,7 @@ int qcom_add_sysmon_subdev(struct rproc *rproc,
 	sysmon->ssctl_instance = ssctl_instance;
 
 	init_completion(&sysmon->comp);
+	init_completion(&sysmon->ind_comp);
 	init_completion(&sysmon->shutdown_comp);
 	mutex_init(&sysmon->lock);
 
@@ -497,7 +536,8 @@ int qcom_add_sysmon_subdev(struct rproc *rproc,
 		}
 	}
 
-	ret = qmi_handle_init(&sysmon->qmi, SSCTL_MAX_MSG_LEN, &ssctl_ops, NULL);
+	ret = qmi_handle_init(&sysmon->qmi, SSCTL_MAX_MSG_LEN, &ssctl_ops,
+			      qmi_indication_handler);
 	if (ret < 0) {
 		dev_err(sysmon->dev, "failed to initialize qmi handle\n");
 		kfree(sysmon);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 19%]

* Re: [PATCH v4 1/8] dt-bindings: soc: qcom: Add remote-pid binding for GLINK SMEM
  2019-01-03 20:17 ` [PATCH v4 1/8] dt-bindings: soc: qcom: Add remote-pid binding for GLINK SMEM Bjorn Andersson
@ 2019-01-08 10:26   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-08 10:26 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: robh+dt, andy.gross, david.brown, dianders, linux-arm-msm,
	linux-soc, devicetree, linux-kernel, tsoni, clew, akdwived,
	mark.rutland, linux-remoteproc, evgreen, briannorris, sricharan,
	linux-remoteproc-owner

Hi Bjorn,
Thanks for the review!

On 2019-01-04 01:47, Bjorn Andersson wrote:
> On Fri 28 Dec 10:53 PST 2018, Sibi Sankar wrote:
> 
>> Add missing qcom,remote-pid dt binding required for GLINK SMEM
>> which specifies the remote endpoint of the GLINK edge.
>> 
>> Fixes: 2b41d6c8e696 ("dt-bindings: soc: qcom: Extend GLINK to cover
>> SMEM")
>> 
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> Reviewed-by: Doug Anderson <dianders@chromium.org>
>> Reviewed-by: Rob Herring <robh@kernel.org>
> 
> Thanks for the updates Sibi!
> 
> @Andy, as this relates to rpmsg I'll take this (patch 1/8) through the
> rpmsg tree.
> 
> And I'm picking 2-7 through the remoteproc tree.
> 
> 
> PS. Please use a --cover-letter when sending a series of patches.

sure will do... this was never meant to be a
series (started of as a single patch) :P

> 
> Regards,
> Bjorn
> 
>> ---
>> 
>> v3:
>>   * Fixed typo
>> 
>>  Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt | 5 +++++
>>  1 file changed, 5 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt 
>> b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> index 0b8cc533ca83..587bb1ddc8cc 100644
>> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> @@ -21,6 +21,11 @@ edge.
>>  	Definition: should specify the IRQ used by the remote processor to
>>  		    signal this processor about communication related events
>> 
>> +- qcom,remote-pid:
>> +	Usage: required for glink-smem
>> +	Value type: <u32>
>> +	Definition: specifies the identifier of the remote endpoint of this 
>> edge
>> +
>>  - qcom,rpm-msg-ram:
>>  	Usage: required for glink-rpm
>>  	Value type: <prop-encoded-array>
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v2 2/2] remoteproc: qcom: Add support for parsing fw dt bindings
  2019-01-03 23:44   ` Brian Norris
@ 2019-01-08 10:32     ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-08 10:32 UTC (permalink / raw)
  To: Brian Norris
  Cc: bjorn.andersson, david.brown, robh+dt, mark.rutland, andy.gross,
	akdwived, clew, linux-kernel, linux-arm-msm-owner, ohad,
	linux-remoteproc, devicetree

Hi Brian,
Thanks for the review!

On 2019-01-04 05:14, Brian Norris wrote:
> On Fri, Dec 28, 2018 at 10:18:19AM +0530, Sibi Sankar wrote:
>> Add support for parsing "firmware-name" dt bindings which specifies
>> the relative paths of mba/modem/pas image as strings. Fallback to
>> the default paths for mba/modem/pas image on -EINVAL.
>> 
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>>  drivers/remoteproc/qcom_q6v5_mss.c | 46 
>> +++++++++++++++++++++++-------
>>  drivers/remoteproc/qcom_q6v5_pas.c | 11 ++++++-
>>  2 files changed, 46 insertions(+), 11 deletions(-)
>> 
>> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
>> b/drivers/remoteproc/qcom_q6v5_mss.c
>> index 01be7314e176..c75179006e24 100644
>> --- a/drivers/remoteproc/qcom_q6v5_mss.c
>> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
>> @@ -188,6 +188,7 @@ struct q6v5 {
>>  	bool has_alt_reset;
>>  	int mpss_perm;
>>  	int mba_perm;
>> +	const char *hexagon_mdt_image;
>>  	int version;
>>  };
>> 
>> @@ -860,17 +861,27 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>>  	phys_addr_t min_addr = PHYS_ADDR_MAX;
>>  	phys_addr_t max_addr = 0;
>>  	bool relocate = false;
>> -	char seg_name[10];
>> +	char *fw_name;
>> +	size_t fw_name_len;
>>  	ssize_t offset;
>>  	size_t size = 0;
>>  	void *ptr;
>>  	int ret;
>>  	int i;
>> 
>> -	ret = request_firmware(&fw, "modem.mdt", qproc->dev);
>> +	fw_name_len = strlen(qproc->hexagon_mdt_image);
>> +	if (fw_name_len <= 4)
>> +		return -EINVAL;
>> +
>> +	fw_name = kstrdup(qproc->hexagon_mdt_image, GFP_KERNEL);
>> +	if (!fw_name)
>> +		return -ENOMEM;
>> +
>> +	ret = request_firmware(&fw, qproc->hexagon_mdt_image, qproc->dev);
>>  	if (ret < 0) {
>> -		dev_err(qproc->dev, "unable to load modem.mdt\n");
>> -		return ret;
>> +		dev_err(qproc->dev, "unable to load %s\n",
>> +			qproc->hexagon_mdt_image);
>> +		goto out;
>>  	}
>> 
>>  	/* Initialize the RMB validator */
>> @@ -918,10 +929,12 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>>  		ptr = qproc->mpss_region + offset;
>> 
>>  		if (phdr->p_filesz) {
>> -			snprintf(seg_name, sizeof(seg_name), "modem.b%02d", i);
>> -			ret = request_firmware(&seg_fw, seg_name, qproc->dev);
>> +			snprintf(fw_name + fw_name_len - 3, fw_name_len,
>> +				 "b%02d", i);
> 
> So, you're assuming that 'fw_name' ends in '.XXX' (for some 3-char 
> value
> of 'XXX')? Seems a bit odd. But if you really want this, it feels like
> you should enforce this, and either comment on what you're doing or 
> else
> use a proper computation that makes it clear (e.g., strlen("bin")).
> 
> Brian

we want to construct the names of the fw blobs
incrementally i.e xxx.xxx to xxx.bxx. Given
that we restrict the fw_name_len to be greater
than 4 at the beginning, I'll probably do
something like this.

/* Replace "xxx.xxx" with "xxx.bxx" */
sprintf(fw_name + fw_name_len - 3, "b%02d", i);

> 
>> +			ret = request_firmware(&seg_fw, fw_name, qproc->dev);
>>  			if (ret) {
>> -				dev_err(qproc->dev, "failed to load %s\n", seg_name);
>> +				dev_err(qproc->dev, "failed to load %s\n",
>> +					fw_name);
>>  				goto release_firmware;
>>  			}
>> 
>> @@ -960,6 +973,8 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>> 
>>  release_firmware:
>>  	release_firmware(fw);
>> +out:
>> +	kfree(fw_name);
>> 
>>  	return ret < 0 ? ret : 0;
>>  }
>> @@ -1075,9 +1090,10 @@ static int 
>> qcom_q6v5_register_dump_segments(struct rproc *rproc,
>>  	unsigned long i;
>>  	int ret;
>> 
>> -	ret = request_firmware(&fw, "modem.mdt", qproc->dev);
>> +	ret = request_firmware(&fw, qproc->hexagon_mdt_image, qproc->dev);
>>  	if (ret < 0) {
>> -		dev_err(qproc->dev, "unable to load modem.mdt\n");
>> +		dev_err(qproc->dev, "unable to load %s\n",
>> +			qproc->hexagon_mdt_image);
>>  		return ret;
>>  	}
>> 
>> @@ -1253,6 +1269,8 @@ static int q6v5_probe(struct platform_device 
>> *pdev)
>>  	const struct rproc_hexagon_res *desc;
>>  	struct q6v5 *qproc;
>>  	struct rproc *rproc;
>> +	const char *mba_image;
>> +	const char *fw_name[2];
>>  	int ret;
>> 
>>  	desc = of_device_get_match_data(&pdev->dev);
>> @@ -1262,8 +1280,15 @@ static int q6v5_probe(struct platform_device 
>> *pdev)
>>  	if (desc->need_mem_protection && !qcom_scm_is_available())
>>  		return -EPROBE_DEFER;
>> 
>> +	ret = of_property_read_string_array(pdev->dev.of_node, 
>> "firmware-name",
>> +					    fw_name, 2);
>> +	if (ret != -EINVAL && ret != 2)
>> +		return ret > 0 ? -EINVAL : ret;
>> +
>> +	mba_image = (ret != 2) ? desc->hexagon_mba_image : fw_name[0];
>> +
>>  	rproc = rproc_alloc(&pdev->dev, pdev->name, &q6v5_ops,
>> -			    desc->hexagon_mba_image, sizeof(*qproc));
>> +			    mba_image, sizeof(*qproc));
>>  	if (!rproc) {
>>  		dev_err(&pdev->dev, "failed to allocate rproc\n");
>>  		return -ENOMEM;
>> @@ -1272,6 +1297,7 @@ static int q6v5_probe(struct platform_device 
>> *pdev)
>>  	qproc = (struct q6v5 *)rproc->priv;
>>  	qproc->dev = &pdev->dev;
>>  	qproc->rproc = rproc;
>> +	qproc->hexagon_mdt_image = (ret != 2) ? "modem.mdt" : fw_name[1];
>>  	platform_set_drvdata(pdev, qproc);
>> 
>>  	ret = q6v5_init_mem(qproc, pdev);
>> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c 
>> b/drivers/remoteproc/qcom_q6v5_pas.c
>> index b1e63fcd5fdf..141c7da29e9a 100644
>> --- a/drivers/remoteproc/qcom_q6v5_pas.c
>> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
>> @@ -258,6 +258,8 @@ static int adsp_probe(struct platform_device 
>> *pdev)
>>  	const struct adsp_data *desc;
>>  	struct qcom_adsp *adsp;
>>  	struct rproc *rproc;
>> +	const char *fw_name;
>> +	const char *of_fw_name;
>>  	int ret;
>> 
>>  	desc = of_device_get_match_data(&pdev->dev);
>> @@ -267,8 +269,15 @@ static int adsp_probe(struct platform_device 
>> *pdev)
>>  	if (!qcom_scm_is_available())
>>  		return -EPROBE_DEFER;
>> 
>> +	ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
>> +				      &of_fw_name);
>> +	if (ret && ret != -EINVAL)
>> +		return ret;
>> +
>> +	fw_name = ret ? desc->firmware_name : of_fw_name;
>> +
>>  	rproc = rproc_alloc(&pdev->dev, pdev->name, &adsp_ops,
>> -			    desc->firmware_name, sizeof(*adsp));
>> +			    fw_name, sizeof(*adsp));
>>  	if (!rproc) {
>>  		dev_err(&pdev->dev, "unable to allocate remoteproc\n");
>>  		return -ENOMEM;
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v2 1/2] dt-bindings: remoteproc: qcom: Add firmware bindings for Q6V5
      [irrelevant]           ` <20190105015430.GA67838@google.com>
@ 2019-01-08 10:50             ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-08 10:50 UTC (permalink / raw)
  To: Brian Norris
  Cc: Bjorn Andersson, david.brown, robh+dt, mark.rutland, andy.gross,
	akdwived, clew, linux-kernel, linux-arm-msm-owner, ohad,
	linux-remoteproc, devicetree, linux-remoteproc-owner

Hi Brian/Bjorn,
Thanks for the review!

On 2019-01-05 07:24, Brian Norris wrote:
> Hi again,
> 
> On Thu, Jan 03, 2019 at 04:11:58PM -0800, Brian Norris wrote:
>> On Thu, Jan 03, 2019 at 04:01:45PM -0800, Bjorn Andersson wrote:
>> > I share your concern about this, but I came to suggest this as the
>> > driver cares about platforms but the firmware is (often?)
>> > device/product-specific.
>> >
>> > E.g. we will serve the MTP and Pixel 3 with the qcom,sdm845-adsp-pas
>> > compatible, but they are unlikely to run the same adsp firmware. This
>> > allows the individual dtb to specify which firmware the driver should
>> > use.
>> 
>> I understand this, but that still doesn't mean we should be suggesting
>> each DTB to clutter the top-level firmware search path, especially 
>> since
>> lazy people will probably just use "modem.mdt" and similar. That means
>> you no longer can ship the same rootfs that supports both QCOM and
>> <other> modems, if <other> modem also uses the same lazy format.
>> 
>> It seems like a much better practice to at least enforce a particular
>> prefix to things. e.g., the driver could assume:
>> 
>>   qcom/sdm845-adsp-pas/ (or if you must, just qcom/)
>> 
>> and your DTB only gets to add .../<your-string-here> to that path.
>> 
>> In case it isn't clear: I think it's also severely misguided that the
>> existing driver gets away with lines like
>> 
>> 	request_firmware(&fw, "modem.mdt", ...);
>> 
>> today ;)
> 
> To add to my thoughts, since I think maybe Sibi was a little unclear of
> my thoughts:
> 
> One of my primary concerns with the existing approach is that it's
> basically a complete free-for-all. We should have some minimal 
> standards
> (enforced in code) such that our DTB can never point us at something
> like /lib/firmware/<other-vendor>/foo.bin (or /lib/firmware/modem.mdt;
> or lots of other bad examples). This could probably be done simply by
> always prefixing 'qcom/' (I don't remember -- does request_firmware()
> follow '..'? e.g., 'firmware-name = "../bar/foo.bin"'.)
> 
> As a bonus: it would be very nice if we can provide a little more
> structure by default, and avoid arbitrary hierarchy in the DTS. That's
> where I brought up ath10k's "variant" as an example; if we can use
> 'compatible' to capture most of this particular Hexagon core's
> properties, then we only leave a single level of variability to the 
> DTS.
> 
> But I might be off-base with the "bonus" paragraph. So I'd also be
> somewhat happy with something much less ambitious, like just a built-in
> prefix ('qcom/').
> 
> And you can also just ignore my thoughts entirely (and I'll be even 
> less
> happy), since Rob did already provide his Reviewed-by ;) I mostly 
> wanted
> to give food for thought, in the hopes that something in here would 
> help
> improve this a bit.

Bjorn,
let me know how you want it implemented.
I am okay with either of the following:
* (variant tag based solution)
or
* (simply going ahead with what we have now).

> 
> Regards,
> Brian

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v2 4/7] remoteproc: q6v5-mss: Vote for rpmh power domains
      [irrelevant] ` <20190106080915.4493-5-bjorn.andersson@linaro.org>
@ 2019-01-09 14:39   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-09 14:39 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland, Russell King,
	Ulf Hansson, Arun Kumar Neelakantam, linux-arm-msm, linux-soc,
	devicetree, linux-kernel, linux-kernel-owner

Hi Bjorn,
With the changes suggested below:

Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Tested-by: Sibi Sankar <sibis@codeaurora.org>

On 2019-01-06 13:39, Bjorn Andersson wrote:
> From: Rajendra Nayak <rnayak@codeaurora.org>
> 
> With rpmh ARC resources being modelled as power domains with 
> performance
> state, we need to proxy vote on these for SDM845.
> Add support to vote on multiple of them, now that genpd supports
> associating mutliple power domains to a device.
> 
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
> [bjorn: Drop device link, improve error handling, name things "proxy"]
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> This is v3 of this patch, but updated to cover "loadstate". v2 can be
> found here:
> https://lore.kernel.org/lkml/20180904071046.8152-1-rnayak@codeaurora.org/
> 
> Changes since v2:
> - Drop device links, as we can do active and proxy votes using device 
> links
> - Improved error handling, by unrolling some votes on failure
> - Rename things proxy, to follow naming of "proxy" and "active"
> 
>  drivers/remoteproc/qcom_q6v5_mss.c | 115 ++++++++++++++++++++++++++++-
>  1 file changed, 111 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index 01be7314e176..62cf16ddb7af 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -25,6 +25,8 @@
>  #include <linux/of_address.h>
>  #include <linux/of_device.h>
>  #include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/pm_runtime.h>
>  #include <linux/regmap.h>
>  #include <linux/regulator/consumer.h>
>  #include <linux/remoteproc.h>
> @@ -131,6 +133,7 @@ struct rproc_hexagon_res {
>  	char **proxy_clk_names;
>  	char **reset_clk_names;
>  	char **active_clk_names;
> +	char **proxy_pd_names;
>  	int version;
>  	bool need_mem_protection;
>  	bool has_alt_reset;
> @@ -156,9 +159,11 @@ struct q6v5 {
>  	struct clk *active_clks[8];
>  	struct clk *reset_clks[4];
>  	struct clk *proxy_clks[4];
> +	struct device *proxy_pds[3];
>  	int active_clk_count;
>  	int reset_clk_count;
>  	int proxy_clk_count;
> +	int proxy_pd_count;
> 
>  	struct reg_info active_regs[1];
>  	struct reg_info proxy_regs[3];
> @@ -321,6 +326,41 @@ static void q6v5_clk_disable(struct device *dev,
>  		clk_disable_unprepare(clks[i]);
>  }
> 
> +static int q6v5_pds_enable(struct q6v5 *qproc, struct device **pds,
> +			   size_t pd_count)
> +{
> +	int ret;
> +	int i;
> +
> +	for (i = 0; i < pd_count; i++) {
> +		dev_pm_genpd_set_performance_state(pds[i], INT_MAX);
> +		ret = pm_runtime_get_sync(pds[i]);
> +		if (ret < 0)
> +			goto unroll_pd_votes;
> +	}
> +
> +	return 0;
> +
> +unroll_pd_votes:
> +	for (i--; i >= 0; i--) {
> +		dev_pm_genpd_set_performance_state(pds[i], 0);
> +		pm_runtime_put(pds[i]);
> +	}
> +
> +	return ret;
> +};
> +
> +static void q6v5_pds_disable(struct q6v5 *qproc, struct device **pds,
> +			     size_t pd_count)
> +{
> +	int i;
> +
> +	for (i = 0; i < pd_count; i++) {
> +		dev_pm_genpd_set_performance_state(pds[i], 0);
> +		pm_runtime_put(pds[i]);
> +	}
> +}
> +
>  static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int 
> *current_perm,
>  				   bool remote_owner, phys_addr_t addr,
>  				   size_t size)
> @@ -690,11 +730,17 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> 
>  	qcom_q6v5_prepare(&qproc->q6v5);
> 
> +	ret = q6v5_pds_enable(qproc, qproc->proxy_pds, 
> qproc->proxy_pd_count);
> +	if (ret < 0) {
> +		dev_err(qproc->dev, "failed to enable proxy power domains\n");
> +		goto disable_irqs;
> +	}
> +
>  	ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
>  				    qproc->proxy_reg_count);
>  	if (ret) {
>  		dev_err(qproc->dev, "failed to enable proxy supplies\n");
> -		goto disable_irqs;
> +		goto disable_proxy_pds;
>  	}
> 
>  	ret = q6v5_clk_enable(qproc->dev, qproc->proxy_clks,
> @@ -791,6 +837,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>  disable_proxy_reg:
>  	q6v5_regulator_disable(qproc, qproc->proxy_regs,
>  			       qproc->proxy_reg_count);
> +disable_proxy_pds:
> +	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
>  disable_irqs:
>  	qcom_q6v5_unprepare(&qproc->q6v5);
> 
> @@ -1121,6 +1169,7 @@ static void qcom_msa_handover(struct qcom_q6v5 
> *q6v5)
>  			 qproc->proxy_clk_count);
>  	q6v5_regulator_disable(qproc, qproc->proxy_regs,
>  			       qproc->proxy_reg_count);
> +	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);

we should call proxy pds_disable on mba_reclaim
as well:

ret = qcom_q6v5_unprepare(&qproc->q6v5);
if (ret) {
   ...
   q6v5_pds_disable(...);
}

>  }
> 
>  static int q6v5_init_mem(struct q6v5 *qproc, struct platform_device 
> *pdev)
> @@ -1181,6 +1230,45 @@ static int q6v5_init_clocks(struct device *dev,
> struct clk **clks,
>  	return i;
>  }
> 
> +static int q6v5_pds_attach(struct device *dev, struct device **devs,
> +			   char **pd_names)
> +{
> +	size_t num_pds = 0;
> +	int ret;
> +	int i;
> +
> +	if (!pd_names)
> +		return 0;
> +
> +	while (pd_names[num_pds])
> +		num_pds++;
> +
> +	for (i = 0; i < num_pds; i++) {
> +		devs[i] = dev_pm_domain_attach_by_name(dev, pd_names[i]);
> +		if (IS_ERR(devs[i])) {
> +			ret = PTR_ERR(devs[i]);
> +			goto unroll_attach;
> +		}
> +	}
> +
> +	return num_pds;
> +
> +unroll_attach:
> +	for (i--; i >= 0; i--)
> +		dev_pm_domain_detach(devs[i], false);
> +
> +	return ret;
> +};
> +
> +static void q6v5_pds_detach(struct q6v5 *qproc, struct device **pds,
> +			    size_t pd_count)
> +{
> +	int i;
> +
> +	for (i = 0; i < pd_count; i++)
> +		dev_pm_domain_detach(pds[i], false);
> +}
> +
>  static int q6v5_init_reset(struct q6v5 *qproc)
>  {
>  	qproc->mss_restart = devm_reset_control_get_exclusive(qproc->dev,
> @@ -1322,10 +1410,18 @@ static int q6v5_probe(struct platform_device 
> *pdev)
>  	}
>  	qproc->active_reg_count = ret;
> 
> +	ret = q6v5_pds_attach(&pdev->dev, qproc->proxy_pds,
> +			      desc->proxy_pd_names);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Failed to init power domains\n");

Should be "Failed to attach proxy power domains"

> +		goto free_rproc;
> +	}
> +	qproc->proxy_pd_count = ret;
> +
>  	qproc->has_alt_reset = desc->has_alt_reset;
>  	ret = q6v5_init_reset(qproc);
>  	if (ret)
> -		goto free_rproc;
> +		goto detach_proxy_pds;
> 
>  	qproc->version = desc->version;
>  	qproc->need_mem_protection = desc->need_mem_protection;
> @@ -1333,7 +1429,7 @@ static int q6v5_probe(struct platform_device 
> *pdev)
>  	ret = qcom_q6v5_init(&qproc->q6v5, pdev, rproc, 
> MPSS_CRASH_REASON_SMEM,
>  			     qcom_msa_handover);
>  	if (ret)
> -		goto free_rproc;
> +		goto detach_proxy_pds;
> 
>  	qproc->mpss_perm = BIT(QCOM_SCM_VMID_HLOS);
>  	qproc->mba_perm = BIT(QCOM_SCM_VMID_HLOS);
> @@ -1344,10 +1440,12 @@ static int q6v5_probe(struct platform_device 
> *pdev)
> 
>  	ret = rproc_add(rproc);
>  	if (ret)
> -		goto free_rproc;
> +		goto detach_proxy_pds;
> 
>  	return 0;
> 
> +detach_proxy_pds:
> +	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
>  free_rproc:
>  	rproc_free(rproc);
> 
> @@ -1364,6 +1462,9 @@ static int q6v5_remove(struct platform_device 
> *pdev)
>  	qcom_remove_glink_subdev(qproc->rproc, &qproc->glink_subdev);
>  	qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
>  	qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
> +
> +	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> +
>  	rproc_free(qproc->rproc);
> 
>  	return 0;
> @@ -1388,6 +1489,12 @@ static const struct rproc_hexagon_res sdm845_mss 
> = {
>  			"mnoc_axi",
>  			NULL
>  	},
> +	.proxy_pd_names = (char*[]){
> +			"cx",
> +			"mx",
> +			"mss",
> +			NULL
> +	},
>  	.need_mem_protection = true,
>  	.has_alt_reset = true,
>  	.version = MSS_SDM845,

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 15%]

* Re: [PATCH v2 5/7] remoteproc: q6v5-mss: Active powerdomain for SDM845
      [irrelevant] ` <20190106080915.4493-6-bjorn.andersson@linaro.org>
@ 2019-01-09 14:40   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-09 14:40 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland, Russell King,
	Ulf Hansson, Arun Kumar Neelakantam, linux-arm-msm, linux-soc,
	devicetree, linux-kernel, linux-kernel-owner

On 2019-01-06 13:39, Bjorn Andersson wrote:
> The SDM845 MSS needs the load_state powerdomain voted for during the
> duration of the MSS being powered on, to let the AOSS know that it may
> not perform certain power save measures. So vote for this.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v1:
> - New patch
> 

Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Tested-by: Sibi Sankar <sibis@codeaurora.org>

>  drivers/remoteproc/qcom_q6v5_mss.c | 31 ++++++++++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
> b/drivers/remoteproc/qcom_q6v5_mss.c
> index 62cf16ddb7af..7f86d9c551c4 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -133,6 +133,7 @@ struct rproc_hexagon_res {
>  	char **proxy_clk_names;
>  	char **reset_clk_names;
>  	char **active_clk_names;
> +	char **active_pd_names;
>  	char **proxy_pd_names;
>  	int version;
>  	bool need_mem_protection;
> @@ -159,10 +160,12 @@ struct q6v5 {
>  	struct clk *active_clks[8];
>  	struct clk *reset_clks[4];
>  	struct clk *proxy_clks[4];
> +	struct device *active_pds[1];
>  	struct device *proxy_pds[3];
>  	int active_clk_count;
>  	int reset_clk_count;
>  	int proxy_clk_count;
> +	int active_pd_count;
>  	int proxy_pd_count;
> 
>  	struct reg_info active_regs[1];
> @@ -730,10 +733,16 @@ static int q6v5_mba_load(struct q6v5 *qproc)
> 
>  	qcom_q6v5_prepare(&qproc->q6v5);
> 
> +	ret = q6v5_pds_enable(qproc, qproc->active_pds, 
> qproc->active_pd_count);
> +	if (ret < 0) {
> +		dev_err(qproc->dev, "failed to enable active power domains\n");
> +		goto disable_irqs;
> +	}
> +
>  	ret = q6v5_pds_enable(qproc, qproc->proxy_pds, 
> qproc->proxy_pd_count);
>  	if (ret < 0) {
>  		dev_err(qproc->dev, "failed to enable proxy power domains\n");
> -		goto disable_irqs;
> +		goto disable_active_pds;
>  	}
> 
>  	ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
> @@ -839,6 +848,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>  			       qproc->proxy_reg_count);
>  disable_proxy_pds:
>  	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> +disable_active_pds:
> +	q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
>  disable_irqs:
>  	qcom_q6v5_unprepare(&qproc->q6v5);
> 
> @@ -878,6 +889,7 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
>  			 qproc->active_clk_count);
>  	q6v5_regulator_disable(qproc, qproc->active_regs,
>  			       qproc->active_reg_count);
> +	q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
> 
>  	/* In case of failure or coredump scenario where reclaiming MBA 
> memory
>  	 * could not happen reclaim it here.
> @@ -1410,11 +1422,19 @@ static int q6v5_probe(struct platform_device 
> *pdev)
>  	}
>  	qproc->active_reg_count = ret;
> 
> +	ret = q6v5_pds_attach(&pdev->dev, qproc->active_pds,
> +			      desc->active_pd_names);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Failed to attach active power domains\n");
> +		goto free_rproc;
> +	}
> +	qproc->active_pd_count = ret;
> +
>  	ret = q6v5_pds_attach(&pdev->dev, qproc->proxy_pds,
>  			      desc->proxy_pd_names);
>  	if (ret < 0) {
>  		dev_err(&pdev->dev, "Failed to init power domains\n");
> -		goto free_rproc;
> +		goto detach_active_pds;
>  	}
>  	qproc->proxy_pd_count = ret;
> 
> @@ -1446,6 +1466,8 @@ static int q6v5_probe(struct platform_device 
> *pdev)
> 
>  detach_proxy_pds:
>  	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> +detach_active_pds:
> +	q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
>  free_rproc:
>  	rproc_free(rproc);
> 
> @@ -1463,6 +1485,7 @@ static int q6v5_remove(struct platform_device 
> *pdev)
>  	qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
>  	qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
> 
> +	q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
>  	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> 
>  	rproc_free(qproc->rproc);
> @@ -1489,6 +1512,10 @@ static const struct rproc_hexagon_res sdm845_mss 
> = {
>  			"mnoc_axi",
>  			NULL
>  	},
> +	.active_pd_names = (char*[]){
> +			"load_state",
> +			NULL
> +	},
>  	.proxy_pd_names = (char*[]){
>  			"cx",
>  			"mx",

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 15%]

* [PATCH v5 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
@ 2019-01-09 17:00 Sibi Sankar
  2019-01-11 21:06 ` Doug Anderson
  0 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-01-09 17:00 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, david.brown, dianders
  Cc: linux-arm-msm, linux-soc, devicetree, linux-kernel, tsoni, clew,
	akdwived, mark.rutland, linux-remoteproc, evgreen, briannorris,
	sricharan, Sibi Sankar

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
---

v5:
  * Use qmp_aop updated dt binding

v3:
  * with shutdown-ack irq redesign make it mandatory,
    merge multiple patches into a single one

v2:
  * Fixed style changes
  * Added missing clocks in the dt-bindings
  * Split mss remoteproc node into a number of patches

This patch depends on the following bindings:
https://patchwork.kernel.org/patch/10662089/ - mba/mpss reserved regions
https://patchwork.kernel.org/patch/10657325/ - pdc reset node
https://patchwork.kernel.org/patch/10753659/ - rpmhpd dt node
https://patchwork.kernel.org/patch/10749469/ - AOP QMP dt bindings
https://patchwork.kernel.org/patch/10751757/ - shutdown-irq binding

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 60 ++++++++++++++++++++++++++++
 1 file changed, 60 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 5da9fa1feb8a..e021b15f87fd 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1366,6 +1366,66 @@
 			};
 		};
 
+		remoteproc@4080000 {
+			compatible = "qcom,sdm845-mss-pil";
+			reg = <0x04080000 0x408>, <0x04180000 0x48>;
+			reg-names = "qdsp6", "rmb";
+
+			interrupts-extended =
+				<&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog", "fatal", "ready",
+					  "handover", "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+				 <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+				 <&gcc GCC_BOOT_ROM_AHB_CLK>,
+				 <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+				 <&gcc GCC_MSS_SNOC_AXI_CLK>,
+				 <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+				 <&gcc GCC_PRNG_AHB_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "iface", "bus", "mem", "gpll0_mss",
+				      "snoc_axi", "mnoc_axi", "prng", "xo";
+
+			qcom,smem-states = <&modem_smp2p_out 0>;
+			qcom,smem-state-names = "stop";
+
+			resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+				 <&pdc_reset PDC_MODEM_SYNC_RESET>;
+			reset-names = "mss_restart", "pdc_reset";
+
+			qcom,halt-regs = <&tcsr_mutex_regs
+						0x23000 0x25000 0x24000>;
+
+			power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
+					<&rpmhpd SDM845_CX>,
+					<&rpmhpd SDM845_MX>,
+					<&rpmhpd SDM845_MSS>;
+			power-domain-names = "load_state", "cx", "mx", "mss";
+
+			mba {
+				memory-region = <&mba_region>;
+			};
+
+			mpss {
+				memory-region = <&mpss_region>;
+			};
+
+			glink-edge {
+				interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+				label = "modem";
+				qcom,remote-pid = <1>;
+				mboxes = <&apss_shared 12>;
+				mbox-names = "mpss_smem";
+			};
+		};
+
 		usb_1_hsphy: phy@88e2000 {
 			compatible = "qcom,sdm845-qusb2-phy";
 			reg = <0x88e2000 0x400>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 19%]

* Re: [PATCH v5 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
  2019-01-09 17:00 [PATCH v5 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Sibi Sankar
@ 2019-01-11 21:06 ` Doug Anderson
  2019-01-12 18:42   ` Bjorn Andersson
  0 siblings, 1 reply; 200+ results
From: Doug Anderson @ 2019-01-11 21:06 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: Bjorn Andersson, Rob Herring, Andy Gross, David Brown,
	linux-arm-msm, open list:ARM/QUALCOMM SUPPORT, devicetree, LKML,
	tsoni, clew, akdwived, Mark Rutland, linux-remoteproc,
	Evan Green, Brian Norris, sricharan

Hi,

On Wed, Jan 9, 2019 at 9:00 AM Sibi Sankar <sibis@codeaurora.org> wrote:
>
> This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.
>
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> v5:
>   * Use qmp_aop updated dt binding

nit: since this is now a singleton patch in v5 (because patches #1 -
#7 landed), the general policy is to drop the "8/8" in the subject.
AKA I believe the subject of the patch ought to have been:

[PATCH v5] arm64: dts: qcom: sdm845: Add Q6V5 MSS node


> v3:
>   * with shutdown-ack irq redesign make it mandatory,
>     merge multiple patches into a single one
>
> v2:
>   * Fixed style changes
>   * Added missing clocks in the dt-bindings
>   * Split mss remoteproc node into a number of patches
>
> This patch depends on the following bindings:
> https://patchwork.kernel.org/patch/10662089/ - mba/mpss reserved regions
> https://patchwork.kernel.org/patch/10657325/ - pdc reset node
> https://patchwork.kernel.org/patch/10753659/ - rpmhpd dt node
> https://patchwork.kernel.org/patch/10749469/ - AOP QMP dt bindings
> https://patchwork.kernel.org/patch/10751757/ - shutdown-irq binding
>
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 60 ++++++++++++++++++++++++++++
>  1 file changed, 60 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 5da9fa1feb8a..e021b15f87fd 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1366,6 +1366,66 @@
>                         };
>                 };
>
> +               remoteproc@4080000 {

It would be handy if you added a label here, AKA:

mss_pil: remoteproc@4080000 {

It's expected that boards will need to refer to this node so that they
can provide a firmware-name, so you need to give them a label to grab
onto.

...and actually, I wonder if boards will also need to be able to set
status = "okay"?  Right now they don't because you don't have a status
= "disabled" in sdm845.dtsi, but maybe you should?  Are there ever
going to be any boards with sdm845 that don't hook up the modem?


-Doug

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v5 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
  2019-01-11 21:06 ` Doug Anderson
@ 2019-01-12 18:42   ` Bjorn Andersson
  0 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-12 18:42 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Sibi Sankar, Rob Herring, Andy Gross, David Brown, linux-arm-msm,
	open list:ARM/QUALCOMM SUPPORT, devicetree, LKML, tsoni, clew,
	akdwived, Mark Rutland, linux-remoteproc, Evan Green,
	Brian Norris, sricharan

On Fri 11 Jan 13:06 PST 2019, Doug Anderson wrote:

> Hi,
> 
> On Wed, Jan 9, 2019 at 9:00 AM Sibi Sankar <sibis@codeaurora.org> wrote:
> >
> > This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.
> >
> > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> > v5:
> >   * Use qmp_aop updated dt binding
> 
> nit: since this is now a singleton patch in v5 (because patches #1 -
> #7 landed), the general policy is to drop the "8/8" in the subject.
> AKA I believe the subject of the patch ought to have been:
> 
> [PATCH v5] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
> 
> 
> > v3:
> >   * with shutdown-ack irq redesign make it mandatory,
> >     merge multiple patches into a single one
> >
> > v2:
> >   * Fixed style changes
> >   * Added missing clocks in the dt-bindings
> >   * Split mss remoteproc node into a number of patches
> >
> > This patch depends on the following bindings:
> > https://patchwork.kernel.org/patch/10662089/ - mba/mpss reserved regions
> > https://patchwork.kernel.org/patch/10657325/ - pdc reset node
> > https://patchwork.kernel.org/patch/10753659/ - rpmhpd dt node
> > https://patchwork.kernel.org/patch/10749469/ - AOP QMP dt bindings
> > https://patchwork.kernel.org/patch/10751757/ - shutdown-irq binding
> >
> >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 60 ++++++++++++++++++++++++++++
> >  1 file changed, 60 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index 5da9fa1feb8a..e021b15f87fd 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -1366,6 +1366,66 @@
> >                         };
> >                 };
> >
> > +               remoteproc@4080000 {
> 
> It would be handy if you added a label here, AKA:
> 
> mss_pil: remoteproc@4080000 {
> 
> It's expected that boards will need to refer to this node so that they
> can provide a firmware-name, so you need to give them a label to grab
> onto.
> 

I agree.

> ...and actually, I wonder if boards will also need to be able to set
> status = "okay"?  Right now they don't because you don't have a status
> = "disabled" in sdm845.dtsi, but maybe you should?  Are there ever
> going to be any boards with sdm845 that don't hook up the modem?
> 

The modem is status "ok" on my SDA845 device (but haven't verified
upstream myself yet), so I think it's fine to leave it enabled.

But merging this as is will cause the modem to crash repeatedly until
rmtfs is present. Sibi is making progress on tying this to rmtfs, which
would be accompanied by the following commit:

https://lore.kernel.org/lkml/20180524192141.20323-1-ramon.fried@gmail.com/

I'm okay with merging that now, to unblock the merge of this patch.
Would appreciate an Ack on this.


Also, Sibi, the glink-edge binding doesn't define the mbox-names
property, so please drop it.

Regards,
Bjorn

^ permalink raw reply	[relevance 0%]

* [PATCH v6] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
@ 2019-01-14 19:22 " Sibi Sankar
  2019-01-17 23:05 ` Doug Anderson
  0 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-01-14 19:22 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, david.brown, dianders
  Cc: linux-arm-msm, linux-soc, devicetree, linux-kernel, tsoni, clew,
	akdwived, mark.rutland, linux-remoteproc, evgreen, briannorris,
	sricharan, Sibi Sankar

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
---

v6:
  * Drop unused mbox-names property
  * Add mss_pil label
  * Rebased to Andy's for-next

v5:
  * Use qmp_aop updated dt binding

v3:
  * with shutdown-ack irq redesign make it mandatory,
    merge multiple patches into a single one

v2:
  * Fixed style changes
  * Added missing clocks in the dt-bindings
  * Split mss remoteproc node into a number of patches

This patch depends on the following bindings:
https://patchwork.kernel.org/patch/10662089/ - mba/mpss reserved regions
https://patchwork.kernel.org/patch/10657325/ - pdc reset node
https://patchwork.kernel.org/patch/10755191/ - rpmhpd dt node
https://patchwork.kernel.org/patch/10755197/ - rpmhpd dt binding
https://patchwork.kernel.org/patch/10749469/ - AOP QMP dt binding
https://patchwork.kernel.org/patch/10751757/ - shutdown-irq binding
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 59 ++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 7d05e967c9ee..b5a58e508bb2 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1440,6 +1440,65 @@
 			};
 		};
 
+		mss_pil: remoteproc@4080000 {
+			compatible = "qcom,sdm845-mss-pil";
+			reg = <0x04080000 0x408>, <0x04180000 0x48>;
+			reg-names = "qdsp6", "rmb";
+
+			interrupts-extended =
+				<&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog", "fatal", "ready",
+					  "handover", "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+				 <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+				 <&gcc GCC_BOOT_ROM_AHB_CLK>,
+				 <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+				 <&gcc GCC_MSS_SNOC_AXI_CLK>,
+				 <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+				 <&gcc GCC_PRNG_AHB_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "iface", "bus", "mem", "gpll0_mss",
+				      "snoc_axi", "mnoc_axi", "prng", "xo";
+
+			qcom,smem-states = <&modem_smp2p_out 0>;
+			qcom,smem-state-names = "stop";
+
+			resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+				 <&pdc_reset PDC_MODEM_SYNC_RESET>;
+			reset-names = "mss_restart", "pdc_reset";
+
+			qcom,halt-regs = <&tcsr_mutex_regs
+						0x23000 0x25000 0x24000>;
+
+			power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
+					<&rpmhpd SDM845_CX>,
+					<&rpmhpd SDM845_MX>,
+					<&rpmhpd SDM845_MSS>;
+			power-domain-names = "load_state", "cx", "mx", "mss";
+
+			mba {
+				memory-region = <&mba_region>;
+			};
+
+			mpss {
+				memory-region = <&mpss_region>;
+			};
+
+			glink-edge {
+				interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+				label = "modem";
+				qcom,remote-pid = <1>;
+				mboxes = <&apss_shared 12>;
+			};
+		};
+
 		sdhc_2: sdhci@8804000 {
 			compatible = "qcom,sdm845-sdhci", "qcom,sdhci-msm-v5";
 			reg = <0x8804000 0x1000>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 19%]

* [PATCH v3] remoteproc: qcom: Add support for parsing fw dt bindings
@ 2019-01-14 19:50 Sibi Sankar
  2019-01-30 21:04 ` Bjorn Andersson
  0 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-01-14 19:50 UTC (permalink / raw)
  To: bjorn.andersson, briannorris, david.brown, robh+dt, mark.rutland,
	andy.gross
  Cc: akdwived, clew, linux-kernel, linux-arm-msm-owner, ohad,
	linux-remoteproc, devicetree, dianders, Sibi Sankar

Add support for parsing "firmware-name" dt bindings which specifies
the relative paths of mba/modem/pas image as strings. Fallback to
the default paths for mba/modem/pas image on -EINVAL.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---

v3:
 * Fixed minor code style issues
 * Add comments for firmware blob name generation
   and use sprintf instead

 drivers/remoteproc/qcom_q6v5_mss.c | 47 +++++++++++++++++++++++-------
 drivers/remoteproc/qcom_q6v5_pas.c |  9 +++++-
 2 files changed, 45 insertions(+), 11 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index c86dc40cfb8c..41e92a025d21 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -188,6 +188,7 @@ struct q6v5 {
 	bool has_alt_reset;
 	int mpss_perm;
 	int mba_perm;
+	const char *hexagon_mdt_image;
 	int version;
 };
 
@@ -860,17 +861,26 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
 	phys_addr_t min_addr = PHYS_ADDR_MAX;
 	phys_addr_t max_addr = 0;
 	bool relocate = false;
-	char seg_name[10];
+	char *fw_name;
+	size_t fw_name_len;
 	ssize_t offset;
 	size_t size = 0;
 	void *ptr;
 	int ret;
 	int i;
 
-	ret = request_firmware(&fw, "modem.mdt", qproc->dev);
+	fw_name_len = strlen(qproc->hexagon_mdt_image);
+	if (fw_name_len <= 4)
+		return -EINVAL;
+
+	fw_name = kstrdup(qproc->hexagon_mdt_image, GFP_KERNEL);
+	if (!fw_name)
+		return -ENOMEM;
+
+	ret = request_firmware(&fw, fw_name, qproc->dev);
 	if (ret < 0) {
-		dev_err(qproc->dev, "unable to load modem.mdt\n");
-		return ret;
+		dev_err(qproc->dev, "unable to load %s\n", fw_name);
+		goto out;
 	}
 
 	/* Initialize the RMB validator */
@@ -918,10 +928,11 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
 		ptr = qproc->mpss_region + offset;
 
 		if (phdr->p_filesz) {
-			snprintf(seg_name, sizeof(seg_name), "modem.b%02d", i);
-			ret = request_firmware(&seg_fw, seg_name, qproc->dev);
+			/* Replace "xxx.xxx" with "xxx.bxx" */
+			sprintf(fw_name + fw_name_len - 3, "b%02d", i);
+			ret = request_firmware(&seg_fw, fw_name, qproc->dev);
 			if (ret) {
-				dev_err(qproc->dev, "failed to load %s\n", seg_name);
+				dev_err(qproc->dev, "failed to load %s\n", fw_name);
 				goto release_firmware;
 			}
 
@@ -960,6 +971,8 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
 
 release_firmware:
 	release_firmware(fw);
+out:
+	kfree(fw_name);
 
 	return ret < 0 ? ret : 0;
 }
@@ -1075,9 +1088,10 @@ static int qcom_q6v5_register_dump_segments(struct rproc *rproc,
 	unsigned long i;
 	int ret;
 
-	ret = request_firmware(&fw, "modem.mdt", qproc->dev);
+	ret = request_firmware(&fw, qproc->hexagon_mdt_image, qproc->dev);
 	if (ret < 0) {
-		dev_err(qproc->dev, "unable to load modem.mdt\n");
+		dev_err(qproc->dev, "unable to load %s\n",
+			qproc->hexagon_mdt_image);
 		return ret;
 	}
 
@@ -1253,6 +1267,7 @@ static int q6v5_probe(struct platform_device *pdev)
 	const struct rproc_hexagon_res *desc;
 	struct q6v5 *qproc;
 	struct rproc *rproc;
+	const char *mba_image;
 	int ret;
 
 	desc = of_device_get_match_data(&pdev->dev);
@@ -1262,8 +1277,14 @@ static int q6v5_probe(struct platform_device *pdev)
 	if (desc->need_mem_protection && !qcom_scm_is_available())
 		return -EPROBE_DEFER;
 
+	mba_image = desc->hexagon_mba_image;
+	ret = of_property_read_string_index(pdev->dev.of_node, "firmware-name",
+					    0, &mba_image);
+	if (ret < 0 && ret != -EINVAL)
+		return ret;
+
 	rproc = rproc_alloc(&pdev->dev, pdev->name, &q6v5_ops,
-			    desc->hexagon_mba_image, sizeof(*qproc));
+			    mba_image, sizeof(*qproc));
 	if (!rproc) {
 		dev_err(&pdev->dev, "failed to allocate rproc\n");
 		return -ENOMEM;
@@ -1272,6 +1293,12 @@ static int q6v5_probe(struct platform_device *pdev)
 	qproc = (struct q6v5 *)rproc->priv;
 	qproc->dev = &pdev->dev;
 	qproc->rproc = rproc;
+	qproc->hexagon_mdt_image = "modem.mdt";
+	ret = of_property_read_string_index(pdev->dev.of_node, "firmware-name",
+					    1, &qproc->hexagon_mdt_image);
+	if (ret < 0 && ret != -EINVAL)
+		return ret;
+
 	platform_set_drvdata(pdev, qproc);
 
 	ret = q6v5_init_mem(qproc, pdev);
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
index b1e63fcd5fdf..cfdafd68e2cd 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -258,6 +258,7 @@ static int adsp_probe(struct platform_device *pdev)
 	const struct adsp_data *desc;
 	struct qcom_adsp *adsp;
 	struct rproc *rproc;
+	const char *fw_name;
 	int ret;
 
 	desc = of_device_get_match_data(&pdev->dev);
@@ -267,8 +268,14 @@ static int adsp_probe(struct platform_device *pdev)
 	if (!qcom_scm_is_available())
 		return -EPROBE_DEFER;
 
+	fw_name = desc->firmware_name;
+	ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
+				      &fw_name);
+	if (ret < 0 && ret != -EINVAL)
+		return ret;
+
 	rproc = rproc_alloc(&pdev->dev, pdev->name, &adsp_ops,
-			    desc->firmware_name, sizeof(*adsp));
+			    fw_name, sizeof(*adsp));
 	if (!rproc) {
 		dev_err(&pdev->dev, "unable to allocate remoteproc\n");
 		return -ENOMEM;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 17%]

* Re: [PATCH v6] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
  2019-01-14 19:22 [PATCH v6] " Sibi Sankar
@ 2019-01-17 23:05 ` Doug Anderson
  2019-01-18  5:21   ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Doug Anderson @ 2019-01-17 23:05 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: Bjorn Andersson, Rob Herring, Andy Gross, David Brown,
	linux-arm-msm, open list:ARM/QUALCOMM SUPPORT, devicetree, LKML,
	tsoni, clew, akdwived, Mark Rutland, linux-remoteproc,
	Evan Green, Brian Norris, sricharan

Hi,

On Mon, Jan 14, 2019 at 11:22 AM Sibi Sankar <sibis@codeaurora.org> wrote:
> +               mss_pil: remoteproc@4080000 {
> +                       compatible = "qcom,sdm845-mss-pil";
> +                       reg = <0x04080000 0x408>, <0x04180000 0x48>;

This will now need to be adjusted to:

reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;

This fixes things up to deal with the patch ("arm64: dts: qcom:
sdm845: Increase address and size cells for soc"), AKA:
- https://patchwork.kernel.org/patch/10767511/
- https://lkml.kernel.org/r/20190117042940.25487-2-bjorn.andersson@linaro.org


-Doug

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v6] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
  2019-01-17 23:05 ` Doug Anderson
@ 2019-01-18  5:21   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-18  5:21 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Bjorn Andersson, Rob Herring, Andy Gross, David Brown,
	linux-arm-msm, open list:ARM/QUALCOMM SUPPORT, devicetree, LKML,
	tsoni, clew, akdwived, Mark Rutland, linux-remoteproc,
	Evan Green, Brian Norris, sricharan, linux-soc-owner

On 2019-01-18 04:35, Doug Anderson wrote:
> Hi,
> 
> On Mon, Jan 14, 2019 at 11:22 AM Sibi Sankar <sibis@codeaurora.org> 
> wrote:
>> +               mss_pil: remoteproc@4080000 {
>> +                       compatible = "qcom,sdm845-mss-pil";
>> +                       reg = <0x04080000 0x408>, <0x04180000 0x48>;
> 
> This will now need to be adjusted to:
> 
> reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;

Yup, this was on my todo list after Bjorn
posted out the patch

> 
> This fixes things up to deal with the patch ("arm64: dts: qcom:
> sdm845: Increase address and size cells for soc"), AKA:
> - https://patchwork.kernel.org/patch/10767511/
> - 
> https://lkml.kernel.org/r/20190117042940.25487-2-bjorn.andersson@linaro.org
> 
> 
> -Doug

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor
      [irrelevant] ` <20180529042047.GE2259@tuxbook-pro>
@ 2019-01-18  7:04   ` Sibi Sankar
  2019-01-18 18:35     ` Brian Norris
  0 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-01-18  7:04 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Ramon Fried, linux-remoteproc, linux-kernel, linux-kernel-owner,
	<Brian Norris>

On 2018-05-29 09:50, Bjorn Andersson wrote:
> On Thu 24 May 12:21 PDT 2018, Ramon Fried wrote:
> 
>> Sometimes that rmtfs userspace module is not brought
>> up fast enough and the modem crashes.
>> disabling automated boot in the driver and triggering
>> the boot from user-space sovles the problem.
>> 
>> Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
> 
> Thanks for your patch Ramon. While this nudges the behavior to make
> things work slightly better I think we need to describe the explicit
> dependency between the mss firmware and the existence of rmtfs.
> 
> As our remoteprocs are essentially always-on I would prefer that they
> start "automatically" and not through use of the sysfs interface.
> 
> But we're at the point where this is a real problem on 410, 820 and 
> 845,
> so we have to come up with some way to tie these pieces together. If
> your patch suits that solution I will happily take it.
> 
> Regards,
> Bjorn

After experimenting with in kernel solutions for
three revisions and observing problems on graceful
shutdown usecase, switching to controlling the
remoteproc mss through rmtfs seems to solve all
the known issues.

https://patchwork.kernel.org/patch/10662395/

we should probably get this merged in, now that
we are planning to start/stop mss through
rmtfs.


Acked-by: Sibi Sankar <sibis@codeaurora.org>

> 
>> ---
>>  drivers/remoteproc/qcom_q6v5_pil.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
>> b/drivers/remoteproc/qcom_q6v5_pil.c
>> index cbbafdcaaecb..719ee96445b3 100644
>> --- a/drivers/remoteproc/qcom_q6v5_pil.c
>> +++ b/drivers/remoteproc/qcom_q6v5_pil.c
>> @@ -1133,6 +1133,8 @@ static int q6v5_probe(struct platform_device 
>> *pdev)
>>  		return -ENOMEM;
>>  	}
>> 
>> +	rproc->auto_boot = false;
>> +
>>  	qproc = (struct q6v5 *)rproc->priv;
>>  	qproc->dev = &pdev->dev;
>>  	qproc->rproc = rproc;
>> --
>> 2.17.0
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 13%]

* Re: [PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor
  2019-01-18  7:04   ` [PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor Sibi Sankar
@ 2019-01-18 18:35     ` Brian Norris
  2019-01-18 19:46       ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Brian Norris @ 2019-01-18 18:35 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: Bjorn Andersson, Ramon Fried, linux-remoteproc, Linux Kernel,
	linux-kernel-owner

On Thu, Jan 17, 2019 at 11:04 PM Sibi Sankar <sibis@codeaurora.org> wrote:
> On 2018-05-29 09:50, Bjorn Andersson wrote:
> > On Thu 24 May 12:21 PDT 2018, Ramon Fried wrote:

Whoa, bringing up a 7-month old patch? Nice.

> >> Sometimes that rmtfs userspace module is not brought
> >> up fast enough and the modem crashes.
> >> disabling automated boot in the driver and triggering
> >> the boot from user-space sovles the problem.
> >>
> >> Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
> >
> > Thanks for your patch Ramon. While this nudges the behavior to make
> > things work slightly better I think we need to describe the explicit
> > dependency between the mss firmware and the existence of rmtfs.
> >
> > As our remoteprocs are essentially always-on I would prefer that they
> > start "automatically" and not through use of the sysfs interface.
> >
> > But we're at the point where this is a real problem on 410, 820 and
> > 845,
> > so we have to come up with some way to tie these pieces together. If
> > your patch suits that solution I will happily take it.
> >
> > Regards,
> > Bjorn
>
> After experimenting with in kernel solutions for
> three revisions and observing problems on graceful
> shutdown usecase,

What exactly were the problems again? e.g., what were the deficiencies
with having the remoteproc device listen for the REMOTEFS_QMI_SVC_ID
service again? Sorry, but I sort of dropped off on reviewing that
stuff, and now I see this. I'd mildly prefer something that is
actually automatic, but if I'm missing some aspects, I'd like to hear
that. (And, I'd like to see them explained in the commit message, if
this is ever to be merged.)

> switching to controlling the
> remoteproc mss through rmtfs seems to solve all
> the known issues.

How so? It explicitly does NOT help at all if RMTFS crashes.
Because...who's going to stop the modem in that case? (It works if you
automatically respawn a new RMTFS daemon, to toggle the modem. But
that's kind of cheating, and you can do that anyway, even without this
patch.) On the contrary, your patch *would* resolve that, since the
modem would notice when the RMTFS server goes away, and it would stop
itself.

> https://patchwork.kernel.org/patch/10662395/
>
> we should probably get this merged in, now that
> we are planning to start/stop mss through
> rmtfs.

Sorry, who's planning to stop mss through rmtfs? Did I miss something?

Brian

^ permalink raw reply	[relevance 6%]

* Re: [PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor
  2019-01-18 18:35     ` Brian Norris
@ 2019-01-18 19:46       ` Sibi Sankar
  2019-01-18 21:04         ` Brian Norris
  0 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-01-18 19:46 UTC (permalink / raw)
  To: Brian Norris
  Cc: Bjorn Andersson, Ramon Fried, linux-remoteproc, Linux Kernel,
	linux-kernel-owner

On 2019-01-19 00:05, Brian Norris wrote:
> On Thu, Jan 17, 2019 at 11:04 PM Sibi Sankar <sibis@codeaurora.org> 
> wrote:
>> On 2018-05-29 09:50, Bjorn Andersson wrote:
>> > On Thu 24 May 12:21 PDT 2018, Ramon Fried wrote:
> 
> Whoa, bringing up a 7-month old patch? Nice.
> 
>> >> Sometimes that rmtfs userspace module is not brought
>> >> up fast enough and the modem crashes.
>> >> disabling automated boot in the driver and triggering
>> >> the boot from user-space sovles the problem.
>> >>
>> >> Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
>> >
>> > Thanks for your patch Ramon. While this nudges the behavior to make
>> > things work slightly better I think we need to describe the explicit
>> > dependency between the mss firmware and the existence of rmtfs.
>> >
>> > As our remoteprocs are essentially always-on I would prefer that they
>> > start "automatically" and not through use of the sysfs interface.
>> >
>> > But we're at the point where this is a real problem on 410, 820 and
>> > 845,
>> > so we have to come up with some way to tie these pieces together. If
>> > your patch suits that solution I will happily take it.
>> >
>> > Regards,
>> > Bjorn
>> 
>> After experimenting with in kernel solutions for
>> three revisions and observing problems on graceful
>> shutdown usecase,
> 
> What exactly were the problems again? e.g., what were the deficiencies
> with having the remoteproc device listen for the REMOTEFS_QMI_SVC_ID
> service again? Sorry, but I sort of dropped off on reviewing that
> stuff, and now I see this. I'd mildly prefer something that is
> actually automatic, but if I'm missing some aspects, I'd like to hear
> that. (And, I'd like to see them explained in the commit message, if
> this is ever to be merged.)

bringing down the modem after the RMTFS server
goes down leaves the modem in limbo (It has a few
pending rmtfs transactions that cannot go through)
which results in sysmon graceful shutdown failing.
And we have to do a modem force-stop to proceed
which we want to avoid in graceful shutdown cases.
This is overcome by starting rproc mss from rmtfs
after REMOTEFS_QMI service is up and stopping
rproc mss from rmtfs on SIGKILL/SIGINT and other
program error signals before bringing down the
RMTFS_QMI service i.e before exiting the rmtfs
server loop.

> 
>> switching to controlling the
>> remoteproc mss through rmtfs seems to solve all
>> the known issues.
> 
> How so? It explicitly does NOT help at all if RMTFS crashes.
> Because...who's going to stop the modem in that case? (It works if you
> automatically respawn a new RMTFS daemon, to toggle the modem. But
> that's kind of cheating, and you can do that anyway, even without this
> patch.) On the contrary, your patch *would* resolve that, since the
> modem would notice when the RMTFS server goes away, and it would stop
> itself.

yeah we would want to mimic what the kernel
patch did with the exception of stopping modem
before bringing down the rmtfs server (not toggle
rproc state but start on rmtfs service up and stop
before rmtfs server exit). So in that case we would
not want the modem to auto-boot.

> 
>> https://patchwork.kernel.org/patch/10662395/
>> 
>> we should probably get this merged in, now that
>> we are planning to start/stop mss through
>> rmtfs.
> 
> Sorry, who's planning to stop mss through rmtfs? Did I miss something?

I have a working patch which I'll soon send
upstream for review, after it clears the internal
reviews/processes

> 
> Brian

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor
  2019-01-18 19:46       ` Sibi Sankar
@ 2019-01-18 21:04         ` Brian Norris
  2019-01-19  4:17           ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Brian Norris @ 2019-01-18 21:04 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: Bjorn Andersson, Ramon Fried, linux-remoteproc, Linux Kernel,
	linux-kernel-owner

Hi Sibi,

On Fri, Jan 18, 2019 at 11:46 AM Sibi Sankar <sibis@codeaurora.org> wrote:
> On 2019-01-19 00:05, Brian Norris wrote:
> > On Thu, Jan 17, 2019 at 11:04 PM Sibi Sankar <sibis@codeaurora.org>
> >> After experimenting with in kernel solutions for
> >> three revisions and observing problems on graceful
> >> shutdown usecase,
> >
> > What exactly were the problems again? e.g., what were the deficiencies
> > with having the remoteproc device listen for the REMOTEFS_QMI_SVC_ID
> > service again? Sorry, but I sort of dropped off on reviewing that
> > stuff, and now I see this. I'd mildly prefer something that is
> > actually automatic, but if I'm missing some aspects, I'd like to hear
> > that. (And, I'd like to see them explained in the commit message, if
> > this is ever to be merged.)
>
> bringing down the modem after the RMTFS server
> goes down leaves the modem in limbo (It has a few
> pending rmtfs transactions that cannot go through)
> which results in sysmon graceful shutdown failing.

Makes sense. Probably should be described in a re-send of this patch,
if we're going with that.

> And we have to do a modem force-stop to proceed
> which we want to avoid in graceful shutdown cases.

Shouldn't you do the "force-stop" in the kernel too? e.g., if rmtfs
daemon dies without doing a properly-timed stop, then we should still
force a stop in the kernel, no? Basically, why not do both mechanisms:
REMOTEFS_QMI_SVC-activated start/stop in the kernel, and manual stop
(and start? this likely might still be redundant) in the daemon?

> This is overcome by starting rproc mss from rmtfs
> after REMOTEFS_QMI service is up and stopping
> rproc mss from rmtfs on SIGKILL/SIGINT and other
> program error signals before bringing down the
> RMTFS_QMI service i.e before exiting the rmtfs
> server loop.

That's still not really a sure-fire way of doing things. For one, you
can't catch SIGKILL. Similarly, you can't really clean up from OOM,
segfault, etc. So it would still be helpful to hook into the QMI
service notifications in the kernel, I think.

> >> switching to controlling the
> >> remoteproc mss through rmtfs seems to solve all
> >> the known issues.
> >
> > How so? It explicitly does NOT help at all if RMTFS crashes.
> > Because...who's going to stop the modem in that case? (It works if you
> > automatically respawn a new RMTFS daemon, to toggle the modem. But
> > that's kind of cheating, and you can do that anyway, even without this
> > patch.) On the contrary, your patch *would* resolve that, since the
> > modem would notice when the RMTFS server goes away, and it would stop
> > itself.
>
> yeah we would want to mimic what the kernel
> patch did with the exception of stopping modem
> before bringing down the rmtfs server (not toggle
> rproc state but start on rmtfs service up and stop
> before rmtfs server exit). So in that case we would
> not want the modem to auto-boot.

See above. You can't really mimic what the kernel patch was doing
completely. You can try (which is probably a good idea), but you
should still have some fallback in the kernel, I expect.

> >> https://patchwork.kernel.org/patch/10662395/
> >>
> >> we should probably get this merged in, now that
> >> we are planning to start/stop mss through
> >> rmtfs.
> >
> > Sorry, who's planning to stop mss through rmtfs? Did I miss something?
>
> I have a working patch which I'll soon send
> upstream for review, after it clears the internal
> reviews/processes

OK.

Brian

^ permalink raw reply	[relevance 6%]

* Re: [PATCH] remoteproc: qcom_q6v5: don't auto boot remote processor
  2019-01-18 21:04         ` Brian Norris
@ 2019-01-19  4:17           ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-19  4:17 UTC (permalink / raw)
  To: Brian Norris
  Cc: Bjorn Andersson, Ramon Fried, linux-remoteproc, Linux Kernel,
	linux-kernel-owner

Hi Brian,
Thanks for the review

On 2019-01-19 02:34, Brian Norris wrote:
> Hi Sibi,
> 
> On Fri, Jan 18, 2019 at 11:46 AM Sibi Sankar <sibis@codeaurora.org> 
> wrote:
>> On 2019-01-19 00:05, Brian Norris wrote:
>> > On Thu, Jan 17, 2019 at 11:04 PM Sibi Sankar <sibis@codeaurora.org>
>> >> After experimenting with in kernel solutions for
>> >> three revisions and observing problems on graceful
>> >> shutdown usecase,
>> >
>> > What exactly were the problems again? e.g., what were the deficiencies
>> > with having the remoteproc device listen for the REMOTEFS_QMI_SVC_ID
>> > service again? Sorry, but I sort of dropped off on reviewing that
>> > stuff, and now I see this. I'd mildly prefer something that is
>> > actually automatic, but if I'm missing some aspects, I'd like to hear
>> > that. (And, I'd like to see them explained in the commit message, if
>> > this is ever to be merged.)
>> 
>> bringing down the modem after the RMTFS server
>> goes down leaves the modem in limbo (It has a few
>> pending rmtfs transactions that cannot go through)
>> which results in sysmon graceful shutdown failing.
> 
> Makes sense. Probably should be described in a re-send of this patch,
> if we're going with that.
> 
>> And we have to do a modem force-stop to proceed
>> which we want to avoid in graceful shutdown cases.
> 
> Shouldn't you do the "force-stop" in the kernel too? e.g., if rmtfs
> daemon dies without doing a properly-timed stop, then we should still
> force a stop in the kernel, no? Basically, why not do both mechanisms:
> REMOTEFS_QMI_SVC-activated start/stop in the kernel, and manual stop
> (and start? this likely might still be redundant) in the daemon?

yeah we already have that implemented in the kernel
i.e first we try graceful shutdown followed by
force-stop which will just timeout if graceful
shutdown was already completed. We would just call
stop from rmtfs without worrying about the underlying
details.

> 
>> This is overcome by starting rproc mss from rmtfs
>> after REMOTEFS_QMI service is up and stopping
>> rproc mss from rmtfs on SIGKILL/SIGINT and other
>> program error signals before bringing down the
>> RMTFS_QMI service i.e before exiting the rmtfs
>> server loop.
> 
> That's still not really a sure-fire way of doing things. For one, you
> can't catch SIGKILL. Similarly, you can't really clean up from OOM,
> segfault, etc. So it would still be helpful to hook into the QMI
> service notifications in the kernel, I think.

yes we would want a fail safe in the kernel
as well. Sorry I meant SIGTERM instead of
SIGKILL earlier

> 
>> >> switching to controlling the
>> >> remoteproc mss through rmtfs seems to solve all
>> >> the known issues.
>> >
>> > How so? It explicitly does NOT help at all if RMTFS crashes.
>> > Because...who's going to stop the modem in that case? (It works if you
>> > automatically respawn a new RMTFS daemon, to toggle the modem. But
>> > that's kind of cheating, and you can do that anyway, even without this
>> > patch.) On the contrary, your patch *would* resolve that, since the
>> > modem would notice when the RMTFS server goes away, and it would stop
>> > itself.
>> 
>> yeah we would want to mimic what the kernel
>> patch did with the exception of stopping modem
>> before bringing down the rmtfs server (not toggle
>> rproc state but start on rmtfs service up and stop
>> before rmtfs server exit). So in that case we would
>> not want the modem to auto-boot.
> 
> See above. You can't really mimic what the kernel patch was doing
> completely. You can try (which is probably a good idea), but you
> should still have some fallback in the kernel, I expect.

yeah

> 
>> >> https://patchwork.kernel.org/patch/10662395/
>> >>
>> >> we should probably get this merged in, now that
>> >> we are planning to start/stop mss through
>> >> rmtfs.
>> >
>> > Sorry, who's planning to stop mss through rmtfs? Did I miss something?
>> 
>> I have a working patch which I'll soon send
>> upstream for review, after it clears the internal
>> reviews/processes
> 
> OK.
> 
> Brian

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* [PATCH v3 10/10] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
      [irrelevant] <20190122055112.30943-1-bjorn.andersson@linaro.org>
  2019-01-22  5:51 ` [PATCH v3 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains Bjorn Andersson
  2019-01-22  5:51 ` [PATCH v3 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845 Bjorn Andersson
@ 2019-01-22  5:51 ` Bjorn Andersson
  2019-01-23  0:28   ` Doug Anderson
      [irrelevant] ` <20190122055112.30943-2-bjorn.andersson@linaro.org>
  3 siblings, 1 reply; 200+ results
From: Bjorn Andersson @ 2019-01-22  5:51 UTC (permalink / raw)
  To: Andy Gross, David Brown, Sibi Sankar
  Cc: Rob Herring, Mark Rutland, linux-arm-msm, devicetree, linux-kernel

From: Sibi Sankar <sibis@codeaurora.org>

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v2:
- Picked up Sibi's patch
- Fixed reg to work with address/size-cells as 2

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 5cc2615461da..78df5f1bce2d 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1617,6 +1617,64 @@
 			clock-names = "xo";
 		};
 
+		mss_pil: remoteproc@4080000 {
+			compatible = "qcom,sdm845-mss-pil";
+			reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
+			reg-names = "qdsp6", "rmb";
+
+			interrupts-extended =
+				<&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog", "fatal", "ready",
+					  "handover", "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+				 <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+				 <&gcc GCC_BOOT_ROM_AHB_CLK>,
+				 <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+				 <&gcc GCC_MSS_SNOC_AXI_CLK>,
+				 <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+				 <&gcc GCC_PRNG_AHB_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "iface", "bus", "mem", "gpll0_mss",
+				      "snoc_axi", "mnoc_axi", "prng", "xo";
+
+			qcom,smem-states = <&modem_smp2p_out 0>;
+			qcom,smem-state-names = "stop";
+
+			resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+				 <&pdc_reset PDC_MODEM_SYNC_RESET>;
+			reset-names = "mss_restart", "pdc_reset";
+
+			qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000 0x24000>;
+
+			power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
+					<&rpmhpd SDM845_CX>,
+					<&rpmhpd SDM845_MX>,
+					<&rpmhpd SDM845_MSS>;
+			power-domain-names = "load_state", "cx", "mx", "mss";
+
+			mba {
+				memory-region = <&mba_region>;
+			};
+
+			mpss {
+				memory-region = <&mpss_region>;
+			};
+
+			glink-edge {
+				interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+				label = "modem";
+				qcom,remote-pid = <1>;
+				mboxes = <&apss_shared 12>;
+			};
+		};
+
 		sdhc_2: sdhci@8804000 {
 			compatible = "qcom,sdm845-sdhci", "qcom,sdhci-msm-v5";
 			reg = <0 0x08804000 0 0x1000>;
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* [PATCH v3 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845
      [irrelevant] <20190122055112.30943-1-bjorn.andersson@linaro.org>
  2019-01-22  5:51 ` [PATCH v3 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains Bjorn Andersson
@ 2019-01-22  5:51 ` Bjorn Andersson
  2019-01-22  5:51 ` [PATCH v3 10/10] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
      [irrelevant] ` <20190122055112.30943-2-bjorn.andersson@linaro.org>
  3 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-22  5:51 UTC (permalink / raw)
  To: Andy Gross, David Brown, Sibi Sankar
  Cc: Rob Herring, Mark Rutland, linux-arm-msm, devicetree, linux-kernel

The SDM845 MSS needs the load_state powerdomain voted for during the
duration of the MSS being powered on, to let the AOSS know that it may
not perform certain power save measures. So vote for this.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v2:
- None

 drivers/remoteproc/qcom_q6v5_mss.c | 31 ++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 003186ce56c7..3e25016954d9 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -133,6 +133,7 @@ struct rproc_hexagon_res {
 	char **proxy_clk_names;
 	char **reset_clk_names;
 	char **active_clk_names;
+	char **active_pd_names;
 	char **proxy_pd_names;
 	int version;
 	bool need_mem_protection;
@@ -159,10 +160,12 @@ struct q6v5 {
 	struct clk *active_clks[8];
 	struct clk *reset_clks[4];
 	struct clk *proxy_clks[4];
+	struct device *active_pds[1];
 	struct device *proxy_pds[3];
 	int active_clk_count;
 	int reset_clk_count;
 	int proxy_clk_count;
+	int active_pd_count;
 	int proxy_pd_count;
 
 	struct reg_info active_regs[1];
@@ -730,10 +733,16 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 
 	qcom_q6v5_prepare(&qproc->q6v5);
 
+	ret = q6v5_pds_enable(qproc, qproc->active_pds, qproc->active_pd_count);
+	if (ret < 0) {
+		dev_err(qproc->dev, "failed to enable active power domains\n");
+		goto disable_irqs;
+	}
+
 	ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 	if (ret < 0) {
 		dev_err(qproc->dev, "failed to enable proxy power domains\n");
-		goto disable_irqs;
+		goto disable_active_pds;
 	}
 
 	ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
@@ -839,6 +848,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 			       qproc->proxy_reg_count);
 disable_proxy_pds:
 	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+disable_active_pds:
+	q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
 disable_irqs:
 	qcom_q6v5_unprepare(&qproc->q6v5);
 
@@ -878,6 +889,7 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
 			 qproc->active_clk_count);
 	q6v5_regulator_disable(qproc, qproc->active_regs,
 			       qproc->active_reg_count);
+	q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
 
 	/* In case of failure or coredump scenario where reclaiming MBA memory
 	 * could not happen reclaim it here.
@@ -1412,11 +1424,19 @@ static int q6v5_probe(struct platform_device *pdev)
 	}
 	qproc->active_reg_count = ret;
 
+	ret = q6v5_pds_attach(&pdev->dev, qproc->active_pds,
+			      desc->active_pd_names);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to attach active power domains\n");
+		goto free_rproc;
+	}
+	qproc->active_pd_count = ret;
+
 	ret = q6v5_pds_attach(&pdev->dev, qproc->proxy_pds,
 			      desc->proxy_pd_names);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Failed to init power domains\n");
-		goto free_rproc;
+		goto detach_active_pds;
 	}
 	qproc->proxy_pd_count = ret;
 
@@ -1448,6 +1468,8 @@ static int q6v5_probe(struct platform_device *pdev)
 
 detach_proxy_pds:
 	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+detach_active_pds:
+	q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
 free_rproc:
 	rproc_free(rproc);
 
@@ -1465,6 +1487,7 @@ static int q6v5_remove(struct platform_device *pdev)
 	qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
 	qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
 
+	q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
 	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 
 	rproc_free(qproc->rproc);
@@ -1491,6 +1514,10 @@ static const struct rproc_hexagon_res sdm845_mss = {
 			"mnoc_axi",
 			NULL
 	},
+	.active_pd_names = (char*[]){
+			"load_state",
+			NULL
+	},
 	.proxy_pd_names = (char*[]){
 			"cx",
 			"mx",
-- 
2.18.0


^ permalink raw reply	[relevance 7%]

* [PATCH v3 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains
      [irrelevant] <20190122055112.30943-1-bjorn.andersson@linaro.org>
@ 2019-01-22  5:51 ` Bjorn Andersson
  2019-01-22  5:51 ` [PATCH v3 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845 Bjorn Andersson
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-22  5:51 UTC (permalink / raw)
  To: Andy Gross, David Brown, Sibi Sankar
  Cc: Rob Herring, Mark Rutland, linux-arm-msm, devicetree, linux-kernel

From: Rajendra Nayak <rnayak@codeaurora.org>

With rpmh ARC resources being modelled as power domains with performance
state, we need to proxy vote on these for SDM845.
Add support to vote on multiple of them, now that genpd supports
associating mutliple power domains to a device.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
[bjorn: Drop device link, improve error handling, name things "proxy"]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v2:
- Disable proxy pds if handover did not arrived before stop

 drivers/remoteproc/qcom_q6v5_mss.c | 117 ++++++++++++++++++++++++++++-
 1 file changed, 113 insertions(+), 4 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 01be7314e176..003186ce56c7 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -25,6 +25,8 @@
 #include <linux/of_address.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 #include <linux/remoteproc.h>
@@ -131,6 +133,7 @@ struct rproc_hexagon_res {
 	char **proxy_clk_names;
 	char **reset_clk_names;
 	char **active_clk_names;
+	char **proxy_pd_names;
 	int version;
 	bool need_mem_protection;
 	bool has_alt_reset;
@@ -156,9 +159,11 @@ struct q6v5 {
 	struct clk *active_clks[8];
 	struct clk *reset_clks[4];
 	struct clk *proxy_clks[4];
+	struct device *proxy_pds[3];
 	int active_clk_count;
 	int reset_clk_count;
 	int proxy_clk_count;
+	int proxy_pd_count;
 
 	struct reg_info active_regs[1];
 	struct reg_info proxy_regs[3];
@@ -321,6 +326,41 @@ static void q6v5_clk_disable(struct device *dev,
 		clk_disable_unprepare(clks[i]);
 }
 
+static int q6v5_pds_enable(struct q6v5 *qproc, struct device **pds,
+			   size_t pd_count)
+{
+	int ret;
+	int i;
+
+	for (i = 0; i < pd_count; i++) {
+		dev_pm_genpd_set_performance_state(pds[i], INT_MAX);
+		ret = pm_runtime_get_sync(pds[i]);
+		if (ret < 0)
+			goto unroll_pd_votes;
+	}
+
+	return 0;
+
+unroll_pd_votes:
+	for (i--; i >= 0; i--) {
+		dev_pm_genpd_set_performance_state(pds[i], 0);
+		pm_runtime_put(pds[i]);
+	}
+
+	return ret;
+};
+
+static void q6v5_pds_disable(struct q6v5 *qproc, struct device **pds,
+			     size_t pd_count)
+{
+	int i;
+
+	for (i = 0; i < pd_count; i++) {
+		dev_pm_genpd_set_performance_state(pds[i], 0);
+		pm_runtime_put(pds[i]);
+	}
+}
+
 static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int *current_perm,
 				   bool remote_owner, phys_addr_t addr,
 				   size_t size)
@@ -690,11 +730,17 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 
 	qcom_q6v5_prepare(&qproc->q6v5);
 
+	ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+	if (ret < 0) {
+		dev_err(qproc->dev, "failed to enable proxy power domains\n");
+		goto disable_irqs;
+	}
+
 	ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
 				    qproc->proxy_reg_count);
 	if (ret) {
 		dev_err(qproc->dev, "failed to enable proxy supplies\n");
-		goto disable_irqs;
+		goto disable_proxy_pds;
 	}
 
 	ret = q6v5_clk_enable(qproc->dev, qproc->proxy_clks,
@@ -791,6 +837,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 disable_proxy_reg:
 	q6v5_regulator_disable(qproc, qproc->proxy_regs,
 			       qproc->proxy_reg_count);
+disable_proxy_pds:
+	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 disable_irqs:
 	qcom_q6v5_unprepare(&qproc->q6v5);
 
@@ -841,6 +889,8 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
 
 	ret = qcom_q6v5_unprepare(&qproc->q6v5);
 	if (ret) {
+		q6v5_pds_disable(qproc, qproc->proxy_pds,
+				 qproc->proxy_pd_count);
 		q6v5_clk_disable(qproc->dev, qproc->proxy_clks,
 				 qproc->proxy_clk_count);
 		q6v5_regulator_disable(qproc, qproc->proxy_regs,
@@ -1121,6 +1171,7 @@ static void qcom_msa_handover(struct qcom_q6v5 *q6v5)
 			 qproc->proxy_clk_count);
 	q6v5_regulator_disable(qproc, qproc->proxy_regs,
 			       qproc->proxy_reg_count);
+	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 }
 
 static int q6v5_init_mem(struct q6v5 *qproc, struct platform_device *pdev)
@@ -1181,6 +1232,45 @@ static int q6v5_init_clocks(struct device *dev, struct clk **clks,
 	return i;
 }
 
+static int q6v5_pds_attach(struct device *dev, struct device **devs,
+			   char **pd_names)
+{
+	size_t num_pds = 0;
+	int ret;
+	int i;
+
+	if (!pd_names)
+		return 0;
+
+	while (pd_names[num_pds])
+		num_pds++;
+
+	for (i = 0; i < num_pds; i++) {
+		devs[i] = dev_pm_domain_attach_by_name(dev, pd_names[i]);
+		if (IS_ERR(devs[i])) {
+			ret = PTR_ERR(devs[i]);
+			goto unroll_attach;
+		}
+	}
+
+	return num_pds;
+
+unroll_attach:
+	for (i--; i >= 0; i--)
+		dev_pm_domain_detach(devs[i], false);
+
+	return ret;
+};
+
+static void q6v5_pds_detach(struct q6v5 *qproc, struct device **pds,
+			    size_t pd_count)
+{
+	int i;
+
+	for (i = 0; i < pd_count; i++)
+		dev_pm_domain_detach(pds[i], false);
+}
+
 static int q6v5_init_reset(struct q6v5 *qproc)
 {
 	qproc->mss_restart = devm_reset_control_get_exclusive(qproc->dev,
@@ -1322,10 +1412,18 @@ static int q6v5_probe(struct platform_device *pdev)
 	}
 	qproc->active_reg_count = ret;
 
+	ret = q6v5_pds_attach(&pdev->dev, qproc->proxy_pds,
+			      desc->proxy_pd_names);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to init power domains\n");
+		goto free_rproc;
+	}
+	qproc->proxy_pd_count = ret;
+
 	qproc->has_alt_reset = desc->has_alt_reset;
 	ret = q6v5_init_reset(qproc);
 	if (ret)
-		goto free_rproc;
+		goto detach_proxy_pds;
 
 	qproc->version = desc->version;
 	qproc->need_mem_protection = desc->need_mem_protection;
@@ -1333,7 +1431,7 @@ static int q6v5_probe(struct platform_device *pdev)
 	ret = qcom_q6v5_init(&qproc->q6v5, pdev, rproc, MPSS_CRASH_REASON_SMEM,
 			     qcom_msa_handover);
 	if (ret)
-		goto free_rproc;
+		goto detach_proxy_pds;
 
 	qproc->mpss_perm = BIT(QCOM_SCM_VMID_HLOS);
 	qproc->mba_perm = BIT(QCOM_SCM_VMID_HLOS);
@@ -1344,10 +1442,12 @@ static int q6v5_probe(struct platform_device *pdev)
 
 	ret = rproc_add(rproc);
 	if (ret)
-		goto free_rproc;
+		goto detach_proxy_pds;
 
 	return 0;
 
+detach_proxy_pds:
+	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 free_rproc:
 	rproc_free(rproc);
 
@@ -1364,6 +1464,9 @@ static int q6v5_remove(struct platform_device *pdev)
 	qcom_remove_glink_subdev(qproc->rproc, &qproc->glink_subdev);
 	qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
 	qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
+
+	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+
 	rproc_free(qproc->rproc);
 
 	return 0;
@@ -1388,6 +1491,12 @@ static const struct rproc_hexagon_res sdm845_mss = {
 			"mnoc_axi",
 			NULL
 	},
+	.proxy_pd_names = (char*[]){
+			"cx",
+			"mx",
+			"mss",
+			NULL
+	},
 	.need_mem_protection = true,
 	.has_alt_reset = true,
 	.version = MSS_SDM845,
-- 
2.18.0


^ permalink raw reply	[relevance 7%]

* Re: [PATCH v3 10/10] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
  2019-01-22  5:51 ` [PATCH v3 10/10] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
@ 2019-01-23  0:28   ` Doug Anderson
  2019-01-23  1:10     ` Bjorn Andersson
  0 siblings, 1 reply; 200+ results
From: Doug Anderson @ 2019-01-23  0:28 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Sibi Sankar, Rob Herring, Mark Rutland,
	linux-arm-msm, devicetree, LKML

Hi,

On Mon, Jan 21, 2019 at 9:52 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> From: Sibi Sankar <sibis@codeaurora.org>
>
> This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.
>
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v2:
> - Picked up Sibi's patch
> - Fixed reg to work with address/size-cells as 2
>
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
>  1 file changed, 58 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 5cc2615461da..78df5f1bce2d 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1617,6 +1617,64 @@
>                         clock-names = "xo";
>                 };
>
> +               mss_pil: remoteproc@4080000 {
> +                       compatible = "qcom,sdm845-mss-pil";
> +                       reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
> +                       reg-names = "qdsp6", "rmb";
> +
> +                       interrupts-extended =
> +                               <&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
> +                               <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> +                               <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> +                               <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> +                               <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
> +                               <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
> +                       interrupt-names = "wdog", "fatal", "ready",
> +                                         "handover", "stop-ack",
> +                                         "shutdown-ack";
> +
> +                       clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
> +                                <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
> +                                <&gcc GCC_BOOT_ROM_AHB_CLK>,
> +                                <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
> +                                <&gcc GCC_MSS_SNOC_AXI_CLK>,
> +                                <&gcc GCC_MSS_MFAB_AXIS_CLK>,
> +                                <&gcc GCC_PRNG_AHB_CLK>,
> +                                <&rpmhcc RPMH_CXO_CLK>;
> +                       clock-names = "iface", "bus", "mem", "gpll0_mss",
> +                                     "snoc_axi", "mnoc_axi", "prng", "xo";
> +
> +                       qcom,smem-states = <&modem_smp2p_out 0>;
> +                       qcom,smem-state-names = "stop";
> +
> +                       resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
> +                                <&pdc_reset PDC_MODEM_SYNC_RESET>;
> +                       reset-names = "mss_restart", "pdc_reset";
> +
> +                       qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000 0x24000>;
> +
> +                       power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
> +                                       <&rpmhpd SDM845_CX>,
> +                                       <&rpmhpd SDM845_MX>,
> +                                       <&rpmhpd SDM845_MSS>;
> +                       power-domain-names = "load_state", "cx", "mx", "mss";
> +
> +                       mba {
> +                               memory-region = <&mba_region>;
> +                       };
> +
> +                       mpss {
> +                               memory-region = <&mpss_region>;
> +                       };
> +
> +                       glink-edge {
> +                               interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
> +                               label = "modem";
> +                               qcom,remote-pid = <1>;
> +                               mboxes = <&apss_shared 12>;
> +                       };
> +               };
> +
>                 sdhc_2: sdhci@8804000 {

Can you please sort by unit address now that you have a device tree
that has more stuff?

-Doug

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 10/10] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
  2019-01-23  0:28   ` Doug Anderson
@ 2019-01-23  1:10     ` Bjorn Andersson
  0 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-23  1:10 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Andy Gross, David Brown, Sibi Sankar, Rob Herring, Mark Rutland,
	linux-arm-msm, devicetree, LKML

On Tue 22 Jan 16:28 PST 2019, Doug Anderson wrote:

> Hi,
> 
> On Mon, Jan 21, 2019 at 9:52 PM Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > From: Sibi Sankar <sibis@codeaurora.org>
> >
> > This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.
> >
> > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >
> > Changes since v2:
> > - Picked up Sibi's patch
> > - Fixed reg to work with address/size-cells as 2
> >
> >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
> >  1 file changed, 58 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index 5cc2615461da..78df5f1bce2d 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -1617,6 +1617,64 @@
> >                         clock-names = "xo";
> >                 };
> >
> > +               mss_pil: remoteproc@4080000 {
> > +                       compatible = "qcom,sdm845-mss-pil";
> > +                       reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
> > +                       reg-names = "qdsp6", "rmb";
> > +
> > +                       interrupts-extended =
> > +                               <&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
> > +                               <&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> > +                               <&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> > +                               <&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> > +                               <&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
> > +                               <&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
> > +                       interrupt-names = "wdog", "fatal", "ready",
> > +                                         "handover", "stop-ack",
> > +                                         "shutdown-ack";
> > +
> > +                       clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
> > +                                <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
> > +                                <&gcc GCC_BOOT_ROM_AHB_CLK>,
> > +                                <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
> > +                                <&gcc GCC_MSS_SNOC_AXI_CLK>,
> > +                                <&gcc GCC_MSS_MFAB_AXIS_CLK>,
> > +                                <&gcc GCC_PRNG_AHB_CLK>,
> > +                                <&rpmhcc RPMH_CXO_CLK>;
> > +                       clock-names = "iface", "bus", "mem", "gpll0_mss",
> > +                                     "snoc_axi", "mnoc_axi", "prng", "xo";
> > +
> > +                       qcom,smem-states = <&modem_smp2p_out 0>;
> > +                       qcom,smem-state-names = "stop";
> > +
> > +                       resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
> > +                                <&pdc_reset PDC_MODEM_SYNC_RESET>;
> > +                       reset-names = "mss_restart", "pdc_reset";
> > +
> > +                       qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000 0x24000>;
> > +
> > +                       power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
> > +                                       <&rpmhpd SDM845_CX>,
> > +                                       <&rpmhpd SDM845_MX>,
> > +                                       <&rpmhpd SDM845_MSS>;
> > +                       power-domain-names = "load_state", "cx", "mx", "mss";
> > +
> > +                       mba {
> > +                               memory-region = <&mba_region>;
> > +                       };
> > +
> > +                       mpss {
> > +                               memory-region = <&mpss_region>;
> > +                       };
> > +
> > +                       glink-edge {
> > +                               interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
> > +                               label = "modem";
> > +                               qcom,remote-pid = <1>;
> > +                               mboxes = <&apss_shared 12>;
> > +                       };
> > +               };
> > +
> >                 sdhc_2: sdhci@8804000 {
> 
> Can you please sort by unit address now that you have a device tree
> that has more stuff?
> 

Of course, sorry for missing that.

Regards,
Bjorn

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 01/10] arm64: dts: qcom: sdm845: Update PIL region memory map
      [irrelevant] ` <20190122055112.30943-2-bjorn.andersson@linaro.org>
@ 2019-01-25 17:40   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-25 17:40 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	linux-arm-msm, devicetree, linux-kernel

Hey Bjorn,

On 2019-01-22 11:21, Bjorn Andersson wrote:
> Update existing and add all missing PIL regions to the reserved memory
> map, as described in version 10.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v2:
> - New patch
> 
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 61 ++++++++++++++++++++++++++--
>  1 file changed, 58 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 0ec827394e92..cdcac3704c13 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -89,12 +89,47 @@
>  		};

Shouldn't we add hyp and xbl regions
as well?

> 
>  		memory@86200000 {
> -			reg = <0 0x86200000 0 0x2d00000>;
> +			reg = <0 0x86200000 0 0x100000>;
>  			no-map;
>  		};
> 
> -		wlan_msa_mem: memory@96700000 {
> -			reg = <0 0x96700000 0 0x100000>;
> +		memory@86300000 {
> +			reg = <0 0x86300000 0 0x4800000>;

from v10 I see we don't need to reserve the
last 28M it just needs to be

reg = <0 0x86300000 0 0x2c00000>;

> +			no-map;
> +		};
> +
> +		memory@8ab00000 {
> +			reg = <0 0x8ab00000 0 0x1400000>;
> +			no-map;
> +		};
> +
> +		memory@8bf00000 {
> +			reg = <0 0x8bf00000 0 0x500000>;
> +			no-map;
> +		};
> +
> +		ipa_fw_mem: memory@8c400000 {
> +			reg = <0 0x8c400000 0 0x10000>;
> +			no-map;
> +		};
> +
> +		ipa_gsi_mem: memory@8c410000 {
> +			reg = <0 0x8c410000 0 0x5000>;
> +			no-map;
> +		};
> +
> +		memory@8c415000 {
> +			reg = <0 0x8c415000 0 0x2000>;
> +			no-map;
> +		};
> +
> +		adsp_mem: memory@8c500000 {
> +			reg = <0 0x8c500000 0 0x1a00000>;
> +			no-map;
> +		};
> +
> +		wlan_msa_mem: memory@8df00000 {
> +			reg = <0 0x8df00000 0 0x100000>;
>  			no-map;
>  		};
> 
> @@ -103,10 +138,30 @@
>  			no-map;
>  		};
> 
> +		venus_mem: memory@95800000 {
> +			reg = <0 0x95800000 0 0x500000>;
> +			no-map;
> +		};
> +
> +		cdsp_mem: memory@95d00000 {
> +			reg = <0 0x95d00000 0 0x800000>;
> +			no-map;
> +		};
> +
>  		mba_region: memory@96500000 {

should we re-name mba_region/mpss_region
to mba_mem and mpss_mem for consistency.

>  			reg = <0 0x96500000 0 0x200000>;
>  			no-map;
>  		};
> +
> +		slpi_mem: memory@96700000 {
> +			reg = <0 0x96700000 0 0x1400000>;
> +			no-map;
> +		};
> +
> +		spss_mem: memory@97b00000 {
> +			reg = <0 0x97b00000 0 0x100000>;
> +			no-map;
> +		};
>  	};
> 
>  	cpus {

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v5] arm64: dts: sdm845: add video nodes
      [irrelevant] <1548403893-21677-1-git-send-email-mgottam@codeaurora.org>
@ 2019-01-28  8:32 ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-28  8:32 UTC (permalink / raw)
  To: Malathi Gottam
  Cc: andy.gross, david.brown, robh+dt, mark.rutland, devicetree,
	linux-kernel, linux-arm-msm, acourbot, stanimir.varbanov,
	vgarodia, linux-arm-msm-owner, bjorn.andersson

Hi Malathi,

Bjorn has a patch adding all reserved memory
nodes from version 10 so you can probably drop
the venus_region node from the patch.

https://patchwork.kernel.org/patch/10774869/

On 2019-01-25 13:41, Malathi Gottam wrote:
> This adds video nodes to sdm845 based on the examples
> in the bindings.
> 
> Signed-off-by: Malathi Gottam <mgottam@codeaurora.org>
> ---
> Changes:
> 	Added video firmware node
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 38 
> ++++++++++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index b72bdb0..1af68f5 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -87,6 +87,11 @@
>  			reg = <0 0x86200000 0 0x2d00000>;
>  			no-map;
>  		};
> +
> +		venus_region: memory@95800000 {
> +			reg = <0x0 0x95800000 0x0 0x500000>;
> +			no-map;
> +		};
>  	};
> 
>  	cpus {
> @@ -1403,5 +1408,38 @@
>  				status = "disabled";
>  			};
>  		};
> +
> +		video-codec@aa00000 {
> +			compatible = "qcom,sdm845-venus";
> +			reg = <0x0aa00000 0xff000>;
> +			interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> +			power-domains = <&videocc VENUS_GDSC>;
> +			clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
> +				 <&videocc VIDEO_CC_VENUS_AHB_CLK>,
> +				 <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>;
> +			clock-names = "core", "iface", "bus";
> +			iommus = <&apps_smmu 0x10a0 0x8>,
> +				 <&apps_smmu 0x10b0 0x0>;
> +			memory-region = <&venus_region>;
> +
> +			video-core0 {
> +				compatible = "venus-decoder";
> +				clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
> +					 <&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
> +				clock-names = "core", "bus";
> +				power-domains = <&videocc VCODEC0_GDSC>;
> +			};
> +
> +			video-core1 {
> +				compatible = "venus-encoder";
> +				clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>,
> +					 <&videocc VIDEO_CC_VCODEC1_AXI_CLK>;
> +				clock-names = "core", "bus";
> +				power-domains = <&videocc VCODEC1_GDSC>;
> +			};
> +			video-firmware {
> +				iommus = <&apps_smmu 0x10b2 0x0>;
> +			};
> +		};
>  	};
>  };

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* [PATCH v4 10/10] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
      [irrelevant] <20190129232009.5033-1-bjorn.andersson@linaro.org>
  2019-01-29 23:20 ` [PATCH v4 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains Bjorn Andersson
  2019-01-29 23:20 ` [PATCH v4 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845 Bjorn Andersson
@ 2019-01-29 23:20 ` Bjorn Andersson
  2 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-29 23:20 UTC (permalink / raw)
  To: Andy Gross, David Brown
  Cc: Rob Herring, Mark Rutland, Ohad Ben-Cohen,
	Arun Kumar Neelakantam, Sibi Sankar, linux-arm-msm, devicetree,
	linux-kernel, linux-remoteproc

From: Sibi Sankar <sibis@codeaurora.org>

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v3:
- Fixed sort order in /soc

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 24c30be974bf..eb02c39d2048 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1618,6 +1618,64 @@
 			};
 		};
 
+		mss_pil: remoteproc@4080000 {
+			compatible = "qcom,sdm845-mss-pil";
+			reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
+			reg-names = "qdsp6", "rmb";
+
+			interrupts-extended =
+				<&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog", "fatal", "ready",
+					  "handover", "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+				 <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+				 <&gcc GCC_BOOT_ROM_AHB_CLK>,
+				 <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+				 <&gcc GCC_MSS_SNOC_AXI_CLK>,
+				 <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+				 <&gcc GCC_PRNG_AHB_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "iface", "bus", "mem", "gpll0_mss",
+				      "snoc_axi", "mnoc_axi", "prng", "xo";
+
+			qcom,smem-states = <&modem_smp2p_out 0>;
+			qcom,smem-state-names = "stop";
+
+			resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+				 <&pdc_reset PDC_MODEM_SYNC_RESET>;
+			reset-names = "mss_restart", "pdc_reset";
+
+			qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000 0x24000>;
+
+			power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
+					<&rpmhpd SDM845_CX>,
+					<&rpmhpd SDM845_MX>,
+					<&rpmhpd SDM845_MSS>;
+			power-domain-names = "load_state", "cx", "mx", "mss";
+
+			mba {
+				memory-region = <&mba_region>;
+			};
+
+			mpss {
+				memory-region = <&mpss_region>;
+			};
+
+			glink-edge {
+				interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+				label = "modem";
+				qcom,remote-pid = <1>;
+				mboxes = <&apss_shared 12>;
+			};
+		};
+
 		gpucc: clock-controller@5090000 {
 			compatible = "qcom,sdm845-gpucc";
 			reg = <0 0x05090000 0 0x9000>;
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* [PATCH v4 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains
      [irrelevant] <20190129232009.5033-1-bjorn.andersson@linaro.org>
@ 2019-01-29 23:20 ` Bjorn Andersson
  2019-01-29 23:20 ` [PATCH v4 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845 Bjorn Andersson
  2019-01-29 23:20 ` [PATCH v4 10/10] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
  2 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-29 23:20 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	Arun Kumar Neelakantam, Sibi Sankar, linux-arm-msm, devicetree,
	linux-kernel, linux-remoteproc

From: Rajendra Nayak <rnayak@codeaurora.org>

With rpmh ARC resources being modelled as power domains with performance
state, we need to proxy vote on these for SDM845.
Add support to vote on multiple of them, now that genpd supports
associating mutliple power domains to a device.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
[bjorn: Drop device link, improve error handling, name things "proxy"]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v3:
- Rebased upon latest remoteproc branch

 drivers/remoteproc/qcom_q6v5_mss.c | 119 +++++++++++++++++++++++++++--
 1 file changed, 114 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 07d1cc52a647..c32c63e351a0 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -25,6 +25,8 @@
 #include <linux/of_address.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 #include <linux/remoteproc.h>
@@ -131,6 +133,7 @@ struct rproc_hexagon_res {
 	char **proxy_clk_names;
 	char **reset_clk_names;
 	char **active_clk_names;
+	char **proxy_pd_names;
 	int version;
 	bool need_mem_protection;
 	bool has_alt_reset;
@@ -156,9 +159,11 @@ struct q6v5 {
 	struct clk *active_clks[8];
 	struct clk *reset_clks[4];
 	struct clk *proxy_clks[4];
+	struct device *proxy_pds[3];
 	int active_clk_count;
 	int reset_clk_count;
 	int proxy_clk_count;
+	int proxy_pd_count;
 
 	struct reg_info active_regs[1];
 	struct reg_info proxy_regs[3];
@@ -321,6 +326,41 @@ static void q6v5_clk_disable(struct device *dev,
 		clk_disable_unprepare(clks[i]);
 }
 
+static int q6v5_pds_enable(struct q6v5 *qproc, struct device **pds,
+			   size_t pd_count)
+{
+	int ret;
+	int i;
+
+	for (i = 0; i < pd_count; i++) {
+		dev_pm_genpd_set_performance_state(pds[i], INT_MAX);
+		ret = pm_runtime_get_sync(pds[i]);
+		if (ret < 0)
+			goto unroll_pd_votes;
+	}
+
+	return 0;
+
+unroll_pd_votes:
+	for (i--; i >= 0; i--) {
+		dev_pm_genpd_set_performance_state(pds[i], 0);
+		pm_runtime_put(pds[i]);
+	}
+
+	return ret;
+};
+
+static void q6v5_pds_disable(struct q6v5 *qproc, struct device **pds,
+			     size_t pd_count)
+{
+	int i;
+
+	for (i = 0; i < pd_count; i++) {
+		dev_pm_genpd_set_performance_state(pds[i], 0);
+		pm_runtime_put(pds[i]);
+	}
+}
+
 static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int *current_perm,
 				   bool remote_owner, phys_addr_t addr,
 				   size_t size)
@@ -690,11 +730,17 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 
 	qcom_q6v5_prepare(&qproc->q6v5);
 
+	ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+	if (ret < 0) {
+		dev_err(qproc->dev, "failed to enable proxy power domains\n");
+		goto disable_irqs;
+	}
+
 	ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
 				    qproc->proxy_reg_count);
 	if (ret) {
 		dev_err(qproc->dev, "failed to enable proxy supplies\n");
-		goto disable_irqs;
+		goto disable_proxy_pds;
 	}
 
 	ret = q6v5_clk_enable(qproc->dev, qproc->proxy_clks,
@@ -791,6 +837,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 disable_proxy_reg:
 	q6v5_regulator_disable(qproc, qproc->proxy_regs,
 			       qproc->proxy_reg_count);
+disable_proxy_pds:
+	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 disable_irqs:
 	qcom_q6v5_unprepare(&qproc->q6v5);
 
@@ -841,6 +889,8 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
 
 	ret = qcom_q6v5_unprepare(&qproc->q6v5);
 	if (ret) {
+		q6v5_pds_disable(qproc, qproc->proxy_pds,
+				 qproc->proxy_pd_count);
 		q6v5_clk_disable(qproc->dev, qproc->proxy_clks,
 				 qproc->proxy_clk_count);
 		q6v5_regulator_disable(qproc, qproc->proxy_regs,
@@ -1121,6 +1171,7 @@ static void qcom_msa_handover(struct qcom_q6v5 *q6v5)
 			 qproc->proxy_clk_count);
 	q6v5_regulator_disable(qproc, qproc->proxy_regs,
 			       qproc->proxy_reg_count);
+	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 }
 
 static int q6v5_init_mem(struct q6v5 *qproc, struct platform_device *pdev)
@@ -1181,6 +1232,45 @@ static int q6v5_init_clocks(struct device *dev, struct clk **clks,
 	return i;
 }
 
+static int q6v5_pds_attach(struct device *dev, struct device **devs,
+			   char **pd_names)
+{
+	size_t num_pds = 0;
+	int ret;
+	int i;
+
+	if (!pd_names)
+		return 0;
+
+	while (pd_names[num_pds])
+		num_pds++;
+
+	for (i = 0; i < num_pds; i++) {
+		devs[i] = dev_pm_domain_attach_by_name(dev, pd_names[i]);
+		if (IS_ERR(devs[i])) {
+			ret = PTR_ERR(devs[i]);
+			goto unroll_attach;
+		}
+	}
+
+	return num_pds;
+
+unroll_attach:
+	for (i--; i >= 0; i--)
+		dev_pm_domain_detach(devs[i], false);
+
+	return ret;
+};
+
+static void q6v5_pds_detach(struct q6v5 *qproc, struct device **pds,
+			    size_t pd_count)
+{
+	int i;
+
+	for (i = 0; i < pd_count; i++)
+		dev_pm_domain_detach(pds[i], false);
+}
+
 static int q6v5_init_reset(struct q6v5 *qproc)
 {
 	qproc->mss_restart = devm_reset_control_get_exclusive(qproc->dev,
@@ -1322,10 +1412,18 @@ static int q6v5_probe(struct platform_device *pdev)
 	}
 	qproc->active_reg_count = ret;
 
+	ret = q6v5_pds_attach(&pdev->dev, qproc->proxy_pds,
+			      desc->proxy_pd_names);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to init power domains\n");
+		goto free_rproc;
+	}
+	qproc->proxy_pd_count = ret;
+
 	qproc->has_alt_reset = desc->has_alt_reset;
 	ret = q6v5_init_reset(qproc);
 	if (ret)
-		goto free_rproc;
+		goto detach_proxy_pds;
 
 	qproc->version = desc->version;
 	qproc->need_mem_protection = desc->need_mem_protection;
@@ -1333,7 +1431,7 @@ static int q6v5_probe(struct platform_device *pdev)
 	ret = qcom_q6v5_init(&qproc->q6v5, pdev, rproc, MPSS_CRASH_REASON_SMEM,
 			     qcom_msa_handover);
 	if (ret)
-		goto free_rproc;
+		goto detach_proxy_pds;
 
 	qproc->mpss_perm = BIT(QCOM_SCM_VMID_HLOS);
 	qproc->mba_perm = BIT(QCOM_SCM_VMID_HLOS);
@@ -1343,15 +1441,17 @@ static int q6v5_probe(struct platform_device *pdev)
 	qproc->sysmon = qcom_add_sysmon_subdev(rproc, "modem", 0x12);
 	if (IS_ERR(qproc->sysmon)) {
 		ret = PTR_ERR(qproc->sysmon);
-		goto free_rproc;
+		goto detach_proxy_pds;
 	}
 
 	ret = rproc_add(rproc);
 	if (ret)
-		goto free_rproc;
+		goto detach_proxy_pds;
 
 	return 0;
 
+detach_proxy_pds:
+	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 free_rproc:
 	rproc_free(rproc);
 
@@ -1368,6 +1468,9 @@ static int q6v5_remove(struct platform_device *pdev)
 	qcom_remove_glink_subdev(qproc->rproc, &qproc->glink_subdev);
 	qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
 	qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
+
+	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+
 	rproc_free(qproc->rproc);
 
 	return 0;
@@ -1392,6 +1495,12 @@ static const struct rproc_hexagon_res sdm845_mss = {
 			"mnoc_axi",
 			NULL
 	},
+	.proxy_pd_names = (char*[]){
+			"cx",
+			"mx",
+			"mss",
+			NULL
+	},
 	.need_mem_protection = true,
 	.has_alt_reset = true,
 	.version = MSS_SDM845,
-- 
2.18.0


^ permalink raw reply	[relevance 7%]

* [PATCH v4 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845
      [irrelevant] <20190129232009.5033-1-bjorn.andersson@linaro.org>
  2019-01-29 23:20 ` [PATCH v4 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains Bjorn Andersson
@ 2019-01-29 23:20 ` Bjorn Andersson
  2019-01-29 23:20 ` [PATCH v4 10/10] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
  2 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-29 23:20 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	Arun Kumar Neelakantam, Sibi Sankar, linux-arm-msm, devicetree,
	linux-kernel, linux-remoteproc

The SDM845 MSS needs the load_state powerdomain voted for during the
duration of the MSS being powered on, to let the AOSS know that it may
not perform certain power save measures. So vote for this.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v3:
- None

 drivers/remoteproc/qcom_q6v5_mss.c | 31 ++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index c32c63e351a0..e30f5486fd20 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -133,6 +133,7 @@ struct rproc_hexagon_res {
 	char **proxy_clk_names;
 	char **reset_clk_names;
 	char **active_clk_names;
+	char **active_pd_names;
 	char **proxy_pd_names;
 	int version;
 	bool need_mem_protection;
@@ -159,10 +160,12 @@ struct q6v5 {
 	struct clk *active_clks[8];
 	struct clk *reset_clks[4];
 	struct clk *proxy_clks[4];
+	struct device *active_pds[1];
 	struct device *proxy_pds[3];
 	int active_clk_count;
 	int reset_clk_count;
 	int proxy_clk_count;
+	int active_pd_count;
 	int proxy_pd_count;
 
 	struct reg_info active_regs[1];
@@ -730,10 +733,16 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 
 	qcom_q6v5_prepare(&qproc->q6v5);
 
+	ret = q6v5_pds_enable(qproc, qproc->active_pds, qproc->active_pd_count);
+	if (ret < 0) {
+		dev_err(qproc->dev, "failed to enable active power domains\n");
+		goto disable_irqs;
+	}
+
 	ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 	if (ret < 0) {
 		dev_err(qproc->dev, "failed to enable proxy power domains\n");
-		goto disable_irqs;
+		goto disable_active_pds;
 	}
 
 	ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
@@ -839,6 +848,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 			       qproc->proxy_reg_count);
 disable_proxy_pds:
 	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+disable_active_pds:
+	q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
 disable_irqs:
 	qcom_q6v5_unprepare(&qproc->q6v5);
 
@@ -878,6 +889,7 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
 			 qproc->active_clk_count);
 	q6v5_regulator_disable(qproc, qproc->active_regs,
 			       qproc->active_reg_count);
+	q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
 
 	/* In case of failure or coredump scenario where reclaiming MBA memory
 	 * could not happen reclaim it here.
@@ -1412,11 +1424,19 @@ static int q6v5_probe(struct platform_device *pdev)
 	}
 	qproc->active_reg_count = ret;
 
+	ret = q6v5_pds_attach(&pdev->dev, qproc->active_pds,
+			      desc->active_pd_names);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to attach active power domains\n");
+		goto free_rproc;
+	}
+	qproc->active_pd_count = ret;
+
 	ret = q6v5_pds_attach(&pdev->dev, qproc->proxy_pds,
 			      desc->proxy_pd_names);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Failed to init power domains\n");
-		goto free_rproc;
+		goto detach_active_pds;
 	}
 	qproc->proxy_pd_count = ret;
 
@@ -1452,6 +1472,8 @@ static int q6v5_probe(struct platform_device *pdev)
 
 detach_proxy_pds:
 	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+detach_active_pds:
+	q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
 free_rproc:
 	rproc_free(rproc);
 
@@ -1469,6 +1491,7 @@ static int q6v5_remove(struct platform_device *pdev)
 	qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
 	qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
 
+	q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
 	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 
 	rproc_free(qproc->rproc);
@@ -1495,6 +1518,10 @@ static const struct rproc_hexagon_res sdm845_mss = {
 			"mnoc_axi",
 			NULL
 	},
+	.active_pd_names = (char*[]){
+			"load_state",
+			NULL
+	},
 	.proxy_pd_names = (char*[]){
 			"cx",
 			"mx",
-- 
2.18.0


^ permalink raw reply	[relevance 7%]

* Re: [PATCH v3] remoteproc: qcom: Add support for parsing fw dt bindings
  2019-01-14 19:50 [PATCH v3] remoteproc: qcom: Add support for parsing fw dt bindings Sibi Sankar
@ 2019-01-30 21:04 ` Bjorn Andersson
  0 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-30 21:04 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: briannorris, david.brown, robh+dt, mark.rutland, andy.gross,
	akdwived, clew, linux-kernel, linux-arm-msm-owner, ohad,
	linux-remoteproc, devicetree, dianders

On Mon 14 Jan 11:50 PST 2019, Sibi Sankar wrote:

> Add support for parsing "firmware-name" dt bindings which specifies
> the relative paths of mba/modem/pas image as strings. Fallback to
> the default paths for mba/modem/pas image on -EINVAL.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>

Applied,

Thanks,
Bjorn

> ---
> 
> v3:
>  * Fixed minor code style issues
>  * Add comments for firmware blob name generation
>    and use sprintf instead
> 
>  drivers/remoteproc/qcom_q6v5_mss.c | 47 +++++++++++++++++++++++-------
>  drivers/remoteproc/qcom_q6v5_pas.c |  9 +++++-
>  2 files changed, 45 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index c86dc40cfb8c..41e92a025d21 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -188,6 +188,7 @@ struct q6v5 {
>  	bool has_alt_reset;
>  	int mpss_perm;
>  	int mba_perm;
> +	const char *hexagon_mdt_image;
>  	int version;
>  };
>  
> @@ -860,17 +861,26 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>  	phys_addr_t min_addr = PHYS_ADDR_MAX;
>  	phys_addr_t max_addr = 0;
>  	bool relocate = false;
> -	char seg_name[10];
> +	char *fw_name;
> +	size_t fw_name_len;
>  	ssize_t offset;
>  	size_t size = 0;
>  	void *ptr;
>  	int ret;
>  	int i;
>  
> -	ret = request_firmware(&fw, "modem.mdt", qproc->dev);
> +	fw_name_len = strlen(qproc->hexagon_mdt_image);
> +	if (fw_name_len <= 4)
> +		return -EINVAL;
> +
> +	fw_name = kstrdup(qproc->hexagon_mdt_image, GFP_KERNEL);
> +	if (!fw_name)
> +		return -ENOMEM;
> +
> +	ret = request_firmware(&fw, fw_name, qproc->dev);
>  	if (ret < 0) {
> -		dev_err(qproc->dev, "unable to load modem.mdt\n");
> -		return ret;
> +		dev_err(qproc->dev, "unable to load %s\n", fw_name);
> +		goto out;
>  	}
>  
>  	/* Initialize the RMB validator */
> @@ -918,10 +928,11 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>  		ptr = qproc->mpss_region + offset;
>  
>  		if (phdr->p_filesz) {
> -			snprintf(seg_name, sizeof(seg_name), "modem.b%02d", i);
> -			ret = request_firmware(&seg_fw, seg_name, qproc->dev);
> +			/* Replace "xxx.xxx" with "xxx.bxx" */
> +			sprintf(fw_name + fw_name_len - 3, "b%02d", i);
> +			ret = request_firmware(&seg_fw, fw_name, qproc->dev);
>  			if (ret) {
> -				dev_err(qproc->dev, "failed to load %s\n", seg_name);
> +				dev_err(qproc->dev, "failed to load %s\n", fw_name);
>  				goto release_firmware;
>  			}
>  
> @@ -960,6 +971,8 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
>  
>  release_firmware:
>  	release_firmware(fw);
> +out:
> +	kfree(fw_name);
>  
>  	return ret < 0 ? ret : 0;
>  }
> @@ -1075,9 +1088,10 @@ static int qcom_q6v5_register_dump_segments(struct rproc *rproc,
>  	unsigned long i;
>  	int ret;
>  
> -	ret = request_firmware(&fw, "modem.mdt", qproc->dev);
> +	ret = request_firmware(&fw, qproc->hexagon_mdt_image, qproc->dev);
>  	if (ret < 0) {
> -		dev_err(qproc->dev, "unable to load modem.mdt\n");
> +		dev_err(qproc->dev, "unable to load %s\n",
> +			qproc->hexagon_mdt_image);
>  		return ret;
>  	}
>  
> @@ -1253,6 +1267,7 @@ static int q6v5_probe(struct platform_device *pdev)
>  	const struct rproc_hexagon_res *desc;
>  	struct q6v5 *qproc;
>  	struct rproc *rproc;
> +	const char *mba_image;
>  	int ret;
>  
>  	desc = of_device_get_match_data(&pdev->dev);
> @@ -1262,8 +1277,14 @@ static int q6v5_probe(struct platform_device *pdev)
>  	if (desc->need_mem_protection && !qcom_scm_is_available())
>  		return -EPROBE_DEFER;
>  
> +	mba_image = desc->hexagon_mba_image;
> +	ret = of_property_read_string_index(pdev->dev.of_node, "firmware-name",
> +					    0, &mba_image);
> +	if (ret < 0 && ret != -EINVAL)
> +		return ret;
> +
>  	rproc = rproc_alloc(&pdev->dev, pdev->name, &q6v5_ops,
> -			    desc->hexagon_mba_image, sizeof(*qproc));
> +			    mba_image, sizeof(*qproc));
>  	if (!rproc) {
>  		dev_err(&pdev->dev, "failed to allocate rproc\n");
>  		return -ENOMEM;
> @@ -1272,6 +1293,12 @@ static int q6v5_probe(struct platform_device *pdev)
>  	qproc = (struct q6v5 *)rproc->priv;
>  	qproc->dev = &pdev->dev;
>  	qproc->rproc = rproc;
> +	qproc->hexagon_mdt_image = "modem.mdt";
> +	ret = of_property_read_string_index(pdev->dev.of_node, "firmware-name",
> +					    1, &qproc->hexagon_mdt_image);
> +	if (ret < 0 && ret != -EINVAL)
> +		return ret;
> +
>  	platform_set_drvdata(pdev, qproc);
>  
>  	ret = q6v5_init_mem(qproc, pdev);
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index b1e63fcd5fdf..cfdafd68e2cd 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -258,6 +258,7 @@ static int adsp_probe(struct platform_device *pdev)
>  	const struct adsp_data *desc;
>  	struct qcom_adsp *adsp;
>  	struct rproc *rproc;
> +	const char *fw_name;
>  	int ret;
>  
>  	desc = of_device_get_match_data(&pdev->dev);
> @@ -267,8 +268,14 @@ static int adsp_probe(struct platform_device *pdev)
>  	if (!qcom_scm_is_available())
>  		return -EPROBE_DEFER;
>  
> +	fw_name = desc->firmware_name;
> +	ret = of_property_read_string(pdev->dev.of_node, "firmware-name",
> +				      &fw_name);
> +	if (ret < 0 && ret != -EINVAL)
> +		return ret;
> +
>  	rproc = rproc_alloc(&pdev->dev, pdev->name, &adsp_ops,
> -			    desc->firmware_name, sizeof(*adsp));
> +			    fw_name, sizeof(*adsp));
>  	if (!rproc) {
>  		dev_err(&pdev->dev, "unable to allocate remoteproc\n");
>  		return -ENOMEM;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

^ permalink raw reply	[relevance 0%]

* [PATCH v5 10/10] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
      [irrelevant] <20190131003933.11436-1-bjorn.andersson@linaro.org>
  2019-01-31  0:39 ` [PATCH v5 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains Bjorn Andersson
  2019-01-31  0:39 ` [PATCH v5 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845 Bjorn Andersson
@ 2019-01-31  0:39 ` Bjorn Andersson
      [irrelevant] ` <20190131003933.11436-2-bjorn.andersson@linaro.org>
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-31  0:39 UTC (permalink / raw)
  To: Andy Gross, David Brown
  Cc: Rob Herring, Mark Rutland, Ohad Ben-Cohen,
	Arun Kumar Neelakantam, Sibi Sankar, linux-arm-msm, devicetree,
	linux-kernel, linux-remoteproc

From: Sibi Sankar <sibis@codeaurora.org>

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v4:
- None

Changes since v3:
- Fixed sort order in /soc

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index dc43fee8bb90..cba09899282e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1613,6 +1613,64 @@
 			};
 		};
 
+		mss_pil: remoteproc@4080000 {
+			compatible = "qcom,sdm845-mss-pil";
+			reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
+			reg-names = "qdsp6", "rmb";
+
+			interrupts-extended =
+				<&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog", "fatal", "ready",
+					  "handover", "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+				 <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+				 <&gcc GCC_BOOT_ROM_AHB_CLK>,
+				 <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+				 <&gcc GCC_MSS_SNOC_AXI_CLK>,
+				 <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+				 <&gcc GCC_PRNG_AHB_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "iface", "bus", "mem", "gpll0_mss",
+				      "snoc_axi", "mnoc_axi", "prng", "xo";
+
+			qcom,smem-states = <&modem_smp2p_out 0>;
+			qcom,smem-state-names = "stop";
+
+			resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+				 <&pdc_reset PDC_MODEM_SYNC_RESET>;
+			reset-names = "mss_restart", "pdc_reset";
+
+			qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000 0x24000>;
+
+			power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
+					<&rpmhpd SDM845_CX>,
+					<&rpmhpd SDM845_MX>,
+					<&rpmhpd SDM845_MSS>;
+			power-domain-names = "load_state", "cx", "mx", "mss";
+
+			mba {
+				memory-region = <&mba_region>;
+			};
+
+			mpss {
+				memory-region = <&mpss_region>;
+			};
+
+			glink-edge {
+				interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+				label = "modem";
+				qcom,remote-pid = <1>;
+				mboxes = <&apss_shared 12>;
+			};
+		};
+
 		gpucc: clock-controller@5090000 {
 			compatible = "qcom,sdm845-gpucc";
 			reg = <0 0x05090000 0 0x9000>;
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* [PATCH v5 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845
      [irrelevant] <20190131003933.11436-1-bjorn.andersson@linaro.org>
  2019-01-31  0:39 ` [PATCH v5 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains Bjorn Andersson
@ 2019-01-31  0:39 ` Bjorn Andersson
  2019-01-31  4:51   ` Bjorn Andersson
  2019-01-31  0:39 ` [PATCH v5 10/10] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
                   ` (5 subsequent siblings)
  7 siblings, 1 reply; 200+ results
From: Bjorn Andersson @ 2019-01-31  0:39 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	Arun Kumar Neelakantam, Sibi Sankar, linux-arm-msm, devicetree,
	linux-kernel, linux-remoteproc

The SDM845 MSS needs the load_state powerdomain voted for during the
duration of the MSS being powered on, to let the AOSS know that it may
not perform certain power save measures. So vote for this.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v4:
- None

Changes since v3:
- None

 drivers/remoteproc/qcom_q6v5_mss.c | 31 ++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index c32c63e351a0..e30f5486fd20 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -133,6 +133,7 @@ struct rproc_hexagon_res {
 	char **proxy_clk_names;
 	char **reset_clk_names;
 	char **active_clk_names;
+	char **active_pd_names;
 	char **proxy_pd_names;
 	int version;
 	bool need_mem_protection;
@@ -159,10 +160,12 @@ struct q6v5 {
 	struct clk *active_clks[8];
 	struct clk *reset_clks[4];
 	struct clk *proxy_clks[4];
+	struct device *active_pds[1];
 	struct device *proxy_pds[3];
 	int active_clk_count;
 	int reset_clk_count;
 	int proxy_clk_count;
+	int active_pd_count;
 	int proxy_pd_count;
 
 	struct reg_info active_regs[1];
@@ -730,10 +733,16 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 
 	qcom_q6v5_prepare(&qproc->q6v5);
 
+	ret = q6v5_pds_enable(qproc, qproc->active_pds, qproc->active_pd_count);
+	if (ret < 0) {
+		dev_err(qproc->dev, "failed to enable active power domains\n");
+		goto disable_irqs;
+	}
+
 	ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 	if (ret < 0) {
 		dev_err(qproc->dev, "failed to enable proxy power domains\n");
-		goto disable_irqs;
+		goto disable_active_pds;
 	}
 
 	ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
@@ -839,6 +848,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 			       qproc->proxy_reg_count);
 disable_proxy_pds:
 	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+disable_active_pds:
+	q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
 disable_irqs:
 	qcom_q6v5_unprepare(&qproc->q6v5);
 
@@ -878,6 +889,7 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
 			 qproc->active_clk_count);
 	q6v5_regulator_disable(qproc, qproc->active_regs,
 			       qproc->active_reg_count);
+	q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
 
 	/* In case of failure or coredump scenario where reclaiming MBA memory
 	 * could not happen reclaim it here.
@@ -1412,11 +1424,19 @@ static int q6v5_probe(struct platform_device *pdev)
 	}
 	qproc->active_reg_count = ret;
 
+	ret = q6v5_pds_attach(&pdev->dev, qproc->active_pds,
+			      desc->active_pd_names);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to attach active power domains\n");
+		goto free_rproc;
+	}
+	qproc->active_pd_count = ret;
+
 	ret = q6v5_pds_attach(&pdev->dev, qproc->proxy_pds,
 			      desc->proxy_pd_names);
 	if (ret < 0) {
 		dev_err(&pdev->dev, "Failed to init power domains\n");
-		goto free_rproc;
+		goto detach_active_pds;
 	}
 	qproc->proxy_pd_count = ret;
 
@@ -1452,6 +1472,8 @@ static int q6v5_probe(struct platform_device *pdev)
 
 detach_proxy_pds:
 	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+detach_active_pds:
+	q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
 free_rproc:
 	rproc_free(rproc);
 
@@ -1469,6 +1491,7 @@ static int q6v5_remove(struct platform_device *pdev)
 	qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
 	qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
 
+	q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
 	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 
 	rproc_free(qproc->rproc);
@@ -1495,6 +1518,10 @@ static const struct rproc_hexagon_res sdm845_mss = {
 			"mnoc_axi",
 			NULL
 	},
+	.active_pd_names = (char*[]){
+			"load_state",
+			NULL
+	},
 	.proxy_pd_names = (char*[]){
 			"cx",
 			"mx",
-- 
2.18.0


^ permalink raw reply	[relevance 7%]

* [PATCH v5 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains
      [irrelevant] <20190131003933.11436-1-bjorn.andersson@linaro.org>
@ 2019-01-31  0:39 ` Bjorn Andersson
  2019-01-31  4:51   ` Bjorn Andersson
  2019-01-31  0:39 ` [PATCH v5 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845 Bjorn Andersson
                   ` (6 subsequent siblings)
  7 siblings, 1 reply; 200+ results
From: Bjorn Andersson @ 2019-01-31  0:39 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	Arun Kumar Neelakantam, Sibi Sankar, linux-arm-msm, devicetree,
	linux-kernel, linux-remoteproc

From: Rajendra Nayak <rnayak@codeaurora.org>

With rpmh ARC resources being modelled as power domains with performance
state, we need to proxy vote on these for SDM845.
Add support to vote on multiple of them, now that genpd supports
associating mutliple power domains to a device.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
[bjorn: Drop device link, improve error handling, name things "proxy"]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v4:
- None

Changes since v3:
- Rebased upon latest remoteproc branch

 drivers/remoteproc/qcom_q6v5_mss.c | 119 +++++++++++++++++++++++++++--
 1 file changed, 114 insertions(+), 5 deletions(-)

diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
index 07d1cc52a647..c32c63e351a0 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -25,6 +25,8 @@
 #include <linux/of_address.h>
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
 #include <linux/regmap.h>
 #include <linux/regulator/consumer.h>
 #include <linux/remoteproc.h>
@@ -131,6 +133,7 @@ struct rproc_hexagon_res {
 	char **proxy_clk_names;
 	char **reset_clk_names;
 	char **active_clk_names;
+	char **proxy_pd_names;
 	int version;
 	bool need_mem_protection;
 	bool has_alt_reset;
@@ -156,9 +159,11 @@ struct q6v5 {
 	struct clk *active_clks[8];
 	struct clk *reset_clks[4];
 	struct clk *proxy_clks[4];
+	struct device *proxy_pds[3];
 	int active_clk_count;
 	int reset_clk_count;
 	int proxy_clk_count;
+	int proxy_pd_count;
 
 	struct reg_info active_regs[1];
 	struct reg_info proxy_regs[3];
@@ -321,6 +326,41 @@ static void q6v5_clk_disable(struct device *dev,
 		clk_disable_unprepare(clks[i]);
 }
 
+static int q6v5_pds_enable(struct q6v5 *qproc, struct device **pds,
+			   size_t pd_count)
+{
+	int ret;
+	int i;
+
+	for (i = 0; i < pd_count; i++) {
+		dev_pm_genpd_set_performance_state(pds[i], INT_MAX);
+		ret = pm_runtime_get_sync(pds[i]);
+		if (ret < 0)
+			goto unroll_pd_votes;
+	}
+
+	return 0;
+
+unroll_pd_votes:
+	for (i--; i >= 0; i--) {
+		dev_pm_genpd_set_performance_state(pds[i], 0);
+		pm_runtime_put(pds[i]);
+	}
+
+	return ret;
+};
+
+static void q6v5_pds_disable(struct q6v5 *qproc, struct device **pds,
+			     size_t pd_count)
+{
+	int i;
+
+	for (i = 0; i < pd_count; i++) {
+		dev_pm_genpd_set_performance_state(pds[i], 0);
+		pm_runtime_put(pds[i]);
+	}
+}
+
 static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int *current_perm,
 				   bool remote_owner, phys_addr_t addr,
 				   size_t size)
@@ -690,11 +730,17 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 
 	qcom_q6v5_prepare(&qproc->q6v5);
 
+	ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+	if (ret < 0) {
+		dev_err(qproc->dev, "failed to enable proxy power domains\n");
+		goto disable_irqs;
+	}
+
 	ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
 				    qproc->proxy_reg_count);
 	if (ret) {
 		dev_err(qproc->dev, "failed to enable proxy supplies\n");
-		goto disable_irqs;
+		goto disable_proxy_pds;
 	}
 
 	ret = q6v5_clk_enable(qproc->dev, qproc->proxy_clks,
@@ -791,6 +837,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
 disable_proxy_reg:
 	q6v5_regulator_disable(qproc, qproc->proxy_regs,
 			       qproc->proxy_reg_count);
+disable_proxy_pds:
+	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 disable_irqs:
 	qcom_q6v5_unprepare(&qproc->q6v5);
 
@@ -841,6 +889,8 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
 
 	ret = qcom_q6v5_unprepare(&qproc->q6v5);
 	if (ret) {
+		q6v5_pds_disable(qproc, qproc->proxy_pds,
+				 qproc->proxy_pd_count);
 		q6v5_clk_disable(qproc->dev, qproc->proxy_clks,
 				 qproc->proxy_clk_count);
 		q6v5_regulator_disable(qproc, qproc->proxy_regs,
@@ -1121,6 +1171,7 @@ static void qcom_msa_handover(struct qcom_q6v5 *q6v5)
 			 qproc->proxy_clk_count);
 	q6v5_regulator_disable(qproc, qproc->proxy_regs,
 			       qproc->proxy_reg_count);
+	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 }
 
 static int q6v5_init_mem(struct q6v5 *qproc, struct platform_device *pdev)
@@ -1181,6 +1232,45 @@ static int q6v5_init_clocks(struct device *dev, struct clk **clks,
 	return i;
 }
 
+static int q6v5_pds_attach(struct device *dev, struct device **devs,
+			   char **pd_names)
+{
+	size_t num_pds = 0;
+	int ret;
+	int i;
+
+	if (!pd_names)
+		return 0;
+
+	while (pd_names[num_pds])
+		num_pds++;
+
+	for (i = 0; i < num_pds; i++) {
+		devs[i] = dev_pm_domain_attach_by_name(dev, pd_names[i]);
+		if (IS_ERR(devs[i])) {
+			ret = PTR_ERR(devs[i]);
+			goto unroll_attach;
+		}
+	}
+
+	return num_pds;
+
+unroll_attach:
+	for (i--; i >= 0; i--)
+		dev_pm_domain_detach(devs[i], false);
+
+	return ret;
+};
+
+static void q6v5_pds_detach(struct q6v5 *qproc, struct device **pds,
+			    size_t pd_count)
+{
+	int i;
+
+	for (i = 0; i < pd_count; i++)
+		dev_pm_domain_detach(pds[i], false);
+}
+
 static int q6v5_init_reset(struct q6v5 *qproc)
 {
 	qproc->mss_restart = devm_reset_control_get_exclusive(qproc->dev,
@@ -1322,10 +1412,18 @@ static int q6v5_probe(struct platform_device *pdev)
 	}
 	qproc->active_reg_count = ret;
 
+	ret = q6v5_pds_attach(&pdev->dev, qproc->proxy_pds,
+			      desc->proxy_pd_names);
+	if (ret < 0) {
+		dev_err(&pdev->dev, "Failed to init power domains\n");
+		goto free_rproc;
+	}
+	qproc->proxy_pd_count = ret;
+
 	qproc->has_alt_reset = desc->has_alt_reset;
 	ret = q6v5_init_reset(qproc);
 	if (ret)
-		goto free_rproc;
+		goto detach_proxy_pds;
 
 	qproc->version = desc->version;
 	qproc->need_mem_protection = desc->need_mem_protection;
@@ -1333,7 +1431,7 @@ static int q6v5_probe(struct platform_device *pdev)
 	ret = qcom_q6v5_init(&qproc->q6v5, pdev, rproc, MPSS_CRASH_REASON_SMEM,
 			     qcom_msa_handover);
 	if (ret)
-		goto free_rproc;
+		goto detach_proxy_pds;
 
 	qproc->mpss_perm = BIT(QCOM_SCM_VMID_HLOS);
 	qproc->mba_perm = BIT(QCOM_SCM_VMID_HLOS);
@@ -1343,15 +1441,17 @@ static int q6v5_probe(struct platform_device *pdev)
 	qproc->sysmon = qcom_add_sysmon_subdev(rproc, "modem", 0x12);
 	if (IS_ERR(qproc->sysmon)) {
 		ret = PTR_ERR(qproc->sysmon);
-		goto free_rproc;
+		goto detach_proxy_pds;
 	}
 
 	ret = rproc_add(rproc);
 	if (ret)
-		goto free_rproc;
+		goto detach_proxy_pds;
 
 	return 0;
 
+detach_proxy_pds:
+	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
 free_rproc:
 	rproc_free(rproc);
 
@@ -1368,6 +1468,9 @@ static int q6v5_remove(struct platform_device *pdev)
 	qcom_remove_glink_subdev(qproc->rproc, &qproc->glink_subdev);
 	qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
 	qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
+
+	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
+
 	rproc_free(qproc->rproc);
 
 	return 0;
@@ -1392,6 +1495,12 @@ static const struct rproc_hexagon_res sdm845_mss = {
 			"mnoc_axi",
 			NULL
 	},
+	.proxy_pd_names = (char*[]){
+			"cx",
+			"mx",
+			"mss",
+			NULL
+	},
 	.need_mem_protection = true,
 	.has_alt_reset = true,
 	.version = MSS_SDM845,
-- 
2.18.0


^ permalink raw reply	[relevance 7%]

* Re: [PATCH v5 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains
  2019-01-31  0:39 ` [PATCH v5 07/10] remoteproc: q6v5-mss: Vote for rpmh power domains Bjorn Andersson
@ 2019-01-31  4:51   ` Bjorn Andersson
  0 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-31  4:51 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	Arun Kumar Neelakantam, Sibi Sankar, linux-arm-msm, devicetree,
	linux-kernel, linux-remoteproc

On Wed 30 Jan 16:39 PST 2019, Bjorn Andersson wrote:

> From: Rajendra Nayak <rnayak@codeaurora.org>
> 
> With rpmh ARC resources being modelled as power domains with performance
> state, we need to proxy vote on these for SDM845.
> Add support to vote on multiple of them, now that genpd supports
> associating mutliple power domains to a device.
> 
> Tested-by: Sibi Sankar <sibis@codeaurora.org>
> Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
> Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
> [bjorn: Drop device link, improve error handling, name things "proxy"]
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 

Applied

> Changes since v4:
> - None
> 
> Changes since v3:
> - Rebased upon latest remoteproc branch
> 
>  drivers/remoteproc/qcom_q6v5_mss.c | 119 +++++++++++++++++++++++++++--
>  1 file changed, 114 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index 07d1cc52a647..c32c63e351a0 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -25,6 +25,8 @@
>  #include <linux/of_address.h>
>  #include <linux/of_device.h>
>  #include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/pm_runtime.h>
>  #include <linux/regmap.h>
>  #include <linux/regulator/consumer.h>
>  #include <linux/remoteproc.h>
> @@ -131,6 +133,7 @@ struct rproc_hexagon_res {
>  	char **proxy_clk_names;
>  	char **reset_clk_names;
>  	char **active_clk_names;
> +	char **proxy_pd_names;
>  	int version;
>  	bool need_mem_protection;
>  	bool has_alt_reset;
> @@ -156,9 +159,11 @@ struct q6v5 {
>  	struct clk *active_clks[8];
>  	struct clk *reset_clks[4];
>  	struct clk *proxy_clks[4];
> +	struct device *proxy_pds[3];
>  	int active_clk_count;
>  	int reset_clk_count;
>  	int proxy_clk_count;
> +	int proxy_pd_count;
>  
>  	struct reg_info active_regs[1];
>  	struct reg_info proxy_regs[3];
> @@ -321,6 +326,41 @@ static void q6v5_clk_disable(struct device *dev,
>  		clk_disable_unprepare(clks[i]);
>  }
>  
> +static int q6v5_pds_enable(struct q6v5 *qproc, struct device **pds,
> +			   size_t pd_count)
> +{
> +	int ret;
> +	int i;
> +
> +	for (i = 0; i < pd_count; i++) {
> +		dev_pm_genpd_set_performance_state(pds[i], INT_MAX);
> +		ret = pm_runtime_get_sync(pds[i]);
> +		if (ret < 0)
> +			goto unroll_pd_votes;
> +	}
> +
> +	return 0;
> +
> +unroll_pd_votes:
> +	for (i--; i >= 0; i--) {
> +		dev_pm_genpd_set_performance_state(pds[i], 0);
> +		pm_runtime_put(pds[i]);
> +	}
> +
> +	return ret;
> +};
> +
> +static void q6v5_pds_disable(struct q6v5 *qproc, struct device **pds,
> +			     size_t pd_count)
> +{
> +	int i;
> +
> +	for (i = 0; i < pd_count; i++) {
> +		dev_pm_genpd_set_performance_state(pds[i], 0);
> +		pm_runtime_put(pds[i]);
> +	}
> +}
> +
>  static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int *current_perm,
>  				   bool remote_owner, phys_addr_t addr,
>  				   size_t size)
> @@ -690,11 +730,17 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>  
>  	qcom_q6v5_prepare(&qproc->q6v5);
>  
> +	ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> +	if (ret < 0) {
> +		dev_err(qproc->dev, "failed to enable proxy power domains\n");
> +		goto disable_irqs;
> +	}
> +
>  	ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
>  				    qproc->proxy_reg_count);
>  	if (ret) {
>  		dev_err(qproc->dev, "failed to enable proxy supplies\n");
> -		goto disable_irqs;
> +		goto disable_proxy_pds;
>  	}
>  
>  	ret = q6v5_clk_enable(qproc->dev, qproc->proxy_clks,
> @@ -791,6 +837,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>  disable_proxy_reg:
>  	q6v5_regulator_disable(qproc, qproc->proxy_regs,
>  			       qproc->proxy_reg_count);
> +disable_proxy_pds:
> +	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
>  disable_irqs:
>  	qcom_q6v5_unprepare(&qproc->q6v5);
>  
> @@ -841,6 +889,8 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
>  
>  	ret = qcom_q6v5_unprepare(&qproc->q6v5);
>  	if (ret) {
> +		q6v5_pds_disable(qproc, qproc->proxy_pds,
> +				 qproc->proxy_pd_count);
>  		q6v5_clk_disable(qproc->dev, qproc->proxy_clks,
>  				 qproc->proxy_clk_count);
>  		q6v5_regulator_disable(qproc, qproc->proxy_regs,
> @@ -1121,6 +1171,7 @@ static void qcom_msa_handover(struct qcom_q6v5 *q6v5)
>  			 qproc->proxy_clk_count);
>  	q6v5_regulator_disable(qproc, qproc->proxy_regs,
>  			       qproc->proxy_reg_count);
> +	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
>  }
>  
>  static int q6v5_init_mem(struct q6v5 *qproc, struct platform_device *pdev)
> @@ -1181,6 +1232,45 @@ static int q6v5_init_clocks(struct device *dev, struct clk **clks,
>  	return i;
>  }
>  
> +static int q6v5_pds_attach(struct device *dev, struct device **devs,
> +			   char **pd_names)
> +{
> +	size_t num_pds = 0;
> +	int ret;
> +	int i;
> +
> +	if (!pd_names)
> +		return 0;
> +
> +	while (pd_names[num_pds])
> +		num_pds++;
> +
> +	for (i = 0; i < num_pds; i++) {
> +		devs[i] = dev_pm_domain_attach_by_name(dev, pd_names[i]);
> +		if (IS_ERR(devs[i])) {
> +			ret = PTR_ERR(devs[i]);
> +			goto unroll_attach;
> +		}
> +	}
> +
> +	return num_pds;
> +
> +unroll_attach:
> +	for (i--; i >= 0; i--)
> +		dev_pm_domain_detach(devs[i], false);
> +
> +	return ret;
> +};
> +
> +static void q6v5_pds_detach(struct q6v5 *qproc, struct device **pds,
> +			    size_t pd_count)
> +{
> +	int i;
> +
> +	for (i = 0; i < pd_count; i++)
> +		dev_pm_domain_detach(pds[i], false);
> +}
> +
>  static int q6v5_init_reset(struct q6v5 *qproc)
>  {
>  	qproc->mss_restart = devm_reset_control_get_exclusive(qproc->dev,
> @@ -1322,10 +1412,18 @@ static int q6v5_probe(struct platform_device *pdev)
>  	}
>  	qproc->active_reg_count = ret;
>  
> +	ret = q6v5_pds_attach(&pdev->dev, qproc->proxy_pds,
> +			      desc->proxy_pd_names);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Failed to init power domains\n");
> +		goto free_rproc;
> +	}
> +	qproc->proxy_pd_count = ret;
> +
>  	qproc->has_alt_reset = desc->has_alt_reset;
>  	ret = q6v5_init_reset(qproc);
>  	if (ret)
> -		goto free_rproc;
> +		goto detach_proxy_pds;
>  
>  	qproc->version = desc->version;
>  	qproc->need_mem_protection = desc->need_mem_protection;
> @@ -1333,7 +1431,7 @@ static int q6v5_probe(struct platform_device *pdev)
>  	ret = qcom_q6v5_init(&qproc->q6v5, pdev, rproc, MPSS_CRASH_REASON_SMEM,
>  			     qcom_msa_handover);
>  	if (ret)
> -		goto free_rproc;
> +		goto detach_proxy_pds;
>  
>  	qproc->mpss_perm = BIT(QCOM_SCM_VMID_HLOS);
>  	qproc->mba_perm = BIT(QCOM_SCM_VMID_HLOS);
> @@ -1343,15 +1441,17 @@ static int q6v5_probe(struct platform_device *pdev)
>  	qproc->sysmon = qcom_add_sysmon_subdev(rproc, "modem", 0x12);
>  	if (IS_ERR(qproc->sysmon)) {
>  		ret = PTR_ERR(qproc->sysmon);
> -		goto free_rproc;
> +		goto detach_proxy_pds;
>  	}
>  
>  	ret = rproc_add(rproc);
>  	if (ret)
> -		goto free_rproc;
> +		goto detach_proxy_pds;
>  
>  	return 0;
>  
> +detach_proxy_pds:
> +	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
>  free_rproc:
>  	rproc_free(rproc);
>  
> @@ -1368,6 +1468,9 @@ static int q6v5_remove(struct platform_device *pdev)
>  	qcom_remove_glink_subdev(qproc->rproc, &qproc->glink_subdev);
>  	qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
>  	qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
> +
> +	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> +
>  	rproc_free(qproc->rproc);
>  
>  	return 0;
> @@ -1392,6 +1495,12 @@ static const struct rproc_hexagon_res sdm845_mss = {
>  			"mnoc_axi",
>  			NULL
>  	},
> +	.proxy_pd_names = (char*[]){
> +			"cx",
> +			"mx",
> +			"mss",
> +			NULL
> +	},
>  	.need_mem_protection = true,
>  	.has_alt_reset = true,
>  	.version = MSS_SDM845,
> -- 
> 2.18.0
> 

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v5 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845
  2019-01-31  0:39 ` [PATCH v5 08/10] remoteproc: q6v5-mss: Active powerdomain for SDM845 Bjorn Andersson
@ 2019-01-31  4:51   ` Bjorn Andersson
  0 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-01-31  4:51 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	Arun Kumar Neelakantam, Sibi Sankar, linux-arm-msm, devicetree,
	linux-kernel, linux-remoteproc

On Wed 30 Jan 16:39 PST 2019, Bjorn Andersson wrote:

> The SDM845 MSS needs the load_state powerdomain voted for during the
> duration of the MSS being powered on, to let the AOSS know that it may
> not perform certain power save measures. So vote for this.
> 
> Tested-by: Sibi Sankar <sibis@codeaurora.org>
> Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 

Applied

> Changes since v4:
> - None
> 
> Changes since v3:
> - None
> 
>  drivers/remoteproc/qcom_q6v5_mss.c | 31 ++++++++++++++++++++++++++++--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index c32c63e351a0..e30f5486fd20 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -133,6 +133,7 @@ struct rproc_hexagon_res {
>  	char **proxy_clk_names;
>  	char **reset_clk_names;
>  	char **active_clk_names;
> +	char **active_pd_names;
>  	char **proxy_pd_names;
>  	int version;
>  	bool need_mem_protection;
> @@ -159,10 +160,12 @@ struct q6v5 {
>  	struct clk *active_clks[8];
>  	struct clk *reset_clks[4];
>  	struct clk *proxy_clks[4];
> +	struct device *active_pds[1];
>  	struct device *proxy_pds[3];
>  	int active_clk_count;
>  	int reset_clk_count;
>  	int proxy_clk_count;
> +	int active_pd_count;
>  	int proxy_pd_count;
>  
>  	struct reg_info active_regs[1];
> @@ -730,10 +733,16 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>  
>  	qcom_q6v5_prepare(&qproc->q6v5);
>  
> +	ret = q6v5_pds_enable(qproc, qproc->active_pds, qproc->active_pd_count);
> +	if (ret < 0) {
> +		dev_err(qproc->dev, "failed to enable active power domains\n");
> +		goto disable_irqs;
> +	}
> +
>  	ret = q6v5_pds_enable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
>  	if (ret < 0) {
>  		dev_err(qproc->dev, "failed to enable proxy power domains\n");
> -		goto disable_irqs;
> +		goto disable_active_pds;
>  	}
>  
>  	ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
> @@ -839,6 +848,8 @@ static int q6v5_mba_load(struct q6v5 *qproc)
>  			       qproc->proxy_reg_count);
>  disable_proxy_pds:
>  	q6v5_pds_disable(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> +disable_active_pds:
> +	q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
>  disable_irqs:
>  	qcom_q6v5_unprepare(&qproc->q6v5);
>  
> @@ -878,6 +889,7 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
>  			 qproc->active_clk_count);
>  	q6v5_regulator_disable(qproc, qproc->active_regs,
>  			       qproc->active_reg_count);
> +	q6v5_pds_disable(qproc, qproc->active_pds, qproc->active_pd_count);
>  
>  	/* In case of failure or coredump scenario where reclaiming MBA memory
>  	 * could not happen reclaim it here.
> @@ -1412,11 +1424,19 @@ static int q6v5_probe(struct platform_device *pdev)
>  	}
>  	qproc->active_reg_count = ret;
>  
> +	ret = q6v5_pds_attach(&pdev->dev, qproc->active_pds,
> +			      desc->active_pd_names);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "Failed to attach active power domains\n");
> +		goto free_rproc;
> +	}
> +	qproc->active_pd_count = ret;
> +
>  	ret = q6v5_pds_attach(&pdev->dev, qproc->proxy_pds,
>  			      desc->proxy_pd_names);
>  	if (ret < 0) {
>  		dev_err(&pdev->dev, "Failed to init power domains\n");
> -		goto free_rproc;
> +		goto detach_active_pds;
>  	}
>  	qproc->proxy_pd_count = ret;
>  
> @@ -1452,6 +1472,8 @@ static int q6v5_probe(struct platform_device *pdev)
>  
>  detach_proxy_pds:
>  	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
> +detach_active_pds:
> +	q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
>  free_rproc:
>  	rproc_free(rproc);
>  
> @@ -1469,6 +1491,7 @@ static int q6v5_remove(struct platform_device *pdev)
>  	qcom_remove_smd_subdev(qproc->rproc, &qproc->smd_subdev);
>  	qcom_remove_ssr_subdev(qproc->rproc, &qproc->ssr_subdev);
>  
> +	q6v5_pds_detach(qproc, qproc->active_pds, qproc->active_pd_count);
>  	q6v5_pds_detach(qproc, qproc->proxy_pds, qproc->proxy_pd_count);
>  
>  	rproc_free(qproc->rproc);
> @@ -1495,6 +1518,10 @@ static const struct rproc_hexagon_res sdm845_mss = {
>  			"mnoc_axi",
>  			NULL
>  	},
> +	.active_pd_names = (char*[]){
> +			"load_state",
> +			NULL
> +	},
>  	.proxy_pd_names = (char*[]){
>  			"cx",
>  			"mx",
> -- 
> 2.18.0
> 

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v5 01/10] arm64: dts: qcom: sdm845: Update reserved memory map
      [irrelevant] ` <20190131003933.11436-2-bjorn.andersson@linaro.org>
@ 2019-01-31 16:58   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-31 16:58 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	Ohad Ben-Cohen, Arun Kumar Neelakantam, linux-arm-msm,
	devicetree, linux-kernel, linux-remoteproc

Hey Bjorn,

On 2019-01-31 06:09, Bjorn Andersson wrote:
> Update existing and add missing regions to the reserved memory map, as
> described in version 10.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v4:
> - Labeled aop_mem, aop_cmd_db_mem and made tz_mem span the last TZ
> related segment
> 
> Changes since v3:
> - Added hyp and xbl memory nodes.
> - Labeled all PIL nodes
> 
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 72 +++++++++++++++++++++++++---
>  1 file changed, 66 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 33f5f4ba6160..45b1616392aa 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -73,12 +73,22 @@
>  		#size-cells = <2>;
>  		ranges;
> 
> -		memory@85fc0000 {
> +		hyp_mem: memory@85700000 {
> +			reg = <0x0 0x85700000 0 0x600000>;
> +			no-map;
> +		};
> +
> +		xbl_mem: memory@85e00000 {
> +			reg = <0x0 0x85e00000 0 0x100000>;
> +			no-map;
> +		};
> +
> +		aop_mem: memory@85fc0000 {
>  			reg = <0 0x85fc0000 0 0x20000>;
>  			no-map;
>  		};
> 
> -		memory@85fe0000 {
> +		aop_cmd_db_mem: memory@85fe0000 {
>  			compatible = "qcom,cmd-db";
>  			reg = <0x0 0x85fe0000 0x0 0x20000>;
>  			no-map;
> @@ -89,13 +99,43 @@
>  			no-map;
>  		};
> 
> -		memory@86200000 {
> -			reg = <0 0x86200000 0 0x2d00000>;
> +		tz_mem: memory@86200000 {
> +			reg = <0 0x86200000 0 0x3c00000>;

should be 0x2d00000 instead of 0x3c00000
tz_mem ends at 0x88F00000 :-)

nit: Also for hyp_mem and xbl_mem you could
use 0 instead of 0x0

Reviewed-by: Sibi Sankar <sibis@codeaurora.org>

> +			no-map;
> +		};
> +
> +		qseecom_mem: memory@8ab00000 {
> +			reg = <0 0x8ab00000 0 0x1400000>;
> +			no-map;
> +		};
> +
> +		camera_mem: memory@8bf00000 {
> +			reg = <0 0x8bf00000 0 0x500000>;
> +			no-map;
> +		};
> +
> +		ipa_fw_mem: memory@8c400000 {
> +			reg = <0 0x8c400000 0 0x10000>;
> +			no-map;
> +		};
> +
> +		ipa_gsi_mem: memory@8c410000 {
> +			reg = <0 0x8c410000 0 0x5000>;
>  			no-map;
>  		};
> 
> -		wlan_msa_mem: memory@96700000 {
> -			reg = <0 0x96700000 0 0x100000>;
> +		gpu_mem: memory@8c415000 {
> +			reg = <0 0x8c415000 0 0x2000>;
> +			no-map;
> +		};
> +
> +		adsp_mem: memory@8c500000 {
> +			reg = <0 0x8c500000 0 0x1a00000>;
> +			no-map;
> +		};
> +
> +		wlan_msa_mem: memory@8df00000 {
> +			reg = <0 0x8df00000 0 0x100000>;
>  			no-map;
>  		};
> 
> @@ -104,10 +144,30 @@
>  			no-map;
>  		};
> 
> +		venus_mem: memory@95800000 {
> +			reg = <0 0x95800000 0 0x500000>;
> +			no-map;
> +		};
> +
> +		cdsp_mem: memory@95d00000 {
> +			reg = <0 0x95d00000 0 0x800000>;
> +			no-map;
> +		};
> +
>  		mba_region: memory@96500000 {
>  			reg = <0 0x96500000 0 0x200000>;
>  			no-map;
>  		};
> +
> +		slpi_mem: memory@96700000 {
> +			reg = <0 0x96700000 0 0x1400000>;
> +			no-map;
> +		};
> +
> +		spss_mem: memory@97b00000 {
> +			reg = <0 0x97b00000 0 0x100000>;
> +			no-map;
> +		};
>  	};
> 
>  	cpus {

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 13%]

* Re: [PATCH v5 02/10] arm64: dts: qcom: sdm845: Define rmtfs memory
      [irrelevant] ` <20190131003933.11436-3-bjorn.andersson@linaro.org>
@ 2019-01-31 17:09   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-01-31 17:09 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	Ohad Ben-Cohen, Arun Kumar Neelakantam, linux-arm-msm,
	devicetree, linux-kernel, linux-remoteproc

On 2019-01-31 06:09, Bjorn Andersson wrote:
> Define the rmtfs memory node. As the memory region specified in version
> 10 of the memory map is only 1MB a chunk of unallocated memory is
> chosen.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v4:
> - Moved rmtfs_mem, to not collide with xbl_mem
> 
> Changes since v3:
> - Labeled the node
> 
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 45b1616392aa..d19486ba1e5e 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -104,6 +104,15 @@
>  			no-map;
>  		};
> 
> +		rmtfs_mem: memory@88f0000 {

Hey Bjorn,
we are missing a trailing zero here ^^
rmtfs_mem: memory@88f00000

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>

> +			compatible = "qcom,rmtfs-mem";
> +			reg = <0 0x88f00000 0 0x200000>;
> +			no-map;
> +
> +			qcom,client-id = <1>;
> +			qcom,vmid = <15>;
> +		};
> +
>  		qseecom_mem: memory@8ab00000 {
>  			reg = <0 0x8ab00000 0 0x1400000>;
>  			no-map;

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 15%]

* Re: [PATCH v5 03/10] arm64: dts: sdm845: Introduce ADSP and CDSP PAS nodes
      [irrelevant] ` <20190131003933.11436-4-bjorn.andersson@linaro.org>
@ 2019-02-01  5:49   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-02-01  5:49 UTC (permalink / raw)
  To: Bjorn Andersson, Andy Gross, David Brown
  Cc: Rob Herring, Mark Rutland, Ohad Ben-Cohen,
	Arun Kumar Neelakantam, linux-arm-msm, devicetree, linux-kernel,
	linux-remoteproc

Hey Bjorn,

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>

On 01/31/2019 06:09 AM, Bjorn Andersson wrote:
> Add the Audio DSP (ADSP) and Compute DSP (CDSP) nodes for TrustZone
> based remoteproc, supporting booting these cores on e.g. the MTP, and
> enable the same for the MTP.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v4:
> - None
> 
> Changes since v3:
> - Make xo reference the actual CXO clock
> 
>   arch/arm64/boot/dts/qcom/sdm845-mtp.dts |  8 ++++
>   arch/arm64/boot/dts/qcom/sdm845.dtsi    | 58 +++++++++++++++++++++++++
>   2 files changed, 66 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> index af8c6a2445a2..02b8357c8ce8 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
> @@ -48,6 +48,10 @@
>   	};
>   };
>   
> +&adsp_pas {
> +	status = "okay";
> +};
> +
>   &apps_rsc {
>   	pm8998-rpmh-regulators {
>   		compatible = "qcom,pm8998-rpmh-regulators";
> @@ -344,6 +348,10 @@
>   	};
>   };
>   
> +&cdsp_pas {
> +	status = "okay";
> +};
> +
>   &gcc {
>   	protected-clocks = <GCC_QSPI_CORE_CLK>,
>   			   <GCC_QSPI_CORE_CLK_SRC>,
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index d19486ba1e5e..07d9cd6fba7d 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -325,6 +325,64 @@
>   		};
>   	};
>   
> +	adsp_pas: remoteproc-adsp {
> +		compatible = "qcom,sdm845-adsp-pas";
> +
> +		interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_EDGE_RISING>,
> +				      <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> +				      <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> +				      <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> +				      <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
> +		interrupt-names = "wdog", "fatal", "ready",
> +				  "handover", "stop-ack";
> +
> +		clocks = <&rpmhcc RPMH_CXO_CLK>;
> +		clock-names = "xo";
> +
> +		memory-region = <&adsp_mem>;
> +
> +		qcom,smem-states = <&adsp_smp2p_out 0>;
> +		qcom,smem-state-names = "stop";
> +
> +		status = "disabled";
> +
> +		glink-edge {
> +			interrupts = <GIC_SPI 156 IRQ_TYPE_EDGE_RISING>;
> +			label = "lpass";
> +			qcom,remote-pid = <2>;
> +			mboxes = <&apss_shared 8>;
> +		};
> +	};
> +
> +	cdsp_pas: remoteproc-cdsp {
> +		compatible = "qcom,sdm845-cdsp-pas";
> +
> +		interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
> +				      <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> +				      <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> +				      <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> +				      <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
> +		interrupt-names = "wdog", "fatal", "ready",
> +				  "handover", "stop-ack";
> +
> +		clocks = <&rpmhcc RPMH_CXO_CLK>;
> +		clock-names = "xo";
> +
> +		memory-region = <&cdsp_mem>;
> +
> +		qcom,smem-states = <&cdsp_smp2p_out 0>;
> +		qcom,smem-state-names = "stop";
> +
> +		status = "disabled";
> +
> +		glink-edge {
> +			interrupts = <GIC_SPI 574 IRQ_TYPE_EDGE_RISING>;
> +			label = "turing";
> +			qcom,remote-pid = <5>;
> +			mboxes = <&apss_shared 4>;
> +		};
> +	};
> +
>   	tcsr_mutex: hwlock {
>   		compatible = "qcom,tcsr-mutex";
>   		syscon = <&tcsr_mutex_regs 0 0x1000>;
> 

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[relevance 15%]

* Re: [PATCH v5 06/10] soc: qcom: Add AOSS QMP genpd provider
      [irrelevant] ` <20190131003933.11436-7-bjorn.andersson@linaro.org>
@ 2019-02-01  7:15   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-02-01  7:15 UTC (permalink / raw)
  To: Bjorn Andersson, Andy Gross, David Brown
  Cc: Rob Herring, Mark Rutland, Ohad Ben-Cohen,
	Arun Kumar Neelakantam, linux-arm-msm, devicetree, linux-kernel,
	linux-remoteproc

Hey Bjorn,

On 01/31/2019 06:09 AM, Bjorn Andersson wrote:
> The AOSS QMP genpd provider implements control over power-related
> resources related to low-power state associated with the remoteprocs in
> the system as well as control over a set of clocks related to debug
> hardware in the SoC.
> 
> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v4:
> - None
> 
> Changes since v3:
> - None
> 
>   drivers/soc/qcom/Kconfig       |   9 +++
>   drivers/soc/qcom/Makefile      |   1 +
>   drivers/soc/qcom/aoss-qmp-pd.c | 138 +++++++++++++++++++++++++++++++++
>   3 files changed, 148 insertions(+)
>   create mode 100644 drivers/soc/qcom/aoss-qmp-pd.c
> 
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 28ab19bf8c98..893b56b70957 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -12,6 +12,15 @@ config QCOM_AOSS_QMP
>   	  micro-controller in the AOSS, using QMP, to control certain resource
>   	  that are not exposed through RPMh.
>   
> +config QCOM_AOSS_QMP_PD
> +	tristate "Qualcomm AOSS Messaging Power Domain driver"
> +	depends on QCOM_AOSS_QMP
> +	select PM_GENERIC_DOMAINS
> +	help
> +	  This driver provides the means of controlling the AOSS's handling of
> +	  low-power state for resources related to the remoteproc subsystems as
> +	  well as controlling the debug clocks.
> +
>   config QCOM_COMMAND_DB
>   	bool "Qualcomm Command DB"
>   	depends on ARCH_QCOM || COMPILE_TEST
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index 2c04d27fbf9e..16913e73fddf 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -1,6 +1,7 @@
>   # SPDX-License-Identifier: GPL-2.0
>   CFLAGS_rpmh-rsc.o := -I$(src)
>   obj-$(CONFIG_QCOM_AOSS_QMP) +=	aoss-qmp.o
> +obj-$(CONFIG_QCOM_AOSS_QMP_PD) += aoss-qmp-pd.o
>   obj-$(CONFIG_QCOM_GENI_SE) +=	qcom-geni-se.o
>   obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
>   obj-$(CONFIG_QCOM_GLINK_SSR) +=	glink_ssr.o
> diff --git a/drivers/soc/qcom/aoss-qmp-pd.c b/drivers/soc/qcom/aoss-qmp-pd.c
> new file mode 100644
> index 000000000000..82dd569a2bc9
> --- /dev/null
> +++ b/drivers/soc/qcom/aoss-qmp-pd.c
> @@ -0,0 +1,138 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, Linaro Ltd
> + */
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/soc/qcom/aoss-qmp.h>
> +#include <dt-bindings/power/qcom-aoss-qmp.h>
> +
> +/* Requests are expected to be 96 bytes long */
> +#define AOSS_QMP_PD_MSG_LEN	96
> +
> +struct qmp_pd {
> +	struct qmp *qmp;
> +
> +	struct generic_pm_domain pd;
> +
> +	const char *name;
> +};
> +
> +#define to_qmp_pd_resource(res) container_of(res, struct qmp_pd, pd)
> +
> +struct qmp_pd_resource {
> +	const char *name;
> +	int (*on)(struct generic_pm_domain *domain);
> +	int (*off)(struct generic_pm_domain *domain);
> +};
> +
> +static int qmp_pd_clock_toggle(struct qmp_pd *res, bool enable)
> +{
> +	char buf[AOSS_QMP_PD_MSG_LEN];
> +
> +	snprintf(buf, sizeof(buf), "{class: clock, res: %s, val: %d}",
> +		 res->name, !!enable);
> +	return qmp_send(res->qmp, buf, sizeof(buf));
> +}
> +
> +static int qmp_pd_clock_on(struct generic_pm_domain *domain)
> +{
> +	return qmp_pd_clock_toggle(to_qmp_pd_resource(domain), true);
> +}
> +
> +static int qmp_pd_clock_off(struct generic_pm_domain *domain)
> +{
> +	return qmp_pd_clock_toggle(to_qmp_pd_resource(domain), false);
> +}
> +
> +static int qmp_pd_image_toggle(struct qmp_pd *res, bool enable)
> +{
> +	char buf[AOSS_QMP_PD_MSG_LEN];
> +
> +	snprintf(buf, sizeof(buf),
> +		 "{class: image, res: load_state, name: %s, val: %s}",
> +		 res->name, enable ? "on" : "off");
> +	return qmp_send(res->qmp, buf, sizeof(buf));
> +}
> +
> +static int qmp_pd_image_on(struct generic_pm_domain *domain)
> +{
> +	return qmp_pd_image_toggle(to_qmp_pd_resource(domain), true);
> +}
> +
> +static int qmp_pd_image_off(struct generic_pm_domain *domain)
> +{
> +	return qmp_pd_image_toggle(to_qmp_pd_resource(domain), false);
> +}
> +
> +static const struct qmp_pd_resource sdm845_resources[] = {
> +	[AOSS_QMP_QDSS_CLK] = { "qdss", qmp_pd_clock_on, qmp_pd_clock_off },
> +	[AOSS_QMP_LS_CDSP] = { "cdsp", qmp_pd_image_on, qmp_pd_image_off },
> +	[AOSS_QMP_LS_LPASS] = { "adsp", qmp_pd_image_on, qmp_pd_image_off },
> +	[AOSS_QMP_LS_MODEM] = { "modem", qmp_pd_image_on, qmp_pd_image_off },
> +	[AOSS_QMP_LS_SLPI] = { "slpi", qmp_pd_image_on, qmp_pd_image_off },
> +	[AOSS_QMP_LS_SPSS] = { "spss", qmp_pd_image_on, qmp_pd_image_off },
> +	[AOSS_QMP_LS_VENUS] = { "venus", qmp_pd_image_on, qmp_pd_image_off },
> +};
> +
> +static int qmp_pd_probe(struct platform_device *pdev)
> +{
> +	struct genpd_onecell_data *data;
> +	struct device *parent = pdev->dev.parent;
> +	struct qmp_pd *res;
> +	struct qmp *qmp;
> +	size_t num = ARRAY_SIZE(sdm845_resources);
> +	int i;
> +
> +	qmp = dev_get_drvdata(pdev->dev.parent);
> +	if (!qmp)
> +		return -EINVAL;
> +
> +	res = devm_kcalloc(&pdev->dev, num, sizeof(*res), GFP_KERNEL);
> +	if (!res)
> +		return -ENOMEM;
> +
> +	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	data->domains = devm_kcalloc(&pdev->dev, num, sizeof(*data->domains),
> +				     GFP_KERNEL);

shouldn't we error out here as well?
if (!data->domains)
         return -ENOMEM;

> +
> +	for (i = 0; i < num; i++) {
> +		pm_genpd_init(&res[i].pd, NULL, true);

shouldn't we populate the pd name before the call to
pm_genpd_init?


Apart from the above nits
Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>

> +		res[i].qmp = qmp;
> +		res[i].name = sdm845_resources[i].name;
> +
> +		res[i].pd.name = sdm845_resources[i].name;
> +		res[i].pd.power_on = sdm845_resources[i].on;
> +		res[i].pd.power_off = sdm845_resources[i].off;
> +
> +		data->domains[data->num_domains++] = &res[i].pd;
> +	}
> +
> +	return of_genpd_add_provider_onecell(parent->of_node, data);
> +}
> +
> +static int qmp_pd_remove(struct platform_device *pdev)
> +{
> +	struct device *parent = pdev->dev.parent;
> +
> +	of_genpd_del_provider(parent->of_node);
> +
> +	return 0;
> +}
> +
> +static struct platform_driver qmp_pd_driver = {
> +	.driver = {
> +		.name		= "aoss_qmp_pd",
> +	},
> +	.probe = qmp_pd_probe,
> +	.remove = qmp_pd_remove,
> +};
> +module_platform_driver(qmp_pd_driver);
> +
> +MODULE_ALIAS("platform:aoss_qmp_pd");
> +MODULE_DESCRIPTION("Qualcomm AOSS QMP load-state driver");
> +MODULE_LICENSE("GPL v2");
> 

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[relevance 15%]

* Re: [PATCH v5 09/10] arm64: dts: qcom: Add AOSS QMP node
      [irrelevant] ` <20190131003933.11436-10-bjorn.andersson@linaro.org>
@ 2019-02-01  7:17   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-02-01  7:17 UTC (permalink / raw)
  To: Bjorn Andersson, Andy Gross, David Brown
  Cc: Rob Herring, Mark Rutland, Ohad Ben-Cohen,
	Arun Kumar Neelakantam, linux-arm-msm, devicetree, linux-kernel,
	linux-remoteproc

Hey Bjorn,

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>


On 01/31/2019 06:09 AM, Bjorn Andersson wrote:
> The AOSS QMP provides a number of power domains, used for QDSS and
> PIL, add the node for this.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v4:
> - None
> 
> Changes since v3:
> - None
> 
>   arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++++++++++
>   1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 07d9cd6fba7d..dc43fee8bb90 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -14,6 +14,7 @@
>   #include <dt-bindings/interconnect/qcom,sdm845.h>
>   #include <dt-bindings/interrupt-controller/arm-gic.h>
>   #include <dt-bindings/phy/phy-qcom-qusb2.h>
> +#include <dt-bindings/power/qcom-aoss-qmp.h>
>   #include <dt-bindings/power/qcom-rpmpd.h>
>   #include <dt-bindings/reset/qcom,sdm845-aoss.h>
>   #include <dt-bindings/reset/qcom,sdm845-pdc.h>
> @@ -2076,6 +2077,15 @@
>   			#reset-cells = <1>;
>   		};
>   
> +		aoss_qmp: qmp@c300000 {
> +			compatible = "qcom,sdm845-aoss-qmp";
> +			reg = <0 0x0c300000 0 0x100000>;
> +			interrupts = <GIC_SPI 389 IRQ_TYPE_EDGE_RISING>;
> +			mboxes = <&apss_shared 0>;
> +
> +			#power-domain-cells = <1>;
> +		};
> +
>   		spmi_bus: spmi@c440000 {
>   			compatible = "qcom,spmi-pmic-arb";
>   			reg = <0 0x0c440000 0 0x1100>,
> 

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[relevance 15%]

* Re: [PATCH v2] arm64: dts: qcom: sdm845: Add clocks and iommus to WCN3990 WLAN node
      [irrelevant] <20190131051438.12867-1-bjorn.andersson@linaro.org>
@ 2019-02-01  8:57 ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-02-01  8:57 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Douglas Anderson, Rob Herring,
	Mark Rutland, linux-arm-msm, devicetree, linux-kernel,
	linux-arm-msm-owner

On 2019-01-31 10:44, Bjorn Andersson wrote:
> From: Douglas Anderson <dianders@chromium.org>
> 
> When commit be7019103469 ("dts: arm64/sdm845: Add WCN3990 WLAN module
> device node") was posted upstream no clocks were specified.  However,
> when the pack was picked into the Chrome OS kernel tree (allegedly
> directly from the mailing list post) it had clock properties.
> 
> I presume that the clock should be there, so let's add it.

Tested-by: Sibi Sankar <sibis@codeaurora.org>

> 
> Fixes: be7019103469 ("dts: arm64/sdm845: Add WCN3990 WLAN module device 
> node")
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> [bjorn: Add also the required iommus property]
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Hijacking Doug's fixup patch to also add the missing iommus property. 
> Without
> this the MTP reboots once the ath10k is trying to exercise the 
> copyengine.
> 
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index cba09899282e..58f034664336 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -2422,6 +2422,8 @@
>  			reg = <0 0x18800000 0 0x800000>;
>  			reg-names = "membase";
>  			memory-region = <&wlan_msa_mem>;
> +			clock-names = "cxo_ref_clk_pin";
> +			clocks = <&rpmhcc RPMH_RF_CLK2>;
>  			interrupts =
>  				<GIC_SPI 414 IRQ_TYPE_LEVEL_HIGH>,
>  				<GIC_SPI 415 IRQ_TYPE_LEVEL_HIGH>,
> @@ -2435,6 +2437,7 @@
>  				<GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH>,
>  				<GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
>  				<GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>;
> +			iommus = <&apps_smmu 0x0040 0x1>;
>  		};
>  	};

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 13%]

* [PATCH v6 1/8] arm64: dts: qcom: sdm845: Update reserved memory map
      [irrelevant] <20190206051335.23799-1-bjorn.andersson@linaro.org>
@ 2019-02-06  5:13 ` Bjorn Andersson
  2019-02-06  5:13 ` [PATCH v6 2/8] arm64: dts: qcom: sdm845: Define rmtfs memory Bjorn Andersson
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-02-06  5:13 UTC (permalink / raw)
  To: Andy Gross
  Cc: David Brown, Rob Herring, Mark Rutland, Arun Kumar Neelakantam,
	Sibi Sankar, Doug Anderson, linux-arm-msm, devicetree,
	linux-kernel

Update existing and add missing regions to the reserved memory map, as
described in version 10.

Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v5:
- Replaced a few 0x0 with 0
- Corrected size of tz_mem

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 74 +++++++++++++++++++++++++---
 1 file changed, 67 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index ade2f385507c..16a060063882 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -72,29 +72,69 @@
 		#size-cells = <2>;
 		ranges;
 
-		memory@85fc0000 {
+		hyp_mem: memory@85700000 {
+			reg = <0 0x85700000 0 0x600000>;
+			no-map;
+		};
+
+		xbl_mem: memory@85e00000 {
+			reg = <0 0x85e00000 0 0x100000>;
+			no-map;
+		};
+
+		aop_mem: memory@85fc0000 {
 			reg = <0 0x85fc0000 0 0x20000>;
 			no-map;
 		};
 
-		memory@85fe0000 {
+		aop_cmd_db_mem: memory@85fe0000 {
 			compatible = "qcom,cmd-db";
-			reg = <0x0 0x85fe0000 0x0 0x20000>;
+			reg = <0x0 0x85fe0000 0 0x20000>;
 			no-map;
 		};
 
 		smem_mem: memory@86000000 {
-			reg = <0x0 0x86000000 0x0 0x200000>;
+			reg = <0x0 0x86000000 0 0x200000>;
 			no-map;
 		};
 
-		memory@86200000 {
+		tz_mem: memory@86200000 {
 			reg = <0 0x86200000 0 0x2d00000>;
 			no-map;
 		};
 
-		wlan_msa_mem: memory@96700000 {
-			reg = <0 0x96700000 0 0x100000>;
+		qseecom_mem: memory@8ab00000 {
+			reg = <0 0x8ab00000 0 0x1400000>;
+			no-map;
+		};
+
+		camera_mem: memory@8bf00000 {
+			reg = <0 0x8bf00000 0 0x500000>;
+			no-map;
+		};
+
+		ipa_fw_mem: memory@8c400000 {
+			reg = <0 0x8c400000 0 0x10000>;
+			no-map;
+		};
+
+		ipa_gsi_mem: memory@8c410000 {
+			reg = <0 0x8c410000 0 0x5000>;
+			no-map;
+		};
+
+		gpu_mem: memory@8c415000 {
+			reg = <0 0x8c415000 0 0x2000>;
+			no-map;
+		};
+
+		adsp_mem: memory@8c500000 {
+			reg = <0 0x8c500000 0 0x1a00000>;
+			no-map;
+		};
+
+		wlan_msa_mem: memory@8df00000 {
+			reg = <0 0x8df00000 0 0x100000>;
 			no-map;
 		};
 
@@ -103,10 +143,30 @@
 			no-map;
 		};
 
+		venus_mem: memory@95800000 {
+			reg = <0 0x95800000 0 0x500000>;
+			no-map;
+		};
+
+		cdsp_mem: memory@95d00000 {
+			reg = <0 0x95d00000 0 0x800000>;
+			no-map;
+		};
+
 		mba_region: memory@96500000 {
 			reg = <0 0x96500000 0 0x200000>;
 			no-map;
 		};
+
+		slpi_mem: memory@96700000 {
+			reg = <0 0x96700000 0 0x1400000>;
+			no-map;
+		};
+
+		spss_mem: memory@97b00000 {
+			reg = <0 0x97b00000 0 0x100000>;
+			no-map;
+		};
 	};
 
 	cpus {
-- 
2.18.0


^ permalink raw reply	[relevance 6%]

* [PATCH v6 3/8] arm64: dts: sdm845: Introduce ADSP and CDSP PAS nodes
      [irrelevant] <20190206051335.23799-1-bjorn.andersson@linaro.org>
  2019-02-06  5:13 ` [PATCH v6 1/8] arm64: dts: qcom: sdm845: Update reserved memory map Bjorn Andersson
  2019-02-06  5:13 ` [PATCH v6 2/8] arm64: dts: qcom: sdm845: Define rmtfs memory Bjorn Andersson
@ 2019-02-06  5:13 ` Bjorn Andersson
  2019-02-06  5:13 ` [PATCH v6 6/8] soc: qcom: Add AOSS QMP genpd provider Bjorn Andersson
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-02-06  5:13 UTC (permalink / raw)
  To: Andy Gross
  Cc: David Brown, Rob Herring, Mark Rutland, Arun Kumar Neelakantam,
	Sibi Sankar, Doug Anderson, linux-arm-msm, devicetree,
	linux-kernel

Add the Audio DSP (ADSP) and Compute DSP (CDSP) nodes for TrustZone
based remoteproc, supporting booting these cores on e.g. the MTP, and
enable the same for the MTP.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v5:
- None

 arch/arm64/boot/dts/qcom/sdm845-mtp.dts |  8 ++++
 arch/arm64/boot/dts/qcom/sdm845.dtsi    | 58 +++++++++++++++++++++++++
 2 files changed, 66 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 89071463a84a..2e78638eb73b 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -48,6 +48,10 @@
 	};
 };
 
+&adsp_pas {
+	status = "okay";
+};
+
 &apps_rsc {
 	pm8998-rpmh-regulators {
 		compatible = "qcom,pm8998-rpmh-regulators";
@@ -344,6 +348,10 @@
 	};
 };
 
+&cdsp_pas {
+	status = "okay";
+};
+
 &gcc {
 	protected-clocks = <GCC_QSPI_CORE_CLK>,
 			   <GCC_QSPI_CORE_CLK_SRC>,
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index a33d27b3a389..12efbdb1fa2e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -324,6 +324,64 @@
 		};
 	};
 
+	adsp_pas: remoteproc-adsp {
+		compatible = "qcom,sdm845-adsp-pas";
+
+		interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_EDGE_RISING>,
+				      <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				      <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				      <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				      <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+		interrupt-names = "wdog", "fatal", "ready",
+				  "handover", "stop-ack";
+
+		clocks = <&rpmhcc RPMH_CXO_CLK>;
+		clock-names = "xo";
+
+		memory-region = <&adsp_mem>;
+
+		qcom,smem-states = <&adsp_smp2p_out 0>;
+		qcom,smem-state-names = "stop";
+
+		status = "disabled";
+
+		glink-edge {
+			interrupts = <GIC_SPI 156 IRQ_TYPE_EDGE_RISING>;
+			label = "lpass";
+			qcom,remote-pid = <2>;
+			mboxes = <&apss_shared 8>;
+		};
+	};
+
+	cdsp_pas: remoteproc-cdsp {
+		compatible = "qcom,sdm845-cdsp-pas";
+
+		interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_EDGE_RISING>,
+				      <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				      <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				      <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				      <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+		interrupt-names = "wdog", "fatal", "ready",
+				  "handover", "stop-ack";
+
+		clocks = <&rpmhcc RPMH_CXO_CLK>;
+		clock-names = "xo";
+
+		memory-region = <&cdsp_mem>;
+
+		qcom,smem-states = <&cdsp_smp2p_out 0>;
+		qcom,smem-state-names = "stop";
+
+		status = "disabled";
+
+		glink-edge {
+			interrupts = <GIC_SPI 574 IRQ_TYPE_EDGE_RISING>;
+			label = "turing";
+			qcom,remote-pid = <5>;
+			mboxes = <&apss_shared 4>;
+		};
+	};
+
 	tcsr_mutex: hwlock {
 		compatible = "qcom,tcsr-mutex";
 		syscon = <&tcsr_mutex_regs 0 0x1000>;
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* [PATCH v6 2/8] arm64: dts: qcom: sdm845: Define rmtfs memory
      [irrelevant] <20190206051335.23799-1-bjorn.andersson@linaro.org>
  2019-02-06  5:13 ` [PATCH v6 1/8] arm64: dts: qcom: sdm845: Update reserved memory map Bjorn Andersson
@ 2019-02-06  5:13 ` Bjorn Andersson
  2019-02-06  5:13 ` [PATCH v6 3/8] arm64: dts: sdm845: Introduce ADSP and CDSP PAS nodes Bjorn Andersson
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-02-06  5:13 UTC (permalink / raw)
  To: Andy Gross
  Cc: David Brown, Rob Herring, Mark Rutland, Arun Kumar Neelakantam,
	Sibi Sankar, Doug Anderson, linux-arm-msm, devicetree,
	linux-kernel

Define the rmtfs memory node. As the memory region specified in version
10 of the memory map is only 1MB a chunk of unallocated memory is
chosen.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v5:
- Corrected unit address

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 16a060063882..a33d27b3a389 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -103,6 +103,15 @@
 			no-map;
 		};
 
+		rmtfs_mem: memory@88f00000 {
+			compatible = "qcom,rmtfs-mem";
+			reg = <0 0x88f00000 0 0x200000>;
+			no-map;
+
+			qcom,client-id = <1>;
+			qcom,vmid = <15>;
+		};
+
 		qseecom_mem: memory@8ab00000 {
 			reg = <0 0x8ab00000 0 0x1400000>;
 			no-map;
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* [PATCH v6 6/8] soc: qcom: Add AOSS QMP genpd provider
      [irrelevant] <20190206051335.23799-1-bjorn.andersson@linaro.org>
                   ` (2 preceding siblings ...)
  2019-02-06  5:13 ` [PATCH v6 3/8] arm64: dts: sdm845: Introduce ADSP and CDSP PAS nodes Bjorn Andersson
@ 2019-02-06  5:13 ` Bjorn Andersson
  2019-02-06  5:13 ` [PATCH v6 7/8] arm64: dts: qcom: Add AOSS QMP node Bjorn Andersson
  2019-02-06  5:13 ` [PATCH v6 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
  5 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-02-06  5:13 UTC (permalink / raw)
  To: Andy Gross
  Cc: David Brown, Rob Herring, Mark Rutland, Arun Kumar Neelakantam,
	Sibi Sankar, Doug Anderson, linux-arm-msm, devicetree,
	linux-kernel

The AOSS QMP genpd provider implements control over power-related
resources related to low-power state associated with the remoteprocs in
the system as well as control over a set of clocks related to debug
hardware in the SoC.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v5:
- Clear outgoing buffer, to avoid sending unitialized stack content to AOP
- Fix domain initialization
- Clean up domains on failure and remove

 drivers/soc/qcom/Kconfig       |   9 ++
 drivers/soc/qcom/Makefile      |   1 +
 drivers/soc/qcom/aoss-qmp-pd.c | 158 +++++++++++++++++++++++++++++++++
 3 files changed, 168 insertions(+)
 create mode 100644 drivers/soc/qcom/aoss-qmp-pd.c

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 28ab19bf8c98..893b56b70957 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -12,6 +12,15 @@ config QCOM_AOSS_QMP
 	  micro-controller in the AOSS, using QMP, to control certain resource
 	  that are not exposed through RPMh.
 
+config QCOM_AOSS_QMP_PD
+	tristate "Qualcomm AOSS Messaging Power Domain driver"
+	depends on QCOM_AOSS_QMP
+	select PM_GENERIC_DOMAINS
+	help
+	  This driver provides the means of controlling the AOSS's handling of
+	  low-power state for resources related to the remoteproc subsystems as
+	  well as controlling the debug clocks.
+
 config QCOM_COMMAND_DB
 	bool "Qualcomm Command DB"
 	depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 2c04d27fbf9e..16913e73fddf 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 CFLAGS_rpmh-rsc.o := -I$(src)
 obj-$(CONFIG_QCOM_AOSS_QMP) +=	aoss-qmp.o
+obj-$(CONFIG_QCOM_AOSS_QMP_PD) += aoss-qmp-pd.o
 obj-$(CONFIG_QCOM_GENI_SE) +=	qcom-geni-se.o
 obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
 obj-$(CONFIG_QCOM_GLINK_SSR) +=	glink_ssr.o
diff --git a/drivers/soc/qcom/aoss-qmp-pd.c b/drivers/soc/qcom/aoss-qmp-pd.c
new file mode 100644
index 000000000000..a375abcbe9c7
--- /dev/null
+++ b/drivers/soc/qcom/aoss-qmp-pd.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, Linaro Ltd
+ */
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/soc/qcom/aoss-qmp.h>
+#include <dt-bindings/power/qcom-aoss-qmp.h>
+
+/* Requests are expected to be 96 bytes long */
+#define AOSS_QMP_PD_MSG_LEN	96
+
+struct qmp_pd {
+	struct qmp *qmp;
+	struct generic_pm_domain pd;
+};
+
+#define to_qmp_pd_resource(res) container_of(res, struct qmp_pd, pd)
+
+struct qmp_pd_resource {
+	const char *name;
+	int (*on)(struct generic_pm_domain *domain);
+	int (*off)(struct generic_pm_domain *domain);
+};
+
+static int qmp_pd_clock_toggle(struct qmp_pd *res, bool enable)
+{
+	char buf[AOSS_QMP_PD_MSG_LEN];
+
+	memset(buf, 0, sizeof(buf));
+	snprintf(buf, sizeof(buf), "{class: clock, res: %s, val: %d}",
+		 res->pd.name, enable);
+	return qmp_send(res->qmp, buf, sizeof(buf));
+}
+
+static int qmp_pd_clock_on(struct generic_pm_domain *domain)
+{
+	return qmp_pd_clock_toggle(to_qmp_pd_resource(domain), true);
+}
+
+static int qmp_pd_clock_off(struct generic_pm_domain *domain)
+{
+	return qmp_pd_clock_toggle(to_qmp_pd_resource(domain), false);
+}
+
+static int qmp_pd_image_toggle(struct qmp_pd *res, bool enable)
+{
+	char buf[AOSS_QMP_PD_MSG_LEN];
+
+	memset(buf, 0, sizeof(buf));
+	snprintf(buf, sizeof(buf),
+		 "{class: image, res: load_state, name: %s, val: %s}",
+		 res->pd.name, enable ? "on" : "off");
+	return qmp_send(res->qmp, buf, sizeof(buf));
+}
+
+static int qmp_pd_image_on(struct generic_pm_domain *domain)
+{
+	return qmp_pd_image_toggle(to_qmp_pd_resource(domain), true);
+}
+
+static int qmp_pd_image_off(struct generic_pm_domain *domain)
+{
+	return qmp_pd_image_toggle(to_qmp_pd_resource(domain), false);
+}
+
+static const struct qmp_pd_resource sdm845_resources[] = {
+	[AOSS_QMP_QDSS_CLK] = { "qdss", qmp_pd_clock_on, qmp_pd_clock_off },
+	[AOSS_QMP_LS_CDSP] = { "cdsp", qmp_pd_image_on, qmp_pd_image_off },
+	[AOSS_QMP_LS_LPASS] = { "adsp", qmp_pd_image_on, qmp_pd_image_off },
+	[AOSS_QMP_LS_MODEM] = { "modem", qmp_pd_image_on, qmp_pd_image_off },
+	[AOSS_QMP_LS_SLPI] = { "slpi", qmp_pd_image_on, qmp_pd_image_off },
+	[AOSS_QMP_LS_SPSS] = { "spss", qmp_pd_image_on, qmp_pd_image_off },
+	[AOSS_QMP_LS_VENUS] = { "venus", qmp_pd_image_on, qmp_pd_image_off },
+};
+
+static int qmp_pd_probe(struct platform_device *pdev)
+{
+	struct genpd_onecell_data *data;
+	struct device *parent = pdev->dev.parent;
+	struct qmp_pd *res;
+	struct qmp *qmp;
+	size_t num = ARRAY_SIZE(sdm845_resources);
+	int ret;
+	int i;
+
+	qmp = dev_get_drvdata(pdev->dev.parent);
+	if (!qmp)
+		return -EINVAL;
+
+	res = devm_kcalloc(&pdev->dev, num, sizeof(*res), GFP_KERNEL);
+	if (!res)
+		return -ENOMEM;
+
+	data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->domains = devm_kcalloc(&pdev->dev, num, sizeof(*data->domains),
+				     GFP_KERNEL);
+	if (!data->domains)
+		return -ENOMEM;
+
+	for (i = 0; i < num; i++) {
+		res[i].qmp = qmp;
+		res[i].pd.name = sdm845_resources[i].name;
+		res[i].pd.power_on = sdm845_resources[i].on;
+		res[i].pd.power_off = sdm845_resources[i].off;
+
+		ret = pm_genpd_init(&res[i].pd, NULL, true);
+		if (ret < 0) {
+			dev_err(&pdev->dev, "failed to init genpd\n");
+			goto unroll_genpds;
+		}
+
+		data->domains[i] = &res[i].pd;
+	}
+
+	data->num_domains = i;
+
+	platform_set_drvdata(pdev, data);
+
+	return of_genpd_add_provider_onecell(parent->of_node, data);
+
+unroll_genpds:
+	for (i--; i >= 0; i--)
+		pm_genpd_remove(data->domains[i]);
+
+	return ret;
+}
+
+static int qmp_pd_remove(struct platform_device *pdev)
+{
+	struct device *parent = pdev->dev.parent;
+	struct genpd_onecell_data *data = platform_get_drvdata(pdev);
+	int i;
+
+	of_genpd_del_provider(parent->of_node);
+
+	for (i = 0; i < data->num_domains; i++)
+		pm_genpd_remove(data->domains[i]);
+
+	return 0;
+}
+
+static struct platform_driver qmp_pd_driver = {
+	.driver = {
+		.name		= "aoss_qmp_pd",
+	},
+	.probe = qmp_pd_probe,
+	.remove = qmp_pd_remove,
+};
+module_platform_driver(qmp_pd_driver);
+
+MODULE_ALIAS("platform:aoss_qmp_pd");
+MODULE_DESCRIPTION("Qualcomm AOSS QMP load-state driver");
+MODULE_LICENSE("GPL v2");
-- 
2.18.0


^ permalink raw reply	[relevance 7%]

* [PATCH v6 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
      [irrelevant] <20190206051335.23799-1-bjorn.andersson@linaro.org>
                   ` (4 preceding siblings ...)
  2019-02-06  5:13 ` [PATCH v6 7/8] arm64: dts: qcom: Add AOSS QMP node Bjorn Andersson
@ 2019-02-06  5:13 ` Bjorn Andersson
  2019-02-26 23:54   ` Doug Anderson
  5 siblings, 1 reply; 200+ results
From: Bjorn Andersson @ 2019-02-06  5:13 UTC (permalink / raw)
  To: Andy Gross
  Cc: David Brown, Rob Herring, Mark Rutland, Arun Kumar Neelakantam,
	Sibi Sankar, Doug Anderson, linux-arm-msm, devicetree,
	linux-kernel

From: Sibi Sankar <sibis@codeaurora.org>

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v5:
- None

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 560c16616ee6..5c41f6fe3e1b 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1612,6 +1612,64 @@
 			};
 		};
 
+		mss_pil: remoteproc@4080000 {
+			compatible = "qcom,sdm845-mss-pil";
+			reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
+			reg-names = "qdsp6", "rmb";
+
+			interrupts-extended =
+				<&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog", "fatal", "ready",
+					  "handover", "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+				 <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+				 <&gcc GCC_BOOT_ROM_AHB_CLK>,
+				 <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+				 <&gcc GCC_MSS_SNOC_AXI_CLK>,
+				 <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+				 <&gcc GCC_PRNG_AHB_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "iface", "bus", "mem", "gpll0_mss",
+				      "snoc_axi", "mnoc_axi", "prng", "xo";
+
+			qcom,smem-states = <&modem_smp2p_out 0>;
+			qcom,smem-state-names = "stop";
+
+			resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+				 <&pdc_reset PDC_MODEM_SYNC_RESET>;
+			reset-names = "mss_restart", "pdc_reset";
+
+			qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000 0x24000>;
+
+			power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
+					<&rpmhpd SDM845_CX>,
+					<&rpmhpd SDM845_MX>,
+					<&rpmhpd SDM845_MSS>;
+			power-domain-names = "load_state", "cx", "mx", "mss";
+
+			mba {
+				memory-region = <&mba_region>;
+			};
+
+			mpss {
+				memory-region = <&mpss_region>;
+			};
+
+			glink-edge {
+				interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+				label = "modem";
+				qcom,remote-pid = <1>;
+				mboxes = <&apss_shared 12>;
+			};
+		};
+
 		gpucc: clock-controller@5090000 {
 			compatible = "qcom,sdm845-gpucc";
 			reg = <0 0x05090000 0 0x9000>;
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* [PATCH v6 7/8] arm64: dts: qcom: Add AOSS QMP node
      [irrelevant] <20190206051335.23799-1-bjorn.andersson@linaro.org>
                   ` (3 preceding siblings ...)
  2019-02-06  5:13 ` [PATCH v6 6/8] soc: qcom: Add AOSS QMP genpd provider Bjorn Andersson
@ 2019-02-06  5:13 ` Bjorn Andersson
  2019-02-06  5:13 ` [PATCH v6 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
  5 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-02-06  5:13 UTC (permalink / raw)
  To: Andy Gross
  Cc: David Brown, Rob Herring, Mark Rutland, Arun Kumar Neelakantam,
	Sibi Sankar, Doug Anderson, linux-arm-msm, devicetree,
	linux-kernel

The AOSS QMP provides a number of power domains, used for QDSS and
PIL, add the node for this.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v5:
- None

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 12efbdb1fa2e..560c16616ee6 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -13,6 +13,7 @@
 #include <dt-bindings/clock/qcom,videocc-sdm845.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/phy/phy-qcom-qusb2.h>
+#include <dt-bindings/power/qcom-aoss-qmp.h>
 #include <dt-bindings/power/qcom-rpmpd.h>
 #include <dt-bindings/reset/qcom,sdm845-aoss.h>
 #include <dt-bindings/reset/qcom,sdm845-pdc.h>
@@ -2080,6 +2081,15 @@
 			#reset-cells = <1>;
 		};
 
+		aoss_qmp: qmp@c300000 {
+			compatible = "qcom,sdm845-aoss-qmp";
+			reg = <0 0x0c300000 0 0x100000>;
+			interrupts = <GIC_SPI 389 IRQ_TYPE_EDGE_RISING>;
+			mboxes = <&apss_shared 0>;
+
+			#power-domain-cells = <1>;
+		};
+
 		spmi_bus: spmi@c440000 {
 			compatible = "qcom,spmi-pmic-arb";
 			reg = <0 0x0c440000 0 0x1100>,
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* Re: [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start
      [irrelevant]   ` <20181214014527epcms1p6c783b4cd1602bbcbcb6e725f840db479@epcms1p6>
@ 2019-02-19  5:12     ` Sibi Sankar
  2019-03-04  8:21       ` Sibi Sankar
      [irrelevant]       ` <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p8>
  0 siblings, 2 replies; 200+ results
From: Sibi Sankar @ 2019-02-19  5:12 UTC (permalink / raw)
  To: myungjoo.ham, Kyungmin Park
  Cc: Chanwoo Choi, linux-pm, linux-kernel, linux-arm-msm-owner, skannan

Hey MyungJoo,

On 12/14/18 7:15 AM, MyungJoo Ham wrote:
>> From: Saravana Kannan <skannan@codeaurora.org>
>>
>> If the new governor fails to start, switch back to old governor so that the
>> devfreq state is not left in some weird limbo.
>>
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> 
> Hello,
> 
> In overall, the idea and the implementation looks good.
> 
> However, I have a question:
> 
> What if the following line fails?
> 
> +		df->governor->event_handler(df, DEVFREQ_GOV_START,
> +					    NULL);
> 
> Don't we still need something to handle for such events?

The original discussion went as follows:
governor_store is expected to be used only on cases
where devfreq_add_device() succeeded i.e prev->governor
is expected to be present and DEVFREQ_GOV_START is
expected to succeed. Hence falling back to the previous
governor seems like a sensible idea.

This would also prevent DEVFREQ_GOV_STOP from being called
on a governor were DEVFREQ_GOV_START had failed which is
ideal.

That being said DEVFREQ_GOV_START can still fail for the
prev-governor due to some change in state of the system.
Do you want to handle this case by clearing the state of
governor rather than switching to previous governor?

> 
> Cheers,
> MyungJoo
> 
> 

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v6 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
  2019-02-06  5:13 ` [PATCH v6 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
@ 2019-02-26 23:54   ` Doug Anderson
  2019-02-27 21:03     ` Doug Anderson
  0 siblings, 1 reply; 200+ results
From: Doug Anderson @ 2019-02-26 23:54 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	Arun Kumar Neelakantam, Sibi Sankar, linux-arm-msm, devicetree,
	LKML, Vivek Gautam, Robin Murphy

Hi,

On Tue, Feb 5, 2019 at 9:13 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> From: Sibi Sankar <sibis@codeaurora.org>
>
> This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.
>
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v5:
> - None
>
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
>  1 file changed, 58 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 560c16616ee6..5c41f6fe3e1b 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -1612,6 +1612,64 @@
>                         };
>                 };
>
> +               mss_pil: remoteproc@4080000 {
> +                       compatible = "qcom,sdm845-mss-pil";
> +                       reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
> +                       reg-names = "qdsp6", "rmb";

I found that when I disabled IOMMU bypass by booting with
"arm-smmu.disable_bypass=y" that I'd get this failure:

---

[   13.633776] qcom-q6v5-mss 4080000.remoteproc: MBA booted, loading mpss
[   13.647694] arm-smmu 15000000.iommu: Unexpected global fault, this
could be serious
[   13.660278] arm-smmu 15000000.iommu: GFSR 0x80000002, GFSYNR0
0x00000000, GFSYNR1 0x00000781, GFSYNR2 0x00000000
...
[   14.648830] qcom-q6v5-mss 4080000.remoteproc: MPSS header
authentication timed out
[   14.657141] qcom-q6v5-mss 4080000.remoteproc: port failed halt
[   14.664983] remoteproc remoteproc0: can't start rproc
4080000.remoteproc: -110

---

Adding "iommus = <&apps_smmu 0x781 0>;" here fixed my problem.  NOTE
that I'm no expert on IOMMUs so you should confirm that this is right,
but if it is then maybe you could include it in the next spin of the
series?  I got the "0x781" just by looking at the value of the GFSYNR1
in the above splat.  I wasn't sure what to put for the mask so I put
0x0.


-Doug

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v6 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
  2019-02-26 23:54   ` Doug Anderson
@ 2019-02-27 21:03     ` Doug Anderson
  2019-02-28  5:42       ` Sibi Sankar
  2019-03-26  6:17       ` Vivek Gautam
  0 siblings, 2 replies; 200+ results
From: Doug Anderson @ 2019-02-27 21:03 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland,
	Arun Kumar Neelakantam, Sibi Sankar, linux-arm-msm, devicetree,
	LKML, Vivek Gautam, Robin Murphy

Hi,

On Tue, Feb 26, 2019 at 3:54 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Tue, Feb 5, 2019 at 9:13 PM Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > From: Sibi Sankar <sibis@codeaurora.org>
> >
> > This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.
> >
> > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >
> > Changes since v5:
> > - None
> >
> >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
> >  1 file changed, 58 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index 560c16616ee6..5c41f6fe3e1b 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -1612,6 +1612,64 @@
> >                         };
> >                 };
> >
> > +               mss_pil: remoteproc@4080000 {
> > +                       compatible = "qcom,sdm845-mss-pil";
> > +                       reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
> > +                       reg-names = "qdsp6", "rmb";
>
> I found that when I disabled IOMMU bypass by booting with
> "arm-smmu.disable_bypass=y" that I'd get this failure:
>
> ---
>
> [   13.633776] qcom-q6v5-mss 4080000.remoteproc: MBA booted, loading mpss
> [   13.647694] arm-smmu 15000000.iommu: Unexpected global fault, this
> could be serious
> [   13.660278] arm-smmu 15000000.iommu: GFSR 0x80000002, GFSYNR0
> 0x00000000, GFSYNR1 0x00000781, GFSYNR2 0x00000000
> ...
> [   14.648830] qcom-q6v5-mss 4080000.remoteproc: MPSS header
> authentication timed out
> [   14.657141] qcom-q6v5-mss 4080000.remoteproc: port failed halt
> [   14.664983] remoteproc remoteproc0: can't start rproc
> 4080000.remoteproc: -110
>
> ---
>
> Adding "iommus = <&apps_smmu 0x781 0>;" here fixed my problem.  NOTE
> that I'm no expert on IOMMUs so you should confirm that this is right,
> but if it is then maybe you could include it in the next spin of the
> series?  I got the "0x781" just by looking at the value of the GFSYNR1
> in the above splat.  I wasn't sure what to put for the mask so I put
> 0x0.

Upon more testing the "iommus" line that I came up with avoids the
global fault but doesn't actually work.  I just get:

qcom-q6v5-mss 4080000.remoteproc: failed to allocate mdt buffer

I'm hoping someone from Qualcomm can help out here and say how this
should be solved.  Thanks!


-Doug

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v6 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
  2019-02-27 21:03     ` Doug Anderson
@ 2019-02-28  5:42       ` Sibi Sankar
  2019-03-26  6:17       ` Vivek Gautam
  1 sibling, 0 replies; 200+ results
From: Sibi Sankar @ 2019-02-28  5:42 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Bjorn Andersson, Andy Gross, David Brown, Rob Herring,
	Mark Rutland, Arun Kumar Neelakantam, linux-arm-msm, devicetree,
	LKML, Vivek Gautam, Robin Murphy, linux-kernel-owner

Hey Doug,

On 2019-02-28 02:33, Doug Anderson wrote:
> Hi,
> 
> On Tue, Feb 26, 2019 at 3:54 PM Doug Anderson <dianders@chromium.org> 
> wrote:
>> 
>> Hi,
>> 
>> On Tue, Feb 5, 2019 at 9:13 PM Bjorn Andersson
>> <bjorn.andersson@linaro.org> wrote:
>> >
>> > From: Sibi Sankar <sibis@codeaurora.org>
>> >
>> > This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.
>> >
>> > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> > Reviewed-by: Douglas Anderson <dianders@chromium.org>
>> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> > ---
>> >
>> > Changes since v5:
>> > - None
>> >
>> >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
>> >  1 file changed, 58 insertions(+)
>> >
>> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> > index 560c16616ee6..5c41f6fe3e1b 100644
>> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> > @@ -1612,6 +1612,64 @@
>> >                         };
>> >                 };
>> >
>> > +               mss_pil: remoteproc@4080000 {
>> > +                       compatible = "qcom,sdm845-mss-pil";
>> > +                       reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
>> > +                       reg-names = "qdsp6", "rmb";
>> 
>> I found that when I disabled IOMMU bypass by booting with
>> "arm-smmu.disable_bypass=y" that I'd get this failure:
>> 
>> ---
>> 
>> [   13.633776] qcom-q6v5-mss 4080000.remoteproc: MBA booted, loading 
>> mpss
>> [   13.647694] arm-smmu 15000000.iommu: Unexpected global fault, this
>> could be serious
>> [   13.660278] arm-smmu 15000000.iommu: GFSR 0x80000002, GFSYNR0
>> 0x00000000, GFSYNR1 0x00000781, GFSYNR2 0x00000000
>> ...
>> [   14.648830] qcom-q6v5-mss 4080000.remoteproc: MPSS header
>> authentication timed out
>> [   14.657141] qcom-q6v5-mss 4080000.remoteproc: port failed halt
>> [   14.664983] remoteproc remoteproc0: can't start rproc
>> 4080000.remoteproc: -110
>> 
>> ---
>> 
>> Adding "iommus = <&apps_smmu 0x781 0>;" here fixed my problem.  NOTE
>> that I'm no expert on IOMMUs so you should confirm that this is right,
>> but if it is then maybe you could include it in the next spin of the
>> series?  I got the "0x781" just by looking at the value of the GFSYNR1
>> in the above splat.  I wasn't sure what to put for the mask so I put
>> 0x0.
> 
> Upon more testing the "iommus" line that I came up with avoids the
> global fault but doesn't actually work.  I just get:
> 
> qcom-q6v5-mss 4080000.remoteproc: failed to allocate mdt buffer

AFAIK modem does not have a smmu in front of it.

We have reserved memory nodes for mba and mpss,
however for mdt authentication we just rely on
dma_alloc_attrs with DMA_ATTR_FORCE_CONTIGUOUS
for allocation which seems to fail here.

> 
> I'm hoping someone from Qualcomm can help out here and say how this
> should be solved.  Thanks!

Yeah I'll enable arm-smmu.disable_bypass and
have a go at booting modem.

> 
> 
> -Doug

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH 0/3] RPMPD for QCS404
      [irrelevant] ` <c4b2a60c-80a5-8491-38fb-1fed3dee2e8a@codeaurora.org>
@ 2019-02-28  6:02   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-02-28  6:02 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: Bjorn Andersson, Andy Gross, David Brown, Rob Herring,
	Mark Rutland, linux-arm-msm, devicetree, linux-kernel,
	linux-arm-msm-owner

On 2019-02-25 18:18, Rajendra Nayak wrote:
> On 2/21/2019 12:14 PM, Bjorn Andersson wrote:
>> Reworkd the macros of the rpmpd driver and add qcs404 power domains, 
>> then add
>> this to the dts.
> 
> For the entire series,
> 
> Reviewed-by: Rajendra Nayak <rnayak@codeaurora.org>

I'll post v2 of this series with support
for msm8998 and a few fixes.

> 
>> 
>> Bjorn Andersson (3):
>>    soc: qcom: rpmpd: Modify corner defining macros
>>    soc: qcom: rpmpd: Add QCS404 corners
>>    arm64: dts: qcom: qcs404: Add rpmpd node
>> 
>>   .../devicetree/bindings/power/qcom,rpmpd.txt  |  1 +
>>   arch/arm64/boot/dts/qcom/qcs404.dtsi          | 35 +++++++++++
>>   drivers/soc/qcom/rpmpd.c                      | 63 
>> +++++++++++++------
>>   include/dt-bindings/power/qcom-rpmpd.h        |  9 +++
>>   4 files changed, 88 insertions(+), 20 deletions(-)
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start
  2019-02-19  5:12     ` [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start Sibi Sankar
@ 2019-03-04  8:21       ` Sibi Sankar
      [irrelevant]       ` <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p8>
  1 sibling, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-04  8:21 UTC (permalink / raw)
  To: myungjoo.ham, Kyungmin Park
  Cc: Chanwoo Choi, linux-pm, linux-kernel, linux-arm-msm-owner, skannan

Hey MyungJoo, Kyungmin
Did you get a chance to think about how you
want this fix implemented?

On 2019-02-19 10:42, Sibi Sankar wrote:
> Hey MyungJoo,
> 
> On 12/14/18 7:15 AM, MyungJoo Ham wrote:
>>> From: Saravana Kannan <skannan@codeaurora.org>
>>> 
>>> If the new governor fails to start, switch back to old governor so 
>>> that the
>>> devfreq state is not left in some weird limbo.
>>> 
>>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>> 
>> Hello,
>> 
>> In overall, the idea and the implementation looks good.
>> 
>> However, I have a question:
>> 
>> What if the following line fails?
>> 
>> +		df->governor->event_handler(df, DEVFREQ_GOV_START,
>> +					    NULL);
>> 
>> Don't we still need something to handle for such events?
> 
> The original discussion went as follows:
> governor_store is expected to be used only on cases
> where devfreq_add_device() succeeded i.e prev->governor
> is expected to be present and DEVFREQ_GOV_START is
> expected to succeed. Hence falling back to the previous
> governor seems like a sensible idea.
> 
> This would also prevent DEVFREQ_GOV_STOP from being called
> on a governor were DEVFREQ_GOV_START had failed which is
> ideal.
> 
> That being said DEVFREQ_GOV_START can still fail for the
> prev-governor due to some change in state of the system.
> Do you want to handle this case by clearing the state of
> governor rather than switching to previous governor?
> 
>> 
>> Cheers,
>> MyungJoo
>> 
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* [PATCH 4.20 86/88] arm64: dts: qcom: msm8998: Extend TZ reserved memory area
      [irrelevant] <20190304081630.610632175@linuxfoundation.org>
@ 2019-03-04  8:23 ` Greg Kroah-Hartman
  0 siblings, 0 replies; 200+ results
From: Greg Kroah-Hartman @ 2019-03-04  8:23 UTC (permalink / raw)
  To: linux-kernel
  Cc: Greg Kroah-Hartman, stable, Sibi Sankar, Marc Gonzalez, Andy Gross

4.20-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Marc Gonzalez <marc.w.gonzalez@free.fr>

commit 6e53330909672bd9a8c9f826e989a5945d9d9fdf upstream.

My console locks up as soon as Linux writes to [88800000,88f00000[
AFAIU, that memory area is reserved for trustzone.

Extend TZ reserved memory range, to prevent Linux from stepping on
trustzone's toes.

Cc: stable@vger.kernel.org # 4.20+
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Fixes: c7833949564ec ("arm64: dts: qcom: msm8998: Add smem related nodes")
Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm64/boot/dts/qcom/msm8998.dtsi |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -36,7 +36,7 @@
 		};
 
 		memory@86200000 {
-			reg = <0x0 0x86200000 0x0 0x2600000>;
+			reg = <0x0 0x86200000 0x0 0x2d00000>;
 			no-map;
 		};
 



^ permalink raw reply	[relevance 6%]

* RE: Re: [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start
      [irrelevant]       ` <CGME20181212135338epcas5p12f7a8cd1c7aab5d5c936cbc5c33eee07@epcms1p8>
@ 2019-03-05  7:18         ` MyungJoo Ham
  2019-03-06 17:44           ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: MyungJoo Ham @ 2019-03-05  7:18 UTC (permalink / raw)
  To: Sibi Sankar, Kyungmin Park
  Cc: Chanwoo Choi, linux-pm, linux-kernel, linux-arm-msm-owner, skannan

>Hey MyungJoo, Kyungmin
>Did you get a chance to think about how you
>want this fix implemented?
>
>On 2019-02-19 10:42, Sibi Sankar wrote:
>> Hey MyungJoo,
>> 
>> On 12/14/18 7:15 AM, MyungJoo Ham wrote:
>>>> From: Saravana Kannan <skannan@codeaurora.org>
>>>> 
>>>> If the new governor fails to start, switch back to old governor so 
>>>> that the
>>>> devfreq state is not left in some weird limbo.
>>>> 
>>>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>>> 
>>> Hello,
>>> 
>>> In overall, the idea and the implementation looks good.
>>> 
>>> However, I have a question:
>>> 
>>> What if the following line fails?
>>> 
>>> +		df->governor->event_handler(df, DEVFREQ_GOV_START,
>>> +					    NULL);
>>> 
>>> Don't we still need something to handle for such events?
>> 
>> The original discussion went as follows:
>> governor_store is expected to be used only on cases
>> where devfreq_add_device() succeeded i.e prev->governor
>> is expected to be present and DEVFREQ_GOV_START is
>> expected to succeed. Hence falling back to the previous
>> governor seems like a sensible idea.
>> 
>> This would also prevent DEVFREQ_GOV_STOP from being called
>> on a governor were DEVFREQ_GOV_START had failed which is
>> ideal.
>> 
>> That being said DEVFREQ_GOV_START can still fail for the
>> prev-governor due to some change in state of the system.
>> Do you want to handle this case by clearing the state of
>> governor rather than switching to previous governor?
>> 

If moving back to previous governor fails after
failing for "next" governor, we may assume it's fatal
and stop the device; we can simply return errors.

In such a case, df->governor may need to be NULL as well.


Cheers,
MyungJoo

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v4] PM / devfreq: Restart previous governor if new governor fails to start
  2019-03-05  7:18         ` MyungJoo Ham
@ 2019-03-06 17:44           ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-06 17:44 UTC (permalink / raw)
  To: myungjoo.ham
  Cc: Kyungmin Park, Chanwoo Choi, linux-pm, linux-kernel,
	linux-arm-msm-owner, skannan, linux-kernel-owner

On 2019-03-05 12:48, MyungJoo Ham wrote:
>> Hey MyungJoo, Kyungmin
>> Did you get a chance to think about how you
>> want this fix implemented?
>> 
>> On 2019-02-19 10:42, Sibi Sankar wrote:
>>> Hey MyungJoo,
>>> 
>>> On 12/14/18 7:15 AM, MyungJoo Ham wrote:
>>>>> From: Saravana Kannan <skannan@codeaurora.org>
>>>>> 
>>>>> If the new governor fails to start, switch back to old governor so
>>>>> that the
>>>>> devfreq state is not left in some weird limbo.
>>>>> 
>>>>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>>>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>>>>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>> 
>>>> Hello,
>>>> 
>>>> In overall, the idea and the implementation looks good.
>>>> 
>>>> However, I have a question:
>>>> 
>>>> What if the following line fails?
>>>> 
>>>> +		df->governor->event_handler(df, DEVFREQ_GOV_START,
>>>> +					    NULL);
>>>> 
>>>> Don't we still need something to handle for such events?
>>> 
>>> The original discussion went as follows:
>>> governor_store is expected to be used only on cases
>>> where devfreq_add_device() succeeded i.e prev->governor
>>> is expected to be present and DEVFREQ_GOV_START is
>>> expected to succeed. Hence falling back to the previous
>>> governor seems like a sensible idea.
>>> 
>>> This would also prevent DEVFREQ_GOV_STOP from being called
>>> on a governor were DEVFREQ_GOV_START had failed which is
>>> ideal.
>>> 
>>> That being said DEVFREQ_GOV_START can still fail for the
>>> prev-governor due to some change in state of the system.
>>> Do you want to handle this case by clearing the state of
>>> governor rather than switching to previous governor?
>>> 
> 
> If moving back to previous governor fails after
> failing for "next" governor, we may assume it's fatal
> and stop the device; we can simply return errors.
> 
> In such a case, df->governor may need to be NULL as well.

Thanks. Will make the necessary changes in the
next re-spin.

> 
> 
> Cheers,
> MyungJoo

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* [PATCH v5] PM / devfreq: Restart previous governor if new governor fails to start
@ 2019-03-11 10:06 Sibi Sankar
      [irrelevant] ` <CGME20190311100759epcas5p41fc634cd67a99b39cd25c4129e489c4c@epcms1p2>
  0 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-11 10:06 UTC (permalink / raw)
  To: myungjoo.ham, kyungmin.park
  Cc: cw00.choi, linux-pm, linux-kernel, linux-arm-msm-owner,
	Saravana Kannan, Sibi Sankar

From: Saravana Kannan <skannan@codeaurora.org>

If the new governor fails to start, switch back to old governor so that the
devfreq state is not left in some weird limbo.

[Mjungjoo: assume fatal on revert failure and set df->governor to NULL]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
---
V5:
* assume fatal on revert failure and set df->governor to NULL

V4:
* Removed prev_governor check.

V3:
* Fix NULL deref for real this time.
* Addressed some style preferences.

V2:
* Fixed typo in commit text
* Fixed potential NULL deref

 drivers/devfreq/devfreq.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 428a1de81008..37490235ec34 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -1124,7 +1124,7 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
 	struct devfreq *df = to_devfreq(dev);
 	int ret;
 	char str_governor[DEVFREQ_NAME_LEN + 1];
-	struct devfreq_governor *governor;
+	const struct devfreq_governor *governor, *prev_governor;
 
 	ret = sscanf(buf, "%" __stringify(DEVFREQ_NAME_LEN) "s", str_governor);
 	if (ret != 1)
@@ -1153,12 +1153,24 @@ static ssize_t governor_store(struct device *dev, struct device_attribute *attr,
 			goto out;
 		}
 	}
+	prev_governor = df->governor;
 	df->governor = governor;
 	strncpy(df->governor_name, governor->name, DEVFREQ_NAME_LEN);
 	ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
-	if (ret)
+	if (ret) {
 		dev_warn(dev, "%s: Governor %s not started(%d)\n",
 			 __func__, df->governor->name, ret);
+		df->governor = prev_governor;
+		strncpy(df->governor_name, prev_governor->name,
+			DEVFREQ_NAME_LEN);
+		ret = df->governor->event_handler(df, DEVFREQ_GOV_START, NULL);
+		if (ret) {
+			dev_warn(dev,
+				 "%s: reverting to Governor %s failed (%d)\n",
+				 __func__, df->governor_name, ret);
+			df->governor = NULL;
+		}
+	}
 out:
 	mutex_unlock(&devfreq_list_lock);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* RE: [PATCH v5] PM / devfreq: Restart previous governor if new governor fails to start
      [irrelevant] ` <CGME20190311100759epcas5p41fc634cd67a99b39cd25c4129e489c4c@epcms1p2>
@ 2019-03-12  7:17   ` MyungJoo Ham
  2019-03-13  6:01     ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: MyungJoo Ham @ 2019-03-12  7:17 UTC (permalink / raw)
  To: Chanwoo Choi, Sibi Sankar
  Cc: Kyungmin Park, linux-pm, linux-kernel, linux-arm-msm-owner,
	Saravana Kannan

>From: Saravana Kannan <skannan@codeaurora.org>
>
>If the new governor fails to start, switch back to old governor so that the
>devfreq state is not left in some weird limbo.
>
>[Mjungjoo: assume fatal on revert failure and set df->governor to NULL]
>Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>

I'll modify WARN->ERROR for the case when it's fatal:

>+		if (ret) {
>+			dev_warn(dev,
>+				 "%s: reverting to Governor %s failed (%d)\n",
>+				 __func__, df->governor_name, ret);
>+			df->governor = NULL;
>+		}

Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>


>---
>V5:
>* assume fatal on revert failure and set df->governor to NULL
>
>V4:
>* Removed prev_governor check.
>
>V3:
>* Fix NULL deref for real this time.
>* Addressed some style preferences.
>
>V2:
>* Fixed typo in commit text
>* Fixed potential NULL deref
>
> drivers/devfreq/devfreq.c | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v5] PM / devfreq: Restart previous governor if new governor fails to start
  2019-03-12  7:17   ` MyungJoo Ham
@ 2019-03-13  6:01     ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-13  6:01 UTC (permalink / raw)
  To: myungjoo.ham
  Cc: Chanwoo Choi, Kyungmin Park, linux-pm, linux-kernel,
	linux-arm-msm-owner, Saravana Kannan

On 2019-03-12 12:47, MyungJoo Ham wrote:
>> From: Saravana Kannan <skannan@codeaurora.org>
>> 
>> If the new governor fails to start, switch back to old governor so 
>> that the
>> devfreq state is not left in some weird limbo.
>> 
>> [Mjungjoo: assume fatal on revert failure and set df->governor to 
>> NULL]
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> 
> I'll modify WARN->ERROR for the case when it's fatal:

Sure, thanks.

> 
>> +		if (ret) {
>> +			dev_warn(dev,
>> +				 "%s: reverting to Governor %s failed (%d)\n",
>> +				 __func__, df->governor_name, ret);
>> +			df->governor = NULL;
>> +		}
> 
> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
> 
> 
>> ---
>> V5:
>> * assume fatal on revert failure and set df->governor to NULL
>> 
>> V4:
>> * Removed prev_governor check.
>> 
>> V3:
>> * Fix NULL deref for real this time.
>> * Addressed some style preferences.
>> 
>> V2:
>> * Fixed typo in commit text
>> * Fixed potential NULL deref
>> 
>> drivers/devfreq/devfreq.c | 16 ++++++++++++++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH 0/4] Introduce OPP bandwidth bindings
      [irrelevant] <20190313090010.20534-1-georgi.djakov@linaro.org>
@ 2019-03-15 19:02 ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-15 19:02 UTC (permalink / raw)
  To: Georgi Djakov, vireshk, sboyd, nm, robh+dt, mark.rutland, rjw
  Cc: jcrouse, vincent.guittot, bjorn.andersson, amit.kucheria, seansw,
	daidavid1, evgreen, linux-pm, devicetree, linux-kernel,
	linux-arm-msm, myungjoo.ham, Chanwoo Choi, Kyungmin Park



On 3/13/19 2:30 PM, Georgi Djakov wrote:
> Here is a proposal to extend the OPP bindings with bandwidth based on
> a previous discussion [1].
> 
> Every functional block on a SoC can contribute to the system power
> efficiency by expressing its own bandwidth needs (to memory or other SoC
> modules). This will allow the system to save power when high throughput
> is not required (and also provide maximum throughput when needed).
> 
> There are at least three ways for a device to determine its bandwidth
> needs:
> 	1. The device can dynamically calculate the needed bandwidth
> based on some known variable. For example: UART (baud rate), I2C (fast
> mode, high-speed mode, etc), USB (specification version, data transfer
> type), SDHC (SD standard, clock rate, bus-width), Video Encoder/Decoder
> (video format, resolution, frame-rate)
> 
> 	2. There is a hardware specific value. For example: hardware
> specific constant value (e.g. for PRNG) or use-case specific value that
> is hard-coded.
> 
> 	3. Predefined SoC/board specific bandwidth values. For example:
> CPU or GPU bandwidth is related to the current core frequency and both
> bandwidth and frequency are scaled together.
> 
> This patchset is trying to address point 3 above by extending the OPP
> bindings to support predefined SoC/board bandwidth values and adds
> support in cpufreq-dt to scale the interconnect between the CPU and the
> DDR together with frequency and voltage.

Hey Georgi,
Having opp-bw-MBps as a part of cpu opp does greatly simplify the
problem of scaling multiple interconnect devices with change in cpu
frequency. But there is still a need to scale other devices (non 
interconnect based) according to cpu frequency. Having a devfreq
governor for the same would help to have the same generic solution
across SoCs (msm8916/8996/qcs405/sdm845). The devfreq maintainer did
like the idea but wanted it incorporated into the passive governor.

* 
https://lore.kernel.org/lkml/20180528060014epcms1p87ec68a4d44f9447b06f979a87e545b7d@epcms1p8/

* 
https://lore.kernel.org/lkml/20180802095608epcms1p33fb061543efc9ceb3ec12d5567ceffbc@epcms1p3/

I have a RFC series implementing ddr scaling with passive governor for 
sdm845 with the following bindings, will post it early next week.

cpus {
	...

	CPU0: cpu@0 {
		...
		operating-points-v2 = <&cpu0_opp_table>;
		...
	};
         ....

	CPU4: cpu@400 {
		...
		operating-points-v2 = <&cpu4_opp_table>;
		...
	};
         ...
};

cpu0_opp_table: cpu0_opp_table {
	compatible = "operating-points-v2";
	opp-shared;

	cpu0_opp1: opp-300000000 {
		opp-hz = /bits/ 64 <300000000>;
	};

	...

	cpu0_opp16: opp-1612800000 {
		opp-hz = /bits/ 64 <1612800000>;
	};

	...
};

cpu4_opp_table: cpu4_opp_table {
	compatible = "operating-points-v2";
	opp-shared;

	...

	cpu4_opp4: opp-1056000000 {
		opp-hz = /bits/ 64 <1056000000>;
	};

	cpu4_opp5: opp-1209600000 {
		opp-hz = /bits/ 64 <1209600000>;
	};

	...
};

bw_opp_table: bw-opp-table {
	compatible = "operating-points-v2";

	opp-200  {
		opp-hz = /bits/ 64 < 200000000 >; /* 200 MHz */
		required-opps = <&cpu0_opp1>;
		/* 0 MB/s average and 762 MB/s peak bandwidth */
		opp-bw-MBs = <0 762>;
	};

	opp-300 {
		opp-hz = /bits/ 64 < 300000000 >; /* 300 MHz */
		/* 0 MB/s average and 1144 MB/s peak bandwidth */
		opp-bw-MBs = <0 1144>;
	};

	...

	opp-768 {
		opp-hz = /bits/ 64 < 768000000 >; /* 768 MHz */
		/* 0 MB/s average and 2929 MB/s peak bandwidth */
		opp-bw-MBs = <0 2929>;
		required-opps = <&cpu4_opp4>;
	};

	opp-1017 {
		opp-hz = /bits/ 64 < 1017000000 >; /* 1017 MHz */
		/* 0 MB/s average and 3879 MB/s peak bandwidth */
		opp-bw-MBs = <0 3879>;
		required-opps = <&cpu0_opp16>, <&cpu4_opp5>;
	};
};

cpubw {
	compatible = "devfreq-icbw";
	interconnects = <&snoc MASTER_APSS_1 &bimc SLAVE_EBI_CH0>;
	operating-points-v2 = <&bw_opp_table>;
};


> > [1] https://patchwork.kernel.org/patch/10577315/
> 
> Georgi Djakov (4):
>    dt-bindings: opp: Introduce opp-bw-MBs bindings
>    OPP: Add support for parsing the interconnect bandwidth
>    OPP: Update the bandwidth on OPP frequency changes
>    cpufreq: dt: Add support for interconnect bandwidth scaling
> 
>   Documentation/devicetree/bindings/opp/opp.txt | 45 ++++++++++++
>   drivers/cpufreq/cpufreq-dt.c                  | 27 ++++++-
>   drivers/opp/core.c                            | 71 +++++++++++++++++++
>   drivers/opp/of.c                              | 44 ++++++++++++
>   drivers/opp/opp.h                             |  6 ++
>   include/linux/pm_opp.h                        | 14 ++++
>   6 files changed, 206 insertions(+), 1 deletion(-)
> 

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[relevance 5%]

* [PATCH v2 0/9] RPMPD for QCS404 and MSM8998
@ 2019-03-24 17:49 Sibi Sankar
  2019-03-24 17:49 ` [PATCH v2 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
                   ` (8 more replies)
  0 siblings, 9 replies; 200+ results
From: Sibi Sankar @ 2019-03-24 17:49 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

Re-worked the macros of the rpmpd driver. Add power domains support
for QCS404 and MSM8998.

V2:
* Add rpmpd support for msm8998
* fixup corner/vfc with vlfl/vfl

Bjorn Andersson (4):
  soc: qcom: rpmpd: Modify corner defining macros
  dt-bindings: power: Add rpm power domain bindings for qcs404
  soc: qcom: rpmpd: Add QCS404 power-domains
  arm64: dts: qcom: qcs404: Add rpmpd node

Sibi Sankar (5):
  soc: qcom: rpmpd: fixup rpmpd set performance state
  soc: qcom: rpmpd: Add support to set rpmpd state to max
  dt-bindings: power: Add rpm power domain bindings for msm8998
  soc: qcom: rpmpd: Add MSM8998 power-domains
  arm64: dts: qcom: msm8998: Add rpmpd node

 .../devicetree/bindings/power/qcom,rpmpd.txt  |   2 +
 arch/arm64/boot/dts/qcom/msm8998.dtsi         |  51 +++++++
 arch/arm64/boot/dts/qcom/qcs404.dtsi          |  55 ++++++++
 drivers/soc/qcom/rpmpd.c                      | 129 ++++++++++++++----
 include/dt-bindings/power/qcom-rpmpd.h        |  34 +++++
 5 files changed, 248 insertions(+), 23 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 15%]

* [PATCH v2 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state
  2019-03-24 17:49 [PATCH v2 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
@ 2019-03-24 17:49 ` Sibi Sankar
  2019-03-25  4:03   ` Rajendra Nayak
  2019-03-24 17:50 ` [PATCH v2 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max Sibi Sankar
                   ` (7 subsequent siblings)
  8 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-24 17:49 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

Fixup rpmpd state to max if the required state is greater than all the
supported states.

Fixes: 075d3db8d10d ("Add support for the .set_performace_state() and
.opp_to_performance_state()")

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 005326050c23..235d01870dd8 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -226,7 +226,7 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
 	struct rpmpd *pd = domain_to_rpmpd(domain);
 
 	if (state > MAX_RPMPD_STATE)
-		goto out;
+		state = MAX_RPMPD_STATE;
 
 	mutex_lock(&rpmpd_lock);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 22%]

* [PATCH v2 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max
  2019-03-24 17:49 [PATCH v2 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
  2019-03-24 17:49 ` [PATCH v2 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
@ 2019-03-24 17:50 ` Sibi Sankar
  2019-03-25  4:06   ` Rajendra Nayak
  2019-03-24 17:50 ` [PATCH v2 3/9] soc: qcom: rpmpd: Modify corner defining macros Sibi Sankar
                   ` (6 subsequent siblings)
  8 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-24 17:50 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

Add support to set rpmpd state to max across SoCs.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 235d01870dd8..71fdfafad2ea 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -83,12 +83,14 @@ struct rpmpd {
 	const int res_type;
 	const int res_id;
 	struct qcom_smd_rpm *rpm;
+	unsigned int max_state;
 	__le32 key;
 };
 
 struct rpmpd_desc {
 	struct rpmpd **rpmpds;
 	size_t num_pds;
+	unsigned int max_state;
 };
 
 static DEFINE_MUTEX(rpmpd_lock);
@@ -114,6 +116,7 @@ static struct rpmpd *msm8996_rpmpds[] = {
 static const struct rpmpd_desc msm8996_desc = {
 	.rpmpds = msm8996_rpmpds,
 	.num_pds = ARRAY_SIZE(msm8996_rpmpds),
+	.max_state = MAX_RPMPD_STATE,
 };
 
 static const struct of_device_id rpmpd_match_table[] = {
@@ -225,8 +228,8 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
 	int ret = 0;
 	struct rpmpd *pd = domain_to_rpmpd(domain);
 
-	if (state > MAX_RPMPD_STATE)
-		state = MAX_RPMPD_STATE;
+	if (state > pd->max_state)
+		state = pd->max_state;
 
 	mutex_lock(&rpmpd_lock);
 
@@ -287,6 +290,7 @@ static int rpmpd_probe(struct platform_device *pdev)
 		}
 
 		rpmpds[i]->rpm = rpm;
+		rpmpds[i]->max_state = desc->max_state;
 		rpmpds[i]->pd.power_off = rpmpd_power_off;
 		rpmpds[i]->pd.power_on = rpmpd_power_on;
 		rpmpds[i]->pd.set_performance_state = rpmpd_set_performance;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* [PATCH v2 3/9] soc: qcom: rpmpd: Modify corner defining macros
  2019-03-24 17:49 [PATCH v2 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
  2019-03-24 17:49 ` [PATCH v2 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
  2019-03-24 17:50 ` [PATCH v2 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max Sibi Sankar
@ 2019-03-24 17:50 ` Sibi Sankar
  2019-03-25  4:07   ` Rajendra Nayak
  2019-03-24 17:50 ` [PATCH v2 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404 Sibi Sankar
                   ` (5 subsequent siblings)
  8 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-24 17:50 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

QCS404 uses individual resource type magic for each power-domain, so
adjust the macros slightly to make them reusable for this.

[sibi: Extend rpmpd corner pair to a generic rpmpd pair]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 39 +++++++++++++++++----------------------
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 71fdfafad2ea..17cd59d1ac3b 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -17,8 +17,8 @@
 #define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
 
 /* Resource types */
-#define RPMPD_SMPA 0x61706d73
-#define RPMPD_LDOA 0x616f646c
+#define RPMPD_SMPA 0x61706d73 /* smpa */
+#define RPMPD_LDOA 0x616f646c /* ldoa */
 
 /* Operation Keys */
 #define KEY_CORNER		0x6e726f63 /* corn */
@@ -27,46 +27,41 @@
 
 #define MAX_RPMPD_STATE		6
 
-#define DEFINE_RPMPD_CORNER_SMPA(_platform, _name, _active, r_id)		\
+#define DEFINE_RPMPD_PAIR(_platform, _name, _active, r_type, r_key,	\
+			  r_id)						\
 	static struct rpmpd _platform##_##_active;			\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = {	.name = #_name,	},				\
 		.peer = &_platform##_##_active,				\
-		.res_type = RPMPD_SMPA,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
-		.key = KEY_CORNER,					\
+		.key = KEY_##r_key,					\
 	};								\
 	static struct rpmpd _platform##_##_active = {			\
 		.pd = { .name = #_active, },				\
 		.peer = &_platform##_##_name,				\
 		.active_only = true,					\
-		.res_type = RPMPD_SMPA,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
-		.key = KEY_CORNER,					\
+		.key = KEY_##r_key,					\
 	}
 
-#define DEFINE_RPMPD_CORNER_LDOA(_platform, _name, r_id)			\
+#define DEFINE_RPMPD_CORNER(_platform, _name, r_type, r_id)		\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = { .name = #_name, },				\
-		.res_type = RPMPD_LDOA,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
 		.key = KEY_CORNER,					\
 	}
 
-#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type)		\
+#define DEFINE_RPMPD_VFC(_platform, _name, r_type, r_id)		\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = { .name = #_name, },				\
-		.res_type = r_type,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
 		.key = KEY_FLOOR_CORNER,				\
 	}
 
-#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id)			\
-	DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
-
-#define DEFINE_RPMPD_VFC_LDOA(_platform, _name, r_id)			\
-	DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_LDOA)
-
 struct rpmpd_req {
 	__le32 key;
 	__le32 nbytes;
@@ -96,12 +91,12 @@ struct rpmpd_desc {
 static DEFINE_MUTEX(rpmpd_lock);
 
 /* msm8996 RPM Power domains */
-DEFINE_RPMPD_CORNER_SMPA(msm8996, vddcx, vddcx_ao, 1);
-DEFINE_RPMPD_CORNER_SMPA(msm8996, vddmx, vddmx_ao, 2);
-DEFINE_RPMPD_CORNER_LDOA(msm8996, vddsscx, 26);
+DEFINE_RPMPD_PAIR(msm8996, vddcx, vddcx_ao, SMPA, CORNER, 1);
+DEFINE_RPMPD_PAIR(msm8996, vddmx, vddmx_ao, SMPA, CORNER, 2);
+DEFINE_RPMPD_CORNER(msm8996, vddsscx, LDOA, 26);
 
-DEFINE_RPMPD_VFC_SMPA(msm8996, vddcx_vfc, 1);
-DEFINE_RPMPD_VFC_LDOA(msm8996, vddsscx_vfc, 26);
+DEFINE_RPMPD_VFC(msm8996, vddcx_vfc, SMPA, 1);
+DEFINE_RPMPD_VFC(msm8996, vddsscx_vfc, LDOA, 26);
 
 static struct rpmpd *msm8996_rpmpds[] = {
 	[MSM8996_VDDCX] =	&msm8996_vddcx,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 20%]

* [PATCH v2 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404
  2019-03-24 17:49 [PATCH v2 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (2 preceding siblings ...)
  2019-03-24 17:50 ` [PATCH v2 3/9] soc: qcom: rpmpd: Modify corner defining macros Sibi Sankar
@ 2019-03-24 17:50 ` Sibi Sankar
  2019-03-25  4:21   ` Rajendra Nayak
  2019-03-24 17:50 ` [PATCH v2 5/9] soc: qcom: rpmpd: Add QCS404 power-domains Sibi Sankar
                   ` (4 subsequent siblings)
  8 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-24 17:50 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

Add RPM Power domain bindings for the qcs404 family of SoC

[sibis: Add supported rpmpd states for qcs404]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
 .../devicetree/bindings/power/qcom,rpmpd.txt  |  1 +
 include/dt-bindings/power/qcom-rpmpd.h        | 22 +++++++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
index 980e5413d18f..172ccf940c5c 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
@@ -6,6 +6,7 @@ which then translates it into a corresponding voltage on a rail
 Required Properties:
  - compatible: Should be one of the following
 	* qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of SoC
+	* qcom,qcs404-rpmpd: RPM Power domain for the qcs404 family of SoC
 	* qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
  - #power-domain-cells: number of cells in Power domain specifier
 	must be 1.
diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
index 87d9c6611682..450378662944 100644
--- a/include/dt-bindings/power/qcom-rpmpd.h
+++ b/include/dt-bindings/power/qcom-rpmpd.h
@@ -36,4 +36,26 @@
 #define MSM8996_VDDSSCX		5
 #define MSM8996_VDDSSCX_VFC	6
 
+/* QCS404 Power Domains */
+#define QCS404_VDDMX		0
+#define QCS404_VDDMX_AO		1
+#define QCS404_VDDMX_VFL	2
+#define QCS404_LPICX		3
+#define QCS404_LPICX_VFL	4
+#define QCS404_LPIMX		5
+#define QCS404_LPIMX_VFL	6
+
+/* RPM SMD Power Domain performance levels */
+#define RPM_SMD_LEVEL_RETENTION       16
+#define RPM_SMD_LEVEL_RETENTION_PLUS  32
+#define RPM_SMD_LEVEL_MIN_SVS         48
+#define RPM_SMD_LEVEL_LOW_SVS         64
+#define RPM_SMD_LEVEL_SVS             128
+#define RPM_SMD_LEVEL_SVS_PLUS        192
+#define RPM_SMD_LEVEL_NOM             256
+#define RPM_SMD_LEVEL_NOM_PLUS        320
+#define RPM_SMD_LEVEL_TURBO           384
+#define RPM_SMD_LEVEL_TURBO_NO_CPR    416
+#define RPM_SMD_LEVEL_BINNING         512
+
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 22%]

* [PATCH v2 5/9] soc: qcom: rpmpd: Add QCS404 power-domains
  2019-03-24 17:49 [PATCH v2 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (3 preceding siblings ...)
  2019-03-24 17:50 ` [PATCH v2 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404 Sibi Sankar
@ 2019-03-24 17:50 ` Sibi Sankar
  2019-03-24 17:50 ` [PATCH v2 6/9] arm64: dts: qcom: qcs404: Add rpmpd node Sibi Sankar
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-24 17:50 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

Add the shared cx/mx and the low-power-island's cx and mx power-domains
found on QCS404.

[sibi: Fixup corner/vfc with vlfl/vfl]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 48 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 17cd59d1ac3b..60a305e9d429 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -19,11 +19,16 @@
 /* Resource types */
 #define RPMPD_SMPA 0x61706d73 /* smpa */
 #define RPMPD_LDOA 0x616f646c /* ldoa */
+#define RPMPD_RWMX 0x786d7772 /* rwmx */
+#define RPMPD_RWLC 0x636c7772 /* rwlc */
+#define RPMPD_RWLM 0x6d6c7772 /* rwlm */
 
 /* Operation Keys */
 #define KEY_CORNER		0x6e726f63 /* corn */
 #define KEY_ENABLE		0x6e657773 /* swen */
 #define KEY_FLOOR_CORNER	0x636676   /* vfc */
+#define KEY_FLOOR_LEVEL		0x6c6676   /* vfl */
+#define KEY_LEVEL		0x6c766c76 /* vlvl */
 
 #define MAX_RPMPD_STATE		6
 
@@ -54,6 +59,14 @@
 		.key = KEY_CORNER,					\
 	}
 
+#define DEFINE_RPMPD_LEVEL(_platform, _name, r_type, r_id)		\
+	static struct rpmpd _platform##_##_name = {			\
+		.pd = { .name = #_name, },				\
+		.res_type = RPMPD_##r_type,				\
+		.res_id = r_id,						\
+		.key = KEY_LEVEL,					\
+	}
+
 #define DEFINE_RPMPD_VFC(_platform, _name, r_type, r_id)		\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = { .name = #_name, },				\
@@ -62,6 +75,14 @@
 		.key = KEY_FLOOR_CORNER,				\
 	}
 
+#define DEFINE_RPMPD_VFL(_platform, _name, r_type, r_id)		\
+	static struct rpmpd _platform##_##_name = {			\
+		.pd = { .name = #_name, },				\
+		.res_type = RPMPD_##r_type,				\
+		.res_id = r_id,						\
+		.key = KEY_FLOOR_LEVEL,					\
+	}
+
 struct rpmpd_req {
 	__le32 key;
 	__le32 nbytes;
@@ -114,8 +135,35 @@ static const struct rpmpd_desc msm8996_desc = {
 	.max_state = MAX_RPMPD_STATE,
 };
 
+/* qcs404 RPM Power domains */
+DEFINE_RPMPD_PAIR(qcs404, vddmx, vddmx_ao, RWMX, LEVEL, 0);
+DEFINE_RPMPD_VFL(qcs404, vddmx_vfl, RWMX, 0);
+
+DEFINE_RPMPD_LEVEL(qcs404, vdd_lpicx, RWLC, 0);
+DEFINE_RPMPD_VFL(qcs404, vdd_lpicx_vfl, RWLC, 0);
+
+DEFINE_RPMPD_LEVEL(qcs404, vdd_lpimx, RWLM, 0);
+DEFINE_RPMPD_VFL(qcs404, vdd_lpimx_vfl, RWLM, 0);
+
+static struct rpmpd *qcs404_rpmpds[] = {
+	[QCS404_VDDMX] = &qcs404_vddmx,
+	[QCS404_VDDMX_AO] = &qcs404_vddmx_ao,
+	[QCS404_VDDMX_VFL] = &qcs404_vddmx_vfl,
+	[QCS404_LPICX] = &qcs404_vdd_lpicx,
+	[QCS404_LPICX_VFL] = &qcs404_vdd_lpicx_vfl,
+	[QCS404_LPIMX] = &qcs404_vdd_lpimx,
+	[QCS404_LPIMX_VFL] = &qcs404_vdd_lpimx_vfl,
+};
+
+static const struct rpmpd_desc qcs404_desc = {
+	.rpmpds = qcs404_rpmpds,
+	.num_pds = ARRAY_SIZE(qcs404_rpmpds),
+	.max_state = RPM_SMD_LEVEL_BINNING,
+};
+
 static const struct of_device_id rpmpd_match_table[] = {
 	{ .compatible = "qcom,msm8996-rpmpd", .data = &msm8996_desc },
+	{ .compatible = "qcom,qcs404-rpmpd", .data = &qcs404_desc },
 	{ }
 };
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 20%]

* [PATCH v2 6/9] arm64: dts: qcom: qcs404: Add rpmpd node
  2019-03-24 17:49 [PATCH v2 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (4 preceding siblings ...)
  2019-03-24 17:50 ` [PATCH v2 5/9] soc: qcom: rpmpd: Add QCS404 power-domains Sibi Sankar
@ 2019-03-24 17:50 ` Sibi Sankar
  2019-03-24 17:50 ` [PATCH v2 7/9] dt-bindings: power: Add rpm power domain bindings for msm8998 Sibi Sankar
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-24 17:50 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

Add the rpmpd node on the qcs404 and define the available levels.

[sibis: fixup available levels]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/qcs404.dtsi | 55 ++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index e8fd26633d57..a7d46647c416 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -4,6 +4,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/qcom,gcc-qcs404.h>
 #include <dt-bindings/clock/qcom,rpmcc.h>
+#include <dt-bindings/power/qcom-rpmpd.h>
 
 / {
 	interrupt-parent = <&intc>;
@@ -230,6 +231,60 @@
 				compatible = "qcom,rpmcc-qcs404";
 				#clock-cells = <1>;
 			};
+
+			rpmpd: power-controller {
+				compatible = "qcom,qcs404-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 = <RPM_SMD_LEVEL_RETENTION>;
+					};
+
+					rpmpd_opp_ret_plus: opp2 {
+						opp-level = <RPM_SMD_LEVEL_RETENTION_PLUS>;
+					};
+
+					rpmpd_opp_min_svs: opp3 {
+						opp-level = <RPM_SMD_LEVEL_MIN_SVS>;
+					};
+
+					rpmpd_opp_low_svs: opp4 {
+						opp-level = <RPM_SMD_LEVEL_LOW_SVS>;
+					};
+
+					rpmhpd_opp_svs: opp5 {
+						opp-level = <RPM_SMD_LEVEL_SVS>;
+					};
+
+					rpmhpd_opp_svs_plus: opp6 {
+						opp-level = <RPM_SMD_LEVEL_SVS_PLUS>;
+					};
+
+					rpmhpd_opp_nom: opp7 {
+						opp-level = <RPM_SMD_LEVEL_NOM>;
+					};
+
+					rpmhpd_opp_nom_plus: opp8 {
+						opp-level = <RPM_SMD_LEVEL_NOM_PLUS>;
+					};
+
+					rpmhpd_opp_turbo: opp9 {
+						opp-level = <RPM_SMD_LEVEL_TURBO>;
+					};
+
+					rpmhpd_opp_turbo_no_cpr: opp10 {
+						opp-level = <RPM_SMD_LEVEL_TURBO_NO_CPR>;
+					};
+
+					rpmhpd_opp_turbo_plus: opp11 {
+						opp-level = <RPM_SMD_LEVEL_BINNING>;
+					};
+				};
+			};
 		};
 	};
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 22%]

* [PATCH v2 7/9] dt-bindings: power: Add rpm power domain bindings for msm8998
  2019-03-24 17:49 [PATCH v2 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (5 preceding siblings ...)
  2019-03-24 17:50 ` [PATCH v2 6/9] arm64: dts: qcom: qcs404: Add rpmpd node Sibi Sankar
@ 2019-03-24 17:50 ` Sibi Sankar
  2019-03-24 17:50 ` [PATCH v2 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains Sibi Sankar
  2019-03-24 17:50 ` [PATCH v2 9/9] arm64: dts: qcom: msm8998: Add rpmpd node Sibi Sankar
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-24 17:50 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

Add RPM Power domain bindings for the msm8998 family of SoC

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 .../devicetree/bindings/power/qcom,rpmpd.txt         |  1 +
 include/dt-bindings/power/qcom-rpmpd.h               | 12 ++++++++++++
 2 files changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
index 172ccf940c5c..eb35b22f9e23 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
@@ -6,6 +6,7 @@ which then translates it into a corresponding voltage on a rail
 Required Properties:
  - compatible: Should be one of the following
 	* qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of SoC
+	* qcom,msm8998-rpmpd: RPM Power domain for the msm8998 family of SoC
 	* qcom,qcs404-rpmpd: RPM Power domain for the qcs404 family of SoC
 	* qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
  - #power-domain-cells: number of cells in Power domain specifier
diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
index 450378662944..93e36d011527 100644
--- a/include/dt-bindings/power/qcom-rpmpd.h
+++ b/include/dt-bindings/power/qcom-rpmpd.h
@@ -36,6 +36,18 @@
 #define MSM8996_VDDSSCX		5
 #define MSM8996_VDDSSCX_VFC	6
 
+/* MSM8998 Power Domain Indexes */
+#define MSM8998_VDDCX		0
+#define MSM8998_VDDCX_AO	1
+#define MSM8998_VDDCX_VFL	2
+#define MSM8998_VDDMX		3
+#define MSM8998_VDDMX_AO	4
+#define MSM8998_VDDMX_VFL	5
+#define MSM8998_SSCCX		6
+#define MSM8998_SSCCX_VFL	7
+#define MSM8998_SSCMX		8
+#define MSM8998_SSCMX_VFL	9
+
 /* QCS404 Power Domains */
 #define QCS404_VDDMX		0
 #define QCS404_VDDMX_AO		1
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* [PATCH v2 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains
  2019-03-24 17:49 [PATCH v2 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (6 preceding siblings ...)
  2019-03-24 17:50 ` [PATCH v2 7/9] dt-bindings: power: Add rpm power domain bindings for msm8998 Sibi Sankar
@ 2019-03-24 17:50 ` Sibi Sankar
  2019-03-24 17:50 ` [PATCH v2 9/9] arm64: dts: qcom: msm8998: Add rpmpd node Sibi Sankar
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-24 17:50 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

Add the shared cx/mx and sensor sub-system's cx and mx
power-domains found on MSM8998.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 60a305e9d429..bc09874a343c 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -19,9 +19,12 @@
 /* Resource types */
 #define RPMPD_SMPA 0x61706d73 /* smpa */
 #define RPMPD_LDOA 0x616f646c /* ldoa */
+#define RPMPD_RWCX 0x78637772 /* rwcx */
 #define RPMPD_RWMX 0x786d7772 /* rwmx */
 #define RPMPD_RWLC 0x636c7772 /* rwlc */
 #define RPMPD_RWLM 0x6d6c7772 /* rwlm */
+#define RPMPD_RWSC 0x63737772 /* rwsc */
+#define RPMPD_RWSM 0x6d737772 /* rwsm */
 
 /* Operation Keys */
 #define KEY_CORNER		0x6e726f63 /* corn */
@@ -135,6 +138,38 @@ static const struct rpmpd_desc msm8996_desc = {
 	.max_state = MAX_RPMPD_STATE,
 };
 
+/* msm8998 RPM Power domains */
+DEFINE_RPMPD_PAIR(msm8998, vddcx, vddcx_ao, RWCX, LEVEL, 0);
+DEFINE_RPMPD_VFL(msm8998, vddcx_vfl, RWCX, 0);
+
+DEFINE_RPMPD_PAIR(msm8998, vddmx, vddmx_ao, RWMX, LEVEL, 0);
+DEFINE_RPMPD_VFL(msm8998, vddmx_vfl, RWMX, 0);
+
+DEFINE_RPMPD_LEVEL(msm8998, vdd_ssccx, RWSC, 0);
+DEFINE_RPMPD_VFL(msm8998, vdd_ssccx_vfl, RWSC, 0);
+
+DEFINE_RPMPD_LEVEL(msm8998, vdd_sscmx, RWSM, 0);
+DEFINE_RPMPD_VFL(msm8998, vdd_sscmx_vfl, RWSM, 0);
+
+static struct rpmpd *msm8998_rpmpds[] = {
+	[MSM8998_VDDCX] =		&msm8998_vddcx,
+	[MSM8998_VDDCX_AO] =		&msm8998_vddcx_ao,
+	[MSM8998_VDDCX_VFL] =		&msm8998_vddcx_vfl,
+	[MSM8998_VDDMX] =		&msm8998_vddmx,
+	[MSM8998_VDDMX_AO] =		&msm8998_vddmx_ao,
+	[MSM8998_VDDMX_VFL] =		&msm8998_vddmx_vfl,
+	[MSM8998_SSCCX] =		&msm8998_vdd_ssccx,
+	[MSM8998_SSCCX_VFL] =		&msm8998_vdd_ssccx_vfl,
+	[MSM8998_SSCMX] =		&msm8998_vdd_sscmx,
+	[MSM8998_SSCMX_VFL] =		&msm8998_vdd_sscmx_vfl,
+};
+
+static const struct rpmpd_desc msm8998_desc = {
+	.rpmpds = msm8998_rpmpds,
+	.num_pds = ARRAY_SIZE(msm8998_rpmpds),
+	.max_state = RPM_SMD_LEVEL_BINNING,
+};
+
 /* qcs404 RPM Power domains */
 DEFINE_RPMPD_PAIR(qcs404, vddmx, vddmx_ao, RWMX, LEVEL, 0);
 DEFINE_RPMPD_VFL(qcs404, vddmx_vfl, RWMX, 0);
@@ -163,6 +198,7 @@ static const struct rpmpd_desc qcs404_desc = {
 
 static const struct of_device_id rpmpd_match_table[] = {
 	{ .compatible = "qcom,msm8996-rpmpd", .data = &msm8996_desc },
+	{ .compatible = "qcom,msm8998-rpmpd", .data = &msm8998_desc },
 	{ .compatible = "qcom,qcs404-rpmpd", .data = &qcs404_desc },
 	{ }
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* [PATCH v2 9/9] arm64: dts: qcom: msm8998: Add rpmpd node
  2019-03-24 17:49 [PATCH v2 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (7 preceding siblings ...)
  2019-03-24 17:50 ` [PATCH v2 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains Sibi Sankar
@ 2019-03-24 17:50 ` Sibi Sankar
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-24 17:50 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

Add the rpmpd node on the msm8998 and define the available levels.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 51 +++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 3fd0769fe648..b7e3e0646b9b 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -4,6 +4,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/qcom,gcc-msm8998.h>
 #include <dt-bindings/clock/qcom,rpmcc.h>
+#include <dt-bindings/power/qcom-rpmpd.h>
 #include <dt-bindings/gpio/gpio.h>
 
 / {
@@ -272,6 +273,56 @@
 				compatible = "qcom,rpmcc-msm8998", "qcom,rpmcc";
 				#clock-cells = <1>;
 			};
+
+			rpmpd: power-controller {
+				compatible = "qcom,msm8998-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 = <RPM_SMD_LEVEL_RETENTION>;
+					};
+
+					rpmpd_opp_ret_plus: opp2 {
+						opp-level = <RPM_SMD_LEVEL_RETENTION_PLUS>;
+					};
+
+					rpmpd_opp_min_svs: opp3 {
+						opp-level = <RPM_SMD_LEVEL_MIN_SVS>;
+					};
+
+					rpmpd_opp_low_svs: opp4 {
+						opp-level = <RPM_SMD_LEVEL_LOW_SVS>;
+					};
+
+					rpmhpd_opp_svs: opp5 {
+						opp-level = <RPM_SMD_LEVEL_SVS>;
+					};
+
+					rpmhpd_opp_svs_plus: opp6 {
+						opp-level = <RPM_SMD_LEVEL_SVS_PLUS>;
+					};
+
+					rpmhpd_opp_nom: opp7 {
+						opp-level = <RPM_SMD_LEVEL_NOM>;
+					};
+
+					rpmhpd_opp_nom_plus: opp8 {
+						opp-level = <RPM_SMD_LEVEL_NOM_PLUS>;
+					};
+
+					rpmhpd_opp_turbo: opp9 {
+						opp-level = <RPM_SMD_LEVEL_TURBO>;
+					};
+
+					rpmhpd_opp_turbo_plus: opp10 {
+						opp-level = <RPM_SMD_LEVEL_BINNING>;
+					};
+				};
+			};
 		};
 	};
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* Re: [PATCH v2 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state
  2019-03-24 17:49 ` [PATCH v2 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
@ 2019-03-25  4:03   ` Rajendra Nayak
  2019-03-27 13:26     ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Rajendra Nayak @ 2019-03-25  4:03 UTC (permalink / raw)
  To: Sibi Sankar, bjorn.andersson, robh+dt, andy.gross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner, devicetree


On 3/24/2019 11:19 PM, Sibi Sankar wrote:
> Fixup rpmpd state to max if the required state is greater than all the
> supported states.

This should also say why, 'so the clients which just want to vote on whatever
is the max state supported can do so by passing an INT_MAX'?

> 
> Fixes: 075d3db8d10d ("Add support for the .set_performace_state() and
> .opp_to_performance_state()")
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>   drivers/soc/qcom/rpmpd.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
> index 005326050c23..235d01870dd8 100644
> --- a/drivers/soc/qcom/rpmpd.c
> +++ b/drivers/soc/qcom/rpmpd.c
> @@ -226,7 +226,7 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
>   	struct rpmpd *pd = domain_to_rpmpd(domain);
>   
>   	if (state > MAX_RPMPD_STATE)
> -		goto out;
> +		state = MAX_RPMPD_STATE;
>   
>   	mutex_lock(&rpmpd_lock);
>   
> 

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max
  2019-03-24 17:50 ` [PATCH v2 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max Sibi Sankar
@ 2019-03-25  4:06   ` Rajendra Nayak
  2019-03-27 13:27     ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Rajendra Nayak @ 2019-03-25  4:06 UTC (permalink / raw)
  To: Sibi Sankar, bjorn.andersson, robh+dt, andy.gross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner, devicetree

On 3/24/2019 11:20 PM, Sibi Sankar wrote:
> Add support to set rpmpd state to max across SoCs.

Changelog could be better, 'rpmpd max state varies across SoCs
and SoC families, add support in the driver to make it SoC/SoC
family specific'

> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>   drivers/soc/qcom/rpmpd.c | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
> index 235d01870dd8..71fdfafad2ea 100644
> --- a/drivers/soc/qcom/rpmpd.c
> +++ b/drivers/soc/qcom/rpmpd.c
> @@ -83,12 +83,14 @@ struct rpmpd {
>   	const int res_type;
>   	const int res_id;
>   	struct qcom_smd_rpm *rpm;
> +	unsigned int max_state;
>   	__le32 key;
>   };
>   
>   struct rpmpd_desc {
>   	struct rpmpd **rpmpds;
>   	size_t num_pds;
> +	unsigned int max_state;
>   };
>   
>   static DEFINE_MUTEX(rpmpd_lock);
> @@ -114,6 +116,7 @@ static struct rpmpd *msm8996_rpmpds[] = {
>   static const struct rpmpd_desc msm8996_desc = {
>   	.rpmpds = msm8996_rpmpds,
>   	.num_pds = ARRAY_SIZE(msm8996_rpmpds),
> +	.max_state = MAX_RPMPD_STATE,

Maybe this needs to be renamed to avoid confusion, MAX_8996_RPMPD_STATE?

>   };
>   
>   static const struct of_device_id rpmpd_match_table[] = {
> @@ -225,8 +228,8 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
>   	int ret = 0;
>   	struct rpmpd *pd = domain_to_rpmpd(domain);
>   
> -	if (state > MAX_RPMPD_STATE)
> -		state = MAX_RPMPD_STATE;
> +	if (state > pd->max_state)
> +		state = pd->max_state;
>   
>   	mutex_lock(&rpmpd_lock);
>   
> @@ -287,6 +290,7 @@ static int rpmpd_probe(struct platform_device *pdev)
>   		}
>   
>   		rpmpds[i]->rpm = rpm;
> +		rpmpds[i]->max_state = desc->max_state;
>   		rpmpds[i]->pd.power_off = rpmpd_power_off;
>   		rpmpds[i]->pd.power_on = rpmpd_power_on;
>   		rpmpds[i]->pd.set_performance_state = rpmpd_set_performance;
> 

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 3/9] soc: qcom: rpmpd: Modify corner defining macros
  2019-03-24 17:50 ` [PATCH v2 3/9] soc: qcom: rpmpd: Modify corner defining macros Sibi Sankar
@ 2019-03-25  4:07   ` Rajendra Nayak
  2019-03-27 13:28     ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Rajendra Nayak @ 2019-03-25  4:07 UTC (permalink / raw)
  To: Sibi Sankar, bjorn.andersson, robh+dt, andy.gross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner, devicetree



On 3/24/2019 11:20 PM, Sibi Sankar wrote:
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
> 
> QCS404 uses individual resource type magic for each power-domain, so
> adjust the macros slightly to make them reusable for this.
> 
> [sibi: Extend rpmpd corner pair to a generic rpmpd pair]

This needs to be right above your SoB I think.

> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>   drivers/soc/qcom/rpmpd.c | 39 +++++++++++++++++----------------------
>   1 file changed, 17 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
> index 71fdfafad2ea..17cd59d1ac3b 100644
> --- a/drivers/soc/qcom/rpmpd.c
> +++ b/drivers/soc/qcom/rpmpd.c
> @@ -17,8 +17,8 @@
>   #define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
>   
>   /* Resource types */
> -#define RPMPD_SMPA 0x61706d73
> -#define RPMPD_LDOA 0x616f646c
> +#define RPMPD_SMPA 0x61706d73 /* smpa */
> +#define RPMPD_LDOA 0x616f646c /* ldoa */
>   
>   /* Operation Keys */
>   #define KEY_CORNER		0x6e726f63 /* corn */
> @@ -27,46 +27,41 @@
>   
>   #define MAX_RPMPD_STATE		6
>   
> -#define DEFINE_RPMPD_CORNER_SMPA(_platform, _name, _active, r_id)		\
> +#define DEFINE_RPMPD_PAIR(_platform, _name, _active, r_type, r_key,	\
> +			  r_id)						\
>   	static struct rpmpd _platform##_##_active;			\
>   	static struct rpmpd _platform##_##_name = {			\
>   		.pd = {	.name = #_name,	},				\
>   		.peer = &_platform##_##_active,				\
> -		.res_type = RPMPD_SMPA,					\
> +		.res_type = RPMPD_##r_type,				\
>   		.res_id = r_id,						\
> -		.key = KEY_CORNER,					\
> +		.key = KEY_##r_key,					\
>   	};								\
>   	static struct rpmpd _platform##_##_active = {			\
>   		.pd = { .name = #_active, },				\
>   		.peer = &_platform##_##_name,				\
>   		.active_only = true,					\
> -		.res_type = RPMPD_SMPA,					\
> +		.res_type = RPMPD_##r_type,				\
>   		.res_id = r_id,						\
> -		.key = KEY_CORNER,					\
> +		.key = KEY_##r_key,					\
>   	}
>   
> -#define DEFINE_RPMPD_CORNER_LDOA(_platform, _name, r_id)			\
> +#define DEFINE_RPMPD_CORNER(_platform, _name, r_type, r_id)		\
>   	static struct rpmpd _platform##_##_name = {			\
>   		.pd = { .name = #_name, },				\
> -		.res_type = RPMPD_LDOA,					\
> +		.res_type = RPMPD_##r_type,				\
>   		.res_id = r_id,						\
>   		.key = KEY_CORNER,					\
>   	}
>   
> -#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type)		\
> +#define DEFINE_RPMPD_VFC(_platform, _name, r_type, r_id)		\
>   	static struct rpmpd _platform##_##_name = {			\
>   		.pd = { .name = #_name, },				\
> -		.res_type = r_type,					\
> +		.res_type = RPMPD_##r_type,				\
>   		.res_id = r_id,						\
>   		.key = KEY_FLOOR_CORNER,				\
>   	}
>   
> -#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id)			\
> -	DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
> -
> -#define DEFINE_RPMPD_VFC_LDOA(_platform, _name, r_id)			\
> -	DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_LDOA)
> -
>   struct rpmpd_req {
>   	__le32 key;
>   	__le32 nbytes;
> @@ -96,12 +91,12 @@ struct rpmpd_desc {
>   static DEFINE_MUTEX(rpmpd_lock);
>   
>   /* msm8996 RPM Power domains */
> -DEFINE_RPMPD_CORNER_SMPA(msm8996, vddcx, vddcx_ao, 1);
> -DEFINE_RPMPD_CORNER_SMPA(msm8996, vddmx, vddmx_ao, 2);
> -DEFINE_RPMPD_CORNER_LDOA(msm8996, vddsscx, 26);
> +DEFINE_RPMPD_PAIR(msm8996, vddcx, vddcx_ao, SMPA, CORNER, 1);
> +DEFINE_RPMPD_PAIR(msm8996, vddmx, vddmx_ao, SMPA, CORNER, 2);
> +DEFINE_RPMPD_CORNER(msm8996, vddsscx, LDOA, 26);
>   
> -DEFINE_RPMPD_VFC_SMPA(msm8996, vddcx_vfc, 1);
> -DEFINE_RPMPD_VFC_LDOA(msm8996, vddsscx_vfc, 26);
> +DEFINE_RPMPD_VFC(msm8996, vddcx_vfc, SMPA, 1);
> +DEFINE_RPMPD_VFC(msm8996, vddsscx_vfc, LDOA, 26);
>   
>   static struct rpmpd *msm8996_rpmpds[] = {
>   	[MSM8996_VDDCX] =	&msm8996_vddcx,
> 

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404
  2019-03-24 17:50 ` [PATCH v2 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404 Sibi Sankar
@ 2019-03-25  4:21   ` Rajendra Nayak
  2019-03-27 13:25     ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Rajendra Nayak @ 2019-03-25  4:21 UTC (permalink / raw)
  To: Sibi Sankar, bjorn.andersson, robh+dt, andy.gross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner, devicetree


On 3/24/2019 11:20 PM, Sibi Sankar wrote:
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
> 
> Add RPM Power domain bindings for the qcs404 family of SoC
> 
> [sibis: Add supported rpmpd states for qcs404]
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>

SoB ordering seems wrong.

> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>   .../devicetree/bindings/power/qcom,rpmpd.txt  |  1 +
>   include/dt-bindings/power/qcom-rpmpd.h        | 22 +++++++++++++++++++
>   2 files changed, 23 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
> index 980e5413d18f..172ccf940c5c 100644
> --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
> +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
> @@ -6,6 +6,7 @@ which then translates it into a corresponding voltage on a rail
>   Required Properties:
>    - compatible: Should be one of the following
>   	* qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of SoC
> +	* qcom,qcs404-rpmpd: RPM Power domain for the qcs404 family of SoC
>   	* qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
>    - #power-domain-cells: number of cells in Power domain specifier
>   	must be 1.
> diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
> index 87d9c6611682..450378662944 100644
> --- a/include/dt-bindings/power/qcom-rpmpd.h
> +++ b/include/dt-bindings/power/qcom-rpmpd.h
> @@ -36,4 +36,26 @@
>   #define MSM8996_VDDSSCX		5
>   #define MSM8996_VDDSSCX_VFC	6
>   
> +/* QCS404 Power Domains */
> +#define QCS404_VDDMX		0
> +#define QCS404_VDDMX_AO		1
> +#define QCS404_VDDMX_VFL	2
> +#define QCS404_LPICX		3
> +#define QCS404_LPICX_VFL	4
> +#define QCS404_LPIMX		5
> +#define QCS404_LPIMX_VFL	6
> +
> +/* RPM SMD Power Domain performance levels */

so unlike in the sdm845 case where we map these levels to
(contiguous) corners before passing it over to rpm, we seem
to pass these as-is to rpm, right?

Does this work if the user passes some value which does not
really map to a level defined here?
For instance if value passed is 17 for instance do we fall back to
16?
  
> +#define RPM_SMD_LEVEL_RETENTION       16
> +#define RPM_SMD_LEVEL_RETENTION_PLUS  32
> +#define RPM_SMD_LEVEL_MIN_SVS         48
> +#define RPM_SMD_LEVEL_LOW_SVS         64
> +#define RPM_SMD_LEVEL_SVS             128
> +#define RPM_SMD_LEVEL_SVS_PLUS        192
> +#define RPM_SMD_LEVEL_NOM             256
> +#define RPM_SMD_LEVEL_NOM_PLUS        320
> +#define RPM_SMD_LEVEL_TURBO           384
> +#define RPM_SMD_LEVEL_TURBO_NO_CPR    416
> +#define RPM_SMD_LEVEL_BINNING         512
> +
>   #endif
> 

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v6 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
  2019-02-27 21:03     ` Doug Anderson
  2019-02-28  5:42       ` Sibi Sankar
@ 2019-03-26  6:17       ` Vivek Gautam
  1 sibling, 0 replies; 200+ results
From: Vivek Gautam @ 2019-03-26  6:17 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Bjorn Andersson, Andy Gross, David Brown, Rob Herring,
	Mark Rutland, Arun Kumar Neelakantam, Sibi Sankar, linux-arm-msm,
	open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
	Robin Murphy

Hi Doug,


On Thu, Feb 28, 2019 at 2:34 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Tue, Feb 26, 2019 at 3:54 PM Doug Anderson <dianders@chromium.org> wrote:
> >
> > Hi,
> >
> > On Tue, Feb 5, 2019 at 9:13 PM Bjorn Andersson
> > <bjorn.andersson@linaro.org> wrote:
> > >
> > > From: Sibi Sankar <sibis@codeaurora.org>
> > >
> > > This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.
> > >
> > > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> > > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > ---
> > >
> > > Changes since v5:
> > > - None
> > >
> > >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
> > >  1 file changed, 58 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > index 560c16616ee6..5c41f6fe3e1b 100644
> > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > @@ -1612,6 +1612,64 @@
> > >                         };
> > >                 };
> > >
> > > +               mss_pil: remoteproc@4080000 {
> > > +                       compatible = "qcom,sdm845-mss-pil";
> > > +                       reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
> > > +                       reg-names = "qdsp6", "rmb";
> >
> > I found that when I disabled IOMMU bypass by booting with
> > "arm-smmu.disable_bypass=y" that I'd get this failure:
> >
> > ---
> >
> > [   13.633776] qcom-q6v5-mss 4080000.remoteproc: MBA booted, loading mpss
> > [   13.647694] arm-smmu 15000000.iommu: Unexpected global fault, this
> > could be serious
> > [   13.660278] arm-smmu 15000000.iommu: GFSR 0x80000002, GFSYNR0
> > 0x00000000, GFSYNR1 0x00000781, GFSYNR2 0x00000000
> > ...
> > [   14.648830] qcom-q6v5-mss 4080000.remoteproc: MPSS header
> > authentication timed out
> > [   14.657141] qcom-q6v5-mss 4080000.remoteproc: port failed halt
> > [   14.664983] remoteproc remoteproc0: can't start rproc
> > 4080000.remoteproc: -110
> >
> > ---
> >
> > Adding "iommus = <&apps_smmu 0x781 0>;" here fixed my problem.  NOTE
> > that I'm no expert on IOMMUs so you should confirm that this is right,
> > but if it is then maybe you could include it in the next spin of the
> > series?  I got the "0x781" just by looking at the value of the GFSYNR1
> > in the above splat.  I wasn't sure what to put for the mask so I put
> > 0x0.
>
> Upon more testing the "iommus" line that I came up with avoids the
> global fault but doesn't actually work.  I just get:
>
> qcom-q6v5-mss 4080000.remoteproc: failed to allocate mdt buffer
>
> I'm hoping someone from Qualcomm can help out here and say how this
> should be solved.  Thanks!

I and Sibi had a chance to look at this, and we could compare things
with MTP sdm845
device as well.

From the 845 block diagram it's clear that one of the MPSS paths goes
through SMMU
and therefore we have the SIDs 0x780 - 0x783 reserved for these streams.
However, it is recommended to use them in a bypass mode (S2CR_TYPE_BYPASS).

On MTP devices, the secure code programs these SIDs in SMMU and, as these
SMRs are marked secure they are not visible to the kernel. Thus kernel wouldn't
overwrite anything.
However, in your case there's no such reservation by the secure code.
In such a case,
we may need to make SMMU aware of these SIDs in the kernel.

And please note that adding "iommus = <&apps_smmu 0x781 0>" to the PIL
device may not
be the correct thing to do, since actual MPSS data streams don't use the SMMU.
So, configuring DMA path via SMMU isn't right.

Thanks & regards
Vivek

>
>
> -Doug



-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[relevance 0%]

* [PATCH v3 0/9] RPMPD for QCS404 and MSM8998
@ 2019-03-27 12:38 Sibi Sankar
  2019-03-27 12:38 ` [PATCH v3 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
                   ` (8 more replies)
  0 siblings, 9 replies; 200+ results
From: Sibi Sankar @ 2019-03-27 12:38 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

Re-worked the macros of the rpmpd driver. Add power domains support
for QCS404 and MSM8998.

V3:
* always send level updates to vfc and vfl in set_performance state
* fixup commit messages [Rajendra]
* fixup s-o-b ordering

V2:
* Add rpmpd support for msm8998
* fixup corner/vfc with vlfl/vfl

Bjorn Andersson (4):
  soc: qcom: rpmpd: Modify corner defining macros
  dt-bindings: power: Add rpm power domain bindings for qcs404
  soc: qcom: rpmpd: Add QCS404 power-domains
  arm64: dts: qcom: qcs404: Add rpmpd node

Sibi Sankar (5):
  soc: qcom: rpmpd: fixup rpmpd set performance state
  soc: qcom: rpmpd: Add support to set rpmpd state to max
  dt-bindings: power: Add rpm power domain bindings for msm8998
  soc: qcom: rpmpd: Add MSM8998 power-domains
  arm64: dts: qcom: msm8998: Add rpmpd node

 .../devicetree/bindings/power/qcom,rpmpd.txt  |   2 +
 arch/arm64/boot/dts/qcom/msm8998.dtsi         |  51 +++++++
 arch/arm64/boot/dts/qcom/qcs404.dtsi          |  55 +++++++
 drivers/soc/qcom/rpmpd.c                      | 135 ++++++++++++++----
 include/dt-bindings/power/qcom-rpmpd.h        |  34 +++++
 5 files changed, 252 insertions(+), 25 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 15%]

* [PATCH v3 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state
  2019-03-27 12:38 [PATCH v3 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
@ 2019-03-27 12:38 ` Sibi Sankar
  2019-04-05 14:59   ` Marc Gonzalez
  2019-03-27 12:38 ` [PATCH v3 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max Sibi Sankar
                   ` (7 subsequent siblings)
  8 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-27 12:38 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

Remoteproc q6v5-mss does set_performace_state with INT_MAX on
rpmpd. This is currently ignored since it is greater than the
max supported state. Fixup rpmpd state to max if the required
state is greater than all the supported states.

Fixes: 075d3db8d10d ("Add support for the .set_performace_state() and
.opp_to_performance_state()")

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 005326050c23..235d01870dd8 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -226,7 +226,7 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
 	struct rpmpd *pd = domain_to_rpmpd(domain);
 
 	if (state > MAX_RPMPD_STATE)
-		goto out;
+		state = MAX_RPMPD_STATE;
 
 	mutex_lock(&rpmpd_lock);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 22%]

* [PATCH v3 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max
  2019-03-27 12:38 [PATCH v3 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
  2019-03-27 12:38 ` [PATCH v3 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
@ 2019-03-27 12:38 ` Sibi Sankar
  2019-03-27 12:38 ` [PATCH v3 3/9] soc: qcom: rpmpd: Modify corner defining macros Sibi Sankar
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-27 12:38 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

rpmpd max state varies across SoCs and SoC families, add support
in the driver to make it SoC/SoC family specific

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 235d01870dd8..94015ece40e9 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -25,7 +25,7 @@
 #define KEY_ENABLE		0x6e657773 /* swen */
 #define KEY_FLOOR_CORNER	0x636676   /* vfc */
 
-#define MAX_RPMPD_STATE		6
+#define MAX_8996_RPMPD_STATE	6
 
 #define DEFINE_RPMPD_CORNER_SMPA(_platform, _name, _active, r_id)		\
 	static struct rpmpd _platform##_##_active;			\
@@ -83,12 +83,14 @@ struct rpmpd {
 	const int res_type;
 	const int res_id;
 	struct qcom_smd_rpm *rpm;
+	unsigned int max_state;
 	__le32 key;
 };
 
 struct rpmpd_desc {
 	struct rpmpd **rpmpds;
 	size_t num_pds;
+	unsigned int max_state;
 };
 
 static DEFINE_MUTEX(rpmpd_lock);
@@ -114,6 +116,7 @@ static struct rpmpd *msm8996_rpmpds[] = {
 static const struct rpmpd_desc msm8996_desc = {
 	.rpmpds = msm8996_rpmpds,
 	.num_pds = ARRAY_SIZE(msm8996_rpmpds),
+	.max_state = MAX_8996_RPMPD_STATE,
 };
 
 static const struct of_device_id rpmpd_match_table[] = {
@@ -225,8 +228,8 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
 	int ret = 0;
 	struct rpmpd *pd = domain_to_rpmpd(domain);
 
-	if (state > MAX_RPMPD_STATE)
-		state = MAX_RPMPD_STATE;
+	if (state > pd->max_state)
+		state = pd->max_state;
 
 	mutex_lock(&rpmpd_lock);
 
@@ -287,6 +290,7 @@ static int rpmpd_probe(struct platform_device *pdev)
 		}
 
 		rpmpds[i]->rpm = rpm;
+		rpmpds[i]->max_state = desc->max_state;
 		rpmpds[i]->pd.power_off = rpmpd_power_off;
 		rpmpds[i]->pd.power_on = rpmpd_power_on;
 		rpmpds[i]->pd.set_performance_state = rpmpd_set_performance;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* [PATCH v3 3/9] soc: qcom: rpmpd: Modify corner defining macros
  2019-03-27 12:38 [PATCH v3 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
  2019-03-27 12:38 ` [PATCH v3 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
  2019-03-27 12:38 ` [PATCH v3 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max Sibi Sankar
@ 2019-03-27 12:38 ` Sibi Sankar
  2019-03-27 12:38 ` [PATCH v3 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404 Sibi Sankar
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-27 12:38 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

QCS404 uses individual resource type magic for each power-domain, so
adjust the macros slightly to make them reusable for this.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[sibi: Extend rpmpd corner pair to a generic rpmpd pair]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 39 +++++++++++++++++----------------------
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 94015ece40e9..ca736ceb969c 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -17,8 +17,8 @@
 #define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
 
 /* Resource types */
-#define RPMPD_SMPA 0x61706d73
-#define RPMPD_LDOA 0x616f646c
+#define RPMPD_SMPA 0x61706d73 /* smpa */
+#define RPMPD_LDOA 0x616f646c /* ldoa */
 
 /* Operation Keys */
 #define KEY_CORNER		0x6e726f63 /* corn */
@@ -27,46 +27,41 @@
 
 #define MAX_8996_RPMPD_STATE	6
 
-#define DEFINE_RPMPD_CORNER_SMPA(_platform, _name, _active, r_id)		\
+#define DEFINE_RPMPD_PAIR(_platform, _name, _active, r_type, r_key,	\
+			  r_id)						\
 	static struct rpmpd _platform##_##_active;			\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = {	.name = #_name,	},				\
 		.peer = &_platform##_##_active,				\
-		.res_type = RPMPD_SMPA,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
-		.key = KEY_CORNER,					\
+		.key = KEY_##r_key,					\
 	};								\
 	static struct rpmpd _platform##_##_active = {			\
 		.pd = { .name = #_active, },				\
 		.peer = &_platform##_##_name,				\
 		.active_only = true,					\
-		.res_type = RPMPD_SMPA,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
-		.key = KEY_CORNER,					\
+		.key = KEY_##r_key,					\
 	}
 
-#define DEFINE_RPMPD_CORNER_LDOA(_platform, _name, r_id)			\
+#define DEFINE_RPMPD_CORNER(_platform, _name, r_type, r_id)		\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = { .name = #_name, },				\
-		.res_type = RPMPD_LDOA,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
 		.key = KEY_CORNER,					\
 	}
 
-#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type)		\
+#define DEFINE_RPMPD_VFC(_platform, _name, r_type, r_id)		\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = { .name = #_name, },				\
-		.res_type = r_type,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
 		.key = KEY_FLOOR_CORNER,				\
 	}
 
-#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id)			\
-	DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
-
-#define DEFINE_RPMPD_VFC_LDOA(_platform, _name, r_id)			\
-	DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_LDOA)
-
 struct rpmpd_req {
 	__le32 key;
 	__le32 nbytes;
@@ -96,12 +91,12 @@ struct rpmpd_desc {
 static DEFINE_MUTEX(rpmpd_lock);
 
 /* msm8996 RPM Power domains */
-DEFINE_RPMPD_CORNER_SMPA(msm8996, vddcx, vddcx_ao, 1);
-DEFINE_RPMPD_CORNER_SMPA(msm8996, vddmx, vddmx_ao, 2);
-DEFINE_RPMPD_CORNER_LDOA(msm8996, vddsscx, 26);
+DEFINE_RPMPD_PAIR(msm8996, vddcx, vddcx_ao, SMPA, CORNER, 1);
+DEFINE_RPMPD_PAIR(msm8996, vddmx, vddmx_ao, SMPA, CORNER, 2);
+DEFINE_RPMPD_CORNER(msm8996, vddsscx, LDOA, 26);
 
-DEFINE_RPMPD_VFC_SMPA(msm8996, vddcx_vfc, 1);
-DEFINE_RPMPD_VFC_LDOA(msm8996, vddsscx_vfc, 26);
+DEFINE_RPMPD_VFC(msm8996, vddcx_vfc, SMPA, 1);
+DEFINE_RPMPD_VFC(msm8996, vddsscx_vfc, LDOA, 26);
 
 static struct rpmpd *msm8996_rpmpds[] = {
 	[MSM8996_VDDCX] =	&msm8996_vddcx,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 20%]

* [PATCH v3 5/9] soc: qcom: rpmpd: Add QCS404 power-domains
  2019-03-27 12:38 [PATCH v3 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (3 preceding siblings ...)
  2019-03-27 12:38 ` [PATCH v3 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404 Sibi Sankar
@ 2019-03-27 12:38 ` Sibi Sankar
  2019-03-27 12:38 ` [PATCH v3 6/9] arm64: dts: qcom: qcs404: Add rpmpd node Sibi Sankar
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-27 12:38 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

Add the shared cx/mx and the low-power-island's cx and mx power-domains
found on QCS404.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[sibi: Fixup corner/vfc with vlfl/vfl]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 52 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index ca736ceb969c..238a9e02e890 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -19,11 +19,16 @@
 /* Resource types */
 #define RPMPD_SMPA 0x61706d73 /* smpa */
 #define RPMPD_LDOA 0x616f646c /* ldoa */
+#define RPMPD_RWMX 0x786d7772 /* rwmx */
+#define RPMPD_RWLC 0x636c7772 /* rwlc */
+#define RPMPD_RWLM 0x6d6c7772 /* rwlm */
 
 /* Operation Keys */
 #define KEY_CORNER		0x6e726f63 /* corn */
 #define KEY_ENABLE		0x6e657773 /* swen */
 #define KEY_FLOOR_CORNER	0x636676   /* vfc */
+#define KEY_FLOOR_LEVEL		0x6c6676   /* vfl */
+#define KEY_LEVEL		0x6c766c76 /* vlvl */
 
 #define MAX_8996_RPMPD_STATE	6
 
@@ -54,6 +59,14 @@
 		.key = KEY_CORNER,					\
 	}
 
+#define DEFINE_RPMPD_LEVEL(_platform, _name, r_type, r_id)		\
+	static struct rpmpd _platform##_##_name = {			\
+		.pd = { .name = #_name, },				\
+		.res_type = RPMPD_##r_type,				\
+		.res_id = r_id,						\
+		.key = KEY_LEVEL,					\
+	}
+
 #define DEFINE_RPMPD_VFC(_platform, _name, r_type, r_id)		\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = { .name = #_name, },				\
@@ -62,6 +75,14 @@
 		.key = KEY_FLOOR_CORNER,				\
 	}
 
+#define DEFINE_RPMPD_VFL(_platform, _name, r_type, r_id)		\
+	static struct rpmpd _platform##_##_name = {			\
+		.pd = { .name = #_name, },				\
+		.res_type = RPMPD_##r_type,				\
+		.res_id = r_id,						\
+		.key = KEY_FLOOR_LEVEL,					\
+	}
+
 struct rpmpd_req {
 	__le32 key;
 	__le32 nbytes;
@@ -114,8 +135,35 @@ static const struct rpmpd_desc msm8996_desc = {
 	.max_state = MAX_8996_RPMPD_STATE,
 };
 
+/* qcs404 RPM Power domains */
+DEFINE_RPMPD_PAIR(qcs404, vddmx, vddmx_ao, RWMX, LEVEL, 0);
+DEFINE_RPMPD_VFL(qcs404, vddmx_vfl, RWMX, 0);
+
+DEFINE_RPMPD_LEVEL(qcs404, vdd_lpicx, RWLC, 0);
+DEFINE_RPMPD_VFL(qcs404, vdd_lpicx_vfl, RWLC, 0);
+
+DEFINE_RPMPD_LEVEL(qcs404, vdd_lpimx, RWLM, 0);
+DEFINE_RPMPD_VFL(qcs404, vdd_lpimx_vfl, RWLM, 0);
+
+static struct rpmpd *qcs404_rpmpds[] = {
+	[QCS404_VDDMX] = &qcs404_vddmx,
+	[QCS404_VDDMX_AO] = &qcs404_vddmx_ao,
+	[QCS404_VDDMX_VFL] = &qcs404_vddmx_vfl,
+	[QCS404_LPICX] = &qcs404_vdd_lpicx,
+	[QCS404_LPICX_VFL] = &qcs404_vdd_lpicx_vfl,
+	[QCS404_LPIMX] = &qcs404_vdd_lpimx,
+	[QCS404_LPIMX_VFL] = &qcs404_vdd_lpimx_vfl,
+};
+
+static const struct rpmpd_desc qcs404_desc = {
+	.rpmpds = qcs404_rpmpds,
+	.num_pds = ARRAY_SIZE(qcs404_rpmpds),
+	.max_state = RPM_SMD_LEVEL_BINNING,
+};
+
 static const struct of_device_id rpmpd_match_table[] = {
 	{ .compatible = "qcom,msm8996-rpmpd", .data = &msm8996_desc },
+	{ .compatible = "qcom,qcs404-rpmpd", .data = &qcs404_desc },
 	{ }
 };
 
@@ -230,7 +278,9 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
 
 	pd->corner = state;
 
-	if (!pd->enabled && pd->key != KEY_FLOOR_CORNER)
+	/* Always send updates for vfc and vfl */
+	if (!pd->enabled && pd->key != KEY_FLOOR_CORNER &&
+	    pd->key != KEY_FLOOR_LEVEL)
 		goto out;
 
 	ret = rpmpd_aggregate_corner(pd);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 20%]

* [PATCH v3 6/9] arm64: dts: qcom: qcs404: Add rpmpd node
  2019-03-27 12:38 [PATCH v3 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (4 preceding siblings ...)
  2019-03-27 12:38 ` [PATCH v3 5/9] soc: qcom: rpmpd: Add QCS404 power-domains Sibi Sankar
@ 2019-03-27 12:38 ` Sibi Sankar
  2019-04-08  8:10   ` Sibi Sankar
  2019-03-27 12:38 ` [PATCH v3 7/9] dt-bindings: power: Add rpm power domain bindings for msm8998 Sibi Sankar
                   ` (2 subsequent siblings)
  8 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-27 12:38 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

Add the rpmpd node on the qcs404 and define the available levels.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[sibis: fixup available levels]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/qcs404.dtsi | 55 ++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index e8fd26633d57..a7d46647c416 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -4,6 +4,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/qcom,gcc-qcs404.h>
 #include <dt-bindings/clock/qcom,rpmcc.h>
+#include <dt-bindings/power/qcom-rpmpd.h>
 
 / {
 	interrupt-parent = <&intc>;
@@ -230,6 +231,60 @@
 				compatible = "qcom,rpmcc-qcs404";
 				#clock-cells = <1>;
 			};
+
+			rpmpd: power-controller {
+				compatible = "qcom,qcs404-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 = <RPM_SMD_LEVEL_RETENTION>;
+					};
+
+					rpmpd_opp_ret_plus: opp2 {
+						opp-level = <RPM_SMD_LEVEL_RETENTION_PLUS>;
+					};
+
+					rpmpd_opp_min_svs: opp3 {
+						opp-level = <RPM_SMD_LEVEL_MIN_SVS>;
+					};
+
+					rpmpd_opp_low_svs: opp4 {
+						opp-level = <RPM_SMD_LEVEL_LOW_SVS>;
+					};
+
+					rpmhpd_opp_svs: opp5 {
+						opp-level = <RPM_SMD_LEVEL_SVS>;
+					};
+
+					rpmhpd_opp_svs_plus: opp6 {
+						opp-level = <RPM_SMD_LEVEL_SVS_PLUS>;
+					};
+
+					rpmhpd_opp_nom: opp7 {
+						opp-level = <RPM_SMD_LEVEL_NOM>;
+					};
+
+					rpmhpd_opp_nom_plus: opp8 {
+						opp-level = <RPM_SMD_LEVEL_NOM_PLUS>;
+					};
+
+					rpmhpd_opp_turbo: opp9 {
+						opp-level = <RPM_SMD_LEVEL_TURBO>;
+					};
+
+					rpmhpd_opp_turbo_no_cpr: opp10 {
+						opp-level = <RPM_SMD_LEVEL_TURBO_NO_CPR>;
+					};
+
+					rpmhpd_opp_turbo_plus: opp11 {
+						opp-level = <RPM_SMD_LEVEL_BINNING>;
+					};
+				};
+			};
 		};
 	};
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 22%]

* [PATCH v3 7/9] dt-bindings: power: Add rpm power domain bindings for msm8998
  2019-03-27 12:38 [PATCH v3 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (5 preceding siblings ...)
  2019-03-27 12:38 ` [PATCH v3 6/9] arm64: dts: qcom: qcs404: Add rpmpd node Sibi Sankar
@ 2019-03-27 12:38 ` Sibi Sankar
  2019-03-28 18:40   ` Rob Herring
  2019-03-27 12:38 ` [PATCH v3 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains Sibi Sankar
  2019-03-27 12:38 ` [PATCH v3 9/9] arm64: dts: qcom: msm8998: Add rpmpd node Sibi Sankar
  8 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-27 12:38 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

Add RPM power domain bindings for the msm8998 family of SoC

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 .../devicetree/bindings/power/qcom,rpmpd.txt         |  1 +
 include/dt-bindings/power/qcom-rpmpd.h               | 12 ++++++++++++
 2 files changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
index 172ccf940c5c..eb35b22f9e23 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
@@ -6,6 +6,7 @@ which then translates it into a corresponding voltage on a rail
 Required Properties:
  - compatible: Should be one of the following
 	* qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of SoC
+	* qcom,msm8998-rpmpd: RPM Power domain for the msm8998 family of SoC
 	* qcom,qcs404-rpmpd: RPM Power domain for the qcs404 family of SoC
 	* qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
  - #power-domain-cells: number of cells in Power domain specifier
diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
index 450378662944..93e36d011527 100644
--- a/include/dt-bindings/power/qcom-rpmpd.h
+++ b/include/dt-bindings/power/qcom-rpmpd.h
@@ -36,6 +36,18 @@
 #define MSM8996_VDDSSCX		5
 #define MSM8996_VDDSSCX_VFC	6
 
+/* MSM8998 Power Domain Indexes */
+#define MSM8998_VDDCX		0
+#define MSM8998_VDDCX_AO	1
+#define MSM8998_VDDCX_VFL	2
+#define MSM8998_VDDMX		3
+#define MSM8998_VDDMX_AO	4
+#define MSM8998_VDDMX_VFL	5
+#define MSM8998_SSCCX		6
+#define MSM8998_SSCCX_VFL	7
+#define MSM8998_SSCMX		8
+#define MSM8998_SSCMX_VFL	9
+
 /* QCS404 Power Domains */
 #define QCS404_VDDMX		0
 #define QCS404_VDDMX_AO		1
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* [PATCH v3 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains
  2019-03-27 12:38 [PATCH v3 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (6 preceding siblings ...)
  2019-03-27 12:38 ` [PATCH v3 7/9] dt-bindings: power: Add rpm power domain bindings for msm8998 Sibi Sankar
@ 2019-03-27 12:38 ` Sibi Sankar
  2019-04-05 15:08   ` Marc Gonzalez
  2019-03-27 12:38 ` [PATCH v3 9/9] arm64: dts: qcom: msm8998: Add rpmpd node Sibi Sankar
  8 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-27 12:38 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

Add the shared cx/mx and sensor sub-system's cx and mx
power-domains found on MSM8998.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 238a9e02e890..706a3f63038e 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -19,9 +19,12 @@
 /* Resource types */
 #define RPMPD_SMPA 0x61706d73 /* smpa */
 #define RPMPD_LDOA 0x616f646c /* ldoa */
+#define RPMPD_RWCX 0x78637772 /* rwcx */
 #define RPMPD_RWMX 0x786d7772 /* rwmx */
 #define RPMPD_RWLC 0x636c7772 /* rwlc */
 #define RPMPD_RWLM 0x6d6c7772 /* rwlm */
+#define RPMPD_RWSC 0x63737772 /* rwsc */
+#define RPMPD_RWSM 0x6d737772 /* rwsm */
 
 /* Operation Keys */
 #define KEY_CORNER		0x6e726f63 /* corn */
@@ -135,6 +138,38 @@ static const struct rpmpd_desc msm8996_desc = {
 	.max_state = MAX_8996_RPMPD_STATE,
 };
 
+/* msm8998 RPM Power domains */
+DEFINE_RPMPD_PAIR(msm8998, vddcx, vddcx_ao, RWCX, LEVEL, 0);
+DEFINE_RPMPD_VFL(msm8998, vddcx_vfl, RWCX, 0);
+
+DEFINE_RPMPD_PAIR(msm8998, vddmx, vddmx_ao, RWMX, LEVEL, 0);
+DEFINE_RPMPD_VFL(msm8998, vddmx_vfl, RWMX, 0);
+
+DEFINE_RPMPD_LEVEL(msm8998, vdd_ssccx, RWSC, 0);
+DEFINE_RPMPD_VFL(msm8998, vdd_ssccx_vfl, RWSC, 0);
+
+DEFINE_RPMPD_LEVEL(msm8998, vdd_sscmx, RWSM, 0);
+DEFINE_RPMPD_VFL(msm8998, vdd_sscmx_vfl, RWSM, 0);
+
+static struct rpmpd *msm8998_rpmpds[] = {
+	[MSM8998_VDDCX] =		&msm8998_vddcx,
+	[MSM8998_VDDCX_AO] =		&msm8998_vddcx_ao,
+	[MSM8998_VDDCX_VFL] =		&msm8998_vddcx_vfl,
+	[MSM8998_VDDMX] =		&msm8998_vddmx,
+	[MSM8998_VDDMX_AO] =		&msm8998_vddmx_ao,
+	[MSM8998_VDDMX_VFL] =		&msm8998_vddmx_vfl,
+	[MSM8998_SSCCX] =		&msm8998_vdd_ssccx,
+	[MSM8998_SSCCX_VFL] =		&msm8998_vdd_ssccx_vfl,
+	[MSM8998_SSCMX] =		&msm8998_vdd_sscmx,
+	[MSM8998_SSCMX_VFL] =		&msm8998_vdd_sscmx_vfl,
+};
+
+static const struct rpmpd_desc msm8998_desc = {
+	.rpmpds = msm8998_rpmpds,
+	.num_pds = ARRAY_SIZE(msm8998_rpmpds),
+	.max_state = RPM_SMD_LEVEL_BINNING,
+};
+
 /* qcs404 RPM Power domains */
 DEFINE_RPMPD_PAIR(qcs404, vddmx, vddmx_ao, RWMX, LEVEL, 0);
 DEFINE_RPMPD_VFL(qcs404, vddmx_vfl, RWMX, 0);
@@ -163,6 +198,7 @@ static const struct rpmpd_desc qcs404_desc = {
 
 static const struct of_device_id rpmpd_match_table[] = {
 	{ .compatible = "qcom,msm8996-rpmpd", .data = &msm8996_desc },
+	{ .compatible = "qcom,msm8998-rpmpd", .data = &msm8998_desc },
 	{ .compatible = "qcom,qcs404-rpmpd", .data = &qcs404_desc },
 	{ }
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* [PATCH v3 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404
  2019-03-27 12:38 [PATCH v3 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (2 preceding siblings ...)
  2019-03-27 12:38 ` [PATCH v3 3/9] soc: qcom: rpmpd: Modify corner defining macros Sibi Sankar
@ 2019-03-27 12:38 ` Sibi Sankar
  2019-03-28 18:40   ` Rob Herring
  2019-03-27 12:38 ` [PATCH v3 5/9] soc: qcom: rpmpd: Add QCS404 power-domains Sibi Sankar
                   ` (4 subsequent siblings)
  8 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-27 12:38 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

Add RPM power domain bindings for the qcs404 family of SoC

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[sibis: Add supported rpmpd states for qcs404]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---

skip adding Rob's R-b due to some additional changes
https://lore.kernel.org/lkml/20190325223343.GA27389@bogus/

 .../devicetree/bindings/power/qcom,rpmpd.txt  |  1 +
 include/dt-bindings/power/qcom-rpmpd.h        | 22 +++++++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
index 980e5413d18f..172ccf940c5c 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
@@ -6,6 +6,7 @@ which then translates it into a corresponding voltage on a rail
 Required Properties:
  - compatible: Should be one of the following
 	* qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of SoC
+	* qcom,qcs404-rpmpd: RPM Power domain for the qcs404 family of SoC
 	* qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
  - #power-domain-cells: number of cells in Power domain specifier
 	must be 1.
diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
index 87d9c6611682..450378662944 100644
--- a/include/dt-bindings/power/qcom-rpmpd.h
+++ b/include/dt-bindings/power/qcom-rpmpd.h
@@ -36,4 +36,26 @@
 #define MSM8996_VDDSSCX		5
 #define MSM8996_VDDSSCX_VFC	6
 
+/* QCS404 Power Domains */
+#define QCS404_VDDMX		0
+#define QCS404_VDDMX_AO		1
+#define QCS404_VDDMX_VFL	2
+#define QCS404_LPICX		3
+#define QCS404_LPICX_VFL	4
+#define QCS404_LPIMX		5
+#define QCS404_LPIMX_VFL	6
+
+/* RPM SMD Power Domain performance levels */
+#define RPM_SMD_LEVEL_RETENTION       16
+#define RPM_SMD_LEVEL_RETENTION_PLUS  32
+#define RPM_SMD_LEVEL_MIN_SVS         48
+#define RPM_SMD_LEVEL_LOW_SVS         64
+#define RPM_SMD_LEVEL_SVS             128
+#define RPM_SMD_LEVEL_SVS_PLUS        192
+#define RPM_SMD_LEVEL_NOM             256
+#define RPM_SMD_LEVEL_NOM_PLUS        320
+#define RPM_SMD_LEVEL_TURBO           384
+#define RPM_SMD_LEVEL_TURBO_NO_CPR    416
+#define RPM_SMD_LEVEL_BINNING         512
+
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 22%]

* [PATCH v3 9/9] arm64: dts: qcom: msm8998: Add rpmpd node
  2019-03-27 12:38 [PATCH v3 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (7 preceding siblings ...)
  2019-03-27 12:38 ` [PATCH v3 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains Sibi Sankar
@ 2019-03-27 12:38 ` Sibi Sankar
  2019-04-08  8:12   ` Sibi Sankar
  8 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-27 12:38 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, Sibi Sankar

Add the rpmpd node on the msm8998 and define the available levels.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 51 +++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 3fd0769fe648..b7e3e0646b9b 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -4,6 +4,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/qcom,gcc-msm8998.h>
 #include <dt-bindings/clock/qcom,rpmcc.h>
+#include <dt-bindings/power/qcom-rpmpd.h>
 #include <dt-bindings/gpio/gpio.h>
 
 / {
@@ -272,6 +273,56 @@
 				compatible = "qcom,rpmcc-msm8998", "qcom,rpmcc";
 				#clock-cells = <1>;
 			};
+
+			rpmpd: power-controller {
+				compatible = "qcom,msm8998-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 = <RPM_SMD_LEVEL_RETENTION>;
+					};
+
+					rpmpd_opp_ret_plus: opp2 {
+						opp-level = <RPM_SMD_LEVEL_RETENTION_PLUS>;
+					};
+
+					rpmpd_opp_min_svs: opp3 {
+						opp-level = <RPM_SMD_LEVEL_MIN_SVS>;
+					};
+
+					rpmpd_opp_low_svs: opp4 {
+						opp-level = <RPM_SMD_LEVEL_LOW_SVS>;
+					};
+
+					rpmhpd_opp_svs: opp5 {
+						opp-level = <RPM_SMD_LEVEL_SVS>;
+					};
+
+					rpmhpd_opp_svs_plus: opp6 {
+						opp-level = <RPM_SMD_LEVEL_SVS_PLUS>;
+					};
+
+					rpmhpd_opp_nom: opp7 {
+						opp-level = <RPM_SMD_LEVEL_NOM>;
+					};
+
+					rpmhpd_opp_nom_plus: opp8 {
+						opp-level = <RPM_SMD_LEVEL_NOM_PLUS>;
+					};
+
+					rpmhpd_opp_turbo: opp9 {
+						opp-level = <RPM_SMD_LEVEL_TURBO>;
+					};
+
+					rpmhpd_opp_turbo_plus: opp10 {
+						opp-level = <RPM_SMD_LEVEL_BINNING>;
+					};
+				};
+			};
 		};
 	};
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* Re: [PATCH v2 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404
  2019-03-25  4:21   ` Rajendra Nayak
@ 2019-03-27 13:25     ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-27 13:25 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: bjorn.andersson, robh+dt, andy.gross, david.brown, mark.rutland,
	linux-kernel, linux-arm-msm-owner, devicetree,
	linux-kernel-owner

On 2019-03-25 09:51, Rajendra Nayak wrote:
> On 3/24/2019 11:20 PM, Sibi Sankar wrote:
>> From: Bjorn Andersson <bjorn.andersson@linaro.org>
>> 
>> Add RPM Power domain bindings for the qcs404 family of SoC
>> 
>> [sibis: Add supported rpmpd states for qcs404]
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> 
> SoB ordering seems wrong.

will re-order them in v3

> 
>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> ---
>>   .../devicetree/bindings/power/qcom,rpmpd.txt  |  1 +
>>   include/dt-bindings/power/qcom-rpmpd.h        | 22 
>> +++++++++++++++++++
>>   2 files changed, 23 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt 
>> b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
>> index 980e5413d18f..172ccf940c5c 100644
>> --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
>> +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
>> @@ -6,6 +6,7 @@ which then translates it into a corresponding voltage 
>> on a rail
>>   Required Properties:
>>    - compatible: Should be one of the following
>>   	* qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of 
>> SoC
>> +	* qcom,qcs404-rpmpd: RPM Power domain for the qcs404 family of SoC
>>   	* qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of 
>> SoC
>>    - #power-domain-cells: number of cells in Power domain specifier
>>   	must be 1.
>> diff --git a/include/dt-bindings/power/qcom-rpmpd.h 
>> b/include/dt-bindings/power/qcom-rpmpd.h
>> index 87d9c6611682..450378662944 100644
>> --- a/include/dt-bindings/power/qcom-rpmpd.h
>> +++ b/include/dt-bindings/power/qcom-rpmpd.h
>> @@ -36,4 +36,26 @@
>>   #define MSM8996_VDDSSCX		5
>>   #define MSM8996_VDDSSCX_VFC	6
>>   +/* QCS404 Power Domains */
>> +#define QCS404_VDDMX		0
>> +#define QCS404_VDDMX_AO		1
>> +#define QCS404_VDDMX_VFL	2
>> +#define QCS404_LPICX		3
>> +#define QCS404_LPICX_VFL	4
>> +#define QCS404_LPIMX		5
>> +#define QCS404_LPIMX_VFL	6
>> +
>> +/* RPM SMD Power Domain performance levels */
> 
> so unlike in the sdm845 case where we map these levels to
> (contiguous) corners before passing it over to rpm, we seem
> to pass these as-is to rpm, right?
> 
> Does this work if the user passes some value which does not
> really map to a level defined here?
> For instance if value passed is 17 for instance do we fall back to
> 16?

The rpm firmware will ensure that a ceil operation
is performed on any requested level which does not
map to a pre-defined level. I did try to do the
same in kernel however since the opp-levels are not
inserted in ascending order while populating the
opp-table for rpmpd, it becomes difficult to get
ceil/floor levels from the opp-table with minimal
changes.


> 
>> +#define RPM_SMD_LEVEL_RETENTION       16
>> +#define RPM_SMD_LEVEL_RETENTION_PLUS  32
>> +#define RPM_SMD_LEVEL_MIN_SVS         48
>> +#define RPM_SMD_LEVEL_LOW_SVS         64
>> +#define RPM_SMD_LEVEL_SVS             128
>> +#define RPM_SMD_LEVEL_SVS_PLUS        192
>> +#define RPM_SMD_LEVEL_NOM             256
>> +#define RPM_SMD_LEVEL_NOM_PLUS        320
>> +#define RPM_SMD_LEVEL_TURBO           384
>> +#define RPM_SMD_LEVEL_TURBO_NO_CPR    416
>> +#define RPM_SMD_LEVEL_BINNING         512
>> +
>>   #endif
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v2 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state
  2019-03-25  4:03   ` Rajendra Nayak
@ 2019-03-27 13:26     ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-27 13:26 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: bjorn.andersson, robh+dt, andy.gross, david.brown, mark.rutland,
	linux-kernel, linux-arm-msm-owner, devicetree

On 2019-03-25 09:33, Rajendra Nayak wrote:
> On 3/24/2019 11:19 PM, Sibi Sankar wrote:
>> Fixup rpmpd state to max if the required state is greater than all the
>> supported states.
> 
> This should also say why, 'so the clients which just want to vote on 
> whatever
> is the max state supported can do so by passing an INT_MAX'?

will add more detail in v3

> 
>> 
>> Fixes: 075d3db8d10d ("Add support for the .set_performace_state() and
>> .opp_to_performance_state()")
>> 
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>>   drivers/soc/qcom/rpmpd.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
>> index 005326050c23..235d01870dd8 100644
>> --- a/drivers/soc/qcom/rpmpd.c
>> +++ b/drivers/soc/qcom/rpmpd.c
>> @@ -226,7 +226,7 @@ static int rpmpd_set_performance(struct 
>> generic_pm_domain *domain,
>>   	struct rpmpd *pd = domain_to_rpmpd(domain);
>>     	if (state > MAX_RPMPD_STATE)
>> -		goto out;
>> +		state = MAX_RPMPD_STATE;
>>     	mutex_lock(&rpmpd_lock);
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v2 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max
  2019-03-25  4:06   ` Rajendra Nayak
@ 2019-03-27 13:27     ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-27 13:27 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: bjorn.andersson, robh+dt, andy.gross, david.brown, mark.rutland,
	linux-kernel, linux-arm-msm-owner, devicetree,
	linux-kernel-owner

On 2019-03-25 09:36, Rajendra Nayak wrote:
> On 3/24/2019 11:20 PM, Sibi Sankar wrote:
>> Add support to set rpmpd state to max across SoCs.
> 
> Changelog could be better, 'rpmpd max state varies across SoCs
> and SoC families, add support in the driver to make it SoC/SoC
> family specific'

will use this in v3

> 
>> 
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>>   drivers/soc/qcom/rpmpd.c | 8 ++++++--
>>   1 file changed, 6 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
>> index 235d01870dd8..71fdfafad2ea 100644
>> --- a/drivers/soc/qcom/rpmpd.c
>> +++ b/drivers/soc/qcom/rpmpd.c
>> @@ -83,12 +83,14 @@ struct rpmpd {
>>   	const int res_type;
>>   	const int res_id;
>>   	struct qcom_smd_rpm *rpm;
>> +	unsigned int max_state;
>>   	__le32 key;
>>   };
>>     struct rpmpd_desc {
>>   	struct rpmpd **rpmpds;
>>   	size_t num_pds;
>> +	unsigned int max_state;
>>   };
>>     static DEFINE_MUTEX(rpmpd_lock);
>> @@ -114,6 +116,7 @@ static struct rpmpd *msm8996_rpmpds[] = {
>>   static const struct rpmpd_desc msm8996_desc = {
>>   	.rpmpds = msm8996_rpmpds,
>>   	.num_pds = ARRAY_SIZE(msm8996_rpmpds),
>> +	.max_state = MAX_RPMPD_STATE,
> 
> Maybe this needs to be renamed to avoid confusion, 
> MAX_8996_RPMPD_STATE?

sure

> 
>>   };
>>     static const struct of_device_id rpmpd_match_table[] = {
>> @@ -225,8 +228,8 @@ static int rpmpd_set_performance(struct 
>> generic_pm_domain *domain,
>>   	int ret = 0;
>>   	struct rpmpd *pd = domain_to_rpmpd(domain);
>>   -	if (state > MAX_RPMPD_STATE)
>> -		state = MAX_RPMPD_STATE;
>> +	if (state > pd->max_state)
>> +		state = pd->max_state;
>>     	mutex_lock(&rpmpd_lock);
>>   @@ -287,6 +290,7 @@ static int rpmpd_probe(struct platform_device 
>> *pdev)
>>   		}
>>     		rpmpds[i]->rpm = rpm;
>> +		rpmpds[i]->max_state = desc->max_state;
>>   		rpmpds[i]->pd.power_off = rpmpd_power_off;
>>   		rpmpds[i]->pd.power_on = rpmpd_power_on;
>>   		rpmpds[i]->pd.set_performance_state = rpmpd_set_performance;
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v2 3/9] soc: qcom: rpmpd: Modify corner defining macros
  2019-03-25  4:07   ` Rajendra Nayak
@ 2019-03-27 13:28     ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-27 13:28 UTC (permalink / raw)
  To: Rajendra Nayak
  Cc: bjorn.andersson, robh+dt, andy.gross, david.brown, mark.rutland,
	linux-kernel, linux-arm-msm-owner, devicetree,
	linux-kernel-owner

On 2019-03-25 09:37, Rajendra Nayak wrote:
> On 3/24/2019 11:20 PM, Sibi Sankar wrote:
>> From: Bjorn Andersson <bjorn.andersson@linaro.org>
>> 
>> QCS404 uses individual resource type magic for each power-domain, so
>> adjust the macros slightly to make them reusable for this.
>> 
>> [sibi: Extend rpmpd corner pair to a generic rpmpd pair]
> 
> This needs to be right above your SoB I think.

will re-order them in v3

> 
>> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>>   drivers/soc/qcom/rpmpd.c | 39 
>> +++++++++++++++++----------------------
>>   1 file changed, 17 insertions(+), 22 deletions(-)
>> 
>> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
>> index 71fdfafad2ea..17cd59d1ac3b 100644
>> --- a/drivers/soc/qcom/rpmpd.c
>> +++ b/drivers/soc/qcom/rpmpd.c
>> @@ -17,8 +17,8 @@
>>   #define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, 
>> pd)
>>     /* Resource types */
>> -#define RPMPD_SMPA 0x61706d73
>> -#define RPMPD_LDOA 0x616f646c
>> +#define RPMPD_SMPA 0x61706d73 /* smpa */
>> +#define RPMPD_LDOA 0x616f646c /* ldoa */
>>     /* Operation Keys */
>>   #define KEY_CORNER		0x6e726f63 /* corn */
>> @@ -27,46 +27,41 @@
>>     #define MAX_RPMPD_STATE		6
>>   -#define DEFINE_RPMPD_CORNER_SMPA(_platform, _name, _active, 
>> r_id)		\
>> +#define DEFINE_RPMPD_PAIR(_platform, _name, _active, r_type, r_key,	\
>> +			  r_id)						\
>>   	static struct rpmpd _platform##_##_active;			\
>>   	static struct rpmpd _platform##_##_name = {			\
>>   		.pd = {	.name = #_name,	},				\
>>   		.peer = &_platform##_##_active,				\
>> -		.res_type = RPMPD_SMPA,					\
>> +		.res_type = RPMPD_##r_type,				\
>>   		.res_id = r_id,						\
>> -		.key = KEY_CORNER,					\
>> +		.key = KEY_##r_key,					\
>>   	};								\
>>   	static struct rpmpd _platform##_##_active = {			\
>>   		.pd = { .name = #_active, },				\
>>   		.peer = &_platform##_##_name,				\
>>   		.active_only = true,					\
>> -		.res_type = RPMPD_SMPA,					\
>> +		.res_type = RPMPD_##r_type,				\
>>   		.res_id = r_id,						\
>> -		.key = KEY_CORNER,					\
>> +		.key = KEY_##r_key,					\
>>   	}
>>   -#define DEFINE_RPMPD_CORNER_LDOA(_platform, _name, r_id)			\
>> +#define DEFINE_RPMPD_CORNER(_platform, _name, r_type, r_id)		\
>>   	static struct rpmpd _platform##_##_name = {			\
>>   		.pd = { .name = #_name, },				\
>> -		.res_type = RPMPD_LDOA,					\
>> +		.res_type = RPMPD_##r_type,				\
>>   		.res_id = r_id,						\
>>   		.key = KEY_CORNER,					\
>>   	}
>>   -#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type)		\
>> +#define DEFINE_RPMPD_VFC(_platform, _name, r_type, r_id)		\
>>   	static struct rpmpd _platform##_##_name = {			\
>>   		.pd = { .name = #_name, },				\
>> -		.res_type = r_type,					\
>> +		.res_type = RPMPD_##r_type,				\
>>   		.res_id = r_id,						\
>>   		.key = KEY_FLOOR_CORNER,				\
>>   	}
>>   -#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id)			\
>> -	DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
>> -
>> -#define DEFINE_RPMPD_VFC_LDOA(_platform, _name, r_id)			\
>> -	DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_LDOA)
>> -
>>   struct rpmpd_req {
>>   	__le32 key;
>>   	__le32 nbytes;
>> @@ -96,12 +91,12 @@ struct rpmpd_desc {
>>   static DEFINE_MUTEX(rpmpd_lock);
>>     /* msm8996 RPM Power domains */
>> -DEFINE_RPMPD_CORNER_SMPA(msm8996, vddcx, vddcx_ao, 1);
>> -DEFINE_RPMPD_CORNER_SMPA(msm8996, vddmx, vddmx_ao, 2);
>> -DEFINE_RPMPD_CORNER_LDOA(msm8996, vddsscx, 26);
>> +DEFINE_RPMPD_PAIR(msm8996, vddcx, vddcx_ao, SMPA, CORNER, 1);
>> +DEFINE_RPMPD_PAIR(msm8996, vddmx, vddmx_ao, SMPA, CORNER, 2);
>> +DEFINE_RPMPD_CORNER(msm8996, vddsscx, LDOA, 26);
>>   -DEFINE_RPMPD_VFC_SMPA(msm8996, vddcx_vfc, 1);
>> -DEFINE_RPMPD_VFC_LDOA(msm8996, vddsscx_vfc, 26);
>> +DEFINE_RPMPD_VFC(msm8996, vddcx_vfc, SMPA, 1);
>> +DEFINE_RPMPD_VFC(msm8996, vddsscx_vfc, LDOA, 26);
>>     static struct rpmpd *msm8996_rpmpds[] = {
>>   	[MSM8996_VDDCX] =	&msm8996_vddcx,
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v5 0/3] UFS on APQ8098/MSM8998
      [irrelevant] <43768d77-80b7-9cdc-b6e0-08ec4a026c21@free.fr>
@ 2019-03-28  9:37 ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-28  9:37 UTC (permalink / raw)
  To: Marc Gonzalez
  Cc: MSM, SCSI, Jeffrey Hugo, Bjorn Andersson, Andy Gross,
	David Brown, Alim Akhtar, Avri Altman, Pedro Sousa, LKML,
	Lee Jones, linux-arm-msm-owner

On 2019-02-25 17:46, Marc Gonzalez wrote:
> Hello,
> 
> This series adds support for the UFS host controller on
> APQ8098/MSM8998-based boards.
> 
> This should be the final rev ;-)

Tested-by: Sibi Sankar <sibis@codeaurora.org>

> 
> Differences between v4 and v5:
> - Drop patches that have already been accepted or spun off
> 
> Differences between v3 and v4:
> - Rebase on top of -next
> - Pick up Douglas Anderson's UFSHC doc fix
> - Document 8998 UFSHC binding
> - Improve UFS PHY binding doc
> - Put the UFS DT patch at the end of the series
> 
> Difference between v2 and v3:
> - Add qcom,msm8998-qmp-ufs-phy compat string and match it in the PHY 
> driver
> - Drop vdd-hba-fixed-regulator
> - Write the reg addresses with full 32-bit width
> - Set regulator-allow-set-load only on the 3 rails used by UFS.
> - Revert the patch introducing ufshcd_set_vccq_rail_unused
> 
> Difference between v1 and v2:
> - New patch to add 'regulator-allow-set-load' prop to all vreg nodes
> - Rename rpmcc node to 'clock-controller' + Add Review tags
> - Drop UFS pinctrl gymnastics (not required, probably left enabled in
> bootloader)
> - Delete GCC_UFS_ICE_CORE_CLK (ICE not used upstream, I think)
> - Fix sizes of ufsphy register areas based on Jeffrey's feedback
> - Hack ufshcd_set_vccq_rail_unused into a NOP to work around lock up + 
> reboot
> 
> 
> Marc Gonzalez (3):
>   dt-bindings: ufs: Add msm8998 compatible string
>   arm64: dts: qcom: msm8998: Allow UFSHC driver to set-load
>   arm64: dts: qcom: msm8998: Add UFS nodes
> 
>  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt |  1 +
>  arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi     | 22 +++++++
>  arch/arm64/boot/dts/qcom/msm8998.dtsi         | 65 +++++++++++++++++++
>  3 files changed, 88 insertions(+)

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 13%]

* [PATCH RFC 0/9] Add CPU based scaling support to Passive governor
@ 2019-03-28 15:28 Sibi Sankar
  2019-03-28 15:28 ` [PATCH RFC 1/9] OPP: Add and export helpers to get avg/peak bw Sibi Sankar
                   ` (9 more replies)
  0 siblings, 10 replies; 200+ results
From: Sibi Sankar @ 2019-03-28 15:28 UTC (permalink / raw)
  To: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm-owner, devicetree, rnayak, cw00.choi, linux-pm,
	evgreen, daidavid1, dianders, Sibi Sankar

This RFC series aims to add cpu based scaling support to the passive
governor and scale DDR with a generic interconnect bandwidth based
devfreq driver on SDM845 SoC. This series achieves similar functionality
to Georgi's Patch series (https://patchwork.kernel.org/cover/10850817/)
and can be used with MSM8916/MSM8996/QCS404 SoCs.

[patches 1,6 - Add and export export helpers to get avg/peak bandwidth and
 update voltage of an disabled opp respectively]

[patch 3 - Adds cpu based scaling support to passive governor]
To achieve this, it listens to CPU frequency transition notifiers
to keep itself up to date on the current CPU frequency.
To decide the frequency of the device, the governor depends one of
the following:
* Constructs a CPU frequency to device frequency mapping table from
  required-opps property of the devfreq device's opp_table
* Scales the device frequency in proportion to the CPU frequency by
  performing interpolation.

[patch 7 - Parses and updates opps from the frequency/voltage read from
 the look up tables]

The patch series depends on opp-bw-MBs bindings introduced in:
https://patchwork.kernel.org/cover/10850817/

Saravana Kannan (2):
  PM / devfreq: Add cpu based scaling support to passive_governor
  PM / devfreq: Add devfreq driver for interconnect bandwidth voting

Sibi Sankar (7):
  OPP: Add and export helpers to get avg/peak bw
  OPP: Export a number of helpers to prevent code duplication
  dt-bindings: devfreq: Add bindings for devfreq dev-icbw driver
  OPP: Add and export helper to update voltage
  cpufreq: qcom: Add support to update cpu node's OPP tables
  arm64: dts: qcom: sdm845: Add cpu OPP tables
  arm64: dts: qcom: sdm845: Add nodes for icbw driver and opp tables

 .../devicetree/bindings/devfreq/icbw.txt      | 146 +++++++++
 arch/arm64/boot/dts/qcom/sdm845.dtsi          | 262 +++++++++++++++++
 drivers/cpufreq/qcom-cpufreq-hw.c             |  29 +-
 drivers/devfreq/Kconfig                       |  19 ++
 drivers/devfreq/Makefile                      |   1 +
 drivers/devfreq/devfreq_icbw.c                | 132 +++++++++
 drivers/devfreq/governor_passive.c            | 276 +++++++++++++++++-
 drivers/opp/core.c                            | 100 +++++++
 drivers/opp/of.c                              |  13 +-
 include/linux/devfreq.h                       |  43 ++-
 include/linux/pm_opp.h                        |  35 +++
 11 files changed, 1044 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/devfreq/icbw.txt
 create mode 100644 drivers/devfreq/devfreq_icbw.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 13%]

* [PATCH RFC 1/9] OPP: Add and export helpers to get avg/peak bw
  2019-03-28 15:28 [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
@ 2019-03-28 15:28 ` Sibi Sankar
  2019-03-28 15:28 ` [PATCH RFC 2/9] OPP: Export a number of helpers to prevent code duplication Sibi Sankar
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-28 15:28 UTC (permalink / raw)
  To: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm-owner, devicetree, rnayak, cw00.choi, linux-pm,
	evgreen, daidavid1, dianders, Sibi Sankar

Add and export helpers 'dev_pm_opp_get_avg_bw()' and
'dev_pm_opp_get_peak_bw()' that can be used to get the
average and peak bandwidth values read from device tree
when present.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/opp/core.c     | 38 ++++++++++++++++++++++++++++++++++++++
 include/linux/pm_opp.h | 12 ++++++++++++
 2 files changed, 50 insertions(+)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 4fcc2b9259c5..addaf7aae9ae 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -149,6 +149,44 @@ unsigned int dev_pm_opp_get_level(struct dev_pm_opp *opp)
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_get_level);
 
+/**
+ * dev_pm_opp_get_avg_bw() - Gets the average bandwidth corresponding to an
+ * available opp
+ * @opp:	opp for which average bandwidth has to be returned for
+ *
+ * Return: average bandwidth read from device tree corresponding to the
+ * opp, else return 0.
+ */
+unsigned int dev_pm_opp_get_avg_bw(struct dev_pm_opp *opp)
+{
+	if (IS_ERR_OR_NULL(opp) || !opp->available) {
+		pr_err("%s: Invalid parameters\n", __func__);
+		return 0;
+	}
+
+	return opp->bandwidth->avg;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_avg_bw);
+
+/**
+ * dev_pm_opp_get_peak_bw() - Gets the peak bandwidth corresponding to an
+ * available opp
+ * @opp:	opp for which peak bandwidth has to be returned for
+ *
+ * Return: peak bandwidth read from device tree corresponding to the
+ * opp, else return 0.
+ */
+unsigned int dev_pm_opp_get_peak_bw(struct dev_pm_opp *opp)
+{
+	if (IS_ERR_OR_NULL(opp) || !opp->available) {
+		pr_err("%s: Invalid parameters\n", __func__);
+		return 0;
+	}
+
+	return opp->bandwidth->peak;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_peak_bw);
+
 /**
  * dev_pm_opp_is_turbo() - Returns if opp is turbo OPP or not
  * @opp: opp for which turbo mode is being verified
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 80a49d1fa9a8..82ff8e2e1ff7 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -99,6 +99,8 @@ unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp);
 unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp);
 
 unsigned int dev_pm_opp_get_level(struct dev_pm_opp *opp);
+unsigned int dev_pm_opp_get_avg_bw(struct dev_pm_opp *opp);
+unsigned int dev_pm_opp_get_peak_bw(struct dev_pm_opp *opp);
 
 bool dev_pm_opp_is_turbo(struct dev_pm_opp *opp);
 
@@ -179,6 +181,16 @@ static inline unsigned int dev_pm_opp_get_level(struct dev_pm_opp *opp)
 	return 0;
 }
 
+static inline unsigned int dev_pm_opp_get_avg_bw(struct dev_pm_opp *opp)
+{
+	return 0;
+}
+
+static inline unsigned int dev_pm_opp_get_peak_bw(struct dev_pm_opp *opp)
+{
+	return 0;
+}
+
 static inline bool dev_pm_opp_is_turbo(struct dev_pm_opp *opp)
 {
 	return false;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 19%]

* [PATCH RFC 2/9] OPP: Export a number of helpers to prevent code duplication
  2019-03-28 15:28 [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
  2019-03-28 15:28 ` [PATCH RFC 1/9] OPP: Add and export helpers to get avg/peak bw Sibi Sankar
@ 2019-03-28 15:28 ` Sibi Sankar
  2019-07-08  3:28   ` Hsin-Yi Wang
  2019-03-28 15:28 ` [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor Sibi Sankar
                   ` (7 subsequent siblings)
  9 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-28 15:28 UTC (permalink / raw)
  To: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm-owner, devicetree, rnayak, cw00.choi, linux-pm,
	evgreen, daidavid1, dianders, Sibi Sankar

Export 'dev_pm_opp_find_opp_of_np' and 'of_parse_required_nodes'
as it will be used by passive governor to parse and auto-populate
mapping specified using the required-opps property.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/opp/of.c       | 13 +++++++++++--
 include/linux/pm_opp.h | 13 +++++++++++++
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 539f3d013a59..d9d8875eca05 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -98,8 +98,8 @@ static struct dev_pm_opp *_find_opp_of_np(struct opp_table *opp_table,
 	return NULL;
 }
 
-static struct device_node *of_parse_required_opp(struct device_node *np,
-						 int index)
+struct device_node *of_parse_required_opp(struct device_node *np,
+					  int index)
 {
 	struct device_node *required_np;
 
@@ -111,6 +111,15 @@ static struct device_node *of_parse_required_opp(struct device_node *np,
 
 	return required_np;
 }
+EXPORT_SYMBOL_GPL(of_parse_required_opp);
+
+/* The caller must call dev_pm_opp_put() after the OPP is used */
+struct dev_pm_opp *dev_pm_opp_find_opp_of_np(struct opp_table *opp_table,
+					     struct device_node *opp_np)
+{
+	return _find_opp_of_np(opp_table, opp_np);
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_find_opp_of_np);
 
 /* The caller must call dev_pm_opp_put_opp_table() after the table is used */
 static struct opp_table *_find_table_of_opp_np(struct device_node *opp_np)
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 82ff8e2e1ff7..d7cb0e65c4f0 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -359,8 +359,11 @@ void dev_pm_opp_of_cpumask_remove_table(const struct cpumask *cpumask);
 int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask);
 struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
 struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
+struct device_node *of_parse_required_opp(struct device_node *np, int index);
 int of_get_required_opp_performance_state(struct device_node *np, int index);
 void dev_pm_opp_of_register_em(struct cpumask *cpus);
+struct dev_pm_opp *dev_pm_opp_find_opp_of_np(struct opp_table *opp_table,
+					     struct device_node *opp_np);
 #else
 static inline int dev_pm_opp_of_add_table(struct device *dev)
 {
@@ -390,6 +393,11 @@ static inline int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct
 	return -ENOTSUPP;
 }
 
+static inline struct dev_pm_opp *dev_pm_opp_find_opp_of_np(struct opp_table *opp_table, struct device_node *opp_np)
+{
+	return ERR_PTR(-ENOTSUPP);
+}
+
 static inline struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
 {
 	return NULL;
@@ -408,6 +416,11 @@ static inline int of_get_required_opp_performance_state(struct device_node *np,
 {
 	return -ENOTSUPP;
 }
+
+static inline struct device_node *of_parse_required_opp(struct device_node *np, int index)
+{
+	return NULL;
+}
 #endif
 
 #endif		/* __LINUX_OPP_H__ */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 19%]

* [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor
  2019-03-28 15:28 [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
  2019-03-28 15:28 ` [PATCH RFC 1/9] OPP: Add and export helpers to get avg/peak bw Sibi Sankar
  2019-03-28 15:28 ` [PATCH RFC 2/9] OPP: Export a number of helpers to prevent code duplication Sibi Sankar
@ 2019-03-28 15:28 ` Sibi Sankar
  2019-04-12  7:39   ` Chanwoo Choi
  2019-03-28 15:28 ` [PATCH RFC 4/9] dt-bindings: devfreq: Add bindings for devfreq dev-icbw driver Sibi Sankar
                   ` (6 subsequent siblings)
  9 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-28 15:28 UTC (permalink / raw)
  To: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm-owner, devicetree, rnayak, cw00.choi, linux-pm,
	evgreen, daidavid1, dianders, Saravana Kannan, Sibi Sankar

From: Saravana Kannan <skannan@codeaurora.org>

Many CPU architectures have caches that can scale independent of the
CPUs. Frequency scaling of the caches is necessary to make sure the cache
is not a performance bottleneck that leads to poor performance and
power. The same idea applies for RAM/DDR.

To achieve this, this patch add support for cpu based scaling to the
passive governor. This is accomplished by taking the current frequency
of each CPU frequency domain and then adjusts the frequency of the cache
(or any devfreq device) based on the frequency of the CPUs. It listens
to CPU frequency transition notifiers to keep itself up to date on the
current CPU frequency.

To decide the frequency of the device, the governor does one of the
following:
* Constructs a CPU frequency to device frequency mapping table from
  required-opps property of the devfreq device's opp_table

* Scales the device frequency in proportion to the CPU frequency. So, if
  the CPUs are running at their max frequency, the device runs at its
  max frequency. If the CPUs are running at their min frequency, the
  device runs at its min frequency. It is interpolated for frequencies
  in between.

Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
[Sibi: Integrated cpu-freqmap governor into passive_governor]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/devfreq/Kconfig            |   4 +
 drivers/devfreq/governor_passive.c | 276 ++++++++++++++++++++++++++++-
 include/linux/devfreq.h            |  43 ++++-
 3 files changed, 315 insertions(+), 8 deletions(-)

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 6a172d338f6d..9a45f464a56b 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -72,6 +72,10 @@ config DEVFREQ_GOV_PASSIVE
 	  device. This governor does not change the frequency by itself
 	  through sysfs entries. The passive governor recommends that
 	  devfreq device uses the OPP table to get the frequency/voltage.
+	  Alternatively the governor can also be chosen to scale based on
+	  the online CPUs current frequency. A CPU frequency to device
+	  frequency mapping table(s) is auto-populated by the governor
+	  for this purpose.
 
 comment "DEVFREQ Drivers"
 
diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
index 3bc29acbd54e..2506682b233b 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -11,10 +11,63 @@
  */
 
 #include <linux/module.h>
+#include <linux/cpu.h>
+#include <linux/cpufreq.h>
+#include <linux/cpumask.h>
 #include <linux/device.h>
 #include <linux/devfreq.h>
+#include <linux/of.h>
+#include <linux/slab.h>
 #include "governor.h"
 
+static unsigned int xlate_cpufreq_to_devfreq(struct devfreq_passive_data *data,
+					     unsigned int cpu)
+{
+	unsigned int cpu_min, cpu_max;
+	struct devfreq *devfreq = (struct devfreq *)data->this;
+	unsigned int dev_min, dev_max, cpu_percent, cpu_freq = 0, freq = 0;
+	unsigned long *freq_table = devfreq->profile->freq_table;
+	struct device *dev = devfreq->dev.parent;
+	struct devfreq_map *map;
+	int opp_cnt, i;
+
+	if (!data->state[cpu] || data->state[cpu]->first_cpu != cpu) {
+		freq = 0;
+		goto out;
+	}
+
+	/* Use Interpolation if map is not available */
+	cpu_freq = data->state[cpu]->freq;
+	if (!data->map) {
+		cpu_min = data->state[cpu]->min_freq;
+		cpu_max = data->state[cpu]->max_freq;
+		if (freq_table) {
+			dev_min = freq_table[0];
+			dev_max = freq_table[devfreq->profile->max_state - 1];
+		} else {
+			if (devfreq->max_freq <= devfreq->min_freq)
+				return 0;
+			dev_min = devfreq->min_freq;
+			dev_max = devfreq->max_freq;
+		}
+
+		cpu_percent = ((cpu_freq - cpu_min) * 100) / cpu_max - cpu_min;
+		freq = dev_min + mult_frac(dev_max - dev_min, cpu_percent, 100);
+		goto out;
+	}
+
+	map = data->map[cpu];
+	opp_cnt = dev_pm_opp_get_opp_count(dev);
+	for (i = 0; i < opp_cnt; i++) {
+		freq = max(freq, map[i].dev_hz);
+		if (map[i].cpu_khz >= cpu_freq)
+			break;
+	}
+out:
+	dev_dbg(dev, "CPU%u: %d -> dev: %u\n", cpu, cpu_freq, freq);
+	return freq;
+}
+
 static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
 					unsigned long *freq)
 {
@@ -23,6 +76,7 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
 	struct devfreq *parent_devfreq = (struct devfreq *)p_data->parent;
 	unsigned long child_freq = ULONG_MAX;
 	struct dev_pm_opp *opp;
+	unsigned int cpu, tgt_freq = 0;
 	int i, count, ret = 0;
 
 	/*
@@ -35,6 +89,14 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
 		goto out;
 	}
 
+	if (p_data->cpufreq_type) {
+		for_each_possible_cpu(cpu)
+			tgt_freq = max(tgt_freq,
+				       xlate_cpufreq_to_devfreq(p_data, cpu));
+		*freq = tgt_freq;
+		goto out;
+	}
+
 	/*
 	 * If the parent and passive devfreq device uses the OPP table,
 	 * get the next frequency by using the OPP table.
@@ -149,6 +211,200 @@ static int devfreq_passive_notifier_call(struct notifier_block *nb,
 	return NOTIFY_DONE;
 }
 
+static int cpufreq_passive_notifier_call(struct notifier_block *nb,
+					 unsigned long event, void *ptr)
+{
+	struct devfreq_passive_data *data =
+			container_of(nb, struct devfreq_passive_data, nb);
+	struct devfreq *devfreq = (struct devfreq *)data->this;
+	struct cpufreq_freqs *freq = ptr;
+	struct devfreq_cpu_state *state;
+	int ret = 0;
+
+	if (event != CPUFREQ_POSTCHANGE)
+		goto out;
+
+	state = data->state[freq->cpu];
+	if (!state)
+		goto out;
+
+	if (state->freq != freq->new) {
+		state->freq = freq->new;
+		mutex_lock(&devfreq->lock);
+		ret = update_devfreq(devfreq);
+		mutex_unlock(&devfreq->lock);
+		if (ret)
+			dev_err(&devfreq->dev, "Frequency update failed.\n");
+	}
+out:
+	return ret;
+}
+
+static int cpufreq_passive_register(struct devfreq_passive_data **p_data)
+{
+	unsigned int cpu;
+	struct devfreq_map **cpu_map;
+	struct devfreq_map *map, *per_cpu_map;
+	struct devfreq_passive_data *data = *p_data;
+	struct devfreq *devfreq = (struct devfreq *)data->this;
+	int i, count = 0, opp_cnt = 0, ret = 0, iter_val = 0;
+	struct device_node *np, *opp_table_np, *cpu_np;
+	struct opp_table *opp_table, *cpu_opp_tbl;
+	struct device *dev = devfreq->dev.parent;
+	struct devfreq_cpu_state *state;
+	struct dev_pm_opp *opp, *cpu_opp;
+	struct cpufreq_policy *policy;
+	struct device *cpu_dev;
+	u64 cpu_khz, dev_hz;
+
+	get_online_cpus();
+	data->nb.notifier_call = cpufreq_passive_notifier_call;
+	ret = cpufreq_register_notifier(&data->nb,
+					CPUFREQ_TRANSITION_NOTIFIER);
+	if (ret)
+		return ret;
+
+	/* Populate devfreq_cpu_state */
+	for_each_online_cpu(cpu) {
+		if (data->state[cpu])
+			continue;
+
+		policy = cpufreq_cpu_get(cpu);
+		if (policy) {
+			state = kzalloc(sizeof(*state), GFP_KERNEL);
+			if (!state)
+				return -ENOMEM;
+
+			state->first_cpu = cpumask_first(policy->related_cpus);
+			state->freq = policy->cur;
+			state->min_freq = policy->cpuinfo.min_freq;
+			state->max_freq = policy->cpuinfo.max_freq;
+			data->state[cpu] = state;
+			cpufreq_cpu_put(policy);
+		} else {
+			return -EPROBE_DEFER;
+		}
+	}
+
+	opp_table_np = dev_pm_opp_of_get_opp_desc_node(dev);
+	if (!opp_table_np)
+		goto out;
+
+	opp_cnt = dev_pm_opp_get_opp_count(dev);
+	if (opp_cnt <= 0)
+		goto put_opp_table;
+
+	/* Allocate memory for devfreq_map*/
+	cpu_map = kcalloc(num_possible_cpus(), sizeof(*cpu_map), GFP_KERNEL);
+	if (!cpu_map)
+		return -ENOMEM;
+
+	for_each_possible_cpu(cpu) {
+		per_cpu_map = kcalloc(opp_cnt, sizeof(*per_cpu_map),
+				      GFP_KERNEL);
+		if (!per_cpu_map)
+			return -ENOMEM;
+		cpu_map[cpu] = per_cpu_map;
+	}
+	data->map = cpu_map;
+
+	/* Populate devfreq_map */
+	opp_table = dev_pm_opp_get_opp_table(dev);
+	if (!opp_table)
+		return -ENOMEM;
+
+	for_each_available_child_of_node(opp_table_np, np) {
+		opp = dev_pm_opp_find_opp_of_np(opp_table, np);
+		if (IS_ERR(opp))
+			continue;
+
+		dev_hz = dev_pm_opp_get_freq(opp);
+		dev_pm_opp_put(opp);
+
+		count = of_count_phandle_with_args(np, "required-opps", NULL);
+		for (i = 0; i < count; i++) {
+			for_each_possible_cpu(cpu) {
+				cpu_dev = get_cpu_device(cpu);
+				if (!cpu_dev) {
+					dev_err(dev, "CPU get device failed.\n");
+					continue;
+				}
+
+				cpu_np = of_parse_required_opp(np, i);
+				if (!cpu_np) {
+					dev_err(dev, "Parsing required opp failed.\n");
+					continue;
+				}
+
+				/* Get cpu opp-table */
+				cpu_opp_tbl = dev_pm_opp_get_opp_table(cpu_dev);
+				if (!cpu_opp_tbl) {
+					dev_err(dev, "CPU opp table get failed.\n");
+					goto put_cpu_node;
+				}
+
+				/* Match the cpu opp node from required-opp with
+				 * the cpu-opp table */
+				cpu_opp = dev_pm_opp_find_opp_of_np(cpu_opp_tbl,
+								    cpu_np);
+				if (!cpu_opp) {
+					dev_dbg(dev, "CPU opp get failed.\n");
+					goto put_cpu_opp_table;
+				}
+
+				cpu_khz = dev_pm_opp_get_freq(cpu_opp);
+				if (cpu_opp && cpu_khz) {
+					/* Update freq-map if not already set */
+					map = cpu_map[cpu];
+					map[iter_val].cpu_khz = cpu_khz / 1000;
+					map[iter_val].dev_hz = dev_hz;
+				}
+				dev_pm_opp_put(cpu_opp);
+put_cpu_opp_table:
+				dev_pm_opp_put_opp_table(cpu_opp_tbl);
+put_cpu_node:
+				of_node_put(cpu_np);
+			}
+		}
+		iter_val++;
+	}
+	dev_pm_opp_put_opp_table(opp_table);
+put_opp_table:
+	of_node_put(opp_table_np);
+out:
+	put_online_cpus();
+
+	/* Update devfreq */
+	mutex_lock(&devfreq->lock);
+	ret = update_devfreq(devfreq);
+	mutex_unlock(&devfreq->lock);
+	if (ret)
+		dev_err(dev, "Frequency update failed.\n");
+
+	return ret;
+}
+
+static int cpufreq_passive_unregister(struct devfreq_passive_data **p_data)
+{
+	int cpu;
+	struct devfreq_passive_data *data = *p_data;
+
+	cpufreq_unregister_notifier(&data->nb,
+				    CPUFREQ_TRANSITION_NOTIFIER);
+
+	for_each_possible_cpu(cpu) {
+		kfree(data->state[cpu]);
+		kfree(data->map[cpu]);
+		data->state[cpu] = NULL;
+		data->map[cpu] = NULL;
+	}
+
+	kfree(data->map);
+	data->map = NULL;
+
+	return 0;
+}
+
 static int devfreq_passive_event_handler(struct devfreq *devfreq,
 				unsigned int event, void *data)
 {
@@ -159,7 +415,7 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
 	struct notifier_block *nb = &p_data->nb;
 	int ret = 0;
 
-	if (!parent)
+	if (!parent && !p_data->cpufreq_type)
 		return -EPROBE_DEFER;
 
 	switch (event) {
@@ -167,13 +423,21 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
 		if (!p_data->this)
 			p_data->this = devfreq;
 
-		nb->notifier_call = devfreq_passive_notifier_call;
-		ret = devm_devfreq_register_notifier(dev, parent, nb,
-					DEVFREQ_TRANSITION_NOTIFIER);
+		if (p_data->cpufreq_type) {
+			ret = cpufreq_passive_register(&p_data);
+		} else {
+			nb->notifier_call = devfreq_passive_notifier_call;
+			ret = devm_devfreq_register_notifier(dev, parent, nb,
+						DEVFREQ_TRANSITION_NOTIFIER);
+		}
 		break;
 	case DEVFREQ_GOV_STOP:
-		devm_devfreq_unregister_notifier(dev, parent, nb,
-					DEVFREQ_TRANSITION_NOTIFIER);
+		if (p_data->cpufreq_type) {
+			cpufreq_passive_unregister(&p_data);
+		} else {
+			devm_devfreq_unregister_notifier(dev, parent, nb,
+						DEVFREQ_TRANSITION_NOTIFIER);
+		}
 		break;
 	default:
 		break;
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index fbffa74bfc1b..e8235fbe49e6 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -265,6 +265,38 @@ struct devfreq_simple_ondemand_data {
 #endif
 
 #if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
+/**
+ * struct devfreq_cpu_state - holds the per-cpu state
+ * @freq:	holds the current frequency of the cpu.
+ * @min_freq:	holds the min frequency of the cpu.
+ * @max_freq:	holds the max frequency of the cpu.
+ * @first_cpu:	holds the cpumask of the first cpu of a policy.
+ *
+ * This structure stores the required cpu_state of a cpu.
+ * This is auto-populated by the governor.
+ */
+struct devfreq_cpu_state {
+	unsigned int freq;
+	unsigned int min_freq;
+	unsigned int max_freq;
+	unsigned int first_cpu;
+};
+
+/**
+ * struct devfreq_map - holds mapping from cpu frequency
+ * to devfreq frequency
+ * @cpu_khz:	holds the cpu frequency in Khz
+ * @dev_hz:	holds the devfreq device frequency in Hz
+ *
+ * This structure stores the lookup table between cpu
+ * and the devfreq device. This is auto-populated by the
+ * governor.
+ */
+struct devfreq_map {
+	unsigned int cpu_khz;
+	unsigned int dev_hz;
+};
+
 /**
  * struct devfreq_passive_data - void *data fed to struct devfreq
  *	and devfreq_add_device
@@ -278,11 +310,13 @@ struct devfreq_simple_ondemand_data {
  *			the next frequency, should use this callback.
  * @this:	the devfreq instance of own device.
  * @nb:		the notifier block for DEVFREQ_TRANSITION_NOTIFIER list
+ * @state:	holds the state min/max/current frequency of all online cpu's
+ * @map:	holds the maps between cpu frequency and device frequency
  *
  * The devfreq_passive_data have to set the devfreq instance of parent
  * device with governors except for the passive governor. But, don't need to
- * initialize the 'this' and 'nb' field because the devfreq core will handle
- * them.
+ * initialize the 'this', 'nb', 'state' and 'map' field because the devfreq
+ * core will handle them.
  */
 struct devfreq_passive_data {
 	/* Should set the devfreq instance of parent device */
@@ -291,9 +325,14 @@ struct devfreq_passive_data {
 	/* Optional callback to decide the next frequency of passvice device */
 	int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
 
+	/* Should be set if the devfreq device wants to be scaled with cpu*/
+	u8 cpufreq_type;
+
 	/* For passive governor's internal use. Don't need to set them */
 	struct devfreq *this;
 	struct notifier_block nb;
+	struct devfreq_cpu_state *state[NR_CPUS];
+	struct devfreq_map **map;
 };
 #endif
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 12%]

* [PATCH RFC 4/9] dt-bindings: devfreq: Add bindings for devfreq dev-icbw driver
  2019-03-28 15:28 [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
                   ` (2 preceding siblings ...)
  2019-03-28 15:28 ` [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor Sibi Sankar
@ 2019-03-28 15:28 ` Sibi Sankar
  2019-03-28 15:28 ` [PATCH RFC 5/9] PM / devfreq: Add devfreq driver for interconnect bandwidth voting Sibi Sankar
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-28 15:28 UTC (permalink / raw)
  To: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm-owner, devicetree, rnayak, cw00.choi, linux-pm,
	evgreen, daidavid1, dianders, Sibi Sankar

Add dt-bindings support for a generic interconnect bandwidth voting
devfreq driver.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 .../devicetree/bindings/devfreq/icbw.txt      | 146 ++++++++++++++++++
 1 file changed, 146 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/devfreq/icbw.txt

diff --git a/Documentation/devicetree/bindings/devfreq/icbw.txt b/Documentation/devicetree/bindings/devfreq/icbw.txt
new file mode 100644
index 000000000000..389aa77a2363
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/icbw.txt
@@ -0,0 +1,146 @@
+Interconnect bandwidth device
+
+icbw is a device that represents an interconnect path that connects two
+devices. This device is typically used to vote for BW requirements between
+two devices. Eg: CPU to DDR, GPU to DDR, etc. This device is expected to
+use passive govenor by default.
+
+Required properties:
+- compatible:		Must be "devfreq-icbw"
+- interconnects:	Pairs of phandles and interconnect provider specifier
+			to denote the edge source and destination ports of
+			the interconnect path. See also:
+		Documentation/devicetree/bindings/interconnect/interconnect.txt
+- operating-points-v2:	A phandle to an OPP v2 table that holds frequency,
+			bandwidth values (in MB/s) and required-opp's populated
+			with phandles pointing to the required per cpu opp. The
+			bandwidth (in MB/s) values depend on multiple properties
+			of the interconnect path like frequency, interconnect
+			width, etc.
+
+Example:
+
+cpus {
+	...
+
+	CPU0: cpu@0 {
+		...
+		operating-points-v2 = <&cpu0_opp_table>;
+		...
+	};
+
+	CPU1: cpu@100 {
+		...
+		operating-points-v2 = <&cpu0_opp_table>;
+		...
+	};
+
+	CPU2: cpu@200 {
+		...
+		operating-points-v2 = <&cpu0_opp_table>;
+		...
+	};
+
+	CPU3: cpu@300 {
+		...
+		operating-points-v2 = <&cpu0_opp_table>;
+		...
+	};
+
+	CPU4: cpu@400 {
+		...
+		operating-points-v2 = <&cpu4_opp_table>;
+		...
+	};
+
+	CPU5: cpu@500 {
+		...
+		operating-points-v2 = <&cpu4_opp_table>;
+		...
+	};
+
+	CPU6: cpu@600 {
+		...
+		operating-points-v2 = <&cpu4_opp_table>;
+		...
+	};
+
+	CPU7: cpu@700 {
+		...
+		operating-points-v2 = <&cpu4_opp_table>;
+		...
+	};
+};
+
+cpu0_opp_table: cpu0_opp_table {
+	compatible = "operating-points-v2";
+	opp-shared;
+
+	cpu0_opp1: opp-300000000 {
+		opp-hz = /bits/ 64 <300000000>;
+	};
+
+	...
+
+	cpu0_opp16: opp-1612800000 {
+		opp-hz = /bits/ 64 <1612800000>;
+	};
+
+	...
+};
+
+cpu4_opp_table: cpu4_opp_table {
+	compatible = "operating-points-v2";
+	opp-shared;
+
+	...
+
+	cpu4_opp4: opp-1056000000 {
+		opp-hz = /bits/ 64 <1056000000>;
+	};
+
+	cpu4_opp5: opp-1209600000 {
+		opp-hz = /bits/ 64 <1209600000>;
+	};
+
+	...
+};
+
+bw_opp_table: bw-opp-table {
+	compatible = "operating-points-v2";
+
+	opp-200  {
+		opp-hz = /bits/ 64 < 200000000 >; /* 200 MHz */
+		required-opps = <&cpu0_opp1>;
+		/* 0 MB/s average and 762 MB/s peak bandwidth */
+		opp-bw-MBs = <0 762>;
+	};
+
+	opp-300 {
+		opp-hz = /bits/ 64 < 300000000 >; /* 300 MHz */
+		/* 0 MB/s average and 1144 MB/s peak bandwidth */
+		opp-bw-MBs = <0 1144>;
+	};
+
+	...
+
+	opp-768 {
+		opp-hz = /bits/ 64 < 768000000 >; /* 768 MHz */
+		/* 0 MB/s average and 2929 MB/s peak bandwidth */
+		opp-bw-MBs = <0 2929>;
+		required-opps = <&cpu4_opp4>;
+	};
+
+	opp-1017 {
+		opp-hz = /bits/ 64 < 1017000000 >; /* 1017 MHz */
+		/* 0 MB/s average and 3879 MB/s peak bandwidth */
+		opp-bw-MBs = <0 3879>;
+		required-opps = <&cpu0_opp16>, <&cpu4_opp5>;
+	};
+};
+
+cpubw {
+	compatible = "devfreq-icbw";
+	interconnects = <&snoc MASTER_APSS_1 &bimc SLAVE_EBI_CH0>;
+	operating-points-v2 = <&bw_opp_table>;
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 18%]

* [PATCH RFC 5/9] PM / devfreq: Add devfreq driver for interconnect bandwidth voting
  2019-03-28 15:28 [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
                   ` (3 preceding siblings ...)
  2019-03-28 15:28 ` [PATCH RFC 4/9] dt-bindings: devfreq: Add bindings for devfreq dev-icbw driver Sibi Sankar
@ 2019-03-28 15:28 ` Sibi Sankar
  2019-03-28 15:28 ` [PATCH RFC 6/9] OPP: Add and export helper to update voltage Sibi Sankar
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-28 15:28 UTC (permalink / raw)
  To: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm-owner, devicetree, rnayak, cw00.choi, linux-pm,
	evgreen, daidavid1, dianders, Saravana Kannan, Sibi Sankar

From: Saravana Kannan <skannan@codeaurora.org>

This driver registers itself as a devfreq device that allows devfreq
governors to make bandwidth votes for an interconnect path. This allows
applying various policies for different interconnect paths using devfreq
governors.

Example uses:
* Use the devfreq performance governor to set the CPU to DDR
  interconnect path for maximum performance.
* Use the devfreq powersave governor to set the GPU to DDR
  interconnect path for minimum performance.
* Use the Passive governor to scale the DDR frequency based
  on the needs of the CPUs' current frequency

Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
[Sibi: cleanup and added passive governor support]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/devfreq/Kconfig        |  15 ++++
 drivers/devfreq/Makefile       |   1 +
 drivers/devfreq/devfreq_icbw.c | 132 +++++++++++++++++++++++++++++++++
 3 files changed, 148 insertions(+)
 create mode 100644 drivers/devfreq/devfreq_icbw.c

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 9a45f464a56b..0df5b65f157a 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -117,6 +117,21 @@ config ARM_RK3399_DMC_DEVFREQ
           It sets the frequency for the memory controller and reads the usage counts
           from hardware.
 
+config DEVFREQ_ICBW
+	tristate "Driver for making bandwidth votes on interconnect paths"
+	select DEVFREQ_GOV_PASSIVE
+	select DEVFREQ_GOV_PERFORMANCE
+	select DEVFREQ_GOV_POWERSAVE
+	select DEVFREQ_GOV_USERSPACE
+	depends on INTERCONNECT
+	default n
+	help
+	  Different devfreq governors use this devfreq device to make
+	  bandwidth votes for interconnect paths between different devices
+	  (Eg: CPU to DDR, GPU to DDR, etc). This driver provides a generic
+	  interface so that the devfreq governors can be shared across SoCs
+	  and architectures.
+
 source "drivers/devfreq/event/Kconfig"
 
 endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 32b8d4d3f12c..66591b0e5259 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE)	+= governor_passive.o
 obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)	+= exynos-bus.o
 obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ)	+= rk3399_dmc.o
 obj-$(CONFIG_ARM_TEGRA_DEVFREQ)		+= tegra-devfreq.o
+obj-$(CONFIG_DEVFREQ_ICBW)		+= devfreq_icbw.o
 
 # DEVFREQ Event Drivers
 obj-$(CONFIG_PM_DEVFREQ_EVENT)		+= event/
diff --git a/drivers/devfreq/devfreq_icbw.c b/drivers/devfreq/devfreq_icbw.c
new file mode 100644
index 000000000000..c552cf4218c8
--- /dev/null
+++ b/drivers/devfreq/devfreq_icbw.c
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include <linux/devfreq.h>
+#include <linux/interconnect.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+struct icbw_data {
+	struct devfreq *df;
+	struct icc_path *path;
+	u32 cur_ab;
+	u32 cur_pb;
+};
+
+static int icbw_target(struct device *dev, unsigned long *freq, u32 flags)
+{
+	struct dev_pm_opp *opp;
+	struct icbw_data *data = dev_get_drvdata(dev);
+	u32 new_pb, new_ab;
+	int ret;
+
+	opp = devfreq_recommended_opp(dev, freq, flags);
+	if (IS_ERR(opp))
+		return PTR_ERR(opp);
+
+	/* Get avg and peak bandwidth */
+	new_ab = dev_pm_opp_get_avg_bw(opp);
+	new_pb = dev_pm_opp_get_peak_bw(opp);
+	dev_pm_opp_put(opp);
+
+	if (data->cur_pb == new_pb && data->cur_ab == new_ab)
+		return 0;
+
+	dev_dbg(dev, "BW icc: AB: %u PB: %u\n", new_ab, new_pb);
+
+	ret = icc_set_bw(data->path, new_ab, new_pb);
+	if (ret) {
+		dev_err(dev, "bandwidth request failed (%d)\n", ret);
+	} else {
+		data->cur_pb = new_pb;
+		data->cur_ab = new_ab;
+	}
+
+	return ret;
+}
+
+static int devfreq_icbw_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct devfreq_dev_profile *profile;
+	struct devfreq_passive_data *passive_data;
+	struct icbw_data *data;
+	int ret;
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+	dev_set_drvdata(dev, data);
+
+	passive_data = devm_kzalloc(dev, sizeof(*passive_data), GFP_KERNEL);
+	if (!passive_data)
+		return -ENOMEM;
+
+	passive_data->cpufreq_type = true;
+
+	profile = devm_kzalloc(dev, sizeof(*profile), GFP_KERNEL);
+	if (!profile)
+		return -ENOMEM;
+
+	profile->target = icbw_target;
+
+	data->path = of_icc_get(dev, NULL);
+	if (IS_ERR(data->path)) {
+		dev_err(dev, "Unable to register interconnect path\n");
+		return PTR_ERR(data->path);
+	}
+
+	ret = dev_pm_opp_of_add_table(dev);
+	if (ret) {
+		dev_err(dev, "Couldn't find OPP table\n");
+		goto err_icc;
+	}
+
+	data->df = devfreq_add_device(dev, profile,
+				      DEVFREQ_GOV_PASSIVE, passive_data);
+	if (IS_ERR(data->df)) {
+		ret = PTR_ERR(data->df);
+		goto err_opp_table;
+	}
+
+	return 0;
+
+err_opp_table:
+	dev_pm_opp_of_remove_table(dev);
+err_icc:
+	icc_put(data->path);
+	return ret;
+}
+
+static int devfreq_icbw_remove(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct icbw_data *data = dev_get_drvdata(dev);
+
+	devfreq_remove_device(data->df);
+	icc_put(data->path);
+	return 0;
+}
+
+static const struct of_device_id icbw_match_table[] = {
+	{ .compatible = "devfreq-icbw" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, icbw_match_table);
+
+static struct platform_driver icbw_driver = {
+	.probe = devfreq_icbw_probe,
+	.remove = devfreq_icbw_remove,
+	.driver = {
+		.name = "devfreq-icbw",
+		.of_match_table = icbw_match_table,
+	},
+};
+module_platform_driver(icbw_driver);
+
+MODULE_DESCRIPTION("Interconnect bandwidth voting driver");
+MODULE_LICENSE("GPL v2");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 17%]

* [PATCH RFC 6/9] OPP: Add and export helper to update voltage
  2019-03-28 15:28 [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
                   ` (4 preceding siblings ...)
  2019-03-28 15:28 ` [PATCH RFC 5/9] PM / devfreq: Add devfreq driver for interconnect bandwidth voting Sibi Sankar
@ 2019-03-28 15:28 ` Sibi Sankar
  2019-04-10 10:24   ` Viresh Kumar
  2019-03-28 15:28 ` [PATCH RFC 7/9] cpufreq: qcom: Add support to update cpu node's OPP tables Sibi Sankar
                   ` (3 subsequent siblings)
  9 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-28 15:28 UTC (permalink / raw)
  To: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm-owner, devicetree, rnayak, cw00.choi, linux-pm,
	evgreen, daidavid1, dianders, Sibi Sankar

Add and export 'dev_pm_opp_update_voltage' to find and update voltage
of an opp for a given frequency. This will be useful to update the opps
with voltages read back from firmware.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/opp/core.c     | 62 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/pm_opp.h | 10 +++++++
 2 files changed, 72 insertions(+)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index addaf7aae9ae..c066cd120a33 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -2090,6 +2090,68 @@ int dev_pm_opp_disable(struct device *dev, unsigned long freq)
 }
 EXPORT_SYMBOL_GPL(dev_pm_opp_disable);
 
+static int _opp_update_voltage(struct device *dev, unsigned long freq,
+			       unsigned long u_volt)
+{
+	struct opp_table *opp_table;
+	struct dev_pm_opp *tmp_opp, *opp = ERR_PTR(-ENODEV);
+	int r = 0;
+
+	/* Find the opp_table */
+	opp_table = _find_opp_table(dev);
+	if (IS_ERR(opp_table)) {
+		r = PTR_ERR(opp_table);
+		dev_warn(dev, "%s: Device OPP not found (%d)\n", __func__, r);
+		return r;
+	}
+
+	mutex_lock(&opp_table->lock);
+
+	/* Do we have the frequency? */
+	list_for_each_entry(tmp_opp, &opp_table->opp_list, node) {
+		if (tmp_opp->rate == freq) {
+			opp = tmp_opp;
+			break;
+		}
+	}
+
+	if (IS_ERR(opp)) {
+		r = PTR_ERR(opp);
+		goto unlock;
+	}
+
+	/* update only if the opp is disabled */
+	if (opp->available)
+		goto unlock;
+
+	opp->supplies[0].u_volt = u_volt;
+
+unlock:
+	mutex_unlock(&opp_table->lock);
+	dev_pm_opp_put_opp_table(opp_table);
+	return r;
+}
+
+/**
+ * dev_pm_opp_update_voltage() - find and update voltage of an opp
+ *				 for a given frequency
+ * @dev:	device for which we do this operation
+ * @freq:	OPP frequency to update voltage
+ * @u_volt:	voltage requested for this opp
+ *
+ * This is useful only for devices with single power supply.
+ *
+ * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the
+ * copy operation, returns 0 if no modification was done OR modification was
+ * successful.
+ */
+int dev_pm_opp_update_voltage(struct device *dev, unsigned long freq,
+			      unsigned long u_volt)
+{
+	return _opp_update_voltage(dev, freq, u_volt);
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_update_voltage);
+
 /**
  * dev_pm_opp_register_notifier() - Register OPP notifier for the device
  * @dev:	Device for which notifier needs to be registered
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index d7cb0e65c4f0..58490f6839ce 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -130,6 +130,9 @@ int dev_pm_opp_enable(struct device *dev, unsigned long freq);
 
 int dev_pm_opp_disable(struct device *dev, unsigned long freq);
 
+int dev_pm_opp_update_voltage(struct device *dev, unsigned long freq,
+			      unsigned long u_volt);
+
 int dev_pm_opp_register_notifier(struct device *dev, struct notifier_block *nb);
 int dev_pm_opp_unregister_notifier(struct device *dev, struct notifier_block *nb);
 
@@ -265,6 +268,13 @@ static inline int dev_pm_opp_disable(struct device *dev, unsigned long freq)
 	return 0;
 }
 
+static inline int dev_pm_opp_update_voltage(struct device *dev,
+					    unsigned long freq,
+					    unsigned long u_volt)
+{
+	return 0;
+}
+
 static inline int dev_pm_opp_register_notifier(struct device *dev, struct notifier_block *nb)
 {
 	return -ENOTSUPP;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 18%]

* [PATCH RFC 7/9] cpufreq: qcom: Add support to update cpu node's OPP tables
  2019-03-28 15:28 [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
                   ` (5 preceding siblings ...)
  2019-03-28 15:28 ` [PATCH RFC 6/9] OPP: Add and export helper to update voltage Sibi Sankar
@ 2019-03-28 15:28 ` Sibi Sankar
  2019-04-10 10:33   ` Viresh Kumar
  2019-03-28 15:28 ` [PATCH RFC 8/9] arm64: dts: qcom: sdm845: Add cpu " Sibi Sankar
                   ` (2 subsequent siblings)
  9 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-03-28 15:28 UTC (permalink / raw)
  To: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm-owner, devicetree, rnayak, cw00.choi, linux-pm,
	evgreen, daidavid1, dianders, Sibi Sankar

Add support to parse and update OPP tables attached to the cpu nodes.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/cpufreq/qcom-cpufreq-hw.c | 29 +++++++++++++++++++++++++++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
index 4b0b50403901..5c268dd2346c 100644
--- a/drivers/cpufreq/qcom-cpufreq-hw.c
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -73,6 +73,25 @@ static unsigned int qcom_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
 	return policy->freq_table[index].frequency;
 }
 
+static int qcom_find_update_opp(struct device *cpu_dev, unsigned long freq,
+				unsigned long volt)
+{
+	int ret;
+	struct dev_pm_opp *opp;
+
+	opp = dev_pm_opp_find_freq_exact(cpu_dev, freq, true);
+	if (IS_ERR(opp)) {
+		ret = dev_pm_opp_add(cpu_dev, freq, volt);
+	} else {
+		dev_pm_opp_disable(cpu_dev, freq);
+		ret = dev_pm_opp_update_voltage(cpu_dev, freq, volt);
+		dev_pm_opp_enable(cpu_dev, freq);
+		dev_pm_opp_put(opp);
+	}
+
+	return ret;
+}
+
 static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 				    struct cpufreq_policy *policy,
 				    void __iomem *base)
@@ -81,11 +100,16 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 	u32 volt;
 	unsigned int max_cores = cpumask_weight(policy->cpus);
 	struct cpufreq_frequency_table	*table;
+	int ret;
 
 	table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), GFP_KERNEL);
 	if (!table)
 		return -ENOMEM;
 
+	ret = dev_pm_opp_of_add_table(cpu_dev);
+	if (ret)
+		dev_dbg(cpu_dev, "Couldn't add OPP table\n");
+
 	for (i = 0; i < LUT_MAX_ENTRIES; i++) {
 		data = readl_relaxed(base + REG_FREQ_LUT +
 				      i * LUT_ROW_SIZE);
@@ -104,7 +128,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 
 		if (freq != prev_freq && core_count == max_cores) {
 			table[i].frequency = freq;
-			dev_pm_opp_add(cpu_dev, freq * 1000, volt);
+			qcom_find_update_opp(cpu_dev, freq * 1000, volt);
 			dev_dbg(cpu_dev, "index=%d freq=%d, core_count %d\n", i,
 				freq, core_count);
 		} else {
@@ -125,7 +149,8 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
 			if (prev_cc != max_cores) {
 				prev->frequency = prev_freq;
 				prev->flags = CPUFREQ_BOOST_FREQ;
-				dev_pm_opp_add(cpu_dev,	prev_freq * 1000, volt);
+				qcom_find_update_opp(cpu_dev, prev_freq * 1000,
+						     volt);
 			}
 
 			break;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 20%]

* [PATCH RFC 8/9] arm64: dts: qcom: sdm845: Add cpu OPP tables
  2019-03-28 15:28 [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
                   ` (6 preceding siblings ...)
  2019-03-28 15:28 ` [PATCH RFC 7/9] cpufreq: qcom: Add support to update cpu node's OPP tables Sibi Sankar
@ 2019-03-28 15:28 ` " Sibi Sankar
  2019-03-28 15:28 ` [PATCH RFC 9/9] arm64: dts: qcom: sdm845: Add nodes for icbw driver and opp tables Sibi Sankar
  2019-04-11  7:02 ` [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
  9 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-28 15:28 UTC (permalink / raw)
  To: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm-owner, devicetree, rnayak, cw00.choi, linux-pm,
	evgreen, daidavid1, dianders, Sibi Sankar

Add a OPP tables for the cpu nodes.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 182 +++++++++++++++++++++++++++
 1 file changed, 182 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cd8ac481381b..072563f6b6cb 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -193,6 +193,7 @@
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			next-level-cache = <&L2_0>;
+			operating-points-v2 = <&cpu0_opp_table>;
 			L2_0: l2-cache {
 				compatible = "cache";
 				next-level-cache = <&L3_0>;
@@ -210,6 +211,7 @@
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			next-level-cache = <&L2_100>;
+			operating-points-v2 = <&cpu0_opp_table>;
 			L2_100: l2-cache {
 				compatible = "cache";
 				next-level-cache = <&L3_0>;
@@ -224,6 +226,7 @@
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			next-level-cache = <&L2_200>;
+			operating-points-v2 = <&cpu0_opp_table>;
 			L2_200: l2-cache {
 				compatible = "cache";
 				next-level-cache = <&L3_0>;
@@ -238,6 +241,7 @@
 			qcom,freq-domain = <&cpufreq_hw 0>;
 			#cooling-cells = <2>;
 			next-level-cache = <&L2_300>;
+			operating-points-v2 = <&cpu0_opp_table>;
 			L2_300: l2-cache {
 				compatible = "cache";
 				next-level-cache = <&L3_0>;
@@ -252,6 +256,7 @@
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			#cooling-cells = <2>;
 			next-level-cache = <&L2_400>;
+			operating-points-v2 = <&cpu4_opp_table>;
 			L2_400: l2-cache {
 				compatible = "cache";
 				next-level-cache = <&L3_0>;
@@ -266,6 +271,7 @@
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			#cooling-cells = <2>;
 			next-level-cache = <&L2_500>;
+			operating-points-v2 = <&cpu4_opp_table>;
 			L2_500: l2-cache {
 				compatible = "cache";
 				next-level-cache = <&L3_0>;
@@ -280,6 +286,7 @@
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			#cooling-cells = <2>;
 			next-level-cache = <&L2_600>;
+			operating-points-v2 = <&cpu4_opp_table>;
 			L2_600: l2-cache {
 				compatible = "cache";
 				next-level-cache = <&L3_0>;
@@ -294,6 +301,7 @@
 			qcom,freq-domain = <&cpufreq_hw 1>;
 			#cooling-cells = <2>;
 			next-level-cache = <&L2_700>;
+			operating-points-v2 = <&cpu4_opp_table>;
 			L2_700: l2-cache {
 				compatible = "cache";
 				next-level-cache = <&L3_0>;
@@ -301,6 +309,180 @@
 		};
 	};
 
+	cpu0_opp_table: cpu0_opp_table {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		cpu0_opp1: opp-300000000 {
+			opp-hz = /bits/ 64 <300000000>;
+		};
+
+		cpu0_opp2: opp-403200000 {
+			opp-hz = /bits/ 64 <403200000>;
+		};
+
+		cpu0_opp3: opp-480000000 {
+			opp-hz = /bits/ 64 <480000000>;
+		};
+
+		cpu0_opp4: opp-576000000 {
+			opp-hz = /bits/ 64 <576000000>;
+		};
+
+		cpu0_opp5: opp-652800000 {
+			opp-hz = /bits/ 64 <652800000>;
+		};
+
+		cpu0_opp6: opp-748800000 {
+			opp-hz = /bits/ 64 <748800000>;
+		};
+
+		cpu0_opp7: opp-825600000 {
+			opp-hz = /bits/ 64 <825600000>;
+		};
+
+		cpu0_opp8: opp-902400000 {
+			opp-hz = /bits/ 64 <902400000>;
+		};
+
+		cpu0_opp9: opp-979200000 {
+			opp-hz = /bits/ 64 <979200000>;
+		};
+
+		cpu0_opp10: opp-1056000000 {
+			opp-hz = /bits/ 64 <1056000000>;
+		};
+
+		cpu0_opp11: opp-1132800000 {
+			opp-hz = /bits/ 64 <1132800000>;
+		};
+
+		cpu0_opp12: opp-1228800000 {
+			opp-hz = /bits/ 64 <1228800000>;
+		};
+
+		cpu0_opp13: opp-1324800000 {
+			opp-hz = /bits/ 64 <1324800000>;
+		};
+
+		cpu0_opp14: opp-1420800000 {
+			opp-hz = /bits/ 64 <1420800000>;
+		};
+
+		cpu0_opp15: opp-1516800000 {
+			opp-hz = /bits/ 64 <1516800000>;
+		};
+
+		cpu0_opp16: opp-1612800000 {
+			opp-hz = /bits/ 64 <1612800000>;
+		};
+
+		cpu0_opp17: opp-1689600000 {
+			opp-hz = /bits/ 64 <1689600000>;
+		};
+
+		cpu0_opp18: opp-1766400000 {
+			opp-hz = /bits/ 64 <1766400000>;
+		};
+	};
+
+	cpu4_opp_table: cpu4_opp_table {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		cpu4_opp1: opp-825600000 {
+			opp-hz = /bits/ 64 <825600000>;
+		};
+
+		cpu4_opp2: opp-902400000 {
+			opp-hz = /bits/ 64 <902400000>;
+		};
+
+		cpu4_opp3: opp-979200000 {
+			opp-hz = /bits/ 64 <979200000>;
+		};
+
+		cpu4_opp4: opp-1056000000 {
+			opp-hz = /bits/ 64 <1056000000>;
+		};
+
+		cpu4_opp5: opp-1209600000 {
+			opp-hz = /bits/ 64 <1209600000>;
+		};
+
+		cpu4_opp6: opp-1286400000 {
+			opp-hz = /bits/ 64 <1286400000>;
+		};
+
+		cpu4_opp7: opp-1363200000 {
+			opp-hz = /bits/ 64 <1363200000>;
+		};
+
+		cpu4_opp8: opp-1459200000 {
+			opp-hz = /bits/ 64 <1459200000>;
+		};
+
+		cpu4_opp9: opp-1536000000 {
+			opp-hz = /bits/ 64 <1536000000>;
+		};
+
+		cpu4_opp10: opp-1612800000 {
+			opp-hz = /bits/ 64 <1612800000>;
+		};
+
+		cpu4_opp11: opp-1689600000 {
+			opp-hz = /bits/ 64 <1689600000>;
+		};
+
+		cpu4_opp12: opp-1766400000 {
+			opp-hz = /bits/ 64 <1766400000>;
+		};
+
+		cpu4_opp13: opp-1843200000 {
+			opp-hz = /bits/ 64 <1843200000>;
+		};
+
+		cpu4_opp14: opp-1920000000 {
+			opp-hz = /bits/ 64 <1920000000>;
+		};
+
+		cpu4_opp15: opp-1996800000 {
+			opp-hz = /bits/ 64 <1996800000>;
+		};
+
+		cpu4_opp16: opp-2092800000 {
+			opp-hz = /bits/ 64 <2092800000>;
+		};
+
+		cpu4_opp17: opp-2169600000 {
+			opp-hz = /bits/ 64 <2169600000>;
+		};
+
+		cpu4_opp18: opp-2246400000 {
+			opp-hz = /bits/ 64 <2246400000>;
+		};
+
+		cpu4_opp19: opp-2323200000 {
+			opp-hz = /bits/ 64 <2323200000>;
+		};
+
+		cpu4_opp20: opp-2400000000 {
+			opp-hz = /bits/ 64 <2400000000>;
+		};
+
+		cpu4_opp21: opp-2476800000 {
+			opp-hz = /bits/ 64 <2476800000>;
+		};
+
+		cpu4_opp22: opp-2553600000 {
+			opp-hz = /bits/ 64 <2553600000>;
+		};
+
+		cpu4_opp23: opp-2649600000 {
+			opp-hz = /bits/ 64 <2649600000>;
+		};
+	};
+
 	pmu {
 		compatible = "arm,armv8-pmuv3";
 		interrupts = <GIC_PPI 5 IRQ_TYPE_LEVEL_HIGH>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 17%]

* [PATCH RFC 9/9] arm64: dts: qcom: sdm845: Add nodes for icbw driver and opp tables
  2019-03-28 15:28 [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
                   ` (7 preceding siblings ...)
  2019-03-28 15:28 ` [PATCH RFC 8/9] arm64: dts: qcom: sdm845: Add cpu " Sibi Sankar
@ 2019-03-28 15:28 ` Sibi Sankar
  2019-04-11  7:02 ` [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
  9 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-03-28 15:28 UTC (permalink / raw)
  To: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm-owner, devicetree, rnayak, cw00.choi, linux-pm,
	evgreen, daidavid1, dianders, Sibi Sankar

Add nodes to enable DDR devfreq driver on SDM845 SoC.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 80 ++++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 072563f6b6cb..21a0068855e8 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -11,6 +11,7 @@
 #include <dt-bindings/clock/qcom,lpass-sdm845.h>
 #include <dt-bindings/clock/qcom,rpmh.h>
 #include <dt-bindings/clock/qcom,videocc-sdm845.h>
+#include <dt-bindings/interconnect/qcom,sdm845.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/phy/phy-qcom-qusb2.h>
 #include <dt-bindings/power/qcom-aoss-qmp.h>
@@ -488,6 +489,85 @@
 		interrupts = <GIC_PPI 5 IRQ_TYPE_LEVEL_HIGH>;
 	};
 
+	cpubw: cpu-icbw {
+		compatible = "devfreq-icbw";
+		interconnects = <&rsc_hlos MASTER_APPSS_PROC &rsc_hlos SLAVE_EBI1>;
+		operating-points-v2 = <&bw_opp_table>;
+	};
+
+	bw_opp_table: bw-opp-table {
+		compatible = "operating-points-v2";
+
+		opp-200  {
+			opp-hz = /bits/ 64 < 200000000 >; /* 200 MHz */
+			required-opps = <&cpu0_opp1>;
+			/* 0 MB/s average and 762 MB/s peak bandwidth */
+			opp-bw-MBs = <0 762>;
+		};
+
+		opp-300 {
+			opp-hz = /bits/ 64 < 300000000 >; /* 300 MHz */
+			/* 0 MB/s average and 1144 MB/s peak bandwidth */
+			opp-bw-MBs = <0 1144>;
+		};
+
+		opp-451 {
+			opp-hz = /bits/ 64 < 451000000 >; /* 451 MHz */
+			/* 0 MB/s average and 1720 MB/s peak bandwidth */
+			opp-bw-MBs = <0 1720>;
+			required-opps = <&cpu0_opp6>;
+		};
+
+		opp-547 {
+			opp-hz = /bits/ 64 < 547000000 >; /* 547 MHz */
+			/* 0 MB/s average and 2086 MB/s peak bandwidth */
+			opp-bw-MBs = <0 2086>;
+			required-opps = <&cpu0_opp11>;
+		};
+
+		opp-681 {
+			opp-hz = /bits/ 64 < 681000000 >; /* 681 MHz */
+			/* 0 MB/s average and 2597 MB/s peak bandwidth */
+			opp-bw-MBs = <0 2597>;
+			required-opps = <&cpu0_opp15>;
+		};
+
+		opp-768 {
+			opp-hz = /bits/ 64 < 768000000 >; /* 768 MHz */
+			/* 0 MB/s average and 2929 MB/s peak bandwidth */
+			opp-bw-MBs = <0 2929>;
+			required-opps = <&cpu4_opp4>;
+		};
+
+		opp-1017 {
+			opp-hz = /bits/ 64 < 1017000000 >; /* 1017 MHz */
+			/* 0 MB/s average and 3879 MB/s peak bandwidth */
+			opp-bw-MBs = <0 3879>;
+			required-opps = <&cpu0_opp16>, <&cpu4_opp5>;
+		};
+
+		opp-1296 {
+			opp-hz = /bits/ 64 < 1296000000 >; /* 1296 MHz */
+			/* 0 MB/s average and 4943 MB/s peak bandwidth */
+			opp-bw-MBs = <0 4943>;
+			required-opps = <&cpu4_opp10>;
+		};
+
+		opp-1555 {
+			opp-hz = /bits/ 64 < 1555000000 >; /* 1555 MHz */
+			/* 0 MB/s average and 5931 MB/s peak bandwidth */
+			opp-bw-MBs = <0 5931>;
+			required-opps = <&cpu4_opp12>;
+		};
+
+		opp-1804 {
+			opp-hz = /bits/ 64 < 1804000000 >; /* 1804 MHz */
+			/* 0 MB/s average and 6881 MB/s peak bandwidth */
+			opp-bw-MBs = <0 6881>;
+			required-opps = <&cpu4_opp15>;
+		};
+	};
+
 	timer {
 		compatible = "arm,armv8-timer";
 		interrupts = <GIC_PPI 1 IRQ_TYPE_LEVEL_LOW>,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 18%]

* Re: [PATCH v3 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404
  2019-03-27 12:38 ` [PATCH v3 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404 Sibi Sankar
@ 2019-03-28 18:40   ` Rob Herring
  0 siblings, 0 replies; 200+ results
From: Rob Herring @ 2019-03-28 18:40 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: bjorn.andersson, robh+dt, andy.gross, rnayak, david.brown,
	mark.rutland, linux-kernel, linux-arm-msm-owner, devicetree,
	Sibi Sankar

On Wed, 27 Mar 2019 18:08:27 +0530, Sibi Sankar wrote:
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
> 
> Add RPM power domain bindings for the qcs404 family of SoC
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> [sibis: Add supported rpmpd states for qcs404]
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
> 
> skip adding Rob's R-b due to some additional changes
> https://lore.kernel.org/lkml/20190325223343.GA27389@bogus/
> 
>  .../devicetree/bindings/power/qcom,rpmpd.txt  |  1 +
>  include/dt-bindings/power/qcom-rpmpd.h        | 22 +++++++++++++++++++
>  2 files changed, 23 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 7/9] dt-bindings: power: Add rpm power domain bindings for msm8998
  2019-03-27 12:38 ` [PATCH v3 7/9] dt-bindings: power: Add rpm power domain bindings for msm8998 Sibi Sankar
@ 2019-03-28 18:40   ` Rob Herring
  0 siblings, 0 replies; 200+ results
From: Rob Herring @ 2019-03-28 18:40 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: bjorn.andersson, robh+dt, andy.gross, rnayak, david.brown,
	mark.rutland, linux-kernel, linux-arm-msm-owner, devicetree,
	Sibi Sankar

On Wed, 27 Mar 2019 18:08:30 +0530, Sibi Sankar wrote:
> Add RPM power domain bindings for the msm8998 family of SoC
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  .../devicetree/bindings/power/qcom,rpmpd.txt         |  1 +
>  include/dt-bindings/power/qcom-rpmpd.h               | 12 ++++++++++++
>  2 files changed, 13 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state
  2019-03-27 12:38 ` [PATCH v3 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
@ 2019-04-05 14:59   ` Marc Gonzalez
  0 siblings, 0 replies; 200+ results
From: Marc Gonzalez @ 2019-04-05 14:59 UTC (permalink / raw)
  To: Sibi Sankar, Bjorn Andersson; +Cc: MSM, LKML

On 27/03/2019 13:38, Sibi Sankar wrote:

> Remoteproc q6v5-mss does set_performace_state with INT_MAX on

Remoteproc q6v5-mss calls set_performance_state()

> rpmpd. This is currently ignored since it is greater than the
> max supported state. Fixup rpmpd state to max if the required
> state is greater than all the supported states.
> 
> Fixes: 075d3db8d10d ("Add support for the .set_performace_state() and
> .opp_to_performance_state()")
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>

AFAIU, the Fixes tag should be on a single line, and quote the commit subject.
(And no blank line between Fixes and Signed-off-by tags.)

Fixes: 075d3db8d10d ("soc: qcom: rpmpd: Add support for get/set performance state")

> ---
>  drivers/soc/qcom/rpmpd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
> index 005326050c23..235d01870dd8 100644
> --- a/drivers/soc/qcom/rpmpd.c
> +++ b/drivers/soc/qcom/rpmpd.c
> @@ -226,7 +226,7 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
>  	struct rpmpd *pd = domain_to_rpmpd(domain);
>  
>  	if (state > MAX_RPMPD_STATE)
> -		goto out;
> +		state = MAX_RPMPD_STATE;
>  
>  	mutex_lock(&rpmpd_lock);
>  

With these two nits taken care of:

Reviewed-by: Marc Gonzalez <marc.w.gonzalez@free.fr>

Regards.

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains
  2019-03-27 12:38 ` [PATCH v3 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains Sibi Sankar
@ 2019-04-05 15:08   ` Marc Gonzalez
  2019-04-08  8:30     ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Marc Gonzalez @ 2019-04-05 15:08 UTC (permalink / raw)
  To: Sibi Sankar; +Cc: MSM, LKML

On 27/03/2019 13:38, Sibi Sankar wrote:

> Add the shared cx/mx and sensor sub-system's cx and mx
> power-domains found on MSM8998.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  drivers/soc/qcom/rpmpd.c | 36 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 36 insertions(+)
> 
> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
> index 238a9e02e890..706a3f63038e 100644
> --- a/drivers/soc/qcom/rpmpd.c
> +++ b/drivers/soc/qcom/rpmpd.c
> @@ -19,9 +19,12 @@
>  /* Resource types */
>  #define RPMPD_SMPA 0x61706d73 /* smpa */
>  #define RPMPD_LDOA 0x616f646c /* ldoa */
> +#define RPMPD_RWCX 0x78637772 /* rwcx */
>  #define RPMPD_RWMX 0x786d7772 /* rwmx */
>  #define RPMPD_RWLC 0x636c7772 /* rwlc */
>  #define RPMPD_RWLM 0x6d6c7772 /* rwlm */
> +#define RPMPD_RWSC 0x63737772 /* rwsc */
> +#define RPMPD_RWSM 0x6d737772 /* rwsm */

I do not see any value in the comments. Maybe remove them?

I will take a closer look at patches 7-9 on Monday.

Regards.

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 6/9] arm64: dts: qcom: qcs404: Add rpmpd node
  2019-03-27 12:38 ` [PATCH v3 6/9] arm64: dts: qcom: qcs404: Add rpmpd node Sibi Sankar
@ 2019-04-08  8:10   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-04-08  8:10 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm, devicetree

On 2019-03-27 18:08, Sibi Sankar wrote:
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
> 
> Add the rpmpd node on the qcs404 and define the available levels.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> [sibis: fixup available levels]
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  arch/arm64/boot/dts/qcom/qcs404.dtsi | 55 ++++++++++++++++++++++++++++
>  1 file changed, 55 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> index e8fd26633d57..a7d46647c416 100644
> --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> @@ -4,6 +4,7 @@
>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>  #include <dt-bindings/clock/qcom,gcc-qcs404.h>
>  #include <dt-bindings/clock/qcom,rpmcc.h>
> +#include <dt-bindings/power/qcom-rpmpd.h>
> 
>  / {
>  	interrupt-parent = <&intc>;
> @@ -230,6 +231,60 @@
>  				compatible = "qcom,rpmcc-qcs404";
>  				#clock-cells = <1>;
>  			};
> +
> +			rpmpd: power-controller {
> +				compatible = "qcom,qcs404-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 = <RPM_SMD_LEVEL_RETENTION>;
> +					};
> +
> +					rpmpd_opp_ret_plus: opp2 {
> +						opp-level = <RPM_SMD_LEVEL_RETENTION_PLUS>;
> +					};
> +
> +					rpmpd_opp_min_svs: opp3 {
> +						opp-level = <RPM_SMD_LEVEL_MIN_SVS>;
> +					};
> +
> +					rpmpd_opp_low_svs: opp4 {
> +						opp-level = <RPM_SMD_LEVEL_LOW_SVS>;
> +					};
> +

typo in opp5 - opp11 rpmhpd/rpmpd
will fix it in the next re-spin

> +					rpmhpd_opp_svs: opp5 {
> +						opp-level = <RPM_SMD_LEVEL_SVS>;
> +					};
> +
> +					rpmhpd_opp_svs_plus: opp6 {
> +						opp-level = <RPM_SMD_LEVEL_SVS_PLUS>;
> +					};
> +
> +					rpmhpd_opp_nom: opp7 {
> +						opp-level = <RPM_SMD_LEVEL_NOM>;
> +					};
> +
> +					rpmhpd_opp_nom_plus: opp8 {
> +						opp-level = <RPM_SMD_LEVEL_NOM_PLUS>;
> +					};
> +
> +					rpmhpd_opp_turbo: opp9 {
> +						opp-level = <RPM_SMD_LEVEL_TURBO>;
> +					};
> +
> +					rpmhpd_opp_turbo_no_cpr: opp10 {
> +						opp-level = <RPM_SMD_LEVEL_TURBO_NO_CPR>;
> +					};
> +
> +					rpmhpd_opp_turbo_plus: opp11 {
> +						opp-level = <RPM_SMD_LEVEL_BINNING>;
> +					};
> +				};
> +			};
>  		};
>  	};

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v3 9/9] arm64: dts: qcom: msm8998: Add rpmpd node
  2019-03-27 12:38 ` [PATCH v3 9/9] arm64: dts: qcom: msm8998: Add rpmpd node Sibi Sankar
@ 2019-04-08  8:12   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-04-08  8:12 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, andy.gross, rnayak
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm, devicetree

On 2019-03-27 18:08, Sibi Sankar wrote:
> Add the rpmpd node on the msm8998 and define the available levels.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  arch/arm64/boot/dts/qcom/msm8998.dtsi | 51 +++++++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi
> b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> index 3fd0769fe648..b7e3e0646b9b 100644
> --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
> @@ -4,6 +4,7 @@
>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>  #include <dt-bindings/clock/qcom,gcc-msm8998.h>
>  #include <dt-bindings/clock/qcom,rpmcc.h>
> +#include <dt-bindings/power/qcom-rpmpd.h>
>  #include <dt-bindings/gpio/gpio.h>
> 
>  / {
> @@ -272,6 +273,56 @@
>  				compatible = "qcom,rpmcc-msm8998", "qcom,rpmcc";
>  				#clock-cells = <1>;
>  			};
> +
> +			rpmpd: power-controller {
> +				compatible = "qcom,msm8998-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 = <RPM_SMD_LEVEL_RETENTION>;
> +					};
> +
> +					rpmpd_opp_ret_plus: opp2 {
> +						opp-level = <RPM_SMD_LEVEL_RETENTION_PLUS>;
> +					};
> +
> +					rpmpd_opp_min_svs: opp3 {
> +						opp-level = <RPM_SMD_LEVEL_MIN_SVS>;
> +					};
> +
> +					rpmpd_opp_low_svs: opp4 {
> +						opp-level = <RPM_SMD_LEVEL_LOW_SVS>;
> +					};
> +


typo in opp5 - opp10 rpmhpd/rpmpd
will fix it in the next re-spin

> +					rpmhpd_opp_svs: opp5 {
> +						opp-level = <RPM_SMD_LEVEL_SVS>;
> +					};
> +
> +					rpmhpd_opp_svs_plus: opp6 {
> +						opp-level = <RPM_SMD_LEVEL_SVS_PLUS>;
> +					};
> +
> +					rpmhpd_opp_nom: opp7 {
> +						opp-level = <RPM_SMD_LEVEL_NOM>;
> +					};
> +
> +					rpmhpd_opp_nom_plus: opp8 {
> +						opp-level = <RPM_SMD_LEVEL_NOM_PLUS>;
> +					};
> +
> +					rpmhpd_opp_turbo: opp9 {
> +						opp-level = <RPM_SMD_LEVEL_TURBO>;
> +					};
> +
> +					rpmhpd_opp_turbo_plus: opp10 {
> +						opp-level = <RPM_SMD_LEVEL_BINNING>;
> +					};
> +				};
> +			};
>  		};
>  	};

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v3 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains
  2019-04-05 15:08   ` Marc Gonzalez
@ 2019-04-08  8:30     ` Sibi Sankar
  2019-04-08  8:54       ` Marc Gonzalez
  0 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-04-08  8:30 UTC (permalink / raw)
  To: Marc Gonzalez; +Cc: MSM, LKML, linux-kernel-owner

On 2019-04-05 20:38, Marc Gonzalez wrote:
> On 27/03/2019 13:38, Sibi Sankar wrote:
> 
>> Add the shared cx/mx and sensor sub-system's cx and mx
>> power-domains found on MSM8998.
>> 
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>>  drivers/soc/qcom/rpmpd.c | 36 ++++++++++++++++++++++++++++++++++++
>>  1 file changed, 36 insertions(+)
>> 
>> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
>> index 238a9e02e890..706a3f63038e 100644
>> --- a/drivers/soc/qcom/rpmpd.c
>> +++ b/drivers/soc/qcom/rpmpd.c
>> @@ -19,9 +19,12 @@
>>  /* Resource types */
>>  #define RPMPD_SMPA 0x61706d73 /* smpa */
>>  #define RPMPD_LDOA 0x616f646c /* ldoa */
>> +#define RPMPD_RWCX 0x78637772 /* rwcx */
>>  #define RPMPD_RWMX 0x786d7772 /* rwmx */
>>  #define RPMPD_RWLC 0x636c7772 /* rwlc */
>>  #define RPMPD_RWLM 0x6d6c7772 /* rwlm */
>> +#define RPMPD_RWSC 0x63737772 /* rwsc */
>> +#define RPMPD_RWSM 0x6d737772 /* rwsm */
> 
> I do not see any value in the comments. Maybe remove them?

comments were included to add value
though, however I guess the comments
were definitely not clear enough.
The magic values for the resources
are calculated as follows:

ascii to hex in reverse order
eg: smpa -> 0x61706d73

0x61 0x70 0x6d 0x73
   a    p    m    s

> 
> I will take a closer look at patches 7-9 on Monday.

Thanks for taking time to review
this series.

> 
> Regards.

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v3 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains
  2019-04-08  8:30     ` Sibi Sankar
@ 2019-04-08  8:54       ` Marc Gonzalez
  2019-04-08  9:02         ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Marc Gonzalez @ 2019-04-08  8:54 UTC (permalink / raw)
  To: Sibi Sankar; +Cc: MSM, LKML

On 08/04/2019 10:30, Sibi Sankar wrote:
> On 2019-04-05 20:38, Marc Gonzalez wrote:
>> On 27/03/2019 13:38, Sibi Sankar wrote:
>>
>>> Add the shared cx/mx and sensor sub-system's cx and mx
>>> power-domains found on MSM8998.
>>>
>>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>>> ---
>>>  drivers/soc/qcom/rpmpd.c | 36 ++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 36 insertions(+)
>>>
>>> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
>>> index 238a9e02e890..706a3f63038e 100644
>>> --- a/drivers/soc/qcom/rpmpd.c
>>> +++ b/drivers/soc/qcom/rpmpd.c
>>> @@ -19,9 +19,12 @@
>>>  /* Resource types */
>>>  #define RPMPD_SMPA 0x61706d73 /* smpa */
>>>  #define RPMPD_LDOA 0x616f646c /* ldoa */
>>> +#define RPMPD_RWCX 0x78637772 /* rwcx */
>>>  #define RPMPD_RWMX 0x786d7772 /* rwmx */
>>>  #define RPMPD_RWLC 0x636c7772 /* rwlc */
>>>  #define RPMPD_RWLM 0x6d6c7772 /* rwlm */
>>> +#define RPMPD_RWSC 0x63737772 /* rwsc */
>>> +#define RPMPD_RWSM 0x6d737772 /* rwsm */
>>
>> I do not see any value in the comments. Maybe remove them?
> 
> comments were included to add value
> though, however I guess the comments
> were definitely not clear enough.
> The magic values for the resources
> are calculated as follows:
> 
> ascii to hex in reverse order
> eg: smpa -> 0x61706d73
> 
> 0x61 0x70 0x6d 0x73
>    a    p    m    s

Ah... I see now.

I agree that explaining *why* e.g. RPMPD_SMPA is defined as 0x61706d73
is worthwhile indeed.

What I meant is that adding /* smpa */ to a macro named RPMPD_SMPA does
not really bring any new information ;-)

How about prefixing the whole block with a small blurb, for example

/* The value of RPMPD_X is X encoded as a little-endian, lower-case, ASCII string */

Regards.

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains
  2019-04-08  8:54       ` Marc Gonzalez
@ 2019-04-08  9:02         ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-04-08  9:02 UTC (permalink / raw)
  To: Marc Gonzalez; +Cc: MSM, LKML

Hey Marc,
Thanks for the review!

On 2019-04-08 14:24, Marc Gonzalez wrote:
> On 08/04/2019 10:30, Sibi Sankar wrote:
>> On 2019-04-05 20:38, Marc Gonzalez wrote:
>>> On 27/03/2019 13:38, Sibi Sankar wrote:
>>> 
>>>> Add the shared cx/mx and sensor sub-system's cx and mx
>>>> power-domains found on MSM8998.
>>>> 
>>>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>>>> ---
>>>>  drivers/soc/qcom/rpmpd.c | 36 ++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 36 insertions(+)
>>>> 
>>>> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
>>>> index 238a9e02e890..706a3f63038e 100644
>>>> --- a/drivers/soc/qcom/rpmpd.c
>>>> +++ b/drivers/soc/qcom/rpmpd.c
>>>> @@ -19,9 +19,12 @@
>>>>  /* Resource types */
>>>>  #define RPMPD_SMPA 0x61706d73 /* smpa */
>>>>  #define RPMPD_LDOA 0x616f646c /* ldoa */
>>>> +#define RPMPD_RWCX 0x78637772 /* rwcx */
>>>>  #define RPMPD_RWMX 0x786d7772 /* rwmx */
>>>>  #define RPMPD_RWLC 0x636c7772 /* rwlc */
>>>>  #define RPMPD_RWLM 0x6d6c7772 /* rwlm */
>>>> +#define RPMPD_RWSC 0x63737772 /* rwsc */
>>>> +#define RPMPD_RWSM 0x6d737772 /* rwsm */
>>> 
>>> I do not see any value in the comments. Maybe remove them?
>> 
>> comments were included to add value
>> though, however I guess the comments
>> were definitely not clear enough.
>> The magic values for the resources
>> are calculated as follows:
>> 
>> ascii to hex in reverse order
>> eg: smpa -> 0x61706d73
>> 
>> 0x61 0x70 0x6d 0x73
>>    a    p    m    s
> 
> Ah... I see now.
> 
> I agree that explaining *why* e.g. RPMPD_SMPA is defined as 0x61706d73
> is worthwhile indeed.
> 
> What I meant is that adding /* smpa */ to a macro named RPMPD_SMPA does
> not really bring any new information ;-)

yeah I got that

> 
> How about prefixing the whole block with a small blurb, for example
> 
> /* The value of RPMPD_X is X encoded as a little-endian, lower-case,
> ASCII string */

sure will add this ^^ instead in the next
re-spin

> 
> Regards.

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH RFC 6/9] OPP: Add and export helper to update voltage
  2019-03-28 15:28 ` [PATCH RFC 6/9] OPP: Add and export helper to update voltage Sibi Sankar
@ 2019-04-10 10:24   ` Viresh Kumar
  2019-04-10 11:08     ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Viresh Kumar @ 2019-04-10 10:24 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw, nm, sboyd,
	georgi.djakov, bjorn.andersson, david.brown, mark.rutland,
	linux-kernel, linux-arm-msm-owner, devicetree, rnayak, cw00.choi,
	linux-pm, evgreen, daidavid1, dianders

On 28-03-19, 20:58, Sibi Sankar wrote:
> Add and export 'dev_pm_opp_update_voltage' to find and update voltage
> of an opp for a given frequency. This will be useful to update the opps
> with voltages read back from firmware.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  drivers/opp/core.c     | 62 ++++++++++++++++++++++++++++++++++++++++++
>  include/linux/pm_opp.h | 10 +++++++
>  2 files changed, 72 insertions(+)
> 
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index addaf7aae9ae..c066cd120a33 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -2090,6 +2090,68 @@ int dev_pm_opp_disable(struct device *dev, unsigned long freq)
>  }
>  EXPORT_SYMBOL_GPL(dev_pm_opp_disable);
>  
> +static int _opp_update_voltage(struct device *dev, unsigned long freq,
> +			       unsigned long u_volt)
> +{
> +	struct opp_table *opp_table;
> +	struct dev_pm_opp *tmp_opp, *opp = ERR_PTR(-ENODEV);
> +	int r = 0;

s/r/ret/

> +
> +	/* Find the opp_table */
> +	opp_table = _find_opp_table(dev);
> +	if (IS_ERR(opp_table)) {
> +		r = PTR_ERR(opp_table);
> +		dev_warn(dev, "%s: Device OPP not found (%d)\n", __func__, r);

Why dev_warn instead of dev_err which is normally used in this file ? And you
weren't searching for OPP but opp_table. Put out the correct error message
please.

> +		return r;
> +	}
> +
> +	mutex_lock(&opp_table->lock);
> +
> +	/* Do we have the frequency? */
> +	list_for_each_entry(tmp_opp, &opp_table->opp_list, node) {
> +		if (tmp_opp->rate == freq) {
> +			opp = tmp_opp;
> +			break;
> +		}
> +	}
> +
> +	if (IS_ERR(opp)) {
> +		r = PTR_ERR(opp);
> +		goto unlock;
> +	}
> +
> +	/* update only if the opp is disabled */
> +	if (opp->available)
> +		goto unlock;
> +

What about reusing dev_pm_opp_find_freq_exact() instead of the above code in
this routine ?

> +	opp->supplies[0].u_volt = u_volt;
> +
> +unlock:
> +	mutex_unlock(&opp_table->lock);
> +	dev_pm_opp_put_opp_table(opp_table);
> +	return r;
> +}
> +
> +/**
> + * dev_pm_opp_update_voltage() - find and update voltage of an opp
> + *				 for a given frequency
> + * @dev:	device for which we do this operation
> + * @freq:	OPP frequency to update voltage
> + * @u_volt:	voltage requested for this opp
> + *
> + * This is useful only for devices with single power supply.
> + *
> + * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for the
> + * copy operation, returns 0 if no modification was done OR modification was
> + * successful.
> + */
> +int dev_pm_opp_update_voltage(struct device *dev, unsigned long freq,
> +			      unsigned long u_volt)
> +{
> +	return _opp_update_voltage(dev, freq, u_volt);

Remove the unnecessary wrapper and open code this routine here. While at it, you
should updated min/max/target and not just target voltage.

> +}
> +EXPORT_SYMBOL_GPL(dev_pm_opp_update_voltage);
> +
>  /**
>   * dev_pm_opp_register_notifier() - Register OPP notifier for the device
>   * @dev:	Device for which notifier needs to be registered
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index d7cb0e65c4f0..58490f6839ce 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -130,6 +130,9 @@ int dev_pm_opp_enable(struct device *dev, unsigned long freq);
>  
>  int dev_pm_opp_disable(struct device *dev, unsigned long freq);
>  
> +int dev_pm_opp_update_voltage(struct device *dev, unsigned long freq,
> +			      unsigned long u_volt);
> +
>  int dev_pm_opp_register_notifier(struct device *dev, struct notifier_block *nb);
>  int dev_pm_opp_unregister_notifier(struct device *dev, struct notifier_block *nb);
>  
> @@ -265,6 +268,13 @@ static inline int dev_pm_opp_disable(struct device *dev, unsigned long freq)
>  	return 0;
>  }
>  
> +static inline int dev_pm_opp_update_voltage(struct device *dev,
> +					    unsigned long freq,
> +					    unsigned long u_volt)
> +{
> +	return 0;
> +}
> +
>  static inline int dev_pm_opp_register_notifier(struct device *dev, struct notifier_block *nb)
>  {
>  	return -ENOTSUPP;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project

-- 
viresh

^ permalink raw reply	[relevance 0%]

* Re: [PATCH RFC 7/9] cpufreq: qcom: Add support to update cpu node's OPP tables
  2019-03-28 15:28 ` [PATCH RFC 7/9] cpufreq: qcom: Add support to update cpu node's OPP tables Sibi Sankar
@ 2019-04-10 10:33   ` Viresh Kumar
  2019-04-10 11:16     ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Viresh Kumar @ 2019-04-10 10:33 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw, nm, sboyd,
	georgi.djakov, bjorn.andersson, david.brown, mark.rutland,
	linux-kernel, linux-arm-msm-owner, devicetree, rnayak, cw00.choi,
	linux-pm, evgreen, daidavid1, dianders

On 28-03-19, 20:58, Sibi Sankar wrote:
> Add support to parse and update OPP tables attached to the cpu nodes.
> 
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  drivers/cpufreq/qcom-cpufreq-hw.c | 29 +++++++++++++++++++++++++++--
>  1 file changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index 4b0b50403901..5c268dd2346c 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> @@ -73,6 +73,25 @@ static unsigned int qcom_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
>  	return policy->freq_table[index].frequency;
>  }
>  
> +static int qcom_find_update_opp(struct device *cpu_dev, unsigned long freq,
> +				unsigned long volt)
> +{
> +	int ret;
> +	struct dev_pm_opp *opp;
> +
> +	opp = dev_pm_opp_find_freq_exact(cpu_dev, freq, true);
> +	if (IS_ERR(opp)) {
> +		ret = dev_pm_opp_add(cpu_dev, freq, volt);

With my comment on the other patch, you can just call
dev_pm_opp_update_voltage() and if that fails then call dev_pm_opp_add().

> +	} else {
> +		dev_pm_opp_disable(cpu_dev, freq);
> +		ret = dev_pm_opp_update_voltage(cpu_dev, freq, volt);
> +		dev_pm_opp_enable(cpu_dev, freq);

Perhaps no one else should be using the CPU OPP table at this point of time and
so we can get away with disable and enable stuff ? Just add a comment on why
that works.

> +		dev_pm_opp_put(opp);
> +	}
> +
> +	return ret;
> +}
> +
>  static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
>  				    struct cpufreq_policy *policy,
>  				    void __iomem *base)
> @@ -81,11 +100,16 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
>  	u32 volt;
>  	unsigned int max_cores = cpumask_weight(policy->cpus);
>  	struct cpufreq_frequency_table	*table;
> +	int ret;
>  
>  	table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), GFP_KERNEL);
>  	if (!table)
>  		return -ENOMEM;
>  
> +	ret = dev_pm_opp_of_add_table(cpu_dev);
> +	if (ret)
> +		dev_dbg(cpu_dev, "Couldn't add OPP table\n");
> +
>  	for (i = 0; i < LUT_MAX_ENTRIES; i++) {
>  		data = readl_relaxed(base + REG_FREQ_LUT +
>  				      i * LUT_ROW_SIZE);
> @@ -104,7 +128,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
>  
>  		if (freq != prev_freq && core_count == max_cores) {
>  			table[i].frequency = freq;
> -			dev_pm_opp_add(cpu_dev, freq * 1000, volt);
> +			qcom_find_update_opp(cpu_dev, freq * 1000, volt);
>  			dev_dbg(cpu_dev, "index=%d freq=%d, core_count %d\n", i,
>  				freq, core_count);
>  		} else {
> @@ -125,7 +149,8 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
>  			if (prev_cc != max_cores) {
>  				prev->frequency = prev_freq;
>  				prev->flags = CPUFREQ_BOOST_FREQ;
> -				dev_pm_opp_add(cpu_dev,	prev_freq * 1000, volt);
> +				qcom_find_update_opp(cpu_dev, prev_freq * 1000,
> +						     volt);
>  			}
>  
>  			break;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project

-- 
viresh

^ permalink raw reply	[relevance 0%]

* Re: [PATCH RFC 6/9] OPP: Add and export helper to update voltage
  2019-04-10 10:24   ` Viresh Kumar
@ 2019-04-10 11:08     ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-04-10 11:08 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw, nm, sboyd,
	georgi.djakov, bjorn.andersson, david.brown, mark.rutland,
	linux-kernel, linux-arm-msm-owner, devicetree, rnayak, cw00.choi,
	linux-pm, evgreen, daidavid1, dianders

Hey Viresh,
Thanks for the review!

On 2019-04-10 15:54, Viresh Kumar wrote:
> On 28-03-19, 20:58, Sibi Sankar wrote:
>> Add and export 'dev_pm_opp_update_voltage' to find and update voltage
>> of an opp for a given frequency. This will be useful to update the 
>> opps
>> with voltages read back from firmware.
>> 
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>>  drivers/opp/core.c     | 62 
>> ++++++++++++++++++++++++++++++++++++++++++
>>  include/linux/pm_opp.h | 10 +++++++
>>  2 files changed, 72 insertions(+)
>> 
>> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
>> index addaf7aae9ae..c066cd120a33 100644
>> --- a/drivers/opp/core.c
>> +++ b/drivers/opp/core.c
>> @@ -2090,6 +2090,68 @@ int dev_pm_opp_disable(struct device *dev, 
>> unsigned long freq)
>>  }
>>  EXPORT_SYMBOL_GPL(dev_pm_opp_disable);
>> 
>> +static int _opp_update_voltage(struct device *dev, unsigned long 
>> freq,
>> +			       unsigned long u_volt)
>> +{
>> +	struct opp_table *opp_table;
>> +	struct dev_pm_opp *tmp_opp, *opp = ERR_PTR(-ENODEV);
>> +	int r = 0;
> 
> s/r/ret/
> 
>> +
>> +	/* Find the opp_table */
>> +	opp_table = _find_opp_table(dev);
>> +	if (IS_ERR(opp_table)) {
>> +		r = PTR_ERR(opp_table);
>> +		dev_warn(dev, "%s: Device OPP not found (%d)\n", __func__, r);
> 
> Why dev_warn instead of dev_err which is normally used in this file ? 
> And you
> weren't searching for OPP but opp_table. Put out the correct error 
> message
> please.

yeah I'll use dev_err (I'll fix the same in
_opp_set_availability too)

> 
>> +		return r;
>> +	}
>> +
>> +	mutex_lock(&opp_table->lock);
>> +
>> +	/* Do we have the frequency? */
>> +	list_for_each_entry(tmp_opp, &opp_table->opp_list, node) {
>> +		if (tmp_opp->rate == freq) {
>> +			opp = tmp_opp;
>> +			break;
>> +		}
>> +	}
>> +
>> +	if (IS_ERR(opp)) {
>> +		r = PTR_ERR(opp);
>> +		goto unlock;
>> +	}
>> +
>> +	/* update only if the opp is disabled */
>> +	if (opp->available)
>> +		goto unlock;
>> +
> 
> What about reusing dev_pm_opp_find_freq_exact() instead of the above 
> code in
> this routine ?

yes I'll use that

> 
>> +	opp->supplies[0].u_volt = u_volt;
>> +
>> +unlock:
>> +	mutex_unlock(&opp_table->lock);
>> +	dev_pm_opp_put_opp_table(opp_table);
>> +	return r;
>> +}
>> +
>> +/**
>> + * dev_pm_opp_update_voltage() - find and update voltage of an opp
>> + *				 for a given frequency
>> + * @dev:	device for which we do this operation
>> + * @freq:	OPP frequency to update voltage
>> + * @u_volt:	voltage requested for this opp
>> + *
>> + * This is useful only for devices with single power supply.
>> + *
>> + * Return: -EINVAL for bad pointers, -ENOMEM if no memory available 
>> for the
>> + * copy operation, returns 0 if no modification was done OR 
>> modification was
>> + * successful.
>> + */
>> +int dev_pm_opp_update_voltage(struct device *dev, unsigned long freq,
>> +			      unsigned long u_volt)
>> +{
>> +	return _opp_update_voltage(dev, freq, u_volt);
> 
> Remove the unnecessary wrapper and open code this routine here. While 
> at it, you
> should updated min/max/target and not just target voltage.

will fix this in the next-respin

> 
>> +}
>> +EXPORT_SYMBOL_GPL(dev_pm_opp_update_voltage);
>> +
>>  /**
>>   * dev_pm_opp_register_notifier() - Register OPP notifier for the 
>> device
>>   * @dev:	Device for which notifier needs to be registered
>> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
>> index d7cb0e65c4f0..58490f6839ce 100644
>> --- a/include/linux/pm_opp.h
>> +++ b/include/linux/pm_opp.h
>> @@ -130,6 +130,9 @@ int dev_pm_opp_enable(struct device *dev, unsigned 
>> long freq);
>> 
>>  int dev_pm_opp_disable(struct device *dev, unsigned long freq);
>> 
>> +int dev_pm_opp_update_voltage(struct device *dev, unsigned long freq,
>> +			      unsigned long u_volt);
>> +
>>  int dev_pm_opp_register_notifier(struct device *dev, struct 
>> notifier_block *nb);
>>  int dev_pm_opp_unregister_notifier(struct device *dev, struct 
>> notifier_block *nb);
>> 
>> @@ -265,6 +268,13 @@ static inline int dev_pm_opp_disable(struct 
>> device *dev, unsigned long freq)
>>  	return 0;
>>  }
>> 
>> +static inline int dev_pm_opp_update_voltage(struct device *dev,
>> +					    unsigned long freq,
>> +					    unsigned long u_volt)
>> +{
>> +	return 0;
>> +}
>> +
>>  static inline int dev_pm_opp_register_notifier(struct device *dev, 
>> struct notifier_block *nb)
>>  {
>>  	return -ENOTSUPP;
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH RFC 7/9] cpufreq: qcom: Add support to update cpu node's OPP tables
  2019-04-10 10:33   ` Viresh Kumar
@ 2019-04-10 11:16     ` Sibi Sankar
  2019-04-10 11:25       ` Viresh Kumar
  0 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-04-10 11:16 UTC (permalink / raw)
  To: Viresh Kumar
  Cc: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw, nm, sboyd,
	georgi.djakov, bjorn.andersson, david.brown, mark.rutland,
	linux-kernel, linux-arm-msm-owner, devicetree, rnayak, cw00.choi,
	linux-pm, evgreen, daidavid1, dianders

On 2019-04-10 16:03, Viresh Kumar wrote:
> On 28-03-19, 20:58, Sibi Sankar wrote:
>> Add support to parse and update OPP tables attached to the cpu nodes.
>> 
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>>  drivers/cpufreq/qcom-cpufreq-hw.c | 29 +++++++++++++++++++++++++++--
>>  1 file changed, 27 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
>> b/drivers/cpufreq/qcom-cpufreq-hw.c
>> index 4b0b50403901..5c268dd2346c 100644
>> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
>> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
>> @@ -73,6 +73,25 @@ static unsigned int 
>> qcom_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
>>  	return policy->freq_table[index].frequency;
>>  }
>> 
>> +static int qcom_find_update_opp(struct device *cpu_dev, unsigned long 
>> freq,
>> +				unsigned long volt)
>> +{
>> +	int ret;
>> +	struct dev_pm_opp *opp;
>> +
>> +	opp = dev_pm_opp_find_freq_exact(cpu_dev, freq, true);
>> +	if (IS_ERR(opp)) {
>> +		ret = dev_pm_opp_add(cpu_dev, freq, volt);
> 
> With my comment on the other patch, you can just call
> dev_pm_opp_update_voltage() and if that fails then call 
> dev_pm_opp_add().

yeah that should simplify things.

Also through the above approach I cannot
really disable opps that the OSM does not
support. I can only try enabling opp's that
OSM supports. But that would require all
opp's nodes to start with "disabled" but
that is not allowed I guess.

> 
>> +	} else {
>> +		dev_pm_opp_disable(cpu_dev, freq);
>> +		ret = dev_pm_opp_update_voltage(cpu_dev, freq, volt);
>> +		dev_pm_opp_enable(cpu_dev, freq);
> 
> Perhaps no one else should be using the CPU OPP table at this point of 
> time and
> so we can get away with disable and enable stuff ? Just add a comment 
> on why
> that works.

we can get away without enable/disable here

> 
>> +		dev_pm_opp_put(opp);
>> +	}
>> +
>> +	return ret;
>> +}
>> +
>>  static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
>>  				    struct cpufreq_policy *policy,
>>  				    void __iomem *base)
>> @@ -81,11 +100,16 @@ static int qcom_cpufreq_hw_read_lut(struct device 
>> *cpu_dev,
>>  	u32 volt;
>>  	unsigned int max_cores = cpumask_weight(policy->cpus);
>>  	struct cpufreq_frequency_table	*table;
>> +	int ret;
>> 
>>  	table = kcalloc(LUT_MAX_ENTRIES + 1, sizeof(*table), GFP_KERNEL);
>>  	if (!table)
>>  		return -ENOMEM;
>> 
>> +	ret = dev_pm_opp_of_add_table(cpu_dev);
>> +	if (ret)
>> +		dev_dbg(cpu_dev, "Couldn't add OPP table\n");
>> +
>>  	for (i = 0; i < LUT_MAX_ENTRIES; i++) {
>>  		data = readl_relaxed(base + REG_FREQ_LUT +
>>  				      i * LUT_ROW_SIZE);
>> @@ -104,7 +128,7 @@ static int qcom_cpufreq_hw_read_lut(struct device 
>> *cpu_dev,
>> 
>>  		if (freq != prev_freq && core_count == max_cores) {
>>  			table[i].frequency = freq;
>> -			dev_pm_opp_add(cpu_dev, freq * 1000, volt);
>> +			qcom_find_update_opp(cpu_dev, freq * 1000, volt);
>>  			dev_dbg(cpu_dev, "index=%d freq=%d, core_count %d\n", i,
>>  				freq, core_count);
>>  		} else {
>> @@ -125,7 +149,8 @@ static int qcom_cpufreq_hw_read_lut(struct device 
>> *cpu_dev,
>>  			if (prev_cc != max_cores) {
>>  				prev->frequency = prev_freq;
>>  				prev->flags = CPUFREQ_BOOST_FREQ;
>> -				dev_pm_opp_add(cpu_dev,	prev_freq * 1000, volt);
>> +				qcom_find_update_opp(cpu_dev, prev_freq * 1000,
>> +						     volt);
>>  			}
>> 
>>  			break;
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH RFC 7/9] cpufreq: qcom: Add support to update cpu node's OPP tables
  2019-04-10 11:16     ` Sibi Sankar
@ 2019-04-10 11:25       ` Viresh Kumar
  0 siblings, 0 replies; 200+ results
From: Viresh Kumar @ 2019-04-10 11:25 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw, nm, sboyd,
	georgi.djakov, bjorn.andersson, david.brown, mark.rutland,
	linux-kernel, linux-arm-msm-owner, devicetree, rnayak, cw00.choi,
	linux-pm, evgreen, daidavid1, dianders

On 10-04-19, 16:46, Sibi Sankar wrote:
> On 2019-04-10 16:03, Viresh Kumar wrote:
> > On 28-03-19, 20:58, Sibi Sankar wrote:
> > > Add support to parse and update OPP tables attached to the cpu nodes.
> > > 
> > > Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> > > ---
> > >  drivers/cpufreq/qcom-cpufreq-hw.c | 29 +++++++++++++++++++++++++++--
> > >  1 file changed, 27 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c
> > > b/drivers/cpufreq/qcom-cpufreq-hw.c
> > > index 4b0b50403901..5c268dd2346c 100644
> > > --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> > > +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
> > > @@ -73,6 +73,25 @@ static unsigned int
> > > qcom_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
> > >  	return policy->freq_table[index].frequency;
> > >  }
> > > 
> > > +static int qcom_find_update_opp(struct device *cpu_dev, unsigned
> > > long freq,
> > > +				unsigned long volt)
> > > +{
> > > +	int ret;
> > > +	struct dev_pm_opp *opp;
> > > +
> > > +	opp = dev_pm_opp_find_freq_exact(cpu_dev, freq, true);
> > > +	if (IS_ERR(opp)) {
> > > +		ret = dev_pm_opp_add(cpu_dev, freq, volt);
> > 
> > With my comment on the other patch, you can just call
> > dev_pm_opp_update_voltage() and if that fails then call
> > dev_pm_opp_add().
> 
> yeah that should simplify things.
> 
> Also through the above approach I cannot
> really disable opps that the OSM does not
> support. I can only try enabling opp's that
> OSM supports. But that would require all
> opp's nodes to start with "disabled" but
> that is not allowed I guess.

Yeah maybe add all OPPs from DT, disable all of them and then only modify and
enable the ones you need.

-- 
viresh

^ permalink raw reply	[relevance 0%]

* Re: [PATCH RFC 0/9] Add CPU based scaling support to Passive governor
  2019-03-28 15:28 [PATCH RFC 0/9] Add CPU based scaling support to Passive governor Sibi Sankar
                   ` (8 preceding siblings ...)
  2019-03-28 15:28 ` [PATCH RFC 9/9] arm64: dts: qcom: sdm845: Add nodes for icbw driver and opp tables Sibi Sankar
@ 2019-04-11  7:02 ` Sibi Sankar
  9 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-04-11  7:02 UTC (permalink / raw)
  To: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm, devicetree, rnayak, cw00.choi, linux-pm, evgreen,
	daidavid1, dianders

On 2019-03-28 20:58, Sibi Sankar wrote:
> This RFC series aims to add cpu based scaling support to the passive
> governor and scale DDR with a generic interconnect bandwidth based
> devfreq driver on SDM845 SoC. This series achieves similar 
> functionality
> to Georgi's Patch series (https://patchwork.kernel.org/cover/10850817/)
> and can be used with MSM8916/MSM8996/QCS404 SoCs.
> 
> [patches 1,6 - Add and export export helpers to get avg/peak bandwidth 
> and
>  update voltage of an disabled opp respectively]
> 
> [patch 3 - Adds cpu based scaling support to passive governor]
> To achieve this, it listens to CPU frequency transition notifiers
> to keep itself up to date on the current CPU frequency.
> To decide the frequency of the device, the governor depends one of
> the following:
> * Constructs a CPU frequency to device frequency mapping table from
>   required-opps property of the devfreq device's opp_table
> * Scales the device frequency in proportion to the CPU frequency by
>   performing interpolation.

Had a discussion with Viresh and Georgi,
Viresh pointed out cpu based scaling can
be done in a better way by placing the
required-opps in the cpu opp table and
with some changes in the core so dropping
the idea of cpufreq integration into passive
governor for now.

> 
> [patch 7 - Parses and updates opps from the frequency/voltage read from
>  the look up tables]
> 
> The patch series depends on opp-bw-MBs bindings introduced in:
> https://patchwork.kernel.org/cover/10850817/
> 
> Saravana Kannan (2):
>   PM / devfreq: Add cpu based scaling support to passive_governor
>   PM / devfreq: Add devfreq driver for interconnect bandwidth voting
> 
> Sibi Sankar (7):
>   OPP: Add and export helpers to get avg/peak bw
>   OPP: Export a number of helpers to prevent code duplication
>   dt-bindings: devfreq: Add bindings for devfreq dev-icbw driver
>   OPP: Add and export helper to update voltage
>   cpufreq: qcom: Add support to update cpu node's OPP tables
>   arm64: dts: qcom: sdm845: Add cpu OPP tables
>   arm64: dts: qcom: sdm845: Add nodes for icbw driver and opp tables
> 
>  .../devicetree/bindings/devfreq/icbw.txt      | 146 +++++++++
>  arch/arm64/boot/dts/qcom/sdm845.dtsi          | 262 +++++++++++++++++
>  drivers/cpufreq/qcom-cpufreq-hw.c             |  29 +-
>  drivers/devfreq/Kconfig                       |  19 ++
>  drivers/devfreq/Makefile                      |   1 +
>  drivers/devfreq/devfreq_icbw.c                | 132 +++++++++
>  drivers/devfreq/governor_passive.c            | 276 +++++++++++++++++-
>  drivers/opp/core.c                            | 100 +++++++
>  drivers/opp/of.c                              |  13 +-
>  include/linux/devfreq.h                       |  43 ++-
>  include/linux/pm_opp.h                        |  35 +++
>  11 files changed, 1044 insertions(+), 12 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/icbw.txt
>  create mode 100644 drivers/devfreq/devfreq_icbw.c

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor
  2019-03-28 15:28 ` [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor Sibi Sankar
@ 2019-04-12  7:39   ` Chanwoo Choi
  2019-05-27  8:23     ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Chanwoo Choi @ 2019-04-12  7:39 UTC (permalink / raw)
  To: Sibi Sankar, robh+dt, andy.gross, myungjoo.ham, kyungmin.park,
	rjw, viresh.kumar, nm, sboyd, georgi.djakov
  Cc: bjorn.andersson, david.brown, mark.rutland, linux-kernel,
	linux-arm-msm-owner, devicetree, rnayak, linux-pm, evgreen,
	daidavid1, dianders, Saravana Kannan

Hi,

I agree this approach absolutely.
Just I add some comments. Please check it.

On 19. 3. 29. 오전 12:28, Sibi Sankar wrote:
> From: Saravana Kannan <skannan@codeaurora.org>
> 
> Many CPU architectures have caches that can scale independent of the
> CPUs. Frequency scaling of the caches is necessary to make sure the cache
> is not a performance bottleneck that leads to poor performance and
> power. The same idea applies for RAM/DDR.
> 
> To achieve this, this patch add support for cpu based scaling to the
> passive governor. This is accomplished by taking the current frequency
> of each CPU frequency domain and then adjusts the frequency of the cache
> (or any devfreq device) based on the frequency of the CPUs. It listens
> to CPU frequency transition notifiers to keep itself up to date on the
> current CPU frequency.
> 
> To decide the frequency of the device, the governor does one of the
> following:
> * Constructs a CPU frequency to device frequency mapping table from
>   required-opps property of the devfreq device's opp_table
> 
> * Scales the device frequency in proportion to the CPU frequency. So, if
>   the CPUs are running at their max frequency, the device runs at its
>   max frequency. If the CPUs are running at their min frequency, the
>   device runs at its min frequency. It is interpolated for frequencies
>   in between.
> 
> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
> [Sibi: Integrated cpu-freqmap governor into passive_governor]
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  drivers/devfreq/Kconfig            |   4 +
>  drivers/devfreq/governor_passive.c | 276 ++++++++++++++++++++++++++++-
>  include/linux/devfreq.h            |  43 ++++-
>  3 files changed, 315 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 6a172d338f6d..9a45f464a56b 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -72,6 +72,10 @@ config DEVFREQ_GOV_PASSIVE
>  	  device. This governor does not change the frequency by itself
>  	  through sysfs entries. The passive governor recommends that
>  	  devfreq device uses the OPP table to get the frequency/voltage.
> +	  Alternatively the governor can also be chosen to scale based on
> +	  the online CPUs current frequency. A CPU frequency to device
> +	  frequency mapping table(s) is auto-populated by the governor
> +	  for this purpose.
>  
>  comment "DEVFREQ Drivers"
>  
> diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
> index 3bc29acbd54e..2506682b233b 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -11,10 +11,63 @@
>   */
>  
>  #include <linux/module.h>
> +#include <linux/cpu.h>
> +#include <linux/cpufreq.h>
> +#include <linux/cpumask.h>
>  #include <linux/device.h>
>  #include <linux/devfreq.h>
> +#include <linux/of.h>
> +#include <linux/slab.h>
>  #include "governor.h"
>  
> +static unsigned int xlate_cpufreq_to_devfreq(struct devfreq_passive_data *data,
> +					     unsigned int cpu)
> +{
> +	unsigned int cpu_min, cpu_max;
> +	struct devfreq *devfreq = (struct devfreq *)data->this;
> +	unsigned int dev_min, dev_max, cpu_percent, cpu_freq = 0, freq = 0;
> +	unsigned long *freq_table = devfreq->profile->freq_table;
> +	struct device *dev = devfreq->dev.parent;
> +	struct devfreq_map *map;
> +	int opp_cnt, i;
> +
> +	if (!data->state[cpu] || data->state[cpu]->first_cpu != cpu) {
> +		freq = 0;
> +		goto out;

goto out -> return 0;

> +	}
> +
> +	/* Use Interpolation if map is not available */
> +	cpu_freq = data->state[cpu]->freq;
> +	if (!data->map) {
> +		cpu_min = data->state[cpu]->min_freq;
> +		cpu_max = data->state[cpu]->max_freq;
> +		if (freq_table) {
> +			dev_min = freq_table[0];
> +			dev_max = freq_table[devfreq->profile->max_state - 1];

Actually, it is not always true. The devfreq recommend the ascending order for
'freq_table'. But, it is not mandatory. Also, some devfreq device uses the
decending order for 'freq_table'. So, a patch[1] was considering the order
when getting the minimum/maximum frequency from freq_table. 

If you want to get the minimum/maximum frequency, you have to consider the order
of 'freq_table' as the patch[1].

[1] df5cf4a36178 ("PM / devfreq: Fix handling of min/max_freq == 0")

             /* Get minimum frequency according to sorting order */
+               if (freq_table[0] < freq_table[df->profile->max_state - 1])
+                       value = freq_table[0];
+               else
+                       value = freq_table[df->profile->max_state - 1];


> +		} else {
> +			if (devfreq->max_freq <= devfreq->min_freq)
> +				return 0;
> +			dev_min = devfreq->min_freq;
> +			dev_max = devfreq->max_freq;
> +		}
> +
> +		cpu_percent = ((cpu_freq - cpu_min) * 100) / cpu_max - cpu_min;
> +		freq = dev_min + mult_frac(dev_max - dev_min, cpu_percent, 100);
> +		goto out;

You don't need to jump 'out'. Instead, you better to use the 'else' statement
for if data->map is not NULL. I think that almost case when using this patch
will be available of data->map. In order to skip the likely 'false' statement,
I recommend the following sequence.

	if (data->map) {
		map = data->map[cpu];
		...
	} else {
		/* Use Interpolation if map is not available */
	}


> +	}
> +
> +	map = data->map[cpu];
> +	opp_cnt = dev_pm_opp_get_opp_count(dev);
> +	for (i = 0; i < opp_cnt; i++) {
> +		freq = max(freq, map[i].dev_hz);
> +		if (map[i].cpu_khz >= cpu_freq)
> +			break;
> +	}
> +out:
> +	dev_dbg(dev, "CPU%u: %d -> dev: %u\n", cpu, cpu_freq, freq);

IMO, I think it is not necessary. If you want to print log, you better to print
it on device driver instead of governor.

> +	return freq;
> +}
> +
>  static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>  					unsigned long *freq)
>  {
> @@ -23,6 +76,7 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>  	struct devfreq *parent_devfreq = (struct devfreq *)p_data->parent;
>  	unsigned long child_freq = ULONG_MAX;
>  	struct dev_pm_opp *opp;
> +	unsigned int cpu, tgt_freq = 0;

tgt means 'target'? If right, just use target_freq intead of 'tgt_freq'
for the readability.

>  	int i, count, ret = 0;
>  
>  	/*
> @@ -35,6 +89,14 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>  		goto out;
>  	}
>  
> +	if (p_data->cpufreq_type) {
> +		for_each_possible_cpu(cpu)
> +			tgt_freq = max(tgt_freq,
> +				       xlate_cpufreq_to_devfreq(p_data, cpu));
> +		*freq = tgt_freq;

You better to change from 'tgt_freq' to 'target_freq' for the readability.

> +		goto out;
> +	}

I think that 'goto out' using is not proper for supporting two case.
Instead, you better to split out as following according to the type
of parent device (devfreq device or cpufreq device).

	switch (p_data->parent_type) {
	case DEVFREQ_PARENT_DEV:
		ret = get_target_freq_with_devfreq() 
		break;
	case CPUFREQ_PARENT_DEV:
		ret = get_target_freq_with_cpufreq()
		break;
	default:
		dev_err(...)
		ret = -EINVAL;
		goto out;
	}
		
	if (ret < 0) {
		/* exception handling for 'ret' value */
	}

> +
>  	/*
>  	 * If the parent and passive devfreq device uses the OPP table,
>  	 * get the next frequency by using the OPP table.
> @@ -149,6 +211,200 @@ static int devfreq_passive_notifier_call(struct notifier_block *nb,
>  	return NOTIFY_DONE;
>  }
>  
> +static int cpufreq_passive_notifier_call(struct notifier_block *nb,
> +					 unsigned long event, void *ptr)
> +{
> +	struct devfreq_passive_data *data =
> +			container_of(nb, struct devfreq_passive_data, nb);
> +	struct devfreq *devfreq = (struct devfreq *)data->this;
> +	struct cpufreq_freqs *freq = ptr;
> +	struct devfreq_cpu_state *state;

nitpick. how about using 'cpu_state' instead of 'state'?
in order to get the meaning from just variable name.

> +	int ret = 0;
> +
> +	if (event != CPUFREQ_POSTCHANGE)
> +		goto out;

just 'return' is simple instead of 'goto out' because this case  
don't need to treat the any restoring code. And also, you have
to check whether freq is NULL or not as following:

	if (event != CPUFREQ_POSTCHANGE || !freq || data->state[freq->cpu])
		return ret;
	state = data->state[freq->cpu];

> +
> +	state = data->state[freq->cpu];
> +	if (!state)
> +		goto out;
> +
> +	if (state->freq != freq->new) {
> +		state->freq = freq->new;

You have to update the frequency after update_devfreq() is completed without error.

> +		mutex_lock(&devfreq->lock);
> +		ret = update_devfreq(devfreq);
> +		mutex_unlock(&devfreq->lock);
> +		if (ret)
> +			dev_err(&devfreq->dev, "Frequency update failed.\n");

Almost devfreq error used the following format: "Couldn't ..." .
If there is no any specific reason to change the format for error log,
	"Couldnt update the frequency.\n" 

> +	}> +out:
> +	return ret;

Also, we can reduce the unneeded indentation as following:

	if (state->freq == freq->new)
		return ret;
	
	mutex_lock(&devfreq->lock);
	ret = update_devfreq(devfreq);
	mutex_unlock(&devfreq->lock);
	if (ret) {
		dev_err(&devfreq->dev, "Couldnt update the frequency.\n");
		return ret;
	}
	state->freq = freq->new;

	return 0;

> +}
> +
> +static int cpufreq_passive_register(struct devfreq_passive_data **p_data)
> +{
> +	unsigned int cpu;
> +	struct devfreq_map **cpu_map;
> +	struct devfreq_map *map, *per_cpu_map;
> +	struct devfreq_passive_data *data = *p_data;
> +	struct devfreq *devfreq = (struct devfreq *)data->this;
> +	int i, count = 0, opp_cnt = 0, ret = 0, iter_val = 0;
> +	struct device_node *np, *opp_table_np, *cpu_np;
> +	struct opp_table *opp_table, *cpu_opp_tbl;
> +	struct device *dev = devfreq->dev.parent;
> +	struct devfreq_cpu_state *state;
> +	struct dev_pm_opp *opp, *cpu_opp;
> +	struct cpufreq_policy *policy;
> +	struct device *cpu_dev;
> +	u64 cpu_khz, dev_hz;
> +
> +	get_online_cpus();
> +	data->nb.notifier_call = cpufreq_passive_notifier_call;
> +	ret = cpufreq_register_notifier(&data->nb,
> +					CPUFREQ_TRANSITION_NOTIFIER);
> +	if (ret)
> +		return ret;
> +
> +	/* Populate devfreq_cpu_state */
> +	for_each_online_cpu(cpu) {
> +		if (data->state[cpu])
> +			continue;
> +
> +		policy = cpufreq_cpu_get(cpu);
> +		if (policy) {
> +			state = kzalloc(sizeof(*state), GFP_KERNEL);
> +			if (!state)
> +				return -ENOMEM;
> +
> +			state->first_cpu = cpumask_first(policy->related_cpus);
> +			state->freq = policy->cur;
> +			state->min_freq = policy->cpuinfo.min_freq;
> +			state->max_freq = policy->cpuinfo.max_freq;
> +			data->state[cpu] = state;
> +			cpufreq_cpu_put(policy);
> +		} else {
> +			return -EPROBE_DEFER;
> +		}
> +	}
> +
> +	opp_table_np = dev_pm_opp_of_get_opp_desc_node(dev);
> +	if (!opp_table_np)
> +		goto out;
> +
> +	opp_cnt = dev_pm_opp_get_opp_count(dev);
> +	if (opp_cnt <= 0)
> +		goto put_opp_table;
> +
> +	/* Allocate memory for devfreq_map*/
> +	cpu_map = kcalloc(num_possible_cpus(), sizeof(*cpu_map), GFP_KERNEL);
> +	if (!cpu_map)
> +		return -ENOMEM;
> +
> +	for_each_possible_cpu(cpu) {
> +		per_cpu_map = kcalloc(opp_cnt, sizeof(*per_cpu_map),
> +				      GFP_KERNEL);
> +		if (!per_cpu_map)
> +			return -ENOMEM;
> +		cpu_map[cpu] = per_cpu_map;
> +	}
> +	data->map = cpu_map;
> +
> +	/* Populate devfreq_map */
> +	opp_table = dev_pm_opp_get_opp_table(dev);
> +	if (!opp_table)
> +		return -ENOMEM;
> +
> +	for_each_available_child_of_node(opp_table_np, np) {
> +		opp = dev_pm_opp_find_opp_of_np(opp_table, np);
> +		if (IS_ERR(opp))
> +			continue;
> +
> +		dev_hz = dev_pm_opp_get_freq(opp);
> +		dev_pm_opp_put(opp);
> +
> +		count = of_count_phandle_with_args(np, "required-opps", NULL);
> +		for (i = 0; i < count; i++) {
> +			for_each_possible_cpu(cpu) {
> +				cpu_dev = get_cpu_device(cpu);
> +				if (!cpu_dev) {
> +					dev_err(dev, "CPU get device failed.\n");
> +					continue;
> +				}
> +
> +				cpu_np = of_parse_required_opp(np, i);
> +				if (!cpu_np) {
> +					dev_err(dev, "Parsing required opp failed.\n");
> +					continue;
> +				}
> +
> +				/* Get cpu opp-table */
> +				cpu_opp_tbl = dev_pm_opp_get_opp_table(cpu_dev);
> +				if (!cpu_opp_tbl) {
> +					dev_err(dev, "CPU opp table get failed.\n");
> +					goto put_cpu_node;
> +				}
> +
> +				/* Match the cpu opp node from required-opp with
> +				 * the cpu-opp table */
> +				cpu_opp = dev_pm_opp_find_opp_of_np(cpu_opp_tbl,
> +								    cpu_np);
> +				if (!cpu_opp) {
> +					dev_dbg(dev, "CPU opp get failed.\n");
> +					goto put_cpu_opp_table;
> +				}
> +
> +				cpu_khz = dev_pm_opp_get_freq(cpu_opp);
> +				if (cpu_opp && cpu_khz) {
> +					/* Update freq-map if not already set */
> +					map = cpu_map[cpu];
> +					map[iter_val].cpu_khz = cpu_khz / 1000;
> +					map[iter_val].dev_hz = dev_hz;
> +				}
> +				dev_pm_opp_put(cpu_opp);
> +put_cpu_opp_table:
> +				dev_pm_opp_put_opp_table(cpu_opp_tbl);
> +put_cpu_node:
> +				of_node_put(cpu_np);
> +			}
> +		}
> +		iter_val++;
> +	}
> +	dev_pm_opp_put_opp_table(opp_table);
> +put_opp_table:
> +	of_node_put(opp_table_np);
> +out:
> +	put_online_cpus();
> +
> +	/* Update devfreq */
> +	mutex_lock(&devfreq->lock);
> +	ret = update_devfreq(devfreq);
> +	mutex_unlock(&devfreq->lock);
> +	if (ret)
> +		dev_err(dev, "Frequency update failed.\n");
> +
> +	return ret;
> +}
> +
> +static int cpufreq_passive_unregister(struct devfreq_passive_data **p_data)
> +{
> +	int cpu;
> +	struct devfreq_passive_data *data = *p_data;
> +
> +	cpufreq_unregister_notifier(&data->nb,
> +				    CPUFREQ_TRANSITION_NOTIFIER);
> +
> +	for_each_possible_cpu(cpu) {
> +		kfree(data->state[cpu]);
> +		kfree(data->map[cpu]);
> +		data->state[cpu] = NULL;
> +		data->map[cpu] = NULL;
> +	}
> +
> +	kfree(data->map);
> +	data->map = NULL;
> +
> +	return 0;
> +}
> +
>  static int devfreq_passive_event_handler(struct devfreq *devfreq,
>  				unsigned int event, void *data)
>  {
> @@ -159,7 +415,7 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
>  	struct notifier_block *nb = &p_data->nb;
>  	int ret = 0;
>  
> -	if (!parent)
> +	if (!parent && !p_data->cpufreq_type)
>  		return -EPROBE_DEFER;

It makes the fault for the existing devfreq devices with passive governor.
Please remove '!p_data->cpufreq_type' condition.

>  
>  	switch (event) {
> @@ -167,13 +423,21 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
>  		if (!p_data->this)
>  			p_data->this = devfreq;
>  
> -		nb->notifier_call = devfreq_passive_notifier_call;
> -		ret = devm_devfreq_register_notifier(dev, parent, nb,
> -					DEVFREQ_TRANSITION_NOTIFIER);
> +		if (p_data->cpufreq_type) {
> +			ret = cpufreq_passive_register(&p_data);
> +		} else {
> +			nb->notifier_call = devfreq_passive_notifier_call;
> +			ret = devm_devfreq_register_notifier(dev, parent, nb,
> +						DEVFREQ_TRANSITION_NOTIFIER);
> +		}

I suggested the my opinion aboyt 'cpufreq_type' variable below.
You can separte it for more clready with using parent device type.

		if (p_data->parent_type == DEVFREQ_PARENT_DEV)
			...
		else if (p_data->parent_type == CPUFREQ_PARENT_DEV)
			...
		else 
			// error handling

>  		break;
>  	case DEVFREQ_GOV_STOP:
> -		devm_devfreq_unregister_notifier(dev, parent, nb,
> -					DEVFREQ_TRANSITION_NOTIFIER);
> +		if (p_data->cpufreq_type) {
> +			cpufreq_passive_unregister(&p_data);
> +		} else {
> +			devm_devfreq_unregister_notifier(dev, parent, nb,
> +						DEVFREQ_TRANSITION_NOTIFIER);
> +		}

ditto.

>  		break;
>  	default:
>  		break;
> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
> index fbffa74bfc1b..e8235fbe49e6 100644
> --- a/include/linux/devfreq.h
> +++ b/include/linux/devfreq.h
> @@ -265,6 +265,38 @@ struct devfreq_simple_ondemand_data {
>  #endif
>  
>  #if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
> +/**
> + * struct devfreq_cpu_state - holds the per-cpu state
> + * @freq:	holds the current frequency of the cpu.
> + * @min_freq:	holds the min frequency of the cpu.
> + * @max_freq:	holds the max frequency of the cpu.
> + * @first_cpu:	holds the cpumask of the first cpu of a policy.
> + *
> + * This structure stores the required cpu_state of a cpu.
> + * This is auto-populated by the governor.
> + */
> +struct devfreq_cpu_state {
> +	unsigned int freq;
> +	unsigned int min_freq;
> +	unsigned int max_freq;
> +	unsigned int first_cpu;
> +};
> +
> +/**
> + * struct devfreq_map - holds mapping from cpu frequency
> + * to devfreq frequency
> + * @cpu_khz:	holds the cpu frequency in Khz
> + * @dev_hz:	holds the devfreq device frequency in Hz
> + *
> + * This structure stores the lookup table between cpu
> + * and the devfreq device. This is auto-populated by the
> + * governor.
> + */
> +struct devfreq_map {

How about changing the structure name as following or others?
- devfreq_freq_map or devfreq_cpufreq_map or others.

Because this structure name guessing the meaning of mapping
between devfreq frequency and cpufreq frequency.

> +	unsigned int cpu_khz;
> +	unsigned int dev_hz;
> +};
> +
>  /**
>   * struct devfreq_passive_data - void *data fed to struct devfreq
>   *	and devfreq_add_device
> @@ -278,11 +310,13 @@ struct devfreq_simple_ondemand_data {
>   *			the next frequency, should use this callback.
>   * @this:	the devfreq instance of own device.
>   * @nb:		the notifier block for DEVFREQ_TRANSITION_NOTIFIER list
> + * @state:	holds the state min/max/current frequency of all online cpu's

As I commented above, how about using 'cpu_state' instead of 'state'?
in order to get the meaning from just variable name.

nitpick. Also,  I think that you can skip 'holds' from the description
of 'state' variable.


> + * @map:	holds the maps between cpu frequency and device frequency

How about using 'cpufreq_map' instead of 'map' for the readability?
IMHO, Because this variable is only used when parent device is cpu. 
I think that if you add to specify the meaningful prefix about cpu to variable name,
it is easy to catch the meaning of variable.
- map -> cpufreq_map.

nitpick. Also,  I think that you can skip 'holds' from the description
of 'map' variable.

>   *
>   * The devfreq_passive_data have to set the devfreq instance of parent
>   * device with governors except for the passive governor. But, don't need to
> - * initialize the 'this' and 'nb' field because the devfreq core will handle
> - * them.
> + * initialize the 'this', 'nb', 'state' and 'map' field because the devfreq

If you agree my opinion above, 
- state -> cpu_state.
- map -> cpufreq_map

> + * core will handle them.
>   */
>  struct devfreq_passive_data {
>  	/* Should set the devfreq instance of parent device */
> @@ -291,9 +325,14 @@ struct devfreq_passive_data {
>  	/* Optional callback to decide the next frequency of passvice device */
>  	int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
>  
> +	/* Should be set if the devfreq device wants to be scaled with cpu*/
> +	u8 cpufreq_type;

The devfreq devices with passive governor have always parent
either devfreq device or cpufreq device. So, you better to specify
the parent type as following: I think that it is more clear to check
the type of parent device.

	enum devfreq_parent_dev_type {
		DEVFREQ_PARENT_DEV,
		CPUFREQ_PARENT_DEV,
	};

	enum devfreq_parent_dev_type parent_type;

> +
>  	/* For passive governor's internal use. Don't need to set them */
>  	struct devfreq *this;
>  	struct notifier_block nb;
> +	struct devfreq_cpu_state *state[NR_CPUS];
> +	struct devfreq_map **map;

ditto.

>  };
>  #endif
>  
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 1/5] dt-bindings: opp: Introduce bandwidth-MBps bindings
      [irrelevant] ` <20190423132823.7915-2-georgi.djakov@linaro.org>
@ 2019-04-24  8:44   ` Sibi Sankar
      [irrelevant]   ` <e35223d0-80ac-5236-2b8d-7f46cd3a1581@codeaurora.org>
  1 sibling, 0 replies; 200+ results
From: Sibi Sankar @ 2019-04-24  8:44 UTC (permalink / raw)
  To: Georgi Djakov, vireshk, sboyd, nm, robh+dt, mark.rutland, rjw
  Cc: jcrouse, vincent.guittot, bjorn.andersson, amit.kucheria, seansw,
	daidavid1, evgreen, linux-pm, devicetree, linux-kernel,
	linux-arm-msm

Hey Georgi,

On 4/23/19 6:58 PM, Georgi Djakov wrote:
> In addition to frequency and voltage, some devices may have bandwidth
> requirements for their interconnect throughput - for example a CPU
> or GPU may also need to increase or decrease their bandwidth to DDR
> memory based on the current operating performance point.
> 
> Extend the OPP tables with additional property to describe the bandwidth
> needs of a device. The average and peak bandwidth values depend on the
> hardware and its properties.
> 
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
>   Documentation/devicetree/bindings/opp/opp.txt | 38 +++++++++++++++++++
>   .../devicetree/bindings/property-units.txt    |  4 ++
>   2 files changed, 42 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index 76b6c79604a5..830f0206aea7 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -132,6 +132,9 @@ Optional properties:
>   - opp-level: A value representing the performance level of the device,
>     expressed as a 32-bit integer.
>   
> +- bandwidth-MBps: The interconnect bandwidth is specified with an array containing
> +  the two integer values for average and peak bandwidth in megabytes per second.
> +
>   - clock-latency-ns: Specifies the maximum possible transition latency (in
>     nanoseconds) for switching to this OPP from any other OPP.
>   
> @@ -546,3 +549,38 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
>   		};
>   	};
>   };
> +
> +Example 7: bandwidth-MBps:
> +Average and peak bandwidth values for the interconnects between CPU and DDR
> +memory and also between CPU and L3 are defined per each OPP. Bandwidth of both
> +interconnects is scaled together with CPU frequency.
> +
> +/ {
> +	cpus {
> +		CPU0: cpu@0 {
> +			compatible = "arm,cortex-a53", "arm,armv8";
> +			...
> +			operating-points-v2 = <&cpu_opp_table>;
> +			/* path between CPU and DDR memory and CPU and L3 */
> +			interconnects = <&noc MASTER_CPU &noc SLAVE_DDR>,
> +					<&noc MASTER_CPU &noc SLAVE_L3>;
> +		};
> +	};
> +
> +	cpu_opp_table: cpu_opp_table {
> +		compatible = "operating-points-v2";
> +		opp-shared;
> +
> +		opp-200000000 {
> +			opp-hz = /bits/ 64 <200000000>;
> +			/* CPU<->DDR bandwidth: 457 MB/s average, 1525 MB/s peak */
> +			 * CPU<->L3 bandwidth: 914 MB/s average, 3050 MB/s peak */
> +			bandwidth-MBps = <457 1525>, <914 3050>;
> +		};
> +		opp-400000000 {
> +			opp-hz = /bits/ 64 <400000000>;
> +			/* CPU<->DDR bandwidth: 915 MB/s average, 3051 MB/s peak */
> +			 * CPU<->L3 bandwidth: 1828 MB/s average, 6102 MB/s peak */
> +			bandwidth-MBps = <915 3051>, <1828 6102>;
> +		};
> +	};

nit: missed closing braces

> diff --git a/Documentation/devicetree/bindings/property-units.txt b/Documentation/devicetree/bindings/property-units.txt
> index bfd33734faca..9c3dbefcdae8 100644
> --- a/Documentation/devicetree/bindings/property-units.txt
> +++ b/Documentation/devicetree/bindings/property-units.txt
> @@ -41,3 +41,7 @@ Temperature
>   Pressure
>   ----------------------------------------
>   -kpascal	: kiloPascal
> +
> +Throughput
> +----------------------------------------
> +-MBps		: megabytes per second
> 

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v2 1/5] dt-bindings: opp: Introduce bandwidth-MBps bindings
      [irrelevant]     ` <20190424064942.v5g6jr5l3xy5z3xv@vireshk-i7>
@ 2019-04-24  9:00       ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-04-24  9:00 UTC (permalink / raw)
  To: Viresh Kumar, Rajendra Nayak
  Cc: Georgi Djakov, vireshk, sboyd, nm, robh+dt, mark.rutland, rjw,
	jcrouse, vincent.guittot, bjorn.andersson, amit.kucheria, seansw,
	daidavid1, evgreen, linux-pm, devicetree, linux-kernel,
	linux-arm-msm

Hey Viresh,

On 4/24/19 12:19 PM, Viresh Kumar wrote:
> On 24-04-19, 12:16, Rajendra Nayak wrote:
>>
>>
>> On 4/23/2019 6:58 PM, Georgi Djakov wrote:
>>> In addition to frequency and voltage, some devices may have bandwidth
>>> requirements for their interconnect throughput - for example a CPU
>>> or GPU may also need to increase or decrease their bandwidth to DDR
>>> memory based on the current operating performance point.
>>>
>>> Extend the OPP tables with additional property to describe the bandwidth
>>> needs of a device. The average and peak bandwidth values depend on the
>>> hardware and its properties.
>>>
>>> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
>>> ---
>>>    Documentation/devicetree/bindings/opp/opp.txt | 38 +++++++++++++++++++
>>>    .../devicetree/bindings/property-units.txt    |  4 ++
>>>    2 files changed, 42 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
>>> index 76b6c79604a5..830f0206aea7 100644
>>> --- a/Documentation/devicetree/bindings/opp/opp.txt
>>> +++ b/Documentation/devicetree/bindings/opp/opp.txt
>>> @@ -132,6 +132,9 @@ Optional properties:
>>>    - opp-level: A value representing the performance level of the device,
>>>      expressed as a 32-bit integer.
>>> +- bandwidth-MBps: The interconnect bandwidth is specified with an array containing
>>> +  the two integer values for average and peak bandwidth in megabytes per second.
>>> +
>>>    - clock-latency-ns: Specifies the maximum possible transition latency (in
>>>      nanoseconds) for switching to this OPP from any other OPP.
>>> @@ -546,3 +549,38 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
>>>    		};
>>>    	};
>>>    };
>>> +
>>> +Example 7: bandwidth-MBps:
>>> +Average and peak bandwidth values for the interconnects between CPU and DDR
>>> +memory and also between CPU and L3 are defined per each OPP. Bandwidth of both
>>> +interconnects is scaled together with CPU frequency.
>>> +
>>> +/ {
>>> +	cpus {
>>> +		CPU0: cpu@0 {
>>> +			compatible = "arm,cortex-a53", "arm,armv8";
>>> +			...
>>> +			operating-points-v2 = <&cpu_opp_table>;
>>> +			/* path between CPU and DDR memory and CPU and L3 */
>>> +			interconnects = <&noc MASTER_CPU &noc SLAVE_DDR>,
>>> +					<&noc MASTER_CPU &noc SLAVE_L3>;
>>> +		};
>>> +	};
>>> +
>>> +	cpu_opp_table: cpu_opp_table {
>>> +		compatible = "operating-points-v2";
>>> +		opp-shared;
>>> +
>>> +		opp-200000000 {
>>> +			opp-hz = /bits/ 64 <200000000>;
>>> +			/* CPU<->DDR bandwidth: 457 MB/s average, 1525 MB/s peak */
>>> +			 * CPU<->L3 bandwidth: 914 MB/s average, 3050 MB/s peak */
>>> +			bandwidth-MBps = <457 1525>, <914 3050>;
>>
>> Should this also have a bandwidth-MBps-name perhaps? Without that I guess we assume
>> the order in which we specify the interconnects is the same as the order here?
> 
> Right, so I suggested not to add the -name property and to rely on the
> order. Though I missed that he hasn't mentioned the order thing here.

by skipping names, aren't we forced to specify all the specified paths
bandwidths for each opp even if it is redundant? i.e if the first/second
icc path doesn't have to change across a few opps but if the other path
does need to change this scheme would force it to be included and will
try to set the first/second path again.


e.g: Here the first path does not have to change across these two opps
but have to specified nonetheless since we omit names.

+		opp-1200000000 {
+			opp-hz = /bits/ 64 <1200000000>;
+			bandwidth-MBps = <457 1525>, <914 3050>;
+		};
+		opp-1400000000 {
+			opp-hz = /bits/ 64 <1400000000>;
+			bandwidth-MBps = <457 1525>, <1828 6102>;
+		};


> 
> @Georgi: Please mention above in the binding that the order is same as
> interconnects binding.
> 

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[relevance 6%]

* Re: [PATCH v2 4/5] OPP: Update the bandwidth on OPP frequency changes
      [irrelevant] ` <20190423132823.7915-5-georgi.djakov@linaro.org>
@ 2019-04-24 10:05   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-04-24 10:05 UTC (permalink / raw)
  To: Georgi Djakov, vireshk, sboyd, nm, robh+dt, mark.rutland, rjw
  Cc: jcrouse, vincent.guittot, bjorn.andersson, amit.kucheria, seansw,
	daidavid1, evgreen, linux-pm, devicetree, linux-kernel,
	linux-arm-msm

Hey Georgi,

On 4/23/19 6:58 PM, Georgi Djakov wrote:
> If the OPP bandwidth values are populated, we want to switch also the
> interconnect bandwidth in addition to frequency and voltage.
> 
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
>   drivers/opp/core.c | 9 ++++++++-
>   1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 97ee39ecdebd..91d1c2abfb3e 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -707,7 +707,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
>   	unsigned long freq, old_freq;
>   	struct dev_pm_opp *old_opp, *opp;
>   	struct clk *clk;
> -	int ret;
> +	int ret, i;
>   
>   	if (unlikely(!target_freq)) {
>   		dev_err(dev, "%s: Invalid target frequency %lu\n", __func__,
> @@ -780,6 +780,13 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq)
>   		ret = _generic_set_opp_clk_only(dev, clk, freq);
>   	}
>   
> +	if (!ret && !IS_ERR_OR_NULL(opp_table->paths)) {
> +		for (i = 0; i < opp_table->path_count; i++) {
> +			icc_set_bw(opp_table->paths[i], opp->bandwidth[i].avg,
> +				   opp->bandwidth[i].peak);
> +		}
> +	}

An helper funcion dev_pm_opp_set_bw() would be needed by devices that
use alternative ways of scaling like "qcom-cpufreq-hw". I can probably
do that when I get ddr scaling working on sdm845 with your series.

> +
>   	/* Scaling down? Configure required OPPs after frequency */
>   	if (!ret && freq < old_freq) {
>   		ret = _set_required_opps(dev, opp_table, opp);
> 

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[relevance 6%]

* [PATCH v7 4/4] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
      [irrelevant] <20190501043734.26706-1-bjorn.andersson@linaro.org>
  2019-05-01  4:37 ` [PATCH v7 3/4] arm64: dts: qcom: Add AOSS QMP node Bjorn Andersson
@ 2019-05-01  4:37 ` Bjorn Andersson
  2019-05-21 11:13   ` Vinod Koul
      [irrelevant] ` <20190501043734.26706-3-bjorn.andersson@linaro.org>
  2 siblings, 1 reply; 200+ results
From: Bjorn Andersson @ 2019-05-01  4:37 UTC (permalink / raw)
  To: Andy Gross, David Brown
  Cc: Rob Herring, Mark Rutland, Stephen Boyd, linux-arm-msm,
	devicetree, linux-kernel

From: Sibi Sankar <sibis@codeaurora.org>

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v6:
- None

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 666bc88d3e81..2f3ab6acda3d 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1672,6 +1672,64 @@
 			};
 		};
 
+		mss_pil: remoteproc@4080000 {
+			compatible = "qcom,sdm845-mss-pil";
+			reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
+			reg-names = "qdsp6", "rmb";
+
+			interrupts-extended =
+				<&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog", "fatal", "ready",
+					  "handover", "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+				 <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+				 <&gcc GCC_BOOT_ROM_AHB_CLK>,
+				 <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+				 <&gcc GCC_MSS_SNOC_AXI_CLK>,
+				 <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+				 <&gcc GCC_PRNG_AHB_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "iface", "bus", "mem", "gpll0_mss",
+				      "snoc_axi", "mnoc_axi", "prng", "xo";
+
+			qcom,smem-states = <&modem_smp2p_out 0>;
+			qcom,smem-state-names = "stop";
+
+			resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+				 <&pdc_reset PDC_MODEM_SYNC_RESET>;
+			reset-names = "mss_restart", "pdc_reset";
+
+			qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000 0x24000>;
+
+			power-domains = <&aoss_qmp AOSS_QMP_LS_MODEM>,
+					<&rpmhpd SDM845_CX>,
+					<&rpmhpd SDM845_MX>,
+					<&rpmhpd SDM845_MSS>;
+			power-domain-names = "load_state", "cx", "mx", "mss";
+
+			mba {
+				memory-region = <&mba_region>;
+			};
+
+			mpss {
+				memory-region = <&mpss_region>;
+			};
+
+			glink-edge {
+				interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+				label = "modem";
+				qcom,remote-pid = <1>;
+				mboxes = <&apss_shared 12>;
+			};
+		};
+
 		gpucc: clock-controller@5090000 {
 			compatible = "qcom,sdm845-gpucc";
 			reg = <0 0x05090000 0 0x9000>;
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* [PATCH v7 3/4] arm64: dts: qcom: Add AOSS QMP node
      [irrelevant] <20190501043734.26706-1-bjorn.andersson@linaro.org>
@ 2019-05-01  4:37 ` Bjorn Andersson
  2019-05-23 15:12   ` Doug Anderson
  2019-05-01  4:37 ` [PATCH v7 4/4] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
      [irrelevant] ` <20190501043734.26706-3-bjorn.andersson@linaro.org>
  2 siblings, 1 reply; 200+ results
From: Bjorn Andersson @ 2019-05-01  4:37 UTC (permalink / raw)
  To: Andy Gross, David Brown
  Cc: Rob Herring, Mark Rutland, Stephen Boyd, linux-arm-msm,
	devicetree, linux-kernel

The AOSS QMP provides a number of power domains, used for QDSS and
PIL, add the node for this.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v6:
- Added #clock-cells

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index fcb93300ca62..666bc88d3e81 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -14,6 +14,7 @@
 #include <dt-bindings/interconnect/qcom,sdm845.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/phy/phy-qcom-qusb2.h>
+#include <dt-bindings/power/qcom-aoss-qmp.h>
 #include <dt-bindings/power/qcom-rpmpd.h>
 #include <dt-bindings/reset/qcom,sdm845-aoss.h>
 #include <dt-bindings/reset/qcom,sdm845-pdc.h>
@@ -2142,6 +2143,15 @@
 			#reset-cells = <1>;
 		};
 
+		aoss_qmp: qmp@c300000 {
+			compatible = "qcom,sdm845-aoss-qmp";
+			reg = <0 0x0c300000 0 0x100000>;
+			interrupts = <GIC_SPI 389 IRQ_TYPE_EDGE_RISING>;
+			mboxes = <&apss_shared 0>;
+
+			#clock-cells = <0>;
+			#power-domain-cells = <1>;
+		};
+
 		spmi_bus: spmi@c440000 {
 			compatible = "qcom,spmi-pmic-arb";
 			reg = <0 0x0c440000 0 0x1100>,
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* Re: [PATCH v2 2/5] interconnect: Add of_icc_get_by_index() helper function
      [irrelevant] ` <20190423132823.7915-3-georgi.djakov@linaro.org>
@ 2019-05-07 11:59   ` Sibi Sankar
  2019-06-27  5:56     ` Sibi Sankar
  0 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-05-07 11:59 UTC (permalink / raw)
  To: Georgi Djakov, vireshk, sboyd, nm, robh+dt, mark.rutland, rjw
  Cc: jcrouse, vincent.guittot, bjorn.andersson, amit.kucheria, seansw,
	daidavid1, evgreen, linux-pm, devicetree, linux-kernel,
	linux-arm-msm

Hey Georgi,

On 4/23/19 6:58 PM, Georgi Djakov wrote:
> This is the same as the traditional of_icc_get() function, but the
> difference is that it takes index as an argument, instead of name.
> 
> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
> ---
>   drivers/interconnect/core.c  | 45 ++++++++++++++++++++++++++++--------
>   include/linux/interconnect.h |  6 +++++
>   2 files changed, 41 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 871eb4bc4efc..a7c3c262c974 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -295,9 +295,9 @@ static struct icc_node *of_icc_get_from_provider(struct of_phandle_args *spec)
>   }
>   
>   /**
> - * of_icc_get() - get a path handle from a DT node based on name
> + * of_icc_get_by_index() - get a path handle from a DT node based on index
>    * @dev: device pointer for the consumer device
> - * @name: interconnect path name
> + * @idx: interconnect path index
>    *
>    * This function will search for a path between two endpoints and return an
>    * icc_path handle on success. Use icc_put() to release constraints when they
> @@ -309,13 +309,12 @@ static struct icc_node *of_icc_get_from_provider(struct of_phandle_args *spec)
>    * Return: icc_path pointer on success or ERR_PTR() on error. NULL is returned
>    * when the API is disabled or the "interconnects" DT property is missing.
>    */
> -struct icc_path *of_icc_get(struct device *dev, const char *name)
> +struct icc_path *of_icc_get_by_index(struct device *dev, int idx)
>   {
>   	struct icc_path *path = ERR_PTR(-EPROBE_DEFER);
>   	struct icc_node *src_node, *dst_node;
>   	struct device_node *np = NULL;
>   	struct of_phandle_args src_args, dst_args;
> -	int idx = 0;
>   	int ret;
>   
>   	if (!dev || !dev->of_node)
> @@ -335,12 +334,6 @@ struct icc_path *of_icc_get(struct device *dev, const char *name)
>   	 * lets support only global ids and extend this in the future if needed
>   	 * without breaking DT compatibility.
>   	 */
> -	if (name) {
> -		idx = of_property_match_string(np, "interconnect-names", name);
> -		if (idx < 0)
> -			return ERR_PTR(idx);
> -	}
> -
>   	ret = of_parse_phandle_with_args(np, "interconnects",
>   					 "#interconnect-cells", idx * 2,
>   					 &src_args);
> @@ -383,6 +376,38 @@ struct icc_path *of_icc_get(struct device *dev, const char *name)
>   
>   	return path;
>   }
> +
> +/**
> + * of_icc_get() - get a path handle from a DT node based on name
> + * @dev: device pointer for the consumer device
> + * @name: interconnect path name
> + *
> + * This function will search for a path between two endpoints and return an
> + * icc_path handle on success. Use icc_put() to release constraints when they
> + * are not needed anymore.
> + * If the interconnect API is disabled, NULL is returned and the consumer
> + * drivers will still build. Drivers are free to handle this specifically,
> + * but they don't have to.
> + *
> + * Return: icc_path pointer on success or ERR_PTR() on error. NULL is returned
> + * when the API is disabled or the "interconnects" DT property is missing.
> + */
> +struct icc_path *of_icc_get(struct device *dev, const char *name)
> +{
> +	int idx = 0;
> +
> +	if (!dev || !dev->of_node)
> +		return ERR_PTR(-ENODEV);
> +
> +	if (name) {
> +		idx = of_property_match_string(dev->of_node,
> +					       "interconnect-names", name);
> +		if (idx < 0)
> +			return ERR_PTR(idx);
> +	}
> +
> +	return of_icc_get_by_index(dev, idx);
> +}
>   EXPORT_SYMBOL_GPL(of_icc_get);
>   
>   /**
> diff --git a/include/linux/interconnect.h b/include/linux/interconnect.h
> index dc25864755ba..0e430b3b6519 100644
> --- a/include/linux/interconnect.h
> +++ b/include/linux/interconnect.h
> @@ -28,6 +28,7 @@ struct device;
>   struct icc_path *icc_get(struct device *dev, const int src_id,
>   			 const int dst_id);
>   struct icc_path *of_icc_get(struct device *dev, const char *name);
> +struct icc_path *of_icc_get_by_index(struct device *dev, int idx);
>   void icc_put(struct icc_path *path);
>   int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw);
>   
> @@ -45,6 +46,11 @@ static inline struct icc_path *of_icc_get(struct device *dev,
>   	return NULL;
>   }
>   
> +struct icc_path *of_icc_get_by_index(struct device *dev, int idx)

This should be static inline instead

> +{
> +	return NULL;
> +}
> +
>   static inline void icc_put(struct icc_path *path)
>   {
>   }
> 

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[relevance 6%]

* [RFC 1/3] arm64: dts: qcom: sdm845-cheza: add initial cheza dt
      [irrelevant] <20190509184415.11592-1-robdclark@gmail.com>
@ 2019-05-09 18:44 ` Rob Clark
  2019-05-13 22:47   ` Doug Anderson
  0 siblings, 1 reply; 200+ results
From: Rob Clark @ 2019-05-09 18:44 UTC (permalink / raw)
  To: linux-arm-msm
  Cc: Rob Clark, Douglas Anderson, Sibi Sankar, Evan Green,
	Matthias Kaehlcke, Abhinav Kumar, Brian Norris,
	Venkat Gopalakrishnan, Rajendra Nayak, Andy Gross, David Brown,
	Rob Herring, Mark Rutland, devicetree, linux-kernel

From: Rob Clark <robdclark@chromium.org>

This is essentialy a squash of a bunch of history of cheza dt updates
from chromium kernel, some of which were themselves squashes of history
from older chromium kernels.

I don't claim any credit other than wanting to more easily boot upstream
kernel on cheza to have an easier way to test upstream driver work ;-)

I've added below in Cc tags all the original actual authors (apologies
if I missed any).

Cc: Douglas Anderson <dianders@chromium.org>
Cc: Sibi Sankar <sibis@codeaurora.org>
Cc: Evan Green <evgreen@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Abhinav Kumar <abhinavk@codeaurora.org>
Cc: Brian Norris <briannorris@chromium.org>
Cc: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
---
 arch/arm64/boot/dts/qcom/Makefile            |    3 +
 arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts |  238 ++++
 arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts |  238 ++++
 arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts |  180 +++
 arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi   | 1317 ++++++++++++++++++
 5 files changed, 1976 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index b3fe72ff2955..7a038cf81543 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -8,6 +8,9 @@ dtb-$(CONFIG_ARCH_QCOM)	+= msm8994-angler-rev-101.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8996-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-cheza-r1.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-cheza-r2.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-cheza-r3.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts b/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
new file mode 100644
index 000000000000..35bb4629edd4
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Cheza board device tree source
+ *
+ * Copyright 2018 Google LLC.
+ */
+
+/dts-v1/;
+
+#include "sdm845-cheza.dtsi"
+
+/ {
+	model = "Google Cheza (rev1)";
+	compatible = "google,cheza-rev1", "google,cheza", "qcom,sdm845";
+
+	/*
+	 * FIXED REGULATORS (not in sdm845-cheza.dtsi) - parents above children
+	 */
+
+	/*
+	 * NOTE: Technically pp3500_a is not the exact same signal as
+	 * pp3500_a_vbob (there's a load switch between them and the EC can
+	 * control pp3500_a via "en_pp3300_a"), but from the AP's point of
+	 * view they are the same.
+	 */
+	pp3500_a:
+	pp3500_a_vbob: pp3500-a-vbob-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_bob";
+
+		/*
+		 * Comes on automatically when pp5000_ldo comes on, which
+		 * comes on automatically when ppvar_sys comes on
+		 */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3500000>;
+		regulator-max-microvolt = <3500000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp3300_dx_edp: pp3300-dx-edp-regulator {
+		/* Yes, it's really 3.5 despite the name of the signal */
+		regulator-min-microvolt = <3500000>;
+		regulator-max-microvolt = <3500000>;
+
+		vin-supply = <&pp3500_a>;
+	};
+};
+
+/* FIXED REGULATOR OVERRIDES (modifications to sdm845-cheza.dtsi) */
+
+/*
+ * L19 and L28 technically go to 3.3V, but most boards have old AOP firmware
+ * that limits them to 3.0, and trying to run at 3.3V with that old firmware
+ * prevents the system from booting.
+ */
+&src_pp3000_l19a {
+	regulator-min-microvolt = <3008000>;
+	regulator-max-microvolt = <3008000>;
+};
+
+&src_pp3300_l22a {
+	/delete-property/regulator-boot-on;
+	/delete-property/regulator-always-on;
+};
+
+&src_pp3300_l28a {
+	regulator-min-microvolt = <3008000>;
+	regulator-max-microvolt = <3008000>;
+};
+
+&src_vreg_bob {
+	regulator-min-microvolt = <3500000>;
+	regulator-max-microvolt = <3500000>;
+	vin-supply = <&pp3500_a_vbob>;
+};
+
+/*
+ * NON-REGULATOR OVERRIDES
+ * (modifications to sdm845-cheza.dtsi) - alphabetized by dtsi label
+ */
+
+/* PINCTRL - board-specific pinctrl */
+
+&tlmm {
+	gpio-line-names = "AP_SPI_FP_MISO",
+			  "AP_SPI_FP_MOSI",
+			  "AP_SPI_FP_CLK",
+			  "AP_SPI_FP_CS_L",
+			  "UART_AP_TX_DBG_RX",
+			  "UART_DBG_TX_AP_RX",
+			  "",
+			  "FP_RST_L",
+			  "FCAM_EN",
+			  "",
+			  "EDP_BRIJ_IRQ",
+			  "EC_IN_RW_ODL",
+			  "",
+			  "RCAM_MCLK",
+			  "FCAM_MCLK",
+			  "",
+			  "RCAM_EN",
+			  "CCI0_SDA",
+			  "CCI0_SCL",
+			  "CCI1_SDA",
+			  "CCI1_SCL",
+			  "FCAM_RST_L",
+			  "",
+			  "PEN_RST_L",
+			  "PEN_IRQ_L",
+			  "",
+			  "RCAM_VSYNC",
+			  "ESIM_MISO",
+			  "ESIM_MOSI",
+			  "ESIM_CLK",
+			  "ESIM_CS_L",
+			  "AP_PEN_1V8_SDA",
+			  "AP_PEN_1V8_SCL",
+			  "AP_TS_I2C_SDA",
+			  "AP_TS_I2C_SCL",
+			  "RCAM_RST_L",
+			  "",
+			  "AP_EDP_BKLTEN",
+			  "AP_BRD_ID1",
+			  "BOOT_CONFIG_4",
+			  "AMP_IRQ_L",
+			  "EDP_BRIJ_I2C_SDA",
+			  "EDP_BRIJ_I2C_SCL",
+			  "EN_PP3300_DX_EDP",
+			  "SD_CD_ODL",
+			  "BT_UART_RTS",
+			  "BT_UART_CTS",
+			  "BT_UART_RXD",
+			  "BT_UART_TXD",
+			  "AMP_I2C_SDA",
+			  "AMP_I2C_SCL",
+			  "AP_BRD_ID3",
+			  "",
+			  "AP_EC_SPI_CLK",
+			  "AP_EC_SPI_CS_L",
+			  "AP_EC_SPI_MISO",
+			  "AP_EC_SPI_MOSI",
+			  "FORCED_USB_BOOT",
+			  "AMP_BCLK",
+			  "AMP_LRCLK",
+			  "AMP_DOUT",
+			  "AMP_DIN",
+			  "AP_BRD_ID2",
+			  "PEN_PDCT_L",
+			  "HP_MCLK",
+			  "HP_BCLK",
+			  "HP_LRCLK",
+			  "HP_DOUT",
+			  "HP_DIN",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "BT_SLIMBUS_DATA",
+			  "BT_SLIMBUS_CLK",
+			  "AMP_RESET_L",
+			  "",
+			  "FCAM_VSYNC",
+			  "",
+			  "AP_SKU_ID1",
+			  "EC_WOV_BCLK",
+			  "EC_WOV_LRCLK",
+			  "EC_WOV_DOUT",
+			  "",
+			  "",
+			  "AP_H1_SPI_MISO",
+			  "AP_H1_SPI_MOSI",
+			  "AP_H1_SPI_CLK",
+			  "AP_H1_SPI_CS_L",
+			  "",
+			  "AP_SPI_CS0_L",
+			  "AP_SPI_MOSI",
+			  "AP_SPI_MISO",
+			  "",
+			  "",
+			  "AP_SPI_CLK",
+			  "",
+			  "RFFE6_CLK",
+			  "RFFE6_DATA",
+			  "BOOT_CONFIG_1",
+			  "BOOT_CONFIG_2",
+			  "BOOT_CONFIG_0",
+			  "EDP_BRIJ_EN",
+			  "",
+			  "USB_HS_TX_EN",
+			  "UIM2_DATA",
+			  "UIM2_CLK",
+			  "UIM2_RST",
+			  "UIM2_PRESENT",
+			  "UIM1_DATA",
+			  "UIM1_CLK",
+			  "UIM1_RST",
+			  "",
+			  "AP_SKU_ID2",
+			  "SDM_GRFC_8",
+			  "SDM_GRFC_9",
+			  "AP_RST_REQ",
+			  "HP_IRQ",
+			  "TS_RESET_L",
+			  "PEN_EJECT_ODL",
+			  "HUB_RST_L",
+			  "FP_TO_AP_IRQ",
+			  "AP_EC_INT_L",
+			  "",
+			  "",
+			  "TS_INT_L",
+			  "AP_SUSPEND_L",
+			  "SDM_GRFC_3",
+			  "",
+			  "H1_AP_INT_ODL",
+			  "QLINK_REQ",
+			  "QLINK_EN",
+			  "SDM_GRFC_2",
+			  "BOOT_CONFIG_3",
+			  "WMSS_RESET_L",
+			  "SDM_GRFC_0",
+			  "SDM_GRFC_1",
+			  "RFFE3_DATA",
+			  "RFFE3_CLK",
+			  "RFFE4_DATA",
+			  "RFFE4_CLK",
+			  "RFFE5_DATA",
+			  "RFFE5_CLK",
+			  "GNSS_EN",
+			  "WCI2_LTE_COEX_RXD",
+			  "WCI2_LTE_COEX_TXD",
+			  "AP_RAM_ID1",
+			  "AP_RAM_ID2",
+			  "RFFE1_DATA",
+			  "RFFE1_CLK";
+};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts b/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
new file mode 100644
index 000000000000..4359a82d4bb4
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Cheza board device tree source
+ *
+ * Copyright 2018 Google LLC.
+ */
+
+/dts-v1/;
+
+#include "sdm845-cheza.dtsi"
+
+/ {
+	model = "Google Cheza (rev2)";
+	compatible = "google,cheza-rev2", "google,cheza", "qcom,sdm845";
+
+	/*
+	 * FIXED REGULATORS (not in sdm845-cheza.dtsi) - parents above children
+	 */
+
+	/*
+	 * NOTE: Technically pp3500_a is not the exact same signal as
+	 * pp3500_a_vbob (there's a load switch between them and the EC can
+	 * control pp3500_a via "en_pp3300_a"), but from the AP's point of
+	 * view they are the same.
+	 */
+	pp3500_a:
+	pp3500_a_vbob: pp3500-a-vbob-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_bob";
+
+		/*
+		 * Comes on automatically when pp5000_ldo comes on, which
+		 * comes on automatically when ppvar_sys comes on
+		 */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3500000>;
+		regulator-max-microvolt = <3500000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp3300_dx_edp: pp3300-dx-edp-regulator {
+		/* Yes, it's really 3.5 despite the name of the signal */
+		regulator-min-microvolt = <3500000>;
+		regulator-max-microvolt = <3500000>;
+
+		vin-supply = <&pp3500_a>;
+	};
+};
+
+/* FIXED REGULATOR OVERRIDES (modifications to sdm845-cheza.dtsi) */
+
+/*
+ * L19 and L28 technically go to 3.3V, but most boards have old AOP firmware
+ * that limits them to 3.0, and trying to run at 3.3V with that old firmware
+ * prevents the system from booting.
+ */
+&src_pp3000_l19a {
+	regulator-min-microvolt = <3008000>;
+	regulator-max-microvolt = <3008000>;
+};
+
+&src_pp3300_l22a {
+	/delete-property/regulator-boot-on;
+	/delete-property/regulator-always-on;
+};
+
+&src_pp3300_l28a {
+	regulator-min-microvolt = <3008000>;
+	regulator-max-microvolt = <3008000>;
+};
+
+&src_vreg_bob {
+	regulator-min-microvolt = <3500000>;
+	regulator-max-microvolt = <3500000>;
+	vin-supply = <&pp3500_a_vbob>;
+};
+
+/*
+ * NON-REGULATOR OVERRIDES
+ * (modifications to sdm845-cheza.dtsi) - alphabetized by dtsi label
+ */
+
+/* PINCTRL - board-specific pinctrl */
+
+&tlmm {
+	gpio-line-names = "AP_SPI_FP_MISO",
+			  "AP_SPI_FP_MOSI",
+			  "AP_SPI_FP_CLK",
+			  "AP_SPI_FP_CS_L",
+			  "UART_AP_TX_DBG_RX",
+			  "UART_DBG_TX_AP_RX",
+			  "BRIJ_SUSPEND",
+			  "FP_RST_L",
+			  "FCAM_EN",
+			  "",
+			  "EDP_BRIJ_IRQ",
+			  "EC_IN_RW_ODL",
+			  "",
+			  "RCAM_MCLK",
+			  "FCAM_MCLK",
+			  "",
+			  "RCAM_EN",
+			  "CCI0_SDA",
+			  "CCI0_SCL",
+			  "CCI1_SDA",
+			  "CCI1_SCL",
+			  "FCAM_RST_L",
+			  "FPMCU_BOOT0",
+			  "PEN_RST_L",
+			  "PEN_IRQ_L",
+			  "FPMCU_SEL_OD",
+			  "RCAM_VSYNC",
+			  "ESIM_MISO",
+			  "ESIM_MOSI",
+			  "ESIM_CLK",
+			  "ESIM_CS_L",
+			  "AP_PEN_1V8_SDA",
+			  "AP_PEN_1V8_SCL",
+			  "AP_TS_I2C_SDA",
+			  "AP_TS_I2C_SCL",
+			  "RCAM_RST_L",
+			  "",
+			  "AP_EDP_BKLTEN",
+			  "AP_BRD_ID1",
+			  "BOOT_CONFIG_4",
+			  "AMP_IRQ_L",
+			  "EDP_BRIJ_I2C_SDA",
+			  "EDP_BRIJ_I2C_SCL",
+			  "EN_PP3300_DX_EDP",
+			  "SD_CD_ODL",
+			  "BT_UART_RTS",
+			  "BT_UART_CTS",
+			  "BT_UART_RXD",
+			  "BT_UART_TXD",
+			  "AMP_I2C_SDA",
+			  "AMP_I2C_SCL",
+			  "AP_BRD_ID3",
+			  "",
+			  "AP_EC_SPI_CLK",
+			  "AP_EC_SPI_CS_L",
+			  "AP_EC_SPI_MISO",
+			  "AP_EC_SPI_MOSI",
+			  "FORCED_USB_BOOT",
+			  "AMP_BCLK",
+			  "AMP_LRCLK",
+			  "AMP_DOUT",
+			  "AMP_DIN",
+			  "AP_BRD_ID2",
+			  "PEN_PDCT_L",
+			  "HP_MCLK",
+			  "HP_BCLK",
+			  "HP_LRCLK",
+			  "HP_DOUT",
+			  "HP_DIN",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "BT_SLIMBUS_DATA",
+			  "BT_SLIMBUS_CLK",
+			  "AMP_RESET_L",
+			  "",
+			  "FCAM_VSYNC",
+			  "",
+			  "AP_SKU_ID1",
+			  "EC_WOV_BCLK",
+			  "EC_WOV_LRCLK",
+			  "EC_WOV_DOUT",
+			  "",
+			  "",
+			  "AP_H1_SPI_MISO",
+			  "AP_H1_SPI_MOSI",
+			  "AP_H1_SPI_CLK",
+			  "AP_H1_SPI_CS_L",
+			  "",
+			  "AP_SPI_CS0_L",
+			  "AP_SPI_MOSI",
+			  "AP_SPI_MISO",
+			  "",
+			  "",
+			  "AP_SPI_CLK",
+			  "",
+			  "RFFE6_CLK",
+			  "RFFE6_DATA",
+			  "BOOT_CONFIG_1",
+			  "BOOT_CONFIG_2",
+			  "BOOT_CONFIG_0",
+			  "EDP_BRIJ_EN",
+			  "",
+			  "USB_HS_TX_EN",
+			  "UIM2_DATA",
+			  "UIM2_CLK",
+			  "UIM2_RST",
+			  "UIM2_PRESENT",
+			  "UIM1_DATA",
+			  "UIM1_CLK",
+			  "UIM1_RST",
+			  "",
+			  "AP_SKU_ID2",
+			  "SDM_GRFC_8",
+			  "SDM_GRFC_9",
+			  "AP_RST_REQ",
+			  "HP_IRQ",
+			  "TS_RESET_L",
+			  "PEN_EJECT_ODL",
+			  "HUB_RST_L",
+			  "FP_TO_AP_IRQ",
+			  "AP_EC_INT_L",
+			  "",
+			  "",
+			  "TS_INT_L",
+			  "AP_SUSPEND_L",
+			  "SDM_GRFC_3",
+			  "",
+			  "H1_AP_INT_ODL",
+			  "QLINK_REQ",
+			  "QLINK_EN",
+			  "SDM_GRFC_2",
+			  "BOOT_CONFIG_3",
+			  "WMSS_RESET_L",
+			  "SDM_GRFC_0",
+			  "SDM_GRFC_1",
+			  "RFFE3_DATA",
+			  "RFFE3_CLK",
+			  "RFFE4_DATA",
+			  "RFFE4_CLK",
+			  "RFFE5_DATA",
+			  "RFFE5_CLK",
+			  "GNSS_EN",
+			  "WCI2_LTE_COEX_RXD",
+			  "WCI2_LTE_COEX_TXD",
+			  "AP_RAM_ID1",
+			  "AP_RAM_ID2",
+			  "RFFE1_DATA",
+			  "RFFE1_CLK";
+};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts b/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
new file mode 100644
index 000000000000..2c3f815b90c1
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Cheza board device tree source
+ *
+ * Copyright 2018 Google LLC.
+ */
+
+/dts-v1/;
+
+#include "sdm845-cheza.dtsi"
+
+/ {
+	model = "Google Cheza (rev3+)";
+	compatible = "google,cheza-rev15", "google,cheza-rev14",
+		     "google,cheza-rev13", "google,cheza-rev12",
+		     "google,cheza-rev11", "google,cheza-rev10",
+		     "google,cheza-rev9", "google,cheza-rev8",
+		     "google,cheza-rev7", "google,cheza-rev6",
+		     "google,cheza-rev5", "google,cheza-rev4",
+		     "google,cheza-rev3", "google,cheza", "qcom,sdm845";
+};
+
+/* PINCTRL - board-specific pinctrl */
+
+&tlmm {
+	gpio-line-names = "AP_SPI_FP_MISO",
+			  "AP_SPI_FP_MOSI",
+			  "AP_SPI_FP_CLK",
+			  "AP_SPI_FP_CS_L",
+			  "UART_AP_TX_DBG_RX",
+			  "UART_DBG_TX_AP_RX",
+			  "BRIJ_SUSPEND",
+			  "FP_RST_L",
+			  "FCAM_EN",
+			  "",
+			  "EDP_BRIJ_IRQ",
+			  "EC_IN_RW_ODL",
+			  "",
+			  "RCAM_MCLK",
+			  "FCAM_MCLK",
+			  "",
+			  "RCAM_EN",
+			  "CCI0_SDA",
+			  "CCI0_SCL",
+			  "CCI1_SDA",
+			  "CCI1_SCL",
+			  "FCAM_RST_L",
+			  "FPMCU_BOOT0",
+			  "PEN_RST_L",
+			  "PEN_IRQ_L",
+			  "FPMCU_SEL_OD",
+			  "RCAM_VSYNC",
+			  "ESIM_MISO",
+			  "ESIM_MOSI",
+			  "ESIM_CLK",
+			  "ESIM_CS_L",
+			  "AP_PEN_1V8_SDA",
+			  "AP_PEN_1V8_SCL",
+			  "AP_TS_I2C_SDA",
+			  "AP_TS_I2C_SCL",
+			  "RCAM_RST_L",
+			  "",
+			  "AP_EDP_BKLTEN",
+			  "AP_BRD_ID0",
+			  "BOOT_CONFIG_4",
+			  "AMP_IRQ_L",
+			  "EDP_BRIJ_I2C_SDA",
+			  "EDP_BRIJ_I2C_SCL",
+			  "EN_PP3300_DX_EDP",
+			  "SD_CD_ODL",
+			  "BT_UART_RTS",
+			  "BT_UART_CTS",
+			  "BT_UART_RXD",
+			  "BT_UART_TXD",
+			  "AMP_I2C_SDA",
+			  "AMP_I2C_SCL",
+			  "AP_BRD_ID2",
+			  "",
+			  "AP_EC_SPI_CLK",
+			  "AP_EC_SPI_CS_L",
+			  "AP_EC_SPI_MISO",
+			  "AP_EC_SPI_MOSI",
+			  "FORCED_USB_BOOT",
+			  "AMP_BCLK",
+			  "AMP_LRCLK",
+			  "AMP_DOUT",
+			  "AMP_DIN",
+			  "AP_BRD_ID1",
+			  "PEN_PDCT_L",
+			  "HP_MCLK",
+			  "HP_BCLK",
+			  "HP_LRCLK",
+			  "HP_DOUT",
+			  "HP_DIN",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "BT_SLIMBUS_DATA",
+			  "BT_SLIMBUS_CLK",
+			  "AMP_RESET_L",
+			  "",
+			  "FCAM_VSYNC",
+			  "",
+			  "AP_SKU_ID0",
+			  "EC_WOV_BCLK",
+			  "EC_WOV_LRCLK",
+			  "EC_WOV_DOUT",
+			  "",
+			  "",
+			  "AP_H1_SPI_MISO",
+			  "AP_H1_SPI_MOSI",
+			  "AP_H1_SPI_CLK",
+			  "AP_H1_SPI_CS_L",
+			  "",
+			  "AP_SPI_CS0_L",
+			  "AP_SPI_MOSI",
+			  "AP_SPI_MISO",
+			  "",
+			  "",
+			  "AP_SPI_CLK",
+			  "",
+			  "RFFE6_CLK",
+			  "RFFE6_DATA",
+			  "BOOT_CONFIG_1",
+			  "BOOT_CONFIG_2",
+			  "BOOT_CONFIG_0",
+			  "EDP_BRIJ_EN",
+			  "",
+			  "USB_HS_TX_EN",
+			  "UIM2_DATA",
+			  "UIM2_CLK",
+			  "UIM2_RST",
+			  "UIM2_PRESENT",
+			  "UIM1_DATA",
+			  "UIM1_CLK",
+			  "UIM1_RST",
+			  "",
+			  "AP_SKU_ID1",
+			  "SDM_GRFC_8",
+			  "SDM_GRFC_9",
+			  "AP_RST_REQ",
+			  "HP_IRQ",
+			  "TS_RESET_L",
+			  "PEN_EJECT_ODL",
+			  "HUB_RST_L",
+			  "FP_TO_AP_IRQ",
+			  "AP_EC_INT_L",
+			  "",
+			  "",
+			  "TS_INT_L",
+			  "AP_SUSPEND_L",
+			  "SDM_GRFC_3",
+			  /*
+			   * AP_FLASH_WP_L is crossystem ABI. Rev3 schematics
+			   * call it BIOS_FLASH_WP_R_L.
+			   */
+			  "AP_FLASH_WP_L",
+			  "H1_AP_INT_ODL",
+			  "QLINK_REQ",
+			  "QLINK_EN",
+			  "SDM_GRFC_2",
+			  "BOOT_CONFIG_3",
+			  "WMSS_RESET_L",
+			  "SDM_GRFC_0",
+			  "SDM_GRFC_1",
+			  "RFFE3_DATA",
+			  "RFFE3_CLK",
+			  "RFFE4_DATA",
+			  "RFFE4_CLK",
+			  "RFFE5_DATA",
+			  "RFFE5_CLK",
+			  "GNSS_EN",
+			  "WCI2_LTE_COEX_RXD",
+			  "WCI2_LTE_COEX_TXD",
+			  "AP_RAM_ID0",
+			  "AP_RAM_ID1",
+			  "RFFE1_DATA",
+			  "RFFE1_CLK";
+};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
new file mode 100644
index 000000000000..338c92ddd1c3
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -0,0 +1,1317 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Cheza device tree source (common between revisions)
+ *
+ * Copyright 2018 Google LLC.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include "sdm845.dtsi"
+
+/* PMICs depend on spmi_bus label and so must come after SoC */
+#include "pm8005.dtsi"
+#include "pm8998.dtsi"
+
+/ {
+	aliases {
+		bluetooth0 = &bluetooth;
+		hsuart0 = &uart6;
+		serial0 = &uart9;
+		wifi0 = &wifi;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&cros_ec_pwm 0>;
+		enable-gpios = <&tlmm 37 GPIO_ACTIVE_HIGH>;
+		power-supply = <&ppvar_sys>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ap_edp_bklten>;
+	};
+
+	reserved-memory {
+		rmtfs@88f00000 {
+			compatible = "qcom,rmtfs-mem";
+			reg = <0x0 0x88f00000 0x0 0x800000>;
+			no-map;
+
+			qcom,client-id = <1>;
+		};
+	};
+
+	/* FIXED REGULATORS - parents above children */
+
+	/* This is the top level supply and variable voltage */
+	ppvar_sys: ppvar-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "ppvar_sys";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	/* This divides ppvar_sys by 2, so voltage is variable */
+	src_vph_pwr: src-vph-pwr-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "src_vph_pwr";
+
+		/* EC turns on with switchcap_on_l; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp5000_a: pp5000-a-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "pp5000_a";
+
+		/* EC turns on with en_pp5000_a; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	src_vreg_bob: src-vreg-bob-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "src_vreg_bob";
+
+		/* EC turns on with vbob_en; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3600000>;
+		regulator-max-microvolt = <3600000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp3300_dx_edp: pp3300-dx-edp-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_dx_edp";
+
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 43 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		pinctrl-names = "default";
+		pinctrl-0 = <&en_pp3300_dx_edp>;
+	};
+
+	/*
+	 * Apparently RPMh does not provide support for PM8998 S4 because it
+	 * is always-on; model it as a fixed regulator.
+	 */
+	src_pp1800_s4a: pm8998-smps4 {
+		compatible = "regulator-fixed";
+		regulator-name = "src_pp1800_s4a";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&src_vph_pwr>;
+	};
+
+	/* BOARD-SPECIFIC TOP LEVEL NODES */
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pen_eject_odl>;
+
+		pen-insert {
+			label = "Pen Insert";
+			/* Insert = low, eject = high */
+			gpios = <&tlmm 119 GPIO_ACTIVE_LOW>;
+			linux,code = <SW_PEN_INSERTED>;
+			linux,input-type = <EV_SW>;
+			wakeup-source;
+		};
+	};
+
+	panel: panel {
+		compatible ="innolux,p120zdg-bf1";
+		power-supply = <&pp3300_dx_edp>;
+		backlight = <&backlight>;
+		no-hpd;
+
+		ports {
+			panel_in: port {
+				panel_in_edp: endpoint {
+					remote-endpoint = <&sn65dsi86_out>;
+				};
+			};
+		};
+	};
+};
+
+&mpss_region {
+	reg = <0 0x8e000000 0 0x8000000>;
+};
+
+&qspi {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&qspi_clk &qspi_cs0 &qspi_data01>;
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+
+		/*
+		 * In theory chip supports up to 104 MHz and controller up
+		 * to 80 MHz, but above 25 MHz wasn't reliable so we'll use
+		 * that for now.  b:117440651
+		 */
+		spi-max-frequency = <25000000>;
+		spi-tx-bus-width = <2>;
+		spi-rx-bus-width = <2>;
+	};
+};
+
+
+&apps_rsc {
+	pm8998-rpmh-regulators {
+		compatible = "qcom,pm8998-rpmh-regulators";
+		qcom,pmic-id = "a";
+
+		vdd-s1-supply = <&src_vph_pwr>;
+		vdd-s2-supply = <&src_vph_pwr>;
+		vdd-s3-supply = <&src_vph_pwr>;
+		vdd-s4-supply = <&src_vph_pwr>;
+		vdd-s5-supply = <&src_vph_pwr>;
+		vdd-s6-supply = <&src_vph_pwr>;
+		vdd-s7-supply = <&src_vph_pwr>;
+		vdd-s8-supply = <&src_vph_pwr>;
+		vdd-s9-supply = <&src_vph_pwr>;
+		vdd-s10-supply = <&src_vph_pwr>;
+		vdd-s11-supply = <&src_vph_pwr>;
+		vdd-s12-supply = <&src_vph_pwr>;
+		vdd-s13-supply = <&src_vph_pwr>;
+		vdd-l1-l27-supply = <&src_pp1025_s7a>;
+		vdd-l2-l8-l17-supply = <&src_pp1350_s3a>;
+		vdd-l3-l11-supply = <&src_pp1025_s7a>;
+		vdd-l4-l5-supply = <&src_pp1025_s7a>;
+		vdd-l6-supply = <&src_vph_pwr>;
+		vdd-l7-l12-l14-l15-supply = <&src_pp2040_s5a>;
+		vdd-l9-supply = <&src_pp2040_s5a>;
+		vdd-l10-l23-l25-supply = <&src_vreg_bob>;
+		vdd-l13-l19-l21-supply = <&src_vreg_bob>;
+		vdd-l16-l28-supply = <&src_vreg_bob>;
+		vdd-l18-l22-supply = <&src_vreg_bob>;
+		vdd-l20-l24-supply = <&src_vreg_bob>;
+		vdd-l26-supply = <&src_pp1350_s3a>;
+		vin-lvs-1-2-supply = <&src_pp1800_s4a>;
+
+		src_pp1125_s2a: smps2 {
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1100000>;
+		};
+
+		src_pp1350_s3a: smps3 {
+			regulator-min-microvolt = <1352000>;
+			regulator-max-microvolt = <1352000>;
+		};
+
+		src_pp2040_s5a: smps5 {
+			regulator-min-microvolt = <1904000>;
+			regulator-max-microvolt = <2040000>;
+		};
+
+		src_pp1025_s7a: smps7 {
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <1028000>;
+		};
+
+		vdd_qusb_hs0:
+		vdda_hp_pcie_core:
+		vdda_mipi_csi0_0p9:
+		vdda_mipi_csi1_0p9:
+		vdda_mipi_csi2_0p9:
+		vdda_mipi_dsi0_pll:
+		vdda_mipi_dsi1_pll:
+		vdda_qlink_lv:
+		vdda_qlink_lv_ck:
+		vdda_qrefs_0p875:
+		vdda_pcie_core:
+		vdda_pll_cc_ebi01:
+		vdda_pll_cc_ebi23:
+		vdda_sp_sensor:
+		vdda_ufs1_core:
+		vdda_ufs2_core:
+		vdda_usb1_ss_core:
+		vdda_usb2_ss_core:
+		src_pp875_l1a: ldo1 {
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vddpx_10:
+		src_pp1200_l2a: ldo2 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+
+			/* TODO: why??? */
+			regulator-always-on;
+		};
+
+		pp1000_l3a_sdr845: ldo3 {
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vdd_wcss_cx:
+		vdd_wcss_mx:
+		vdda_wcss_pll:
+		src_pp800_l5a: ldo5 {
+			regulator-min-microvolt = <800000>;
+			regulator-max-microvolt = <800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vddpx_13:
+		src_pp1800_l6a: ldo6 {
+			regulator-min-microvolt = <1856000>;
+			regulator-max-microvolt = <1856000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp1800_l7a_wcn3990: ldo7 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1200_l8a: ldo8 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1248000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp1800_dx_pen:
+		src_pp1800_l9a: ldo9 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1800_l10a: ldo10 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp1000_l11a_sdr845: ldo11 {
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1048000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vdd_qfprom:
+		vdd_qfprom_sp:
+		vdda_apc1_cs_1p8:
+		vdda_gfx_cs_1p8:
+		vdda_qrefs_1p8:
+		vdda_qusb_hs0_1p8:
+		vddpx_11:
+		src_pp1800_l12a: ldo12 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vddpx_2:
+		src_pp2950_l13a: ldo13 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1800_l14a: ldo14 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1800_l15a: ldo15 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp2700_l16a: ldo16 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2704000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1300_l17a: ldo17 {
+			regulator-min-microvolt = <1304000>;
+			regulator-max-microvolt = <1304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp2700_l18a: ldo18 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		/*
+		 * NOTE: this rail should have been called
+		 * src_pp3300_l19a in the schematic
+		 */
+		src_pp3000_l19a: ldo19 {
+			regulator-min-microvolt = <3304000>;
+			regulator-max-microvolt = <3304000>;
+
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp2950_l20a: ldo20 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp2950_l21a: ldo21 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp3300_hub:
+		src_pp3300_l22a: ldo22 {
+			regulator-min-microvolt = <3304000>;
+			regulator-max-microvolt = <3304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			/*
+			 * HACK: Should add a usb hub node and driver
+			 * to turn this on and off at suspend/resume time
+			 */
+			regulator-boot-on;
+			regulator-always-on;
+		};
+
+		pp3300_l23a_ch1_wcn3990: ldo23 {
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3312000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vdda_qusb_hs0_3p1:
+		src_pp3075_l24a: ldo24 {
+			regulator-min-microvolt = <3088000>;
+			regulator-max-microvolt = <3088000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp3300_l25a_ch0_wcn3990: ldo25 {
+			regulator-min-microvolt = <3304000>;
+			regulator-max-microvolt = <3304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp1200_hub:
+		vdda_hp_pcie_1p2:
+		vdda_hv_ebi0:
+		vdda_hv_ebi1:
+		vdda_hv_ebi2:
+		vdda_hv_ebi3:
+		vdda_mipi_csi_1p25:
+		vdda_mipi_dsi0_1p2:
+		vdda_mipi_dsi1_1p2:
+		vdda_pcie_1p2:
+		vdda_ufs1_1p2:
+		vdda_ufs2_1p2:
+		vdda_usb1_ss_1p2:
+		vdda_usb2_ss_1p2:
+		src_pp1200_l26a: ldo26 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp3300_dx_pen:
+		src_pp3300_l28a: ldo28 {
+			regulator-min-microvolt = <3304000>;
+			regulator-max-microvolt = <3304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1800_lvs1: lvs1 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+		};
+
+		src_pp1800_lvs2: lvs2 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+		};
+	};
+
+	pm8005-rpmh-regulators {
+		compatible = "qcom,pm8005-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		vdd-s1-supply = <&src_vph_pwr>;
+		vdd-s2-supply = <&src_vph_pwr>;
+		vdd-s3-supply = <&src_vph_pwr>;
+		vdd-s4-supply = <&src_vph_pwr>;
+
+		src_pp600_s3c: smps3 {
+			regulator-min-microvolt = <600000>;
+			regulator-max-microvolt = <600000>;
+		};
+	};
+};
+
+&dsi0 {
+	status = "okay";
+	vdda-supply = <&vdda_mipi_dsi0_1p2>;
+
+	ports {
+		port@1 {
+			endpoint {
+				remote-endpoint = <&sn65dsi86_in>;
+				data-lanes = <0 1 2 3>;
+			};
+		};
+	};
+};
+
+&dsi0_phy {
+	status = "okay";
+	vdds-supply = <&vdda_mipi_dsi0_pll>;
+};
+
+edp_brij_i2c: &i2c3 {
+	status = "okay";
+	clock-frequency = <400000>;
+
+	sn65dsi86_bridge: bridge@2d {
+		compatible = "ti,sn65dsi86";
+		reg = <0x2d>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&edp_brij_en &edp_brij_irq>;
+
+		interrupt-parent = <&tlmm>;
+		interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+
+		enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>;
+
+		vpll-supply = <&src_pp1800_s4a>;
+		vccio-supply = <&src_pp1800_s4a>;
+		vcca-supply = <&src_pp1200_l2a>;
+		vcc-supply = <&src_pp1200_l2a>;
+
+		clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
+		clock-names = "refclk";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				sn65dsi86_in: endpoint {
+					remote-endpoint = <&dsi0_out>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+				sn65dsi86_out: endpoint {
+					remote-endpoint = <&panel_in_edp>;
+				};
+			};
+		};
+	};
+};
+
+ap_pen_1v8: &i2c11 {
+	status = "okay";
+	clock-frequency = <400000>;
+
+	digitizer@9 {
+		compatible = "wacom,w9013", "hid-over-i2c";
+		reg = <0x9>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pen_irq_l>, <&pen_pdct_l>, <&pen_rst_l>;
+
+		vdd-supply = <&pp3300_dx_pen>;
+		vddl-supply = <&pp1800_dx_pen>;
+		post-power-on-delay-ms = <100>;
+
+		interrupt-parent = <&tlmm>;
+		interrupts = <24 IRQ_TYPE_LEVEL_LOW>;
+
+		hid-descr-addr = <0x1>;
+	};
+};
+
+amp_i2c: &i2c12 {
+	status = "okay";
+	clock-frequency = <400000>;
+};
+
+ap_ts_i2c: &i2c14 {
+	status = "okay";
+	clock-frequency = <400000>;
+
+	touchscreen@10 {
+		compatible = "elan,ekth3500";
+		reg = <0x10>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ts_int_l &ts_reset_l>;
+
+		interrupt-parent = <&tlmm>;
+		interrupts = <125 IRQ_TYPE_LEVEL_LOW>;
+
+		vcc33-supply = <&src_pp3300_l28a>;
+
+		reset-gpios = <&tlmm 118 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&lpasscc {
+	status = "okay";
+};
+
+&mdss {
+	status = "okay";
+};
+
+&mdss_mdp {
+	status = "okay";
+};
+
+&qupv3_id_0 {
+	status = "okay";
+};
+
+&qupv3_id_1 {
+	status = "okay";
+};
+
+&sdhc_2 {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdc2_clk &sdc2_cmd &sdc2_data &sd_cd_odl>;
+
+	vmmc-supply = <&src_pp2950_l21a>;
+	vqmmc-supply = <&vddpx_2>;
+
+	cd-gpios = <&tlmm 44 GPIO_ACTIVE_LOW>;
+};
+
+&spi0 {
+	status = "okay";
+	spi-max-frequency = <3000000>;  /* TODO: Drop this? */
+};
+
+&spi5 {
+	status = "okay";
+	spi-max-frequency = <800000>; /* TODO: Drop this */
+	cr50@0 {
+		compatible = "google,cr50";
+		reg = <0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&h1_ap_int_odl>;
+		spi-max-frequency = <800000>;
+		interrupt-parent = <&tlmm>;
+		interrupts = <129 IRQ_TYPE_EDGE_RISING>;
+	};
+};
+
+&spi10 {
+	status = "okay";
+	spi-max-frequency = <3000000>;  /* TODO: Drop this? */
+
+	cros_ec: ec@0 {
+		compatible = "google,cros-ec-spi";
+		reg = <0>;
+		interrupt-parent = <&tlmm>;
+		interrupts = <122 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ec_ap_int_l>;
+		spi-max-frequency = <3000000>;
+
+		cros_ec_pwm: ec-pwm {
+			compatible = "google,cros-ec-pwm";
+			#pwm-cells = <1>;
+		};
+
+		i2c_tunnel: i2c-tunnel {
+			compatible = "google,cros-ec-i2c-tunnel";
+			google,remote-bus = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		pdupdate {
+			compatible = "google,cros-ec-pd-update";
+		};
+	};
+};
+
+#include <arm/cros-ec-keyboard.dtsi>
+#include <arm/cros-ec-sbs.dtsi>
+
+&uart6 {
+	status = "okay";
+
+	bluetooth: wcn3990-bt {
+		compatible = "qcom,wcn3990-bt";
+		vddio-supply = <&src_pp1800_s4a>;
+		vddxo-supply = <&pp1800_l7a_wcn3990>;
+		vddrf-supply = <&src_pp1300_l17a>;
+		vddch0-supply = <&pp3300_l25a_ch0_wcn3990>;
+		max-speed = <3200000>;
+	};
+};
+
+&uart9 {
+	status = "okay";
+};
+
+&ufs_mem_hc {
+	status = "okay";
+	pinctrl-names = "init", "default";
+	pinctrl-0 = <&ufs_dev_reset_assert>;
+	pinctrl-1 = <&ufs_dev_reset_deassert>;
+
+	vcc-supply = <&src_pp2950_l20a>;
+	vcc-max-microamp = <600000>;
+};
+
+&ufs_mem_phy {
+	status = "okay";
+
+	vdda-phy-supply = <&vdda_ufs1_core>;
+	vdda-pll-supply = <&vdda_ufs1_1p2>;
+};
+
+&usb_1 {
+	status = "okay";
+
+	/* We'll use this as USB 2.0 only */
+	qcom,select-utmi-as-pipe-clk;
+};
+
+&usb_1_dwc3 {
+	/*
+	 * The hardware design intends this port to be hooked up in peripheral
+	 * mode, so we'll hardcode it here.  Some details:
+	 * - SDM845 expects only a single Type C connector so it has only one
+	 *   native Type C port but cheza has two Type C connectors.
+	 * - The only source of DP is the single native Type C port.
+	 * - On cheza we want to be able to hook DP up to _either_ of the
+	 *   two Type C connectors and want to be able to achieve 4 lanes of DP.
+	 * - When you configure a Type C port for 4 lanes of DP you lose USB3.
+	 * - In order to make everything work, the native Type C port is always
+	 *   configured as 4-lanes DP so it's always available.
+	 * - The extra USB3 port on SDM845 goes to a USB 3 hub which is then
+	 *   sent to the two Type C connectors.
+	 * - The extra USB2 lines from the native Type C port are always
+	 *   setup as "peripheral" so that we can mux them over to one connector
+	 *   or the other if someone needs the connector configured as a gadget
+	 *   (but they only get USB2 speeds).
+	 *
+	 * All the hardware muxes would allow us to hook things up in different
+	 * ways to some potential benefit for static configurations (you could
+	 * achieve extra USB2 bandwidth by using two different ports for the
+	 * two conenctors or possibly even get USB3 peripheral mode), but in
+	 * each case you end up forcing to disconnect/reconnect an in-use
+	 * USB session in some cases depending on what you hotplug into the
+	 * other connector.  Thus hardcoding this as peripheral makes sense.
+	 */
+	dr_mode = "peripheral";
+
+	/*
+	 * We always need the high speed pins as 4-lanes DP in case someone
+	 * hotplugs a DP peripheral.  Thus limit this port to a max of high
+	 * speed.
+	 */
+	maximum-speed = "high-speed";
+
+	/*
+	 * We don't need the usb3-phy since we run in highspeed mode always, so
+	 * re-define these properties removing the superspeed USB PHY reference.
+	 */
+	phys = <&usb_1_hsphy>;
+	phy-names = "usb2-phy";
+};
+
+&usb_1_hsphy {
+	status = "okay";
+
+	vdd-supply = <&vdda_usb1_ss_core>;
+	vdda-pll-supply = <&vdda_qusb_hs0_1p8>;
+	vdda-phy-dpdm-supply = <&vdda_qusb_hs0_3p1>;
+
+	qcom,imp-res-offset-value = <8>;
+	qcom,hstx-trim-value = <QUSB2_V2_HSTX_TRIM_21_6_MA>;
+	qcom,preemphasis-level = <QUSB2_V2_PREEMPHASIS_5_PERCENT>;
+	qcom,preemphasis-width = <QUSB2_V2_PREEMPHASIS_WIDTH_HALF_BIT>;
+};
+
+&usb_2 {
+	status = "okay";
+};
+
+&usb_2_dwc3 {
+	/* We have this hooked up to a hub and we always use in host mode */
+	dr_mode = "host";
+};
+
+&usb_2_hsphy {
+	status = "okay";
+
+	vdd-supply = <&vdda_usb2_ss_core>;
+	vdda-pll-supply = <&vdda_qusb_hs0_1p8>;
+	vdda-phy-dpdm-supply = <&vdda_qusb_hs0_3p1>;
+
+	qcom,imp-res-offset-value = <8>;
+	qcom,hstx-trim-value = <QUSB2_V2_HSTX_TRIM_22_8_MA>;
+};
+
+&usb_2_qmpphy {
+	status = "okay";
+
+	vdda-phy-supply = <&vdda_usb2_ss_1p2>;
+	vdda-pll-supply = <&vdda_usb2_ss_core>;
+};
+
+&wifi {
+	status = "okay";
+
+	vdd-0.8-cx-mx-supply = <&src_pp800_l5a >;
+	vdd-1.8-xo-supply = <&pp1800_l7a_wcn3990>;
+	vdd-1.3-rfa-supply = <&src_pp1300_l17a>;
+	vdd-3.3-ch0-supply = <&pp3300_l25a_ch0_wcn3990>;
+};
+
+/* PINCTRL - additions to nodes defined in sdm845.dtsi */
+
+&qspi_cs0 {
+	pinconf {
+		pins = "gpio90";
+		bias-disable;
+	};
+};
+
+&qspi_clk {
+	pinconf {
+		pins = "gpio95";
+		bias-disable;
+	};
+};
+
+&qspi_data01 {
+	pinconf {
+		pins = "gpio91", "gpio92";
+
+		/* High-Z when no transfers; nice to park the lines */
+		bias-pull-up;
+	};
+};
+
+&qup_i2c3_default {
+	pinconf {
+		pins = "gpio41", "gpio42";
+		drive-strength = <2>;
+
+		/* Has external pullup */
+		bias-disable;
+	};
+};
+
+&qup_i2c11_default {
+	pinconf {
+		pins = "gpio31", "gpio32";
+		drive-strength = <2>;
+
+		/* Has external pullup */
+		bias-disable;
+	};
+};
+
+&qup_i2c12_default {
+	pinconf {
+		pins = "gpio49", "gpio50";
+		drive-strength = <2>;
+
+		/* Has external pullup */
+		bias-disable;
+	};
+};
+
+&qup_i2c14_default {
+	pinconf {
+		pins = "gpio33", "gpio34";
+		drive-strength = <2>;
+
+		/* Has external pullup */
+		bias-disable;
+	};
+};
+
+&qup_spi0_default {
+	pinconf {
+		pins = "gpio0", "gpio1", "gpio2", "gpio3";
+		drive-strength = <2>;
+		bias-disable;
+	};
+};
+
+&qup_spi5_default {
+	pinconf {
+		pins = "gpio85", "gpio86", "gpio87", "gpio88";
+		drive-strength = <2>;
+		bias-disable;
+	};
+};
+
+&qup_spi10_default {
+	pinconf {
+		pins = "gpio53", "gpio54", "gpio55", "gpio56";
+		drive-strength = <2>;
+		bias-disable;
+	};
+};
+
+&qup_uart6_default {
+	/* Change pinmux to all 4 pins since CTS and RTS are connected */
+	pinmux {
+		pins = "gpio45", "gpio46",
+		       "gpio47", "gpio48";
+	};
+
+	pinconf-cts {
+		/*
+		 * Configure a pull-down on 45 (CTS) to match the pull of
+		 * the Bluetooth module.
+		 */
+		pins = "gpio45";
+		bias-pull-down;
+	};
+
+	pinconf-rts-tx {
+		/* We'll drive 46 (RTS) and 47 (TX), so no pull */
+		pins = "gpio46", "gpio47";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	pinconf-rx {
+		/*
+		 * Configure a pull-up on 48 (RX). This is needed to avoid
+		 * garbage data when the TX pin of the Bluetooth module is
+		 * in tri-state (module powered off or not driving the
+		 * signal yet).
+		 */
+		pins = "gpio48";
+		bias-pull-up;
+	};
+};
+
+&qup_uart9_default {
+	pinconf-tx {
+		pins = "gpio4";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	pinconf-rx {
+		pins = "gpio5";
+		drive-strength = <2>;
+		bias-pull-up;
+	};
+};
+
+/* PINCTRL - board-specific pinctrl */
+&pm8005_gpio {
+	gpio-line-names = "",
+			  "",
+			  "SLB",
+			  "";
+};
+
+&pm8998_adc {
+	adc-chan@ADC5_AMUX_THM1_100K_PU {
+		reg = <ADC5_AMUX_THM1_100K_PU>;
+		label = "sdm_temp";
+	};
+
+	adc-chan@ADC5_AMUX_THM2_100K_PU {
+		reg = <ADC5_AMUX_THM2_100K_PU>;
+		label = "quiet_temp";
+	};
+
+	adc-chan@ADC5_AMUX_THM3_100K_PU {
+		reg = <ADC5_AMUX_THM3_100K_PU>;
+		label = "lte_temp_1";
+	};
+
+	adc-chan@ADC5_AMUX_THM4_100K_PU {
+		reg = <ADC5_AMUX_THM4_100K_PU>;
+		label = "lte_temp_2";
+	};
+
+	adc-chan@ADC5_AMUX_THM5_100K_PU {
+		reg = <ADC5_AMUX_THM5_100K_PU>;
+		label = "charger_temp";
+	};
+};
+
+&pm8998_gpio {
+	gpio-line-names = "",
+			  "",
+			  "SW_CTRL",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "CFG_OPT1",
+			  "WCSS_PWR_REQ",
+			  "",
+			  "CFG_OPT2",
+			  "SLB";
+};
+
+&tlmm {
+	/*
+	 * pinctrl settings for pins that have no real owners.
+	 */
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&bios_flash_wp_r_l>,
+		    <&ap_suspend_l_deassert>;
+
+	pinctrl-1 = <&bios_flash_wp_r_l>,
+		    <&ap_suspend_l_assert>;
+
+	/*
+	 * Hogs prevent usermode from changing the value. A GPIO can be both
+	 * here and in the pinctrl section.
+	 */
+	ap-suspend-l-hog {
+		gpio-hog;
+		gpios = <126 GPIO_ACTIVE_LOW>;
+		output-low;
+	};
+
+	ap_edp_bklten: ap-edp-bklten {
+		pinmux {
+			pins = "gpio37";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio37";
+			drive-strength = <2>;
+			bias-disable;
+		};
+	};
+
+	bios_flash_wp_r_l: bios-flash-wp-r-l {
+		pinmux {
+			pins = "gpio128";
+			function = "gpio";
+			input-enable;
+		};
+
+		pinconf {
+			pins = "gpio128";
+			bias-disable;
+		};
+	};
+
+	ec_ap_int_l: ec-ap-int-l {
+		pinmux {
+		       pins = "gpio122";
+		       function = "gpio";
+		       input-enable;
+		};
+
+		pinconf {
+		       pins = "gpio122";
+		       bias-pull-up;
+		};
+	};
+
+	edp_brij_en: edp-brij-en {
+		pinmux {
+			pins = "gpio102";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio102";
+			drive-strength = <2>;
+			bias-disable;
+		};
+	};
+
+	edp_brij_irq: edp-brij-irq {
+		pinmux {
+			pins = "gpio10";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio10";
+			drive-strength = <2>;
+			bias-pull-down;
+		};
+	};
+
+	en_pp3300_dx_edp: en-pp3300-dx-edp {
+		pinmux {
+			pins = "gpio43";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio43";
+			drive-strength = <2>;
+			bias-disable;
+		};
+	};
+
+	h1_ap_int_odl: h1-ap-int-odl {
+		pinmux {
+			pins = "gpio129";
+			function = "gpio";
+			input-enable;
+		};
+
+		pinconf {
+			pins = "gpio129";
+			bias-pull-up;
+		};
+	};
+
+	pen_eject_odl: pen-eject-odl {
+		pinmux {
+			pins = "gpio119";
+			function = "gpio";
+			bias-pull-up;
+		};
+	};
+
+	pen_irq_l: pen-irq-l {
+		pinmux {
+			pins = "gpio24";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio24";
+
+			/* Has external pullup */
+			bias-disable;
+		};
+	};
+
+	pen_pdct_l: pen-pdct-l {
+		pinmux {
+			pins = "gpio63";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio63";
+
+			/* Has external pullup */
+			bias-disable;
+		};
+	};
+
+	pen_rst_l: pen-rst-l {
+		pinmux  {
+			pins = "gpio23";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio23";
+			bias-disable;
+			drive-strength = <2>;
+
+			/*
+			 * The pen driver doesn't currently support
+			 * driving this reset line.  By specifying
+			 * output-high here we're relying on the fact
+			 * that this pin has a default pulldown at boot
+			 * (which makes sure the pen was in reset if it
+			 * was powered) and then we set it high here to
+			 * take it out of reset.  Better would be if the
+			 * pen driver could control this and we could
+			 * remove "output-high" here.
+			 */
+			output-high;
+		};
+	};
+
+	sdc2_clk: sdc2-clk {
+		pinconf {
+			pins = "sdc2_clk";
+			bias-disable;
+
+			/*
+			 * It seems that mmc_test reports errors if drive
+			 * strength is not 16.
+			 */
+			drive-strength = <16>;
+		};
+	};
+
+	sdc2_cmd: sdc2-cmd {
+		pinconf {
+			pins = "sdc2_cmd";
+			bias-pull-up;
+			drive-strength = <16>;
+		};
+	};
+
+	sdc2_data: sdc2-data {
+		pinconf {
+			pins = "sdc2_data";
+			bias-pull-up;
+			drive-strength = <16>;
+		};
+	};
+
+	sd_cd_odl: sd-cd-odl {
+		pinmux {
+			pins = "gpio44";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio44";
+			bias-pull-up;
+		};
+	};
+
+	ts_int_l: ts-int-l {
+		pinmux  {
+			pins = "gpio125";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio125";
+			bias-pull-up;
+		};
+	};
+
+	ts_reset_l: ts-reset-l {
+		pinmux  {
+			pins = "gpio118";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio118";
+			bias-disable;
+			drive-strength = <2>;
+		};
+	};
+
+	ufs_dev_reset_assert: ufs_dev_reset_assert {
+		config {
+			pins = "ufs_reset";
+			bias-pull-down;		/* default: pull down */
+			/*
+			 * UFS_RESET driver strengths are having
+			 * different values/steps compared to typical
+			 * GPIO drive strengths.
+			 *
+			 * Following table clarifies:
+			 *
+			 * HDRV value | UFS_RESET | Typical GPIO
+			 *   (dec)    |   (mA)    |    (mA)
+			 *     0      |   0.8     |    2
+			 *     1      |   1.55    |    4
+			 *     2      |   2.35    |    6
+			 *     3      |   3.1     |    8
+			 *     4      |   3.9     |    10
+			 *     5      |   4.65    |    12
+			 *     6      |   5.4     |    14
+			 *     7      |   6.15    |    16
+			 *
+			 * POR value for UFS_RESET HDRV is 3 which means
+			 * 3.1mA and we want to use that. Hence just
+			 * specify 8mA to "drive-strength" binding and
+			 * that should result into writing 3 to HDRV
+			 * field.
+			 */
+			drive-strength = <8>;	/* default: 3.1 mA */
+			output-low; /* active low reset */
+		};
+	};
+
+	ufs_dev_reset_deassert: ufs_dev_reset_deassert {
+		config {
+			pins = "ufs_reset";
+			bias-pull-down;		/* default: pull down */
+			/*
+			 * default: 3.1 mA
+			 * check comments under ufs_dev_reset_assert
+			 */
+			drive-strength = <8>;
+			output-high; /* active low reset */
+		};
+	};
+
+	ap_suspend_l_assert: ap_suspend_l_assert {
+		config {
+			pins = "gpio126";
+			function = "gpio";
+			bias-no-pull;
+			drive-strength = <2>;
+			output-low;
+		};
+	};
+
+	ap_suspend_l_deassert: ap_suspend_l_deassert {
+		config {
+			pins = "gpio126";
+			function = "gpio";
+			bias-no-pull;
+			drive-strength = <2>;
+			output-high;
+		};
+	};
+};
-- 
2.20.1


^ permalink raw reply	[relevance 2%]

* [PATCH v4 0/9] RPMPD for QCS404 and MSM8998
@ 2019-05-13 10:20 Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
                   ` (8 more replies)
  0 siblings, 9 replies; 200+ results
From: Sibi Sankar @ 2019-05-13 10:20 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, agross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm,
	devicetree, rnayak, marc.w.gonzalez, Sibi Sankar

Re-worked the macros of the rpmpd driver. Add power domains support
for QCS404 and MSM8998.

V4:
* fixup fixes tag and commit message in patch 1 [Marc]
* fixup typos in qcs404 and msm8998 dt nodes
* fixup comments regarding resource type in patch 8 [Marc]

V3:
* always send level updates to vfc and vfl in set_performance state
* fixup commit messages [Rajendra]
* fixup s-o-b ordering

V2:
* Add rpmpd support for msm8998
* fixup corner/vfc with vlfl/vfl

Bjorn Andersson (4):
  soc: qcom: rpmpd: Modify corner defining macros
  dt-bindings: power: Add rpm power domain bindings for qcs404
  soc: qcom: rpmpd: Add QCS404 power-domains
  arm64: dts: qcom: qcs404: Add rpmpd node

Sibi Sankar (5):
  soc: qcom: rpmpd: fixup rpmpd set performance state
  soc: qcom: rpmpd: Add support to set rpmpd state to max
  dt-bindings: power: Add rpm power domain bindings for msm8998
  soc: qcom: rpmpd: Add MSM8998 power-domains
  arm64: dts: qcom: msm8998: Add rpmpd node

 .../devicetree/bindings/power/qcom,rpmpd.txt  |   2 +
 arch/arm64/boot/dts/qcom/msm8998.dtsi         |  51 +++++++
 arch/arm64/boot/dts/qcom/qcs404.dtsi          |  55 +++++++
 drivers/soc/qcom/rpmpd.c                      | 134 ++++++++++++++----
 include/dt-bindings/power/qcom-rpmpd.h        |  34 +++++
 5 files changed, 252 insertions(+), 24 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 14%]

* [PATCH v4 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state
  2019-05-13 10:20 [PATCH v4 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
@ 2019-05-13 10:20 ` Sibi Sankar
  2019-05-21 11:39   ` Vinod Koul
  2019-05-13 10:20 ` [PATCH v4 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max Sibi Sankar
                   ` (7 subsequent siblings)
  8 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-05-13 10:20 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, agross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm,
	devicetree, rnayak, marc.w.gonzalez, Sibi Sankar

Remoteproc q6v5-mss calls set_performace_state with INT_MAX on
rpmpd. This is currently ignored since it is greater than the
max supported state. Fixup rpmpd state to max if the required
state is greater than all the supported states.

Fixes: 075d3db8d10d ("soc: qcom: rpmpd: Add support for get/set performance state")

Reviewed-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 005326050c23..235d01870dd8 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -226,7 +226,7 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
 	struct rpmpd *pd = domain_to_rpmpd(domain);
 
 	if (state > MAX_RPMPD_STATE)
-		goto out;
+		state = MAX_RPMPD_STATE;
 
 	mutex_lock(&rpmpd_lock);
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 22%]

* [PATCH v4 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max
  2019-05-13 10:20 [PATCH v4 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
@ 2019-05-13 10:20 ` Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 3/9] soc: qcom: rpmpd: Modify corner defining macros Sibi Sankar
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-05-13 10:20 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, agross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm,
	devicetree, rnayak, marc.w.gonzalez, Sibi Sankar

rpmpd max state varies across SoCs and SoC families, add support
in the driver to make it SoC/SoC family specific

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 235d01870dd8..94015ece40e9 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -25,7 +25,7 @@
 #define KEY_ENABLE		0x6e657773 /* swen */
 #define KEY_FLOOR_CORNER	0x636676   /* vfc */
 
-#define MAX_RPMPD_STATE		6
+#define MAX_8996_RPMPD_STATE	6
 
 #define DEFINE_RPMPD_CORNER_SMPA(_platform, _name, _active, r_id)		\
 	static struct rpmpd _platform##_##_active;			\
@@ -83,12 +83,14 @@ struct rpmpd {
 	const int res_type;
 	const int res_id;
 	struct qcom_smd_rpm *rpm;
+	unsigned int max_state;
 	__le32 key;
 };
 
 struct rpmpd_desc {
 	struct rpmpd **rpmpds;
 	size_t num_pds;
+	unsigned int max_state;
 };
 
 static DEFINE_MUTEX(rpmpd_lock);
@@ -114,6 +116,7 @@ static struct rpmpd *msm8996_rpmpds[] = {
 static const struct rpmpd_desc msm8996_desc = {
 	.rpmpds = msm8996_rpmpds,
 	.num_pds = ARRAY_SIZE(msm8996_rpmpds),
+	.max_state = MAX_8996_RPMPD_STATE,
 };
 
 static const struct of_device_id rpmpd_match_table[] = {
@@ -225,8 +228,8 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
 	int ret = 0;
 	struct rpmpd *pd = domain_to_rpmpd(domain);
 
-	if (state > MAX_RPMPD_STATE)
-		state = MAX_RPMPD_STATE;
+	if (state > pd->max_state)
+		state = pd->max_state;
 
 	mutex_lock(&rpmpd_lock);
 
@@ -287,6 +290,7 @@ static int rpmpd_probe(struct platform_device *pdev)
 		}
 
 		rpmpds[i]->rpm = rpm;
+		rpmpds[i]->max_state = desc->max_state;
 		rpmpds[i]->pd.power_off = rpmpd_power_off;
 		rpmpds[i]->pd.power_on = rpmpd_power_on;
 		rpmpds[i]->pd.set_performance_state = rpmpd_set_performance;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* [PATCH v4 3/9] soc: qcom: rpmpd: Modify corner defining macros
  2019-05-13 10:20 [PATCH v4 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 2/9] soc: qcom: rpmpd: Add support to set rpmpd state to max Sibi Sankar
@ 2019-05-13 10:20 ` Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404 Sibi Sankar
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-05-13 10:20 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, agross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm,
	devicetree, rnayak, marc.w.gonzalez, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

QCS404 uses individual resource type magic for each power-domain, so
adjust the macros slightly to make them reusable for this.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[sibi: Extend rpmpd corner pair to a generic rpmpd pair]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 38 +++++++++++++++++---------------------
 1 file changed, 17 insertions(+), 21 deletions(-)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 94015ece40e9..bac4499c269d 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -16,7 +16,8 @@
 
 #define domain_to_rpmpd(domain) container_of(domain, struct rpmpd, pd)
 
-/* Resource types */
+/* Resource types:
+ * RPMPD_X is X encoded as a little-endian, lower-case, ASCII string */
 #define RPMPD_SMPA 0x61706d73
 #define RPMPD_LDOA 0x616f646c
 
@@ -27,46 +28,41 @@
 
 #define MAX_8996_RPMPD_STATE	6
 
-#define DEFINE_RPMPD_CORNER_SMPA(_platform, _name, _active, r_id)		\
+#define DEFINE_RPMPD_PAIR(_platform, _name, _active, r_type, r_key,	\
+			  r_id)						\
 	static struct rpmpd _platform##_##_active;			\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = {	.name = #_name,	},				\
 		.peer = &_platform##_##_active,				\
-		.res_type = RPMPD_SMPA,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
-		.key = KEY_CORNER,					\
+		.key = KEY_##r_key,					\
 	};								\
 	static struct rpmpd _platform##_##_active = {			\
 		.pd = { .name = #_active, },				\
 		.peer = &_platform##_##_name,				\
 		.active_only = true,					\
-		.res_type = RPMPD_SMPA,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
-		.key = KEY_CORNER,					\
+		.key = KEY_##r_key,					\
 	}
 
-#define DEFINE_RPMPD_CORNER_LDOA(_platform, _name, r_id)			\
+#define DEFINE_RPMPD_CORNER(_platform, _name, r_type, r_id)		\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = { .name = #_name, },				\
-		.res_type = RPMPD_LDOA,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
 		.key = KEY_CORNER,					\
 	}
 
-#define DEFINE_RPMPD_VFC(_platform, _name, r_id, r_type)		\
+#define DEFINE_RPMPD_VFC(_platform, _name, r_type, r_id)		\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = { .name = #_name, },				\
-		.res_type = r_type,					\
+		.res_type = RPMPD_##r_type,				\
 		.res_id = r_id,						\
 		.key = KEY_FLOOR_CORNER,				\
 	}
 
-#define DEFINE_RPMPD_VFC_SMPA(_platform, _name, r_id)			\
-	DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_SMPA)
-
-#define DEFINE_RPMPD_VFC_LDOA(_platform, _name, r_id)			\
-	DEFINE_RPMPD_VFC(_platform, _name, r_id, RPMPD_LDOA)
-
 struct rpmpd_req {
 	__le32 key;
 	__le32 nbytes;
@@ -96,12 +92,12 @@ struct rpmpd_desc {
 static DEFINE_MUTEX(rpmpd_lock);
 
 /* msm8996 RPM Power domains */
-DEFINE_RPMPD_CORNER_SMPA(msm8996, vddcx, vddcx_ao, 1);
-DEFINE_RPMPD_CORNER_SMPA(msm8996, vddmx, vddmx_ao, 2);
-DEFINE_RPMPD_CORNER_LDOA(msm8996, vddsscx, 26);
+DEFINE_RPMPD_PAIR(msm8996, vddcx, vddcx_ao, SMPA, CORNER, 1);
+DEFINE_RPMPD_PAIR(msm8996, vddmx, vddmx_ao, SMPA, CORNER, 2);
+DEFINE_RPMPD_CORNER(msm8996, vddsscx, LDOA, 26);
 
-DEFINE_RPMPD_VFC_SMPA(msm8996, vddcx_vfc, 1);
-DEFINE_RPMPD_VFC_LDOA(msm8996, vddsscx_vfc, 26);
+DEFINE_RPMPD_VFC(msm8996, vddcx_vfc, SMPA, 1);
+DEFINE_RPMPD_VFC(msm8996, vddsscx_vfc, LDOA, 26);
 
 static struct rpmpd *msm8996_rpmpds[] = {
 	[MSM8996_VDDCX] =	&msm8996_vddcx,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 20%]

* [PATCH v4 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404
  2019-05-13 10:20 [PATCH v4 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (2 preceding siblings ...)
  2019-05-13 10:20 ` [PATCH v4 3/9] soc: qcom: rpmpd: Modify corner defining macros Sibi Sankar
@ 2019-05-13 10:20 ` Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 5/9] soc: qcom: rpmpd: Add QCS404 power-domains Sibi Sankar
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-05-13 10:20 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, agross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm,
	devicetree, rnayak, marc.w.gonzalez, Rob Herring, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

Add RPM power domain bindings for the qcs404 family of SoC

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
[sibis: Add supported rpmpd states for qcs404]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 .../devicetree/bindings/power/qcom,rpmpd.txt  |  1 +
 include/dt-bindings/power/qcom-rpmpd.h        | 22 +++++++++++++++++++
 2 files changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
index 980e5413d18f..172ccf940c5c 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
@@ -6,6 +6,7 @@ which then translates it into a corresponding voltage on a rail
 Required Properties:
  - compatible: Should be one of the following
 	* qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of SoC
+	* qcom,qcs404-rpmpd: RPM Power domain for the qcs404 family of SoC
 	* qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
  - #power-domain-cells: number of cells in Power domain specifier
 	must be 1.
diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
index 87d9c6611682..450378662944 100644
--- a/include/dt-bindings/power/qcom-rpmpd.h
+++ b/include/dt-bindings/power/qcom-rpmpd.h
@@ -36,4 +36,26 @@
 #define MSM8996_VDDSSCX		5
 #define MSM8996_VDDSSCX_VFC	6
 
+/* QCS404 Power Domains */
+#define QCS404_VDDMX		0
+#define QCS404_VDDMX_AO		1
+#define QCS404_VDDMX_VFL	2
+#define QCS404_LPICX		3
+#define QCS404_LPICX_VFL	4
+#define QCS404_LPIMX		5
+#define QCS404_LPIMX_VFL	6
+
+/* RPM SMD Power Domain performance levels */
+#define RPM_SMD_LEVEL_RETENTION       16
+#define RPM_SMD_LEVEL_RETENTION_PLUS  32
+#define RPM_SMD_LEVEL_MIN_SVS         48
+#define RPM_SMD_LEVEL_LOW_SVS         64
+#define RPM_SMD_LEVEL_SVS             128
+#define RPM_SMD_LEVEL_SVS_PLUS        192
+#define RPM_SMD_LEVEL_NOM             256
+#define RPM_SMD_LEVEL_NOM_PLUS        320
+#define RPM_SMD_LEVEL_TURBO           384
+#define RPM_SMD_LEVEL_TURBO_NO_CPR    416
+#define RPM_SMD_LEVEL_BINNING         512
+
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 22%]

* [PATCH v4 5/9] soc: qcom: rpmpd: Add QCS404 power-domains
  2019-05-13 10:20 [PATCH v4 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (3 preceding siblings ...)
  2019-05-13 10:20 ` [PATCH v4 4/9] dt-bindings: power: Add rpm power domain bindings for qcs404 Sibi Sankar
@ 2019-05-13 10:20 ` Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 6/9] arm64: dts: qcom: qcs404: Add rpmpd node Sibi Sankar
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-05-13 10:20 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, agross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm,
	devicetree, rnayak, marc.w.gonzalez, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

Add the shared cx/mx and the low-power-island's cx and mx power-domains
found on QCS404.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[sibi: Fixup corner/vfc with vlfl/vfl]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 52 +++++++++++++++++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index bac4499c269d..63db8b26642c 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -20,11 +20,16 @@
  * RPMPD_X is X encoded as a little-endian, lower-case, ASCII string */
 #define RPMPD_SMPA 0x61706d73
 #define RPMPD_LDOA 0x616f646c
+#define RPMPD_RWMX 0x786d7772
+#define RPMPD_RWLC 0x636c7772
+#define RPMPD_RWLM 0x6d6c7772
 
 /* Operation Keys */
 #define KEY_CORNER		0x6e726f63 /* corn */
 #define KEY_ENABLE		0x6e657773 /* swen */
 #define KEY_FLOOR_CORNER	0x636676   /* vfc */
+#define KEY_FLOOR_LEVEL		0x6c6676   /* vfl */
+#define KEY_LEVEL		0x6c766c76 /* vlvl */
 
 #define MAX_8996_RPMPD_STATE	6
 
@@ -55,6 +60,14 @@
 		.key = KEY_CORNER,					\
 	}
 
+#define DEFINE_RPMPD_LEVEL(_platform, _name, r_type, r_id)		\
+	static struct rpmpd _platform##_##_name = {			\
+		.pd = { .name = #_name, },				\
+		.res_type = RPMPD_##r_type,				\
+		.res_id = r_id,						\
+		.key = KEY_LEVEL,					\
+	}
+
 #define DEFINE_RPMPD_VFC(_platform, _name, r_type, r_id)		\
 	static struct rpmpd _platform##_##_name = {			\
 		.pd = { .name = #_name, },				\
@@ -63,6 +76,14 @@
 		.key = KEY_FLOOR_CORNER,				\
 	}
 
+#define DEFINE_RPMPD_VFL(_platform, _name, r_type, r_id)		\
+	static struct rpmpd _platform##_##_name = {			\
+		.pd = { .name = #_name, },				\
+		.res_type = RPMPD_##r_type,				\
+		.res_id = r_id,						\
+		.key = KEY_FLOOR_LEVEL,					\
+	}
+
 struct rpmpd_req {
 	__le32 key;
 	__le32 nbytes;
@@ -115,8 +136,35 @@ static const struct rpmpd_desc msm8996_desc = {
 	.max_state = MAX_8996_RPMPD_STATE,
 };
 
+/* qcs404 RPM Power domains */
+DEFINE_RPMPD_PAIR(qcs404, vddmx, vddmx_ao, RWMX, LEVEL, 0);
+DEFINE_RPMPD_VFL(qcs404, vddmx_vfl, RWMX, 0);
+
+DEFINE_RPMPD_LEVEL(qcs404, vdd_lpicx, RWLC, 0);
+DEFINE_RPMPD_VFL(qcs404, vdd_lpicx_vfl, RWLC, 0);
+
+DEFINE_RPMPD_LEVEL(qcs404, vdd_lpimx, RWLM, 0);
+DEFINE_RPMPD_VFL(qcs404, vdd_lpimx_vfl, RWLM, 0);
+
+static struct rpmpd *qcs404_rpmpds[] = {
+	[QCS404_VDDMX] = &qcs404_vddmx,
+	[QCS404_VDDMX_AO] = &qcs404_vddmx_ao,
+	[QCS404_VDDMX_VFL] = &qcs404_vddmx_vfl,
+	[QCS404_LPICX] = &qcs404_vdd_lpicx,
+	[QCS404_LPICX_VFL] = &qcs404_vdd_lpicx_vfl,
+	[QCS404_LPIMX] = &qcs404_vdd_lpimx,
+	[QCS404_LPIMX_VFL] = &qcs404_vdd_lpimx_vfl,
+};
+
+static const struct rpmpd_desc qcs404_desc = {
+	.rpmpds = qcs404_rpmpds,
+	.num_pds = ARRAY_SIZE(qcs404_rpmpds),
+	.max_state = RPM_SMD_LEVEL_BINNING,
+};
+
 static const struct of_device_id rpmpd_match_table[] = {
 	{ .compatible = "qcom,msm8996-rpmpd", .data = &msm8996_desc },
+	{ .compatible = "qcom,qcs404-rpmpd", .data = &qcs404_desc },
 	{ }
 };
 
@@ -231,7 +279,9 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
 
 	pd->corner = state;
 
-	if (!pd->enabled && pd->key != KEY_FLOOR_CORNER)
+	/* Always send updates for vfc and vfl */
+	if (!pd->enabled && pd->key != KEY_FLOOR_CORNER &&
+	    pd->key != KEY_FLOOR_LEVEL)
 		goto out;
 
 	ret = rpmpd_aggregate_corner(pd);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 20%]

* [PATCH v4 6/9] arm64: dts: qcom: qcs404: Add rpmpd node
  2019-05-13 10:20 [PATCH v4 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (4 preceding siblings ...)
  2019-05-13 10:20 ` [PATCH v4 5/9] soc: qcom: rpmpd: Add QCS404 power-domains Sibi Sankar
@ 2019-05-13 10:20 ` Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 7/9] dt-bindings: power: Add rpm power domain bindings for msm8998 Sibi Sankar
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-05-13 10:20 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, agross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm,
	devicetree, rnayak, marc.w.gonzalez, Sibi Sankar

From: Bjorn Andersson <bjorn.andersson@linaro.org>

Add the rpmpd node on the qcs404 and define the available levels.

Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[sibis: fixup available levels]
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/qcs404.dtsi | 55 ++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index ffedf9640af7..d1484480c237 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -4,6 +4,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/qcom,gcc-qcs404.h>
 #include <dt-bindings/clock/qcom,rpmcc.h>
+#include <dt-bindings/power/qcom-rpmpd.h>
 
 / {
 	interrupt-parent = <&intc>;
@@ -230,6 +231,60 @@
 				compatible = "qcom,rpmcc-qcs404";
 				#clock-cells = <1>;
 			};
+
+			rpmpd: power-controller {
+				compatible = "qcom,qcs404-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 = <RPM_SMD_LEVEL_RETENTION>;
+					};
+
+					rpmpd_opp_ret_plus: opp2 {
+						opp-level = <RPM_SMD_LEVEL_RETENTION_PLUS>;
+					};
+
+					rpmpd_opp_min_svs: opp3 {
+						opp-level = <RPM_SMD_LEVEL_MIN_SVS>;
+					};
+
+					rpmpd_opp_low_svs: opp4 {
+						opp-level = <RPM_SMD_LEVEL_LOW_SVS>;
+					};
+
+					rpmpd_opp_svs: opp5 {
+						opp-level = <RPM_SMD_LEVEL_SVS>;
+					};
+
+					rpmpd_opp_svs_plus: opp6 {
+						opp-level = <RPM_SMD_LEVEL_SVS_PLUS>;
+					};
+
+					rpmpd_opp_nom: opp7 {
+						opp-level = <RPM_SMD_LEVEL_NOM>;
+					};
+
+					rpmpd_opp_nom_plus: opp8 {
+						opp-level = <RPM_SMD_LEVEL_NOM_PLUS>;
+					};
+
+					rpmpd_opp_turbo: opp9 {
+						opp-level = <RPM_SMD_LEVEL_TURBO>;
+					};
+
+					rpmpd_opp_turbo_no_cpr: opp10 {
+						opp-level = <RPM_SMD_LEVEL_TURBO_NO_CPR>;
+					};
+
+					rpmpd_opp_turbo_plus: opp11 {
+						opp-level = <RPM_SMD_LEVEL_BINNING>;
+					};
+				};
+			};
 		};
 	};
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 22%]

* [PATCH v4 7/9] dt-bindings: power: Add rpm power domain bindings for msm8998
  2019-05-13 10:20 [PATCH v4 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (5 preceding siblings ...)
  2019-05-13 10:20 ` [PATCH v4 6/9] arm64: dts: qcom: qcs404: Add rpmpd node Sibi Sankar
@ 2019-05-13 10:20 ` Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 9/9] arm64: dts: qcom: msm8998: Add rpmpd node Sibi Sankar
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-05-13 10:20 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, agross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm,
	devicetree, rnayak, marc.w.gonzalez, Sibi Sankar, Rob Herring

Add RPM power domain bindings for the msm8998 family of SoC

Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 .../devicetree/bindings/power/qcom,rpmpd.txt         |  1 +
 include/dt-bindings/power/qcom-rpmpd.h               | 12 ++++++++++++
 2 files changed, 13 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
index 172ccf940c5c..eb35b22f9e23 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt
@@ -6,6 +6,7 @@ which then translates it into a corresponding voltage on a rail
 Required Properties:
  - compatible: Should be one of the following
 	* qcom,msm8996-rpmpd: RPM Power domain for the msm8996 family of SoC
+	* qcom,msm8998-rpmpd: RPM Power domain for the msm8998 family of SoC
 	* qcom,qcs404-rpmpd: RPM Power domain for the qcs404 family of SoC
 	* qcom,sdm845-rpmhpd: RPMh Power domain for the sdm845 family of SoC
  - #power-domain-cells: number of cells in Power domain specifier
diff --git a/include/dt-bindings/power/qcom-rpmpd.h b/include/dt-bindings/power/qcom-rpmpd.h
index 450378662944..93e36d011527 100644
--- a/include/dt-bindings/power/qcom-rpmpd.h
+++ b/include/dt-bindings/power/qcom-rpmpd.h
@@ -36,6 +36,18 @@
 #define MSM8996_VDDSSCX		5
 #define MSM8996_VDDSSCX_VFC	6
 
+/* MSM8998 Power Domain Indexes */
+#define MSM8998_VDDCX		0
+#define MSM8998_VDDCX_AO	1
+#define MSM8998_VDDCX_VFL	2
+#define MSM8998_VDDMX		3
+#define MSM8998_VDDMX_AO	4
+#define MSM8998_VDDMX_VFL	5
+#define MSM8998_SSCCX		6
+#define MSM8998_SSCCX_VFL	7
+#define MSM8998_SSCMX		8
+#define MSM8998_SSCMX_VFL	9
+
 /* QCS404 Power Domains */
 #define QCS404_VDDMX		0
 #define QCS404_VDDMX_AO		1
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* [PATCH v4 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains
  2019-05-13 10:20 [PATCH v4 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (6 preceding siblings ...)
  2019-05-13 10:20 ` [PATCH v4 7/9] dt-bindings: power: Add rpm power domain bindings for msm8998 Sibi Sankar
@ 2019-05-13 10:20 ` Sibi Sankar
  2019-05-13 10:20 ` [PATCH v4 9/9] arm64: dts: qcom: msm8998: Add rpmpd node Sibi Sankar
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-05-13 10:20 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, agross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm,
	devicetree, rnayak, marc.w.gonzalez, Sibi Sankar

Add the shared cx/mx and sensor sub-system's cx and mx
power-domains found on MSM8998.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 drivers/soc/qcom/rpmpd.c | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
index 63db8b26642c..3c1a55cf25d6 100644
--- a/drivers/soc/qcom/rpmpd.c
+++ b/drivers/soc/qcom/rpmpd.c
@@ -20,9 +20,12 @@
  * RPMPD_X is X encoded as a little-endian, lower-case, ASCII string */
 #define RPMPD_SMPA 0x61706d73
 #define RPMPD_LDOA 0x616f646c
+#define RPMPD_RWCX 0x78637772
 #define RPMPD_RWMX 0x786d7772
 #define RPMPD_RWLC 0x636c7772
 #define RPMPD_RWLM 0x6d6c7772
+#define RPMPD_RWSC 0x63737772
+#define RPMPD_RWSM 0x6d737772
 
 /* Operation Keys */
 #define KEY_CORNER		0x6e726f63 /* corn */
@@ -136,6 +139,38 @@ static const struct rpmpd_desc msm8996_desc = {
 	.max_state = MAX_8996_RPMPD_STATE,
 };
 
+/* msm8998 RPM Power domains */
+DEFINE_RPMPD_PAIR(msm8998, vddcx, vddcx_ao, RWCX, LEVEL, 0);
+DEFINE_RPMPD_VFL(msm8998, vddcx_vfl, RWCX, 0);
+
+DEFINE_RPMPD_PAIR(msm8998, vddmx, vddmx_ao, RWMX, LEVEL, 0);
+DEFINE_RPMPD_VFL(msm8998, vddmx_vfl, RWMX, 0);
+
+DEFINE_RPMPD_LEVEL(msm8998, vdd_ssccx, RWSC, 0);
+DEFINE_RPMPD_VFL(msm8998, vdd_ssccx_vfl, RWSC, 0);
+
+DEFINE_RPMPD_LEVEL(msm8998, vdd_sscmx, RWSM, 0);
+DEFINE_RPMPD_VFL(msm8998, vdd_sscmx_vfl, RWSM, 0);
+
+static struct rpmpd *msm8998_rpmpds[] = {
+	[MSM8998_VDDCX] =		&msm8998_vddcx,
+	[MSM8998_VDDCX_AO] =		&msm8998_vddcx_ao,
+	[MSM8998_VDDCX_VFL] =		&msm8998_vddcx_vfl,
+	[MSM8998_VDDMX] =		&msm8998_vddmx,
+	[MSM8998_VDDMX_AO] =		&msm8998_vddmx_ao,
+	[MSM8998_VDDMX_VFL] =		&msm8998_vddmx_vfl,
+	[MSM8998_SSCCX] =		&msm8998_vdd_ssccx,
+	[MSM8998_SSCCX_VFL] =		&msm8998_vdd_ssccx_vfl,
+	[MSM8998_SSCMX] =		&msm8998_vdd_sscmx,
+	[MSM8998_SSCMX_VFL] =		&msm8998_vdd_sscmx_vfl,
+};
+
+static const struct rpmpd_desc msm8998_desc = {
+	.rpmpds = msm8998_rpmpds,
+	.num_pds = ARRAY_SIZE(msm8998_rpmpds),
+	.max_state = RPM_SMD_LEVEL_BINNING,
+};
+
 /* qcs404 RPM Power domains */
 DEFINE_RPMPD_PAIR(qcs404, vddmx, vddmx_ao, RWMX, LEVEL, 0);
 DEFINE_RPMPD_VFL(qcs404, vddmx_vfl, RWMX, 0);
@@ -164,6 +199,7 @@ static const struct rpmpd_desc qcs404_desc = {
 
 static const struct of_device_id rpmpd_match_table[] = {
 	{ .compatible = "qcom,msm8996-rpmpd", .data = &msm8996_desc },
+	{ .compatible = "qcom,msm8998-rpmpd", .data = &msm8998_desc },
 	{ .compatible = "qcom,qcs404-rpmpd", .data = &qcs404_desc },
 	{ }
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* [PATCH v4 9/9] arm64: dts: qcom: msm8998: Add rpmpd node
  2019-05-13 10:20 [PATCH v4 0/9] RPMPD for QCS404 and MSM8998 Sibi Sankar
                   ` (7 preceding siblings ...)
  2019-05-13 10:20 ` [PATCH v4 8/9] soc: qcom: rpmpd: Add MSM8998 power-domains Sibi Sankar
@ 2019-05-13 10:20 ` Sibi Sankar
  8 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-05-13 10:20 UTC (permalink / raw)
  To: bjorn.andersson, robh+dt, agross
  Cc: david.brown, mark.rutland, linux-kernel, linux-arm-msm,
	devicetree, rnayak, marc.w.gonzalez, Sibi Sankar

Add the rpmpd node on the msm8998 and define the available levels.

Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
---
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 51 +++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index 574be78a936e..aa501221ca4d 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -4,6 +4,7 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/clock/qcom,gcc-msm8998.h>
 #include <dt-bindings/clock/qcom,rpmcc.h>
+#include <dt-bindings/power/qcom-rpmpd.h>
 #include <dt-bindings/gpio/gpio.h>
 
 / {
@@ -264,6 +265,56 @@
 				compatible = "qcom,rpmcc-msm8998", "qcom,rpmcc";
 				#clock-cells = <1>;
 			};
+
+			rpmpd: power-controller {
+				compatible = "qcom,msm8998-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 = <RPM_SMD_LEVEL_RETENTION>;
+					};
+
+					rpmpd_opp_ret_plus: opp2 {
+						opp-level = <RPM_SMD_LEVEL_RETENTION_PLUS>;
+					};
+
+					rpmpd_opp_min_svs: opp3 {
+						opp-level = <RPM_SMD_LEVEL_MIN_SVS>;
+					};
+
+					rpmpd_opp_low_svs: opp4 {
+						opp-level = <RPM_SMD_LEVEL_LOW_SVS>;
+					};
+
+					rpmpd_opp_svs: opp5 {
+						opp-level = <RPM_SMD_LEVEL_SVS>;
+					};
+
+					rpmpd_opp_svs_plus: opp6 {
+						opp-level = <RPM_SMD_LEVEL_SVS_PLUS>;
+					};
+
+					rpmpd_opp_nom: opp7 {
+						opp-level = <RPM_SMD_LEVEL_NOM>;
+					};
+
+					rpmpd_opp_nom_plus: opp8 {
+						opp-level = <RPM_SMD_LEVEL_NOM_PLUS>;
+					};
+
+					rpmpd_opp_turbo: opp9 {
+						opp-level = <RPM_SMD_LEVEL_TURBO>;
+					};
+
+					rpmpd_opp_turbo_plus: opp10 {
+						opp-level = <RPM_SMD_LEVEL_BINNING>;
+					};
+				};
+			};
 		};
 	};
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project


^ permalink raw reply	[relevance 21%]

* Re: [PATCH v7 2/4] soc: qcom: Add AOSS QMP driver
      [irrelevant] ` <20190501043734.26706-3-bjorn.andersson@linaro.org>
@ 2019-05-13 14:10   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-05-13 14:10 UTC (permalink / raw)
  To: Bjorn Andersson, Andy Gross, David Brown, Stephen Boyd
  Cc: Rob Herring, Mark Rutland, linux-arm-msm, devicetree, linux-kernel

Hey Bjorn,

On 5/1/19 10:07 AM, Bjorn Andersson wrote:
> The Always On Subsystem (AOSS) Qualcomm Messaging Protocol (QMP) driver
> is used to communicate with the AOSS for certain side-channel requests,
> that are not available through the RPMh interface.
> 
> The communication is a very simple synchronous mechanism of messages
> being written in message RAM and a doorbell in the AOSS is rung. As the
> AOSS has processed the message length is cleared and an interrupt is
> fired by the AOSS as acknowledgment.
> 
> The driver exposes the QDSS clock as a clock and the low-power state
> associated with the remoteprocs in the system as a set of power-domains.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v6:
> - Squash the pd into the same driver as the communication, to simplify
>    the interaction.
> - Representing the QDSS clocks as a clock/power domain turns out to
>    cascade into a request to make all Coresight drivers have a secondary
>    compatible to replace the required bus clock with a required power
>    domain. So in v7 this is exposed as a clock instead.
> - Some error checking updates, as reported by Doug.
> 
>   drivers/soc/qcom/Kconfig     |  11 +
>   drivers/soc/qcom/Makefile    |   1 +
>   drivers/soc/qcom/qcom_aoss.c | 473 +++++++++++++++++++++++++++++++++++
>   3 files changed, 485 insertions(+)
>   create mode 100644 drivers/soc/qcom/qcom_aoss.c
> 
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 1ee298f6bf17..3e460b334b47 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -3,6 +3,17 @@
>   #
>   menu "Qualcomm SoC drivers"
>   
> +config QCOM_AOSS_QMP
> +	tristate "Qualcomm AOSS Driver"
> +	depends on ARCH_QCOM || COMPILE_TEST
> +	depends on MAILBOX
> +	select PM_GENERIC_DOMAINS
> +	help
> +	  This driver provides the means of communicating with and controlling
> +	  the low-power state for resources related to the remoteproc
> +	  subsystems as well as controlling the debug clocks exposed by the Always On
> +	  Subsystem (AOSS) using Qualcomm Messaging Protocol (QMP).
> +
>   config QCOM_COMMAND_DB
>   	bool "Qualcomm Command DB"
>   	depends on ARCH_QCOM || COMPILE_TEST
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index ffe519b0cb66..eeb088beb15f 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -1,5 +1,6 @@
>   # SPDX-License-Identifier: GPL-2.0
>   CFLAGS_rpmh-rsc.o := -I$(src)
> +obj-$(CONFIG_QCOM_AOSS_QMP) +=	qcom_aoss.o
>   obj-$(CONFIG_QCOM_GENI_SE) +=	qcom-geni-se.o
>   obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
>   obj-$(CONFIG_QCOM_GLINK_SSR) +=	glink_ssr.o
> diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
> new file mode 100644
> index 000000000000..f1fc26ab2e36
> --- /dev/null
> +++ b/drivers/soc/qcom/qcom_aoss.c
> @@ -0,0 +1,473 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019, Linaro Ltd
> + */
> +#include <linux/clk-provider.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/mailbox_client.h>
> +#include <linux/pm_domain.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>

alphabetical order..

> +#include <dt-bindings/power/qcom-aoss-qmp.h>
> +
> +#define QMP_DESC_MAGIC			0x0
> +#define QMP_DESC_VERSION		0x4
> +#define QMP_DESC_FEATURES		0x8
> +
> +/* AOP-side offsets */
> +#define QMP_DESC_UCORE_LINK_STATE	0xc
> +#define QMP_DESC_UCORE_LINK_STATE_ACK	0x10
> +#define QMP_DESC_UCORE_CH_STATE		0x14
> +#define QMP_DESC_UCORE_CH_STATE_ACK	0x18
> +#define QMP_DESC_UCORE_MBOX_SIZE	0x1c
> +#define QMP_DESC_UCORE_MBOX_OFFSET	0x20
> +
> +/* Linux-side offsets */
> +#define QMP_DESC_MCORE_LINK_STATE	0x24
> +#define QMP_DESC_MCORE_LINK_STATE_ACK	0x28
> +#define QMP_DESC_MCORE_CH_STATE		0x2c
> +#define QMP_DESC_MCORE_CH_STATE_ACK	0x30
> +#define QMP_DESC_MCORE_MBOX_SIZE	0x34
> +#define QMP_DESC_MCORE_MBOX_OFFSET	0x38
> +
> +#define QMP_STATE_UP	0x0000ffff
> +#define QMP_STATE_DOWN	0xffff0000
> +
> +#define QMP_MAGIC	0x4d41494c

you may want to mention that the magic stands for MAIL

> +#define QMP_VERSION	1
> +
> +/* Requests are expected to be 96 bytes long */
> +#define QMP_MSG_LEN	96
> +
> +/**
> + * struct qmp - driver state for QMP implementation
> + * @msgram: iomem referencing the message RAM used for communication
> + * @dev: reference to QMP device
> + * @mbox_client: mailbox client used to ring the doorbell on transmit
> + * @mbox_chan: mailbox channel used to ring the doorbell on transmit
> + * @offset: offset within @msgram where messages should be written
> + * @size: maximum size of the messages to be transmitted
> + * @event: wait_queue for synchronization with the IRQ
> + * @tx_lock: provides syncrhonization between multiple callers of qmp_send()
> + * @qdss_clk: QDSS clock hw struct
> + * @pd_data: genpd data
> + */
> +struct qmp {
> +	void __iomem *msgram;
> +	struct device *dev;
> +
> +	struct mbox_client mbox_client;
> +	struct mbox_chan *mbox_chan;
> +
> +	size_t offset;
> +	size_t size;
> +
> +	wait_queue_head_t event;
> +
> +	struct mutex tx_lock;
> +
> +	struct clk_hw qdss_clk;
> +	struct genpd_onecell_data pd_data;
> +};
> +
> +struct qmp_pd {
> +	struct qmp *qmp;
> +	struct generic_pm_domain pd;
> +};
> +
> +#define to_qmp_pd_resource(res) container_of(res, struct qmp_pd, pd)
> +
> +static void qmp_kick(struct qmp *qmp)
> +{
> +	mbox_send_message(qmp->mbox_chan, NULL);
> +	mbox_client_txdone(qmp->mbox_chan, 0);
> +}
> +
> +static bool qmp_magic_valid(struct qmp *qmp)
> +{
> +	return readl(qmp->msgram + QMP_DESC_MAGIC) == QMP_MAGIC;
> +}
> +
> +static bool qmp_link_acked(struct qmp *qmp)
> +{
> +	return readl(qmp->msgram + QMP_DESC_MCORE_LINK_STATE_ACK) == QMP_STATE_UP;
> +}
> +
> +static bool qmp_mcore_channel_acked(struct qmp *qmp)
> +{
> +	return readl(qmp->msgram + QMP_DESC_MCORE_CH_STATE_ACK) == QMP_STATE_UP;
> +}
> +
> +static bool qmp_ucore_channel_up(struct qmp *qmp)
> +{
> +	return readl(qmp->msgram + QMP_DESC_UCORE_CH_STATE) == QMP_STATE_UP;
> +}
> +
> +static int qmp_open(struct qmp *qmp)
> +{
> +	int ret;
> +	u32 val;
> +
> +	if (!qmp_magic_valid(qmp)) {
> +		dev_err(qmp->dev, "QMP magic doesn't match\n");
> +		return -ETIMEDOUT;
> +	}
> +
> +	val = readl(qmp->msgram + QMP_DESC_VERSION);
> +	if (val != QMP_VERSION) {
> +		dev_err(qmp->dev, "unsupported QMP version %d\n", val);
> +		return -EINVAL;
> +	}
> +
> +	qmp->offset = readl(qmp->msgram + QMP_DESC_MCORE_MBOX_OFFSET);
> +	qmp->size = readl(qmp->msgram + QMP_DESC_MCORE_MBOX_SIZE);
> +	if (!qmp->size) {
> +		dev_err(qmp->dev, "invalid mailbox size\n");
> +		return -EINVAL;
> +	}
> +
> +	/* Ack remote core's link state */
> +	val = readl(qmp->msgram + QMP_DESC_UCORE_LINK_STATE);
> +	writel(val, qmp->msgram + QMP_DESC_UCORE_LINK_STATE_ACK);
> +
> +	/* Set local core's link state to up */
> +	writel(QMP_STATE_UP, qmp->msgram + QMP_DESC_MCORE_LINK_STATE);
> +
> +	qmp_kick(qmp);
> +
> +	ret = wait_event_timeout(qmp->event, qmp_link_acked(qmp), HZ);
> +	if (!ret) {
> +		dev_err(qmp->dev, "ucore didn't ack link\n");
> +		goto timeout_close_link;
> +	}
> +
> +	writel(QMP_STATE_UP, qmp->msgram + QMP_DESC_MCORE_CH_STATE);
> +
> +	qmp_kick(qmp);
> +
> +	ret = wait_event_timeout(qmp->event, qmp_ucore_channel_up(qmp), HZ);
> +	if (!ret) {
> +		dev_err(qmp->dev, "ucore didn't open channel\n");
> +		goto timeout_close_channel;
> +	}
> +
> +	/* Ack remote core's channel state */
> +	writel(QMP_STATE_UP, qmp->msgram + QMP_DESC_UCORE_CH_STATE_ACK);
> +
> +	qmp_kick(qmp);
> +
> +	ret = wait_event_timeout(qmp->event, qmp_mcore_channel_acked(qmp), HZ);
> +	if (!ret) {
> +		dev_err(qmp->dev, "ucore didn't ack channel\n");
> +		goto timeout_close_channel;
> +	}
> +
> +	return 0;
> +
> +timeout_close_channel:
> +	writel(QMP_STATE_DOWN, qmp->msgram + QMP_DESC_MCORE_CH_STATE);
> +
> +timeout_close_link:
> +	writel(QMP_STATE_DOWN, qmp->msgram + QMP_DESC_MCORE_LINK_STATE);
> +	qmp_kick(qmp);
> +
> +	return -ETIMEDOUT;
> +}
> +
> +static void qmp_close(struct qmp *qmp)
> +{
> +	writel(QMP_STATE_DOWN, qmp->msgram + QMP_DESC_MCORE_CH_STATE);
> +	writel(QMP_STATE_DOWN, qmp->msgram + QMP_DESC_MCORE_LINK_STATE);
> +	qmp_kick(qmp);
> +}
> +
> +static irqreturn_t qmp_intr(int irq, void *data)
> +{
> +	struct qmp *qmp = data;
> +
> +	wake_up_interruptible_all(&qmp->event);
> +
> +	return IRQ_HANDLED;
> +}
> +
> +static bool qmp_message_empty(struct qmp *qmp)
> +{
> +	return readl(qmp->msgram + qmp->offset) == 0;
> +}
> +
> +/**
> + * qmp_send() - send a message to the AOSS
> + * @qmp: qmp context
> + * @data: message to be sent
> + * @len: length of the message
> + *
> + * Transmit @data to AOSS and wait for the AOSS to acknowledge the message.
> + * @len must be a multiple of 4 and not longer than the mailbox size. Access is
> + * synchronized by this implementation.
> + *
> + * Return: 0 on success, negative errno on failure
> + */
> +int qmp_send(struct qmp *qmp, const void *data, size_t len)
> +{
> +	int ret;
> +
> +	if (WARN_ON(len + sizeof(u32) > qmp->size))
> +		return -EINVAL;
> +
> +	if (WARN_ON(len % sizeof(u32)))
> +		return -EINVAL;
> +
> +	mutex_lock(&qmp->tx_lock);
> +
> +	/* The message RAM only implements 32-bit accesses */
> +	__iowrite32_copy(qmp->msgram + qmp->offset + sizeof(u32),
> +			 data, len / sizeof(u32));
> +	writel(len, qmp->msgram + qmp->offset);
> +	qmp_kick(qmp);
> +
> +	ret = wait_event_interruptible_timeout(qmp->event,
> +					       qmp_message_empty(qmp), HZ);
> +	if (!ret) {
> +		dev_err(qmp->dev, "ucore did not ack channel\n");
> +		ret = -ETIMEDOUT;
> +
> +		/* Clear message from buffer */
> +		writel(0, qmp->msgram + qmp->offset);
> +	} else {
> +		ret = 0;
> +	}
> +
> +	mutex_unlock(&qmp->tx_lock);
> +
> +	return ret;
> +}
> +
> +static int qmp_qdss_clk_prepare(struct clk_hw *hw)
> +{
> +	struct qmp *qmp = container_of(hw, struct qmp, qdss_clk);
> +	char buf[QMP_MSG_LEN] = "{class: clock, res: qdss, val: 1}";
> +
> +	return qmp_send(qmp, buf, sizeof(buf));
> +}
> +
> +static void qmp_qdss_clk_unprepare(struct clk_hw *hw)
> +{
> +	struct qmp *qmp = container_of(hw, struct qmp, qdss_clk);
> +	char buf[QMP_MSG_LEN] = "{class: clock, res: qdss, val: 0}";
> +
> +	qmp_send(qmp, buf, sizeof(buf));
> +}
> +
> +static const struct clk_ops qmp_qdss_clk_ops = {
> +	.prepare = qmp_qdss_clk_prepare,
> +	.unprepare = qmp_qdss_clk_unprepare,
> +};
> +
> +static int qmp_qdss_clk_add(struct qmp *qmp)
> +{
> +	struct clk_init_data qdss_init = {
> +		.ops = &qmp_qdss_clk_ops,
> +		.name = "qdss",
> +	};
> +	int ret;
> +
> +	qmp->qdss_clk.init = &qdss_init;
> +	ret = clk_hw_register(qmp->dev, &qmp->qdss_clk);
> +	if (ret < 0) {
> +		dev_err(qmp->dev, "failed to register qdss clock\n");
> +		return ret;
> +	}
> +
> +	return of_clk_add_hw_provider(qmp->dev->of_node, of_clk_hw_simple_get,
> +				      &qmp->qdss_clk);
> +}
> +
> +static void qmp_qdss_clk_remove(struct qmp *qmp)
> +{
> +	clk_hw_unregister(&qmp->qdss_clk);
> +	of_clk_del_provider(qmp->dev->of_node);
> +}
> +
> +static int qmp_pd_power_toggle(struct qmp_pd *res, bool enable)
> +{
> +	char buf[QMP_MSG_LEN] = {};
> +
> +	snprintf(buf, sizeof(buf),
> +		 "{class: image, res: load_state, name: %s, val: %s}",
> +		 res->pd.name, enable ? "on" : "off");
> +	return qmp_send(res->qmp, buf, sizeof(buf));
> +}
> +
> +static int qmp_pd_power_on(struct generic_pm_domain *domain)
> +{
> +	return qmp_pd_power_toggle(to_qmp_pd_resource(domain), true);
> +}
> +
> +static int qmp_pd_power_off(struct generic_pm_domain *domain)
> +{
> +	return qmp_pd_power_toggle(to_qmp_pd_resource(domain), false);
> +}
> +
> +static const char * const sdm845_resources[] = {
> +	[AOSS_QMP_LS_CDSP] = "cdsp",
> +	[AOSS_QMP_LS_LPASS] = "adsp",
> +	[AOSS_QMP_LS_MODEM] = "modem",
> +	[AOSS_QMP_LS_SLPI] = "slpi",
> +	[AOSS_QMP_LS_SPSS] = "spss",
> +	[AOSS_QMP_LS_VENUS] = "venus",
> +};
> +
> +static int qmp_pd_add(struct qmp *qmp)
> +{
> +	struct genpd_onecell_data *data = &qmp->pd_data;
> +	struct device *dev = qmp->dev;
> +	struct qmp_pd *res;
> +	size_t num = ARRAY_SIZE(sdm845_resources);
> +	int ret;
> +	int i;
> +
> +	res = devm_kcalloc(dev, num, sizeof(*res), GFP_KERNEL);
> +	if (!res)
> +		return -ENOMEM;
> +
> +	data->domains = devm_kcalloc(dev, num, sizeof(*data->domains),
> +				     GFP_KERNEL);
> +	if (!data->domains)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < num; i++) {
> +		res[i].qmp = qmp;
> +		res[i].pd.name = sdm845_resources[i];
> +		res[i].pd.power_on = qmp_pd_power_on;
> +		res[i].pd.power_off = qmp_pd_power_off;
> +
> +		ret = pm_genpd_init(&res[i].pd, NULL, true);
> +		if (ret < 0) {
> +			dev_err(dev, "failed to init genpd\n");
> +			goto unroll_genpds;
> +		}
> +
> +		data->domains[i] = &res[i].pd;
> +	}
> +
> +	data->num_domains = i;
> +
> +	ret = of_genpd_add_provider_onecell(dev->of_node, data);
> +	if (ret < 0)
> +		goto unroll_genpds;
> +
> +	return 0;
> +
> +unroll_genpds:
> +	for (i--; i >= 0; i--)
> +		pm_genpd_remove(data->domains[i]);
> +
> +	return ret;
> +}
> +
> +static void qmp_pd_remove(struct qmp *qmp)
> +{
> +	struct genpd_onecell_data *data = &qmp->pd_data;
> +	struct device *dev = qmp->dev;
> +	int i;
> +
> +	of_genpd_del_provider(dev->of_node);
> +
> +	for (i = 0; i < data->num_domains; i++)
> +		pm_genpd_remove(data->domains[i]);
> +}
> +
> +static int qmp_probe(struct platform_device *pdev)
> +{
> +	struct resource *res;
> +	struct qmp *qmp;
> +	int irq;
> +	int ret;
> +
> +	qmp = devm_kzalloc(&pdev->dev, sizeof(*qmp), GFP_KERNEL);
> +	if (!qmp)
> +		return -ENOMEM;
> +
> +	qmp->dev = &pdev->dev;
> +	init_waitqueue_head(&qmp->event);
> +	mutex_init(&qmp->tx_lock);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	qmp->msgram = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(qmp->msgram))
> +		return PTR_ERR(qmp->msgram);
> +
> +	qmp->mbox_client.dev = &pdev->dev;
> +	qmp->mbox_client.knows_txdone = true;
> +	qmp->mbox_chan = mbox_request_channel(&qmp->mbox_client, 0);
> +	if (IS_ERR(qmp->mbox_chan)) {
> +		dev_err(&pdev->dev, "failed to acquire ipc mailbox\n");
> +		return PTR_ERR(qmp->mbox_chan);
> +	}
> +
> +	irq = platform_get_irq(pdev, 0);
> +	ret = devm_request_irq(&pdev->dev, irq, qmp_intr, IRQF_ONESHOT,
> +			       "aoss-qmp", qmp);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to request interrupt\n");
> +		goto err_close_qmp;

shouldn't this be err_freebox_mbox instead? we can avoid this by doing a
request irq before mbox_request_channel...

> +	}
> +
> +	ret = qmp_open(qmp);
> +	if (ret < 0)
> +		goto err_free_mbox;
> +
> +	ret = qmp_qdss_clk_add(qmp);
> +	if (ret)
> +		goto err_close_qmp;
> +
> +	ret = qmp_pd_add(qmp);
> +	if (ret)
> +		goto err_remove_qdss_clk;
> +
> +	platform_set_drvdata(pdev, qmp);
> +
> +	return 0;
> +
> +err_remove_qdss_clk:
> +	qmp_qdss_clk_remove(qmp);
> +err_close_qmp:
> +	qmp_close(qmp);
> +err_free_mbox:
> +	mbox_free_channel(qmp->mbox_chan);
> +
> +	return ret;
> +}
> +
> +static int qmp_remove(struct platform_device *pdev)
> +{
> +	struct qmp *qmp = platform_get_drvdata(pdev);
> +
> +	qmp_qdss_clk_remove(qmp);
> +	qmp_pd_remove(qmp);
> +
> +	qmp_close(qmp);
> +	mbox_free_channel(qmp->mbox_chan);
> +
> +	return 0;
> +}
> +
> +static const struct of_device_id qmp_dt_match[] = {
> +	{ .compatible = "qcom,sdm845-aoss-qmp", },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, qmp_dt_match);
> +
> +static struct platform_driver qmp_driver = {
> +	.driver = {
> +		.name		= "qcom_aoss_qmp",
> +		.of_match_table	= qmp_dt_match,
> +	},
> +	.probe = qmp_probe,
> +	.remove	= qmp_remove,
> +};
> +module_platform_driver(qmp_driver);
> +
> +MODULE_DESCRIPTION("Qualcomm AOSS QMP driver");
> +MODULE_LICENSE("GPL v2");
> 

-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

^ permalink raw reply	[relevance 6%]

* Re: [RFC 1/3] arm64: dts: qcom: sdm845-cheza: add initial cheza dt
  2019-05-09 18:44 ` [RFC 1/3] arm64: dts: qcom: sdm845-cheza: add initial cheza dt Rob Clark
@ 2019-05-13 22:47   ` Doug Anderson
  0 siblings, 0 replies; 200+ results
From: Doug Anderson @ 2019-05-13 22:47 UTC (permalink / raw)
  To: Rob Clark
  Cc: linux-arm-msm, Rob Clark, Sibi Sankar, Evan Green,
	Matthias Kaehlcke, Abhinav Kumar, Brian Norris,
	Venkat Gopalakrishnan, Rajendra Nayak, Andy Gross, David Brown,
	Rob Herring, Mark Rutland, devicetree, LKML, Stephen Boyd

Hi,

On Thu, May 9, 2019 at 11:44 AM Rob Clark <robdclark@gmail.com>wrote:

> From: Rob Clark <robdclark@chromium.org>
>
> This is essentialy a squash of a bunch of history of cheza dt updates
> from chromium kernel, some of which were themselves squashes of history
> from older chromium kernels.
>
> I don't claim any credit other than wanting to more easily boot upstream
> kernel on cheza to have an easier way to test upstream driver work ;-)
>
> I've added below in Cc tags all the original actual authors (apologies
> if I missed any).
>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Sibi Sankar <sibis@codeaurora.org>
> Cc: Evan Green <evgreen@chromium.org>
> Cc: Matthias Kaehlcke <mka@chromium.org>
> Cc: Abhinav Kumar <abhinavk@codeaurora.org>
> Cc: Brian Norris <briannorris@chromium.org>
> Cc: Venkat Gopalakrishnan <venkatg@codeaurora.org>
> Cc: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Rob Clark <robdclark@chromium.org>
> ---
>  arch/arm64/boot/dts/qcom/Makefile            |    3 +
>  arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts |  238 ++++
>  arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts |  238 ++++
>  arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts |  180 +++
>  arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi   | 1317 ++++++++++++++++++
>  5 files changed, 1976 insertions(+)

In general I am supportive of getting cheza dts landed upstream.

One question is how much cleanup we want to do while landing upstream.
We have a few TODO / HACK comments currently.  Do we want to land what
we have and clean these up in separate commits, or should we try to do
cleanup beforehand.  Bjron / Andy: do you have any opinions?  I've
commented on a few below.


> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index b3fe72ff2955..7a038cf81543 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -8,6 +8,9 @@ dtb-$(CONFIG_ARCH_QCOM) += msm8994-angler-rev-101.dtb
>  dtb-$(CONFIG_ARCH_QCOM)        += msm8996-mtp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)        += msm8998-mtp.dtb
> +dtb-$(CONFIG_ARCH_QCOM)        += sdm845-cheza-r1.dtb
> +dtb-$(CONFIG_ARCH_QCOM)        += sdm845-cheza-r2.dtb
> +dtb-$(CONFIG_ARCH_QCOM)        += sdm845-cheza-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)        += sdm845-mtp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)        += qcs404-evb-1000.dtb
>  dtb-$(CONFIG_ARCH_QCOM)        += qcs404-evb-4000.dtb

Something about the above makes "git am" unhappy and "patch -p1" think
this is a malformed patch.  When I delete the part touching the
Makefile then I can apply OK.


> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts b/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
> new file mode 100644
> index 000000000000..35bb4629edd4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
> @@ -0,0 +1,238 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Google Cheza board device tree source
> + *
> + * Copyright 2018 Google LLC.
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm845-cheza.dtsi"
> +
> +/ {
> +       model = "Google Cheza (rev1)";
> +       compatible = "google,cheza-rev1", "google,cheza", "qcom,sdm845";

See below for rev 3, but I think this might be better as:

compatible = "google,cheza-rev1", "qcom,sdm845";


> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts b/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
> new file mode 100644
> index 000000000000..4359a82d4bb4
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
> @@ -0,0 +1,238 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Google Cheza board device tree source
> + *
> + * Copyright 2018 Google LLC.
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm845-cheza.dtsi"
> +
> +/ {
> +       model = "Google Cheza (rev2)";
> +       compatible = "google,cheza-rev2", "google,cheza", "qcom,sdm845";

See above and below, but probably:

compatible = "google,cheza-rev2", "qcom,sdm845";


> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts b/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
> new file mode 100644
> index 000000000000..2c3f815b90c1
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
> @@ -0,0 +1,180 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Google Cheza board device tree source
> + *
> + * Copyright 2018 Google LLC.
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm845-cheza.dtsi"
> +
> +/ {
> +       model = "Google Cheza (rev3+)";
> +       compatible = "google,cheza-rev15", "google,cheza-rev14",
> +                    "google,cheza-rev13", "google,cheza-rev12",
> +                    "google,cheza-rev11", "google,cheza-rev10",
> +                    "google,cheza-rev9", "google,cheza-rev8",
> +                    "google,cheza-rev7", "google,cheza-rev6",
> +                    "google,cheza-rev5", "google,cheza-rev4",
> +                    "google,cheza-rev3", "google,cheza", "qcom,sdm845";

Julius Werner suggested that a better solution is that the newest dts
should specify no revision.  Thus this should be just:

compatible = "google,cheza", "qcom,sdm845";


> diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> new file mode 100644
> index 000000000000..338c92ddd1c3
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
> @@ -0,0 +1,1317 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Google Cheza device tree source (common between revisions)
> + *
> + * Copyright 2018 Google LLC.
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> +#include "sdm845.dtsi"
> +
> +/* PMICs depend on spmi_bus label and so must come after SoC */
> +#include "pm8005.dtsi"
> +#include "pm8998.dtsi"
> +
> +/ {
> +       aliases {
> +               bluetooth0 = &bluetooth;
> +               hsuart0 = &uart6;
> +               serial0 = &uart9;
> +               wifi0 = &wifi;
> +       };
> +
> +       chosen {
> +               stdout-path = "serial0:115200n8";
> +       };
> +
> +       backlight: backlight {
> +               compatible = "pwm-backlight";
> +               pwms = <&cros_ec_pwm 0>;
> +               enable-gpios = <&tlmm 37 GPIO_ACTIVE_HIGH>;
> +               power-supply = <&ppvar_sys>;
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&ap_edp_bklten>;
> +       };
> +
> +       reserved-memory {
> +               rmtfs@88f00000 {
> +                       compatible = "qcom,rmtfs-mem";
> +                       reg = <0x0 0x88f00000 0x0 0x800000>;
> +                       no-map;
> +
> +                       qcom,client-id = <1>;
> +               };
> +       };

You missed part of:

https://crrev.com/c/1588964 - CHROMIUM: arm64: dts: qcom:
sdm845-cheza: Temporarily delete reserved-mem changes

...that should make the above "reserved-memory" section go away.


> +&spi0 {
> +       status = "okay";
> +       spi-max-frequency = <3000000>;  /* TODO: Drop this? */

Drop "spi-max-frequency".  That was part of original bindings but
shouldn't be there anymore.


> +};
> +
> +&spi5 {
> +       status = "okay";
> +       spi-max-frequency = <800000>; /* TODO: Drop this */
> +       cr50@0 {
> +               compatible = "google,cr50";
> +               reg = <0>;
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&h1_ap_int_odl>;
> +               spi-max-frequency = <800000>;
> +               interrupt-parent = <&tlmm>;
> +               interrupts = <129 IRQ_TYPE_EDGE_RISING>;
> +       };
> +};

Presumably the above needs to be dropped since "google,cr50" isn't
actually upstream.


> +&spi10 {
> +       status = "okay";
> +       spi-max-frequency = <3000000>;  /* TODO: Drop this? */

Drop "spi-max-frequency".  That was part of original bindings but
shouldn't be there anymore.


-Doug

^ permalink raw reply	[relevance 0%]

* [PATCH] arm64: dts: qcom: sdm845-cheza: add initial cheza dt
@ 2019-05-17  1:52 Rob Clark
  2019-05-17 18:34 ` Doug Anderson
  2019-06-25 18:58 ` Stephen Boyd
  0 siblings, 2 replies; 200+ results
From: Rob Clark @ 2019-05-17  1:52 UTC (permalink / raw)
  To: linux-arm-msm
  Cc: Bjorn Andersson, Stephen Boyd, Rob Clark, Douglas Anderson,
	Sibi Sankar, Evan Green, Matthias Kaehlcke, Abhinav Kumar,
	Brian Norris, Venkat Gopalakrishnan, Rajendra Nayak, Andy Gross,
	David Brown, Rob Herring, Mark Rutland, devicetree, linux-kernel

From: Rob Clark <robdclark@chromium.org>

This is essentialy a squash of a bunch of history of cheza dt updates
from chromium kernel, some of which were themselves squashes of history
from older chromium kernels.

I don't claim any credit other than wanting to more easily boot upstream
kernel on cheza to have an easier way to test upstream driver work ;-)

I've added below in Cc tags all the original actual authors (apologies
if I missed any).

Cc: Douglas Anderson <dianders@chromium.org>
Cc: Sibi Sankar <sibis@codeaurora.org>
Cc: Evan Green <evgreen@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Abhinav Kumar <abhinavk@codeaurora.org>
Cc: Brian Norris <briannorris@chromium.org>
Cc: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
---
Updated from review comments and squashed.  I left out the the patch
related to deleting gpu_mem/zap_shader nodes as the corresponding
patch that adds them in sdm845.dtsi hasn't landed yet, but once it
has we will need to revisit that patch for cheza.

 arch/arm64/boot/dts/qcom/Makefile            |    3 +
 arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts |  238 ++++
 arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts |  238 ++++
 arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts |  174 +++
 arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi   | 1326 ++++++++++++++++++
 5 files changed, 1979 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 21d548f02d39..cf325b263934 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -7,6 +7,9 @@ dtb-$(CONFIG_ARCH_QCOM)	+= msm8992-bullhead-rev-101.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8994-angler-rev-101.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8996-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8998-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-cheza-r1.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-cheza-r2.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-cheza-r3.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts b/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
new file mode 100644
index 000000000000..bd7c25bb8d35
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Cheza board device tree source
+ *
+ * Copyright 2018 Google LLC.
+ */
+
+/dts-v1/;
+
+#include "sdm845-cheza.dtsi"
+
+/ {
+	model = "Google Cheza (rev1)";
+	compatible = "google,cheza-rev1", "qcom,sdm845";
+
+	/*
+	 * FIXED REGULATORS (not in sdm845-cheza.dtsi) - parents above children
+	 */
+
+	/*
+	 * NOTE: Technically pp3500_a is not the exact same signal as
+	 * pp3500_a_vbob (there's a load switch between them and the EC can
+	 * control pp3500_a via "en_pp3300_a"), but from the AP's point of
+	 * view they are the same.
+	 */
+	pp3500_a:
+	pp3500_a_vbob: pp3500-a-vbob-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_bob";
+
+		/*
+		 * Comes on automatically when pp5000_ldo comes on, which
+		 * comes on automatically when ppvar_sys comes on
+		 */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3500000>;
+		regulator-max-microvolt = <3500000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp3300_dx_edp: pp3300-dx-edp-regulator {
+		/* Yes, it's really 3.5 despite the name of the signal */
+		regulator-min-microvolt = <3500000>;
+		regulator-max-microvolt = <3500000>;
+
+		vin-supply = <&pp3500_a>;
+	};
+};
+
+/* FIXED REGULATOR OVERRIDES (modifications to sdm845-cheza.dtsi) */
+
+/*
+ * L19 and L28 technically go to 3.3V, but most boards have old AOP firmware
+ * that limits them to 3.0, and trying to run at 3.3V with that old firmware
+ * prevents the system from booting.
+ */
+&src_pp3000_l19a {
+	regulator-min-microvolt = <3008000>;
+	regulator-max-microvolt = <3008000>;
+};
+
+&src_pp3300_l22a {
+	/delete-property/regulator-boot-on;
+	/delete-property/regulator-always-on;
+};
+
+&src_pp3300_l28a {
+	regulator-min-microvolt = <3008000>;
+	regulator-max-microvolt = <3008000>;
+};
+
+&src_vreg_bob {
+	regulator-min-microvolt = <3500000>;
+	regulator-max-microvolt = <3500000>;
+	vin-supply = <&pp3500_a_vbob>;
+};
+
+/*
+ * NON-REGULATOR OVERRIDES
+ * (modifications to sdm845-cheza.dtsi) - alphabetized by dtsi label
+ */
+
+/* PINCTRL - board-specific pinctrl */
+
+&tlmm {
+	gpio-line-names = "AP_SPI_FP_MISO",
+			  "AP_SPI_FP_MOSI",
+			  "AP_SPI_FP_CLK",
+			  "AP_SPI_FP_CS_L",
+			  "UART_AP_TX_DBG_RX",
+			  "UART_DBG_TX_AP_RX",
+			  "",
+			  "FP_RST_L",
+			  "FCAM_EN",
+			  "",
+			  "EDP_BRIJ_IRQ",
+			  "EC_IN_RW_ODL",
+			  "",
+			  "RCAM_MCLK",
+			  "FCAM_MCLK",
+			  "",
+			  "RCAM_EN",
+			  "CCI0_SDA",
+			  "CCI0_SCL",
+			  "CCI1_SDA",
+			  "CCI1_SCL",
+			  "FCAM_RST_L",
+			  "",
+			  "PEN_RST_L",
+			  "PEN_IRQ_L",
+			  "",
+			  "RCAM_VSYNC",
+			  "ESIM_MISO",
+			  "ESIM_MOSI",
+			  "ESIM_CLK",
+			  "ESIM_CS_L",
+			  "AP_PEN_1V8_SDA",
+			  "AP_PEN_1V8_SCL",
+			  "AP_TS_I2C_SDA",
+			  "AP_TS_I2C_SCL",
+			  "RCAM_RST_L",
+			  "",
+			  "AP_EDP_BKLTEN",
+			  "AP_BRD_ID1",
+			  "BOOT_CONFIG_4",
+			  "AMP_IRQ_L",
+			  "EDP_BRIJ_I2C_SDA",
+			  "EDP_BRIJ_I2C_SCL",
+			  "EN_PP3300_DX_EDP",
+			  "SD_CD_ODL",
+			  "BT_UART_RTS",
+			  "BT_UART_CTS",
+			  "BT_UART_RXD",
+			  "BT_UART_TXD",
+			  "AMP_I2C_SDA",
+			  "AMP_I2C_SCL",
+			  "AP_BRD_ID3",
+			  "",
+			  "AP_EC_SPI_CLK",
+			  "AP_EC_SPI_CS_L",
+			  "AP_EC_SPI_MISO",
+			  "AP_EC_SPI_MOSI",
+			  "FORCED_USB_BOOT",
+			  "AMP_BCLK",
+			  "AMP_LRCLK",
+			  "AMP_DOUT",
+			  "AMP_DIN",
+			  "AP_BRD_ID2",
+			  "PEN_PDCT_L",
+			  "HP_MCLK",
+			  "HP_BCLK",
+			  "HP_LRCLK",
+			  "HP_DOUT",
+			  "HP_DIN",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "BT_SLIMBUS_DATA",
+			  "BT_SLIMBUS_CLK",
+			  "AMP_RESET_L",
+			  "",
+			  "FCAM_VSYNC",
+			  "",
+			  "AP_SKU_ID1",
+			  "EC_WOV_BCLK",
+			  "EC_WOV_LRCLK",
+			  "EC_WOV_DOUT",
+			  "",
+			  "",
+			  "AP_H1_SPI_MISO",
+			  "AP_H1_SPI_MOSI",
+			  "AP_H1_SPI_CLK",
+			  "AP_H1_SPI_CS_L",
+			  "",
+			  "AP_SPI_CS0_L",
+			  "AP_SPI_MOSI",
+			  "AP_SPI_MISO",
+			  "",
+			  "",
+			  "AP_SPI_CLK",
+			  "",
+			  "RFFE6_CLK",
+			  "RFFE6_DATA",
+			  "BOOT_CONFIG_1",
+			  "BOOT_CONFIG_2",
+			  "BOOT_CONFIG_0",
+			  "EDP_BRIJ_EN",
+			  "",
+			  "USB_HS_TX_EN",
+			  "UIM2_DATA",
+			  "UIM2_CLK",
+			  "UIM2_RST",
+			  "UIM2_PRESENT",
+			  "UIM1_DATA",
+			  "UIM1_CLK",
+			  "UIM1_RST",
+			  "",
+			  "AP_SKU_ID2",
+			  "SDM_GRFC_8",
+			  "SDM_GRFC_9",
+			  "AP_RST_REQ",
+			  "HP_IRQ",
+			  "TS_RESET_L",
+			  "PEN_EJECT_ODL",
+			  "HUB_RST_L",
+			  "FP_TO_AP_IRQ",
+			  "AP_EC_INT_L",
+			  "",
+			  "",
+			  "TS_INT_L",
+			  "AP_SUSPEND_L",
+			  "SDM_GRFC_3",
+			  "",
+			  "H1_AP_INT_ODL",
+			  "QLINK_REQ",
+			  "QLINK_EN",
+			  "SDM_GRFC_2",
+			  "BOOT_CONFIG_3",
+			  "WMSS_RESET_L",
+			  "SDM_GRFC_0",
+			  "SDM_GRFC_1",
+			  "RFFE3_DATA",
+			  "RFFE3_CLK",
+			  "RFFE4_DATA",
+			  "RFFE4_CLK",
+			  "RFFE5_DATA",
+			  "RFFE5_CLK",
+			  "GNSS_EN",
+			  "WCI2_LTE_COEX_RXD",
+			  "WCI2_LTE_COEX_TXD",
+			  "AP_RAM_ID1",
+			  "AP_RAM_ID2",
+			  "RFFE1_DATA",
+			  "RFFE1_CLK";
+};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts b/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
new file mode 100644
index 000000000000..2b7230594ecb
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts
@@ -0,0 +1,238 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Cheza board device tree source
+ *
+ * Copyright 2018 Google LLC.
+ */
+
+/dts-v1/;
+
+#include "sdm845-cheza.dtsi"
+
+/ {
+	model = "Google Cheza (rev2)";
+	compatible = "google,cheza-rev2", "qcom,sdm845";
+
+	/*
+	 * FIXED REGULATORS (not in sdm845-cheza.dtsi) - parents above children
+	 */
+
+	/*
+	 * NOTE: Technically pp3500_a is not the exact same signal as
+	 * pp3500_a_vbob (there's a load switch between them and the EC can
+	 * control pp3500_a via "en_pp3300_a"), but from the AP's point of
+	 * view they are the same.
+	 */
+	pp3500_a:
+	pp3500_a_vbob: pp3500-a-vbob-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_bob";
+
+		/*
+		 * Comes on automatically when pp5000_ldo comes on, which
+		 * comes on automatically when ppvar_sys comes on
+		 */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3500000>;
+		regulator-max-microvolt = <3500000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp3300_dx_edp: pp3300-dx-edp-regulator {
+		/* Yes, it's really 3.5 despite the name of the signal */
+		regulator-min-microvolt = <3500000>;
+		regulator-max-microvolt = <3500000>;
+
+		vin-supply = <&pp3500_a>;
+	};
+};
+
+/* FIXED REGULATOR OVERRIDES (modifications to sdm845-cheza.dtsi) */
+
+/*
+ * L19 and L28 technically go to 3.3V, but most boards have old AOP firmware
+ * that limits them to 3.0, and trying to run at 3.3V with that old firmware
+ * prevents the system from booting.
+ */
+&src_pp3000_l19a {
+	regulator-min-microvolt = <3008000>;
+	regulator-max-microvolt = <3008000>;
+};
+
+&src_pp3300_l22a {
+	/delete-property/regulator-boot-on;
+	/delete-property/regulator-always-on;
+};
+
+&src_pp3300_l28a {
+	regulator-min-microvolt = <3008000>;
+	regulator-max-microvolt = <3008000>;
+};
+
+&src_vreg_bob {
+	regulator-min-microvolt = <3500000>;
+	regulator-max-microvolt = <3500000>;
+	vin-supply = <&pp3500_a_vbob>;
+};
+
+/*
+ * NON-REGULATOR OVERRIDES
+ * (modifications to sdm845-cheza.dtsi) - alphabetized by dtsi label
+ */
+
+/* PINCTRL - board-specific pinctrl */
+
+&tlmm {
+	gpio-line-names = "AP_SPI_FP_MISO",
+			  "AP_SPI_FP_MOSI",
+			  "AP_SPI_FP_CLK",
+			  "AP_SPI_FP_CS_L",
+			  "UART_AP_TX_DBG_RX",
+			  "UART_DBG_TX_AP_RX",
+			  "BRIJ_SUSPEND",
+			  "FP_RST_L",
+			  "FCAM_EN",
+			  "",
+			  "EDP_BRIJ_IRQ",
+			  "EC_IN_RW_ODL",
+			  "",
+			  "RCAM_MCLK",
+			  "FCAM_MCLK",
+			  "",
+			  "RCAM_EN",
+			  "CCI0_SDA",
+			  "CCI0_SCL",
+			  "CCI1_SDA",
+			  "CCI1_SCL",
+			  "FCAM_RST_L",
+			  "FPMCU_BOOT0",
+			  "PEN_RST_L",
+			  "PEN_IRQ_L",
+			  "FPMCU_SEL_OD",
+			  "RCAM_VSYNC",
+			  "ESIM_MISO",
+			  "ESIM_MOSI",
+			  "ESIM_CLK",
+			  "ESIM_CS_L",
+			  "AP_PEN_1V8_SDA",
+			  "AP_PEN_1V8_SCL",
+			  "AP_TS_I2C_SDA",
+			  "AP_TS_I2C_SCL",
+			  "RCAM_RST_L",
+			  "",
+			  "AP_EDP_BKLTEN",
+			  "AP_BRD_ID1",
+			  "BOOT_CONFIG_4",
+			  "AMP_IRQ_L",
+			  "EDP_BRIJ_I2C_SDA",
+			  "EDP_BRIJ_I2C_SCL",
+			  "EN_PP3300_DX_EDP",
+			  "SD_CD_ODL",
+			  "BT_UART_RTS",
+			  "BT_UART_CTS",
+			  "BT_UART_RXD",
+			  "BT_UART_TXD",
+			  "AMP_I2C_SDA",
+			  "AMP_I2C_SCL",
+			  "AP_BRD_ID3",
+			  "",
+			  "AP_EC_SPI_CLK",
+			  "AP_EC_SPI_CS_L",
+			  "AP_EC_SPI_MISO",
+			  "AP_EC_SPI_MOSI",
+			  "FORCED_USB_BOOT",
+			  "AMP_BCLK",
+			  "AMP_LRCLK",
+			  "AMP_DOUT",
+			  "AMP_DIN",
+			  "AP_BRD_ID2",
+			  "PEN_PDCT_L",
+			  "HP_MCLK",
+			  "HP_BCLK",
+			  "HP_LRCLK",
+			  "HP_DOUT",
+			  "HP_DIN",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "BT_SLIMBUS_DATA",
+			  "BT_SLIMBUS_CLK",
+			  "AMP_RESET_L",
+			  "",
+			  "FCAM_VSYNC",
+			  "",
+			  "AP_SKU_ID1",
+			  "EC_WOV_BCLK",
+			  "EC_WOV_LRCLK",
+			  "EC_WOV_DOUT",
+			  "",
+			  "",
+			  "AP_H1_SPI_MISO",
+			  "AP_H1_SPI_MOSI",
+			  "AP_H1_SPI_CLK",
+			  "AP_H1_SPI_CS_L",
+			  "",
+			  "AP_SPI_CS0_L",
+			  "AP_SPI_MOSI",
+			  "AP_SPI_MISO",
+			  "",
+			  "",
+			  "AP_SPI_CLK",
+			  "",
+			  "RFFE6_CLK",
+			  "RFFE6_DATA",
+			  "BOOT_CONFIG_1",
+			  "BOOT_CONFIG_2",
+			  "BOOT_CONFIG_0",
+			  "EDP_BRIJ_EN",
+			  "",
+			  "USB_HS_TX_EN",
+			  "UIM2_DATA",
+			  "UIM2_CLK",
+			  "UIM2_RST",
+			  "UIM2_PRESENT",
+			  "UIM1_DATA",
+			  "UIM1_CLK",
+			  "UIM1_RST",
+			  "",
+			  "AP_SKU_ID2",
+			  "SDM_GRFC_8",
+			  "SDM_GRFC_9",
+			  "AP_RST_REQ",
+			  "HP_IRQ",
+			  "TS_RESET_L",
+			  "PEN_EJECT_ODL",
+			  "HUB_RST_L",
+			  "FP_TO_AP_IRQ",
+			  "AP_EC_INT_L",
+			  "",
+			  "",
+			  "TS_INT_L",
+			  "AP_SUSPEND_L",
+			  "SDM_GRFC_3",
+			  "",
+			  "H1_AP_INT_ODL",
+			  "QLINK_REQ",
+			  "QLINK_EN",
+			  "SDM_GRFC_2",
+			  "BOOT_CONFIG_3",
+			  "WMSS_RESET_L",
+			  "SDM_GRFC_0",
+			  "SDM_GRFC_1",
+			  "RFFE3_DATA",
+			  "RFFE3_CLK",
+			  "RFFE4_DATA",
+			  "RFFE4_CLK",
+			  "RFFE5_DATA",
+			  "RFFE5_CLK",
+			  "GNSS_EN",
+			  "WCI2_LTE_COEX_RXD",
+			  "WCI2_LTE_COEX_TXD",
+			  "AP_RAM_ID1",
+			  "AP_RAM_ID2",
+			  "RFFE1_DATA",
+			  "RFFE1_CLK";
+};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts b/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
new file mode 100644
index 000000000000..1ba67be08f81
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Cheza board device tree source
+ *
+ * Copyright 2018 Google LLC.
+ */
+
+/dts-v1/;
+
+#include "sdm845-cheza.dtsi"
+
+/ {
+	model = "Google Cheza (rev3+)";
+	compatible = "google,cheza", "qcom,sdm845";
+};
+
+/* PINCTRL - board-specific pinctrl */
+
+&tlmm {
+	gpio-line-names = "AP_SPI_FP_MISO",
+			  "AP_SPI_FP_MOSI",
+			  "AP_SPI_FP_CLK",
+			  "AP_SPI_FP_CS_L",
+			  "UART_AP_TX_DBG_RX",
+			  "UART_DBG_TX_AP_RX",
+			  "BRIJ_SUSPEND",
+			  "FP_RST_L",
+			  "FCAM_EN",
+			  "",
+			  "EDP_BRIJ_IRQ",
+			  "EC_IN_RW_ODL",
+			  "",
+			  "RCAM_MCLK",
+			  "FCAM_MCLK",
+			  "",
+			  "RCAM_EN",
+			  "CCI0_SDA",
+			  "CCI0_SCL",
+			  "CCI1_SDA",
+			  "CCI1_SCL",
+			  "FCAM_RST_L",
+			  "FPMCU_BOOT0",
+			  "PEN_RST_L",
+			  "PEN_IRQ_L",
+			  "FPMCU_SEL_OD",
+			  "RCAM_VSYNC",
+			  "ESIM_MISO",
+			  "ESIM_MOSI",
+			  "ESIM_CLK",
+			  "ESIM_CS_L",
+			  "AP_PEN_1V8_SDA",
+			  "AP_PEN_1V8_SCL",
+			  "AP_TS_I2C_SDA",
+			  "AP_TS_I2C_SCL",
+			  "RCAM_RST_L",
+			  "",
+			  "AP_EDP_BKLTEN",
+			  "AP_BRD_ID0",
+			  "BOOT_CONFIG_4",
+			  "AMP_IRQ_L",
+			  "EDP_BRIJ_I2C_SDA",
+			  "EDP_BRIJ_I2C_SCL",
+			  "EN_PP3300_DX_EDP",
+			  "SD_CD_ODL",
+			  "BT_UART_RTS",
+			  "BT_UART_CTS",
+			  "BT_UART_RXD",
+			  "BT_UART_TXD",
+			  "AMP_I2C_SDA",
+			  "AMP_I2C_SCL",
+			  "AP_BRD_ID2",
+			  "",
+			  "AP_EC_SPI_CLK",
+			  "AP_EC_SPI_CS_L",
+			  "AP_EC_SPI_MISO",
+			  "AP_EC_SPI_MOSI",
+			  "FORCED_USB_BOOT",
+			  "AMP_BCLK",
+			  "AMP_LRCLK",
+			  "AMP_DOUT",
+			  "AMP_DIN",
+			  "AP_BRD_ID1",
+			  "PEN_PDCT_L",
+			  "HP_MCLK",
+			  "HP_BCLK",
+			  "HP_LRCLK",
+			  "HP_DOUT",
+			  "HP_DIN",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "BT_SLIMBUS_DATA",
+			  "BT_SLIMBUS_CLK",
+			  "AMP_RESET_L",
+			  "",
+			  "FCAM_VSYNC",
+			  "",
+			  "AP_SKU_ID0",
+			  "EC_WOV_BCLK",
+			  "EC_WOV_LRCLK",
+			  "EC_WOV_DOUT",
+			  "",
+			  "",
+			  "AP_H1_SPI_MISO",
+			  "AP_H1_SPI_MOSI",
+			  "AP_H1_SPI_CLK",
+			  "AP_H1_SPI_CS_L",
+			  "",
+			  "AP_SPI_CS0_L",
+			  "AP_SPI_MOSI",
+			  "AP_SPI_MISO",
+			  "",
+			  "",
+			  "AP_SPI_CLK",
+			  "",
+			  "RFFE6_CLK",
+			  "RFFE6_DATA",
+			  "BOOT_CONFIG_1",
+			  "BOOT_CONFIG_2",
+			  "BOOT_CONFIG_0",
+			  "EDP_BRIJ_EN",
+			  "",
+			  "USB_HS_TX_EN",
+			  "UIM2_DATA",
+			  "UIM2_CLK",
+			  "UIM2_RST",
+			  "UIM2_PRESENT",
+			  "UIM1_DATA",
+			  "UIM1_CLK",
+			  "UIM1_RST",
+			  "",
+			  "AP_SKU_ID1",
+			  "SDM_GRFC_8",
+			  "SDM_GRFC_9",
+			  "AP_RST_REQ",
+			  "HP_IRQ",
+			  "TS_RESET_L",
+			  "PEN_EJECT_ODL",
+			  "HUB_RST_L",
+			  "FP_TO_AP_IRQ",
+			  "AP_EC_INT_L",
+			  "",
+			  "",
+			  "TS_INT_L",
+			  "AP_SUSPEND_L",
+			  "SDM_GRFC_3",
+			  /*
+			   * AP_FLASH_WP_L is crossystem ABI. Rev3 schematics
+			   * call it BIOS_FLASH_WP_R_L.
+			   */
+			  "AP_FLASH_WP_L",
+			  "H1_AP_INT_ODL",
+			  "QLINK_REQ",
+			  "QLINK_EN",
+			  "SDM_GRFC_2",
+			  "BOOT_CONFIG_3",
+			  "WMSS_RESET_L",
+			  "SDM_GRFC_0",
+			  "SDM_GRFC_1",
+			  "RFFE3_DATA",
+			  "RFFE3_CLK",
+			  "RFFE4_DATA",
+			  "RFFE4_CLK",
+			  "RFFE5_DATA",
+			  "RFFE5_CLK",
+			  "GNSS_EN",
+			  "WCI2_LTE_COEX_RXD",
+			  "WCI2_LTE_COEX_TXD",
+			  "AP_RAM_ID0",
+			  "AP_RAM_ID1",
+			  "RFFE1_DATA",
+			  "RFFE1_CLK";
+};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
new file mode 100644
index 000000000000..1ebbd568dfd7
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi
@@ -0,0 +1,1326 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Cheza device tree source (common between revisions)
+ *
+ * Copyright 2018 Google LLC.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include "sdm845.dtsi"
+
+/* PMICs depend on spmi_bus label and so must come after SoC */
+#include "pm8005.dtsi"
+#include "pm8998.dtsi"
+
+/ {
+	aliases {
+		bluetooth0 = &bluetooth;
+		hsuart0 = &uart6;
+		serial0 = &uart9;
+		wifi0 = &wifi;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	backlight: backlight {
+		compatible = "pwm-backlight";
+		pwms = <&cros_ec_pwm 0>;
+		enable-gpios = <&tlmm 37 GPIO_ACTIVE_HIGH>;
+		power-supply = <&ppvar_sys>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ap_edp_bklten>;
+	};
+
+	/* FIXED REGULATORS - parents above children */
+
+	/* This is the top level supply and variable voltage */
+	ppvar_sys: ppvar-sys-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "ppvar_sys";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	/* This divides ppvar_sys by 2, so voltage is variable */
+	src_vph_pwr: src-vph-pwr-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "src_vph_pwr";
+
+		/* EC turns on with switchcap_on_l; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp5000_a: pp5000-a-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "pp5000_a";
+
+		/* EC turns on with en_pp5000_a; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	src_vreg_bob: src-vreg-bob-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "src_vreg_bob";
+
+		/* EC turns on with vbob_en; always on for AP */
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3600000>;
+		regulator-max-microvolt = <3600000>;
+
+		vin-supply = <&ppvar_sys>;
+	};
+
+	pp3300_dx_edp: pp3300-dx-edp-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "pp3300_dx_edp";
+
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		gpio = <&tlmm 43 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		pinctrl-names = "default";
+		pinctrl-0 = <&en_pp3300_dx_edp>;
+	};
+
+	/*
+	 * Apparently RPMh does not provide support for PM8998 S4 because it
+	 * is always-on; model it as a fixed regulator.
+	 */
+	src_pp1800_s4a: pm8998-smps4 {
+		compatible = "regulator-fixed";
+		regulator-name = "src_pp1800_s4a";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&src_vph_pwr>;
+	};
+
+	/* BOARD-SPECIFIC TOP LEVEL NODES */
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pen_eject_odl>;
+
+		pen-insert {
+			label = "Pen Insert";
+			/* Insert = low, eject = high */
+			gpios = <&tlmm 119 GPIO_ACTIVE_LOW>;
+			linux,code = <SW_PEN_INSERTED>;
+			linux,input-type = <EV_SW>;
+			wakeup-source;
+		};
+	};
+
+	panel: panel {
+		compatible ="innolux,p120zdg-bf1";
+		power-supply = <&pp3300_dx_edp>;
+		backlight = <&backlight>;
+		no-hpd;
+
+		ports {
+			panel_in: port {
+				panel_in_edp: endpoint {
+					remote-endpoint = <&sn65dsi86_out>;
+				};
+			};
+		};
+	};
+};
+
+/*
+ * Reserved memory changes
+ *
+ * Putting this all together (out of order with the rest of the file) to keep
+ * all modifications to the memory map (from sdm845.dtsi) in one place.
+ */
+
+/*
+ * Our mpss_region is 8MB bigger than the default one and that conflicts
+ * with venus_mem and cdsp_mem.
+ *
+ * For venus_mem we'll delete and re-create at a different address.
+ *
+ * cdsp_mem isn't used on cheza right now so we won't bother re-creating it; but
+ * that also means we need to delete cdsp_pas.
+ */
+/delete-node/ &venus_mem;
+/delete-node/ &cdsp_mem;
+/delete-node/ &cdsp_pas;
+
+/* Increase the size from 120 MB to 128 MB */
+&mpss_region {
+	reg = <0 0x8e000000 0 0x8000000>;
+};
+
+/* Increase the size from 2MB to 8MB */
+&rmtfs_mem {
+	reg = <0 0x88f00000 0 0x800000>;
+};
+
+/ {
+	reserved-memory {
+		venus_mem: memory@96000000 {
+			reg = <0 0x96000000 0 0x500000>;
+			no-map;
+		};
+	};
+};
+
+&qspi {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&qspi_clk &qspi_cs0 &qspi_data01>;
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+
+		/*
+		 * In theory chip supports up to 104 MHz and controller up
+		 * to 80 MHz, but above 25 MHz wasn't reliable so we'll use
+		 * that for now.  b:117440651
+		 */
+		spi-max-frequency = <25000000>;
+		spi-tx-bus-width = <2>;
+		spi-rx-bus-width = <2>;
+	};
+};
+
+
+&apps_rsc {
+	pm8998-rpmh-regulators {
+		compatible = "qcom,pm8998-rpmh-regulators";
+		qcom,pmic-id = "a";
+
+		vdd-s1-supply = <&src_vph_pwr>;
+		vdd-s2-supply = <&src_vph_pwr>;
+		vdd-s3-supply = <&src_vph_pwr>;
+		vdd-s4-supply = <&src_vph_pwr>;
+		vdd-s5-supply = <&src_vph_pwr>;
+		vdd-s6-supply = <&src_vph_pwr>;
+		vdd-s7-supply = <&src_vph_pwr>;
+		vdd-s8-supply = <&src_vph_pwr>;
+		vdd-s9-supply = <&src_vph_pwr>;
+		vdd-s10-supply = <&src_vph_pwr>;
+		vdd-s11-supply = <&src_vph_pwr>;
+		vdd-s12-supply = <&src_vph_pwr>;
+		vdd-s13-supply = <&src_vph_pwr>;
+		vdd-l1-l27-supply = <&src_pp1025_s7a>;
+		vdd-l2-l8-l17-supply = <&src_pp1350_s3a>;
+		vdd-l3-l11-supply = <&src_pp1025_s7a>;
+		vdd-l4-l5-supply = <&src_pp1025_s7a>;
+		vdd-l6-supply = <&src_vph_pwr>;
+		vdd-l7-l12-l14-l15-supply = <&src_pp2040_s5a>;
+		vdd-l9-supply = <&src_pp2040_s5a>;
+		vdd-l10-l23-l25-supply = <&src_vreg_bob>;
+		vdd-l13-l19-l21-supply = <&src_vreg_bob>;
+		vdd-l16-l28-supply = <&src_vreg_bob>;
+		vdd-l18-l22-supply = <&src_vreg_bob>;
+		vdd-l20-l24-supply = <&src_vreg_bob>;
+		vdd-l26-supply = <&src_pp1350_s3a>;
+		vin-lvs-1-2-supply = <&src_pp1800_s4a>;
+
+		src_pp1125_s2a: smps2 {
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1100000>;
+		};
+
+		src_pp1350_s3a: smps3 {
+			regulator-min-microvolt = <1352000>;
+			regulator-max-microvolt = <1352000>;
+		};
+
+		src_pp2040_s5a: smps5 {
+			regulator-min-microvolt = <1904000>;
+			regulator-max-microvolt = <2040000>;
+		};
+
+		src_pp1025_s7a: smps7 {
+			regulator-min-microvolt = <900000>;
+			regulator-max-microvolt = <1028000>;
+		};
+
+		vdd_qusb_hs0:
+		vdda_hp_pcie_core:
+		vdda_mipi_csi0_0p9:
+		vdda_mipi_csi1_0p9:
+		vdda_mipi_csi2_0p9:
+		vdda_mipi_dsi0_pll:
+		vdda_mipi_dsi1_pll:
+		vdda_qlink_lv:
+		vdda_qlink_lv_ck:
+		vdda_qrefs_0p875:
+		vdda_pcie_core:
+		vdda_pll_cc_ebi01:
+		vdda_pll_cc_ebi23:
+		vdda_sp_sensor:
+		vdda_ufs1_core:
+		vdda_ufs2_core:
+		vdda_usb1_ss_core:
+		vdda_usb2_ss_core:
+		src_pp875_l1a: ldo1 {
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vddpx_10:
+		src_pp1200_l2a: ldo2 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+
+			/* TODO: why??? */
+			regulator-always-on;
+		};
+
+		pp1000_l3a_sdr845: ldo3 {
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vdd_wcss_cx:
+		vdd_wcss_mx:
+		vdda_wcss_pll:
+		src_pp800_l5a: ldo5 {
+			regulator-min-microvolt = <800000>;
+			regulator-max-microvolt = <800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vddpx_13:
+		src_pp1800_l6a: ldo6 {
+			regulator-min-microvolt = <1856000>;
+			regulator-max-microvolt = <1856000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp1800_l7a_wcn3990: ldo7 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1200_l8a: ldo8 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1248000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp1800_dx_pen:
+		src_pp1800_l9a: ldo9 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1800_l10a: ldo10 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp1000_l11a_sdr845: ldo11 {
+			regulator-min-microvolt = <1000000>;
+			regulator-max-microvolt = <1048000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vdd_qfprom:
+		vdd_qfprom_sp:
+		vdda_apc1_cs_1p8:
+		vdda_gfx_cs_1p8:
+		vdda_qrefs_1p8:
+		vdda_qusb_hs0_1p8:
+		vddpx_11:
+		src_pp1800_l12a: ldo12 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vddpx_2:
+		src_pp2950_l13a: ldo13 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1800_l14a: ldo14 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1800_l15a: ldo15 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp2700_l16a: ldo16 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2704000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1300_l17a: ldo17 {
+			regulator-min-microvolt = <1304000>;
+			regulator-max-microvolt = <1304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp2700_l18a: ldo18 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		/*
+		 * NOTE: this rail should have been called
+		 * src_pp3300_l19a in the schematic
+		 */
+		src_pp3000_l19a: ldo19 {
+			regulator-min-microvolt = <3304000>;
+			regulator-max-microvolt = <3304000>;
+
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp2950_l20a: ldo20 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp2950_l21a: ldo21 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp3300_hub:
+		src_pp3300_l22a: ldo22 {
+			regulator-min-microvolt = <3304000>;
+			regulator-max-microvolt = <3304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			/*
+			 * HACK: Should add a usb hub node and driver
+			 * to turn this on and off at suspend/resume time
+			 */
+			regulator-boot-on;
+			regulator-always-on;
+		};
+
+		pp3300_l23a_ch1_wcn3990: ldo23 {
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3312000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vdda_qusb_hs0_3p1:
+		src_pp3075_l24a: ldo24 {
+			regulator-min-microvolt = <3088000>;
+			regulator-max-microvolt = <3088000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp3300_l25a_ch0_wcn3990: ldo25 {
+			regulator-min-microvolt = <3304000>;
+			regulator-max-microvolt = <3304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp1200_hub:
+		vdda_hp_pcie_1p2:
+		vdda_hv_ebi0:
+		vdda_hv_ebi1:
+		vdda_hv_ebi2:
+		vdda_hv_ebi3:
+		vdda_mipi_csi_1p25:
+		vdda_mipi_dsi0_1p2:
+		vdda_mipi_dsi1_1p2:
+		vdda_pcie_1p2:
+		vdda_ufs1_1p2:
+		vdda_ufs2_1p2:
+		vdda_usb1_ss_1p2:
+		vdda_usb2_ss_1p2:
+		src_pp1200_l26a: ldo26 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		pp3300_dx_pen:
+		src_pp3300_l28a: ldo28 {
+			regulator-min-microvolt = <3304000>;
+			regulator-max-microvolt = <3304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		src_pp1800_lvs1: lvs1 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+		};
+
+		src_pp1800_lvs2: lvs2 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+		};
+	};
+
+	pm8005-rpmh-regulators {
+		compatible = "qcom,pm8005-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		vdd-s1-supply = <&src_vph_pwr>;
+		vdd-s2-supply = <&src_vph_pwr>;
+		vdd-s3-supply = <&src_vph_pwr>;
+		vdd-s4-supply = <&src_vph_pwr>;
+
+		src_pp600_s3c: smps3 {
+			regulator-min-microvolt = <600000>;
+			regulator-max-microvolt = <600000>;
+		};
+	};
+};
+
+&dsi0 {
+	status = "okay";
+	vdda-supply = <&vdda_mipi_dsi0_1p2>;
+
+	ports {
+		port@1 {
+			endpoint {
+				remote-endpoint = <&sn65dsi86_in>;
+				data-lanes = <0 1 2 3>;
+			};
+		};
+	};
+};
+
+&dsi0_phy {
+	status = "okay";
+	vdds-supply = <&vdda_mipi_dsi0_pll>;
+};
+
+edp_brij_i2c: &i2c3 {
+	status = "okay";
+	clock-frequency = <400000>;
+
+	sn65dsi86_bridge: bridge@2d {
+		compatible = "ti,sn65dsi86";
+		reg = <0x2d>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&edp_brij_en &edp_brij_irq>;
+
+		interrupt-parent = <&tlmm>;
+		interrupts = <10 IRQ_TYPE_LEVEL_HIGH>;
+
+		enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>;
+
+		vpll-supply = <&src_pp1800_s4a>;
+		vccio-supply = <&src_pp1800_s4a>;
+		vcca-supply = <&src_pp1200_l2a>;
+		vcc-supply = <&src_pp1200_l2a>;
+
+		clocks = <&rpmhcc RPMH_LN_BB_CLK2>;
+		clock-names = "refclk";
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+				sn65dsi86_in: endpoint {
+					remote-endpoint = <&dsi0_out>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+				sn65dsi86_out: endpoint {
+					remote-endpoint = <&panel_in_edp>;
+				};
+			};
+		};
+	};
+};
+
+ap_pen_1v8: &i2c11 {
+	status = "okay";
+	clock-frequency = <400000>;
+
+	digitizer@9 {
+		compatible = "wacom,w9013", "hid-over-i2c";
+		reg = <0x9>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pen_irq_l>, <&pen_pdct_l>, <&pen_rst_l>;
+
+		vdd-supply = <&pp3300_dx_pen>;
+		vddl-supply = <&pp1800_dx_pen>;
+		post-power-on-delay-ms = <100>;
+
+		interrupt-parent = <&tlmm>;
+		interrupts = <24 IRQ_TYPE_LEVEL_LOW>;
+
+		hid-descr-addr = <0x1>;
+	};
+};
+
+amp_i2c: &i2c12 {
+	status = "okay";
+	clock-frequency = <400000>;
+};
+
+ap_ts_i2c: &i2c14 {
+	status = "okay";
+	clock-frequency = <400000>;
+
+	touchscreen@10 {
+		compatible = "elan,ekth3500";
+		reg = <0x10>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ts_int_l &ts_reset_l>;
+
+		interrupt-parent = <&tlmm>;
+		interrupts = <125 IRQ_TYPE_LEVEL_LOW>;
+
+		vcc33-supply = <&src_pp3300_l28a>;
+
+		reset-gpios = <&tlmm 118 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&lpasscc {
+	status = "okay";
+};
+
+&mdss {
+	status = "okay";
+};
+
+&mdss_mdp {
+	status = "okay";
+};
+
+&qupv3_id_0 {
+	status = "okay";
+};
+
+&qupv3_id_1 {
+	status = "okay";
+};
+
+&sdhc_2 {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdc2_clk &sdc2_cmd &sdc2_data &sd_cd_odl>;
+
+	vmmc-supply = <&src_pp2950_l21a>;
+	vqmmc-supply = <&vddpx_2>;
+
+	cd-gpios = <&tlmm 44 GPIO_ACTIVE_LOW>;
+};
+
+&spi0 {
+	status = "okay";
+};
+
+&spi10 {
+	status = "okay";
+
+	cros_ec: ec@0 {
+		compatible = "google,cros-ec-spi";
+		reg = <0>;
+		interrupt-parent = <&tlmm>;
+		interrupts = <122 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&ec_ap_int_l>;
+		spi-max-frequency = <3000000>;
+
+		cros_ec_pwm: ec-pwm {
+			compatible = "google,cros-ec-pwm";
+			#pwm-cells = <1>;
+		};
+
+		i2c_tunnel: i2c-tunnel {
+			compatible = "google,cros-ec-i2c-tunnel";
+			google,remote-bus = <0>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
+		pdupdate {
+			compatible = "google,cros-ec-pd-update";
+		};
+	};
+};
+
+#include <arm/cros-ec-keyboard.dtsi>
+#include <arm/cros-ec-sbs.dtsi>
+
+&uart6 {
+	status = "okay";
+
+	bluetooth: wcn3990-bt {
+		compatible = "qcom,wcn3990-bt";
+		vddio-supply = <&src_pp1800_s4a>;
+		vddxo-supply = <&pp1800_l7a_wcn3990>;
+		vddrf-supply = <&src_pp1300_l17a>;
+		vddch0-supply = <&pp3300_l25a_ch0_wcn3990>;
+		max-speed = <3200000>;
+	};
+};
+
+&uart9 {
+	status = "okay";
+};
+
+&ufs_mem_hc {
+	status = "okay";
+	pinctrl-names = "init", "default";
+	pinctrl-0 = <&ufs_dev_reset_assert>;
+	pinctrl-1 = <&ufs_dev_reset_deassert>;
+
+	vcc-supply = <&src_pp2950_l20a>;
+	vcc-max-microamp = <600000>;
+};
+
+&ufs_mem_phy {
+	status = "okay";
+
+	vdda-phy-supply = <&vdda_ufs1_core>;
+	vdda-pll-supply = <&vdda_ufs1_1p2>;
+};
+
+&usb_1 {
+	status = "okay";
+
+	/* We'll use this as USB 2.0 only */
+	qcom,select-utmi-as-pipe-clk;
+};
+
+&usb_1_dwc3 {
+	/*
+	 * The hardware design intends this port to be hooked up in peripheral
+	 * mode, so we'll hardcode it here.  Some details:
+	 * - SDM845 expects only a single Type C connector so it has only one
+	 *   native Type C port but cheza has two Type C connectors.
+	 * - The only source of DP is the single native Type C port.
+	 * - On cheza we want to be able to hook DP up to _either_ of the
+	 *   two Type C connectors and want to be able to achieve 4 lanes of DP.
+	 * - When you configure a Type C port for 4 lanes of DP you lose USB3.
+	 * - In order to make everything work, the native Type C port is always
+	 *   configured as 4-lanes DP so it's always available.
+	 * - The extra USB3 port on SDM845 goes to a USB 3 hub which is then
+	 *   sent to the two Type C connectors.
+	 * - The extra USB2 lines from the native Type C port are always
+	 *   setup as "peripheral" so that we can mux them over to one connector
+	 *   or the other if someone needs the connector configured as a gadget
+	 *   (but they only get USB2 speeds).
+	 *
+	 * All the hardware muxes would allow us to hook things up in different
+	 * ways to some potential benefit for static configurations (you could
+	 * achieve extra USB2 bandwidth by using two different ports for the
+	 * two conenctors or possibly even get USB3 peripheral mode), but in
+	 * each case you end up forcing to disconnect/reconnect an in-use
+	 * USB session in some cases depending on what you hotplug into the
+	 * other connector.  Thus hardcoding this as peripheral makes sense.
+	 */
+	dr_mode = "peripheral";
+
+	/*
+	 * We always need the high speed pins as 4-lanes DP in case someone
+	 * hotplugs a DP peripheral.  Thus limit this port to a max of high
+	 * speed.
+	 */
+	maximum-speed = "high-speed";
+
+	/*
+	 * We don't need the usb3-phy since we run in highspeed mode always, so
+	 * re-define these properties removing the superspeed USB PHY reference.
+	 */
+	phys = <&usb_1_hsphy>;
+	phy-names = "usb2-phy";
+};
+
+&usb_1_hsphy {
+	status = "okay";
+
+	vdd-supply = <&vdda_usb1_ss_core>;
+	vdda-pll-supply = <&vdda_qusb_hs0_1p8>;
+	vdda-phy-dpdm-supply = <&vdda_qusb_hs0_3p1>;
+
+	qcom,imp-res-offset-value = <8>;
+	qcom,hstx-trim-value = <QUSB2_V2_HSTX_TRIM_21_6_MA>;
+	qcom,preemphasis-level = <QUSB2_V2_PREEMPHASIS_5_PERCENT>;
+	qcom,preemphasis-width = <QUSB2_V2_PREEMPHASIS_WIDTH_HALF_BIT>;
+};
+
+&usb_2 {
+	status = "okay";
+};
+
+&usb_2_dwc3 {
+	/* We have this hooked up to a hub and we always use in host mode */
+	dr_mode = "host";
+};
+
+&usb_2_hsphy {
+	status = "okay";
+
+	vdd-supply = <&vdda_usb2_ss_core>;
+	vdda-pll-supply = <&vdda_qusb_hs0_1p8>;
+	vdda-phy-dpdm-supply = <&vdda_qusb_hs0_3p1>;
+
+	qcom,imp-res-offset-value = <8>;
+	qcom,hstx-trim-value = <QUSB2_V2_HSTX_TRIM_22_8_MA>;
+};
+
+&usb_2_qmpphy {
+	status = "okay";
+
+	vdda-phy-supply = <&vdda_usb2_ss_1p2>;
+	vdda-pll-supply = <&vdda_usb2_ss_core>;
+};
+
+&wifi {
+	status = "okay";
+
+	vdd-0.8-cx-mx-supply = <&src_pp800_l5a >;
+	vdd-1.8-xo-supply = <&pp1800_l7a_wcn3990>;
+	vdd-1.3-rfa-supply = <&src_pp1300_l17a>;
+	vdd-3.3-ch0-supply = <&pp3300_l25a_ch0_wcn3990>;
+};
+
+/* PINCTRL - additions to nodes defined in sdm845.dtsi */
+
+&qspi_cs0 {
+	pinconf {
+		pins = "gpio90";
+		bias-disable;
+	};
+};
+
+&qspi_clk {
+	pinconf {
+		pins = "gpio95";
+		bias-disable;
+	};
+};
+
+&qspi_data01 {
+	pinconf {
+		pins = "gpio91", "gpio92";
+
+		/* High-Z when no transfers; nice to park the lines */
+		bias-pull-up;
+	};
+};
+
+&qup_i2c3_default {
+	pinconf {
+		pins = "gpio41", "gpio42";
+		drive-strength = <2>;
+
+		/* Has external pullup */
+		bias-disable;
+	};
+};
+
+&qup_i2c11_default {
+	pinconf {
+		pins = "gpio31", "gpio32";
+		drive-strength = <2>;
+
+		/* Has external pullup */
+		bias-disable;
+	};
+};
+
+&qup_i2c12_default {
+	pinconf {
+		pins = "gpio49", "gpio50";
+		drive-strength = <2>;
+
+		/* Has external pullup */
+		bias-disable;
+	};
+};
+
+&qup_i2c14_default {
+	pinconf {
+		pins = "gpio33", "gpio34";
+		drive-strength = <2>;
+
+		/* Has external pullup */
+		bias-disable;
+	};
+};
+
+&qup_spi0_default {
+	pinconf {
+		pins = "gpio0", "gpio1", "gpio2", "gpio3";
+		drive-strength = <2>;
+		bias-disable;
+	};
+};
+
+&qup_spi5_default {
+	pinconf {
+		pins = "gpio85", "gpio86", "gpio87", "gpio88";
+		drive-strength = <2>;
+		bias-disable;
+	};
+};
+
+&qup_spi10_default {
+	pinconf {
+		pins = "gpio53", "gpio54", "gpio55", "gpio56";
+		drive-strength = <2>;
+		bias-disable;
+	};
+};
+
+&qup_uart6_default {
+	/* Change pinmux to all 4 pins since CTS and RTS are connected */
+	pinmux {
+		pins = "gpio45", "gpio46",
+		       "gpio47", "gpio48";
+	};
+
+	pinconf-cts {
+		/*
+		 * Configure a pull-down on 45 (CTS) to match the pull of
+		 * the Bluetooth module.
+		 */
+		pins = "gpio45";
+		bias-pull-down;
+	};
+
+	pinconf-rts-tx {
+		/* We'll drive 46 (RTS) and 47 (TX), so no pull */
+		pins = "gpio46", "gpio47";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	pinconf-rx {
+		/*
+		 * Configure a pull-up on 48 (RX). This is needed to avoid
+		 * garbage data when the TX pin of the Bluetooth module is
+		 * in tri-state (module powered off or not driving the
+		 * signal yet).
+		 */
+		pins = "gpio48";
+		bias-pull-up;
+	};
+};
+
+&qup_uart9_default {
+	pinconf-tx {
+		pins = "gpio4";
+		drive-strength = <2>;
+		bias-disable;
+	};
+
+	pinconf-rx {
+		pins = "gpio5";
+		drive-strength = <2>;
+		bias-pull-up;
+	};
+};
+
+/* PINCTRL - board-specific pinctrl */
+&pm8005_gpio {
+	gpio-line-names = "",
+			  "",
+			  "SLB",
+			  "";
+};
+
+&pm8998_adc {
+	adc-chan@ADC5_AMUX_THM1_100K_PU {
+		reg = <ADC5_AMUX_THM1_100K_PU>;
+		label = "sdm_temp";
+	};
+
+	adc-chan@ADC5_AMUX_THM2_100K_PU {
+		reg = <ADC5_AMUX_THM2_100K_PU>;
+		label = "quiet_temp";
+	};
+
+	adc-chan@ADC5_AMUX_THM3_100K_PU {
+		reg = <ADC5_AMUX_THM3_100K_PU>;
+		label = "lte_temp_1";
+	};
+
+	adc-chan@ADC5_AMUX_THM4_100K_PU {
+		reg = <ADC5_AMUX_THM4_100K_PU>;
+		label = "lte_temp_2";
+	};
+
+	adc-chan@ADC5_AMUX_THM5_100K_PU {
+		reg = <ADC5_AMUX_THM5_100K_PU>;
+		label = "charger_temp";
+	};
+};
+
+&pm8998_gpio {
+	gpio-line-names = "",
+			  "",
+			  "SW_CTRL",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "",
+			  "CFG_OPT1",
+			  "WCSS_PWR_REQ",
+			  "",
+			  "CFG_OPT2",
+			  "SLB";
+};
+
+&tlmm {
+	/*
+	 * pinctrl settings for pins that have no real owners.
+	 */
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&bios_flash_wp_r_l>,
+		    <&ap_suspend_l_deassert>;
+
+	pinctrl-1 = <&bios_flash_wp_r_l>,
+		    <&ap_suspend_l_assert>;
+
+	/*
+	 * Hogs prevent usermode from changing the value. A GPIO can be both
+	 * here and in the pinctrl section.
+	 */
+	ap-suspend-l-hog {
+		gpio-hog;
+		gpios = <126 GPIO_ACTIVE_LOW>;
+		output-low;
+	};
+
+	ap_edp_bklten: ap-edp-bklten {
+		pinmux {
+			pins = "gpio37";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio37";
+			drive-strength = <2>;
+			bias-disable;
+		};
+	};
+
+	bios_flash_wp_r_l: bios-flash-wp-r-l {
+		pinmux {
+			pins = "gpio128";
+			function = "gpio";
+			input-enable;
+		};
+
+		pinconf {
+			pins = "gpio128";
+			bias-disable;
+		};
+	};
+
+	ec_ap_int_l: ec-ap-int-l {
+		pinmux {
+		       pins = "gpio122";
+		       function = "gpio";
+		       input-enable;
+		};
+
+		pinconf {
+		       pins = "gpio122";
+		       bias-pull-up;
+		};
+	};
+
+	edp_brij_en: edp-brij-en {
+		pinmux {
+			pins = "gpio102";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio102";
+			drive-strength = <2>;
+			bias-disable;
+		};
+	};
+
+	edp_brij_irq: edp-brij-irq {
+		pinmux {
+			pins = "gpio10";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio10";
+			drive-strength = <2>;
+			bias-pull-down;
+		};
+	};
+
+	en_pp3300_dx_edp: en-pp3300-dx-edp {
+		pinmux {
+			pins = "gpio43";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio43";
+			drive-strength = <2>;
+			bias-disable;
+		};
+	};
+
+	h1_ap_int_odl: h1-ap-int-odl {
+		pinmux {
+			pins = "gpio129";
+			function = "gpio";
+			input-enable;
+		};
+
+		pinconf {
+			pins = "gpio129";
+			bias-pull-up;
+		};
+	};
+
+	pen_eject_odl: pen-eject-odl {
+		pinmux {
+			pins = "gpio119";
+			function = "gpio";
+			bias-pull-up;
+		};
+	};
+
+	pen_irq_l: pen-irq-l {
+		pinmux {
+			pins = "gpio24";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio24";
+
+			/* Has external pullup */
+			bias-disable;
+		};
+	};
+
+	pen_pdct_l: pen-pdct-l {
+		pinmux {
+			pins = "gpio63";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio63";
+
+			/* Has external pullup */
+			bias-disable;
+		};
+	};
+
+	pen_rst_l: pen-rst-l {
+		pinmux  {
+			pins = "gpio23";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio23";
+			bias-disable;
+			drive-strength = <2>;
+
+			/*
+			 * The pen driver doesn't currently support
+			 * driving this reset line.  By specifying
+			 * output-high here we're relying on the fact
+			 * that this pin has a default pulldown at boot
+			 * (which makes sure the pen was in reset if it
+			 * was powered) and then we set it high here to
+			 * take it out of reset.  Better would be if the
+			 * pen driver could control this and we could
+			 * remove "output-high" here.
+			 */
+			output-high;
+		};
+	};
+
+	sdc2_clk: sdc2-clk {
+		pinconf {
+			pins = "sdc2_clk";
+			bias-disable;
+
+			/*
+			 * It seems that mmc_test reports errors if drive
+			 * strength is not 16.
+			 */
+			drive-strength = <16>;
+		};
+	};
+
+	sdc2_cmd: sdc2-cmd {
+		pinconf {
+			pins = "sdc2_cmd";
+			bias-pull-up;
+			drive-strength = <16>;
+		};
+	};
+
+	sdc2_data: sdc2-data {
+		pinconf {
+			pins = "sdc2_data";
+			bias-pull-up;
+			drive-strength = <16>;
+		};
+	};
+
+	sd_cd_odl: sd-cd-odl {
+		pinmux {
+			pins = "gpio44";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio44";
+			bias-pull-up;
+		};
+	};
+
+	ts_int_l: ts-int-l {
+		pinmux  {
+			pins = "gpio125";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio125";
+			bias-pull-up;
+		};
+	};
+
+	ts_reset_l: ts-reset-l {
+		pinmux  {
+			pins = "gpio118";
+			function = "gpio";
+		};
+
+		pinconf {
+			pins = "gpio118";
+			bias-disable;
+			drive-strength = <2>;
+		};
+	};
+
+	ufs_dev_reset_assert: ufs_dev_reset_assert {
+		config {
+			pins = "ufs_reset";
+			bias-pull-down;		/* default: pull down */
+			/*
+			 * UFS_RESET driver strengths are having
+			 * different values/steps compared to typical
+			 * GPIO drive strengths.
+			 *
+			 * Following table clarifies:
+			 *
+			 * HDRV value | UFS_RESET | Typical GPIO
+			 *   (dec)    |   (mA)    |    (mA)
+			 *     0      |   0.8     |    2
+			 *     1      |   1.55    |    4
+			 *     2      |   2.35    |    6
+			 *     3      |   3.1     |    8
+			 *     4      |   3.9     |    10
+			 *     5      |   4.65    |    12
+			 *     6      |   5.4     |    14
+			 *     7      |   6.15    |    16
+			 *
+			 * POR value for UFS_RESET HDRV is 3 which means
+			 * 3.1mA and we want to use that. Hence just
+			 * specify 8mA to "drive-strength" binding and
+			 * that should result into writing 3 to HDRV
+			 * field.
+			 */
+			drive-strength = <8>;	/* default: 3.1 mA */
+			output-low; /* active low reset */
+		};
+	};
+
+	ufs_dev_reset_deassert: ufs_dev_reset_deassert {
+		config {
+			pins = "ufs_reset";
+			bias-pull-down;		/* default: pull down */
+			/*
+			 * default: 3.1 mA
+			 * check comments under ufs_dev_reset_assert
+			 */
+			drive-strength = <8>;
+			output-high; /* active low reset */
+		};
+	};
+
+	ap_suspend_l_assert: ap_suspend_l_assert {
+		config {
+			pins = "gpio126";
+			function = "gpio";
+			bias-no-pull;
+			drive-strength = <2>;
+			output-low;
+		};
+	};
+
+	ap_suspend_l_deassert: ap_suspend_l_deassert {
+		config {
+			pins = "gpio126";
+			function = "gpio";
+			bias-no-pull;
+			drive-strength = <2>;
+			output-high;
+		};
+	};
+};
-- 
2.20.1


^ permalink raw reply	[relevance 2%]

* Re: [PATCH] arm64: dts: qcom: sdm845-cheza: add initial cheza dt
  2019-05-17  1:52 [PATCH] arm64: dts: qcom: sdm845-cheza: add initial cheza dt Rob Clark
@ 2019-05-17 18:34 ` Doug Anderson
  2019-06-25 18:58 ` Stephen Boyd
  1 sibling, 0 replies; 200+ results
From: Doug Anderson @ 2019-05-17 18:34 UTC (permalink / raw)
  To: Rob Clark
  Cc: linux-arm-msm, Bjorn Andersson, Stephen Boyd, Rob Clark,
	Sibi Sankar, Evan Green, Matthias Kaehlcke, Abhinav Kumar,
	Brian Norris, Venkat Gopalakrishnan, Rajendra Nayak, Andy Gross,
	David Brown, Rob Herring, Mark Rutland, devicetree, LKML

Hi,

On Thu, May 16, 2019 at 6:53 PM Rob Clark <robdclark@gmail.com> wrote:
>
> From: Rob Clark <robdclark@chromium.org>
>
> This is essentialy a squash of a bunch of history of cheza dt updates
> from chromium kernel, some of which were themselves squashes of history
> from older chromium kernels.
>
> I don't claim any credit other than wanting to more easily boot upstream
> kernel on cheza to have an easier way to test upstream driver work ;-)
>
> I've added below in Cc tags all the original actual authors (apologies
> if I missed any).
>
> Cc: Douglas Anderson <dianders@chromium.org>
> Cc: Sibi Sankar <sibis@codeaurora.org>
> Cc: Evan Green <evgreen@chromium.org>
> Cc: Matthias Kaehlcke <mka@chromium.org>
> Cc: Abhinav Kumar <abhinavk@codeaurora.org>
> Cc: Brian Norris <briannorris@chromium.org>
> Cc: Venkat Gopalakrishnan <venkatg@codeaurora.org>
> Cc: Rajendra Nayak <rnayak@codeaurora.org>
> Signed-off-by: Rob Clark <robdclark@chromium.org>
> ---
> Updated from review comments and squashed.  I left out the the patch
> related to deleting gpu_mem/zap_shader nodes as the corresponding
> patch that adds them in sdm845.dtsi hasn't landed yet, but once it
> has we will need to revisit that patch for cheza.
>
>  arch/arm64/boot/dts/qcom/Makefile            |    3 +
>  arch/arm64/boot/dts/qcom/sdm845-cheza-r1.dts |  238 ++++
>  arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dts |  238 ++++
>  arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dts |  174 +++
>  arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi   | 1326 ++++++++++++++++++
>  5 files changed, 1979 insertions(+)

Looks sane to me.  Thanks!

Reviewed-by: Douglas Anderson <dianders@chromium.org>

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v7 4/4] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
  2019-05-01  4:37 ` [PATCH v7 4/4] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
@ 2019-05-21 11:13   ` Vinod Koul
  0 siblings, 0 replies; 200+ results
From: Vinod Koul @ 2019-05-21 11:13 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland, Stephen Boyd,
	linux-arm-msm, devicetree, linux-kernel

On 30-04-19, 21:37, Bjorn Andersson wrote:
> From: Sibi Sankar <sibis@codeaurora.org>
> 
> This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Reviewed-by: Vinod Koul <vkoul@kernel.org>

-- 
~Vinod

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v4 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state
  2019-05-13 10:20 ` [PATCH v4 1/9] soc: qcom: rpmpd: fixup rpmpd set performance state Sibi Sankar
@ 2019-05-21 11:39   ` Vinod Koul
  0 siblings, 0 replies; 200+ results
From: Vinod Koul @ 2019-05-21 11:39 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: bjorn.andersson, robh+dt, agross, david.brown, mark.rutland,
	linux-kernel, linux-arm-msm, devicetree, rnayak, marc.w.gonzalez

On 13-05-19, 15:50, Sibi Sankar wrote:
> Remoteproc q6v5-mss calls set_performace_state with INT_MAX on

s/performace/performance

> rpmpd. This is currently ignored since it is greater than the
> max supported state. Fixup rpmpd state to max if the required
> state is greater than all the supported states.
> 
> Fixes: 075d3db8d10d ("soc: qcom: rpmpd: Add support for get/set performance state")
> 
> Reviewed-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
> ---
>  drivers/soc/qcom/rpmpd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/rpmpd.c b/drivers/soc/qcom/rpmpd.c
> index 005326050c23..235d01870dd8 100644
> --- a/drivers/soc/qcom/rpmpd.c
> +++ b/drivers/soc/qcom/rpmpd.c
> @@ -226,7 +226,7 @@ static int rpmpd_set_performance(struct generic_pm_domain *domain,
>  	struct rpmpd *pd = domain_to_rpmpd(domain);
>  
>  	if (state > MAX_RPMPD_STATE)
> -		goto out;
> +		state = MAX_RPMPD_STATE;
>  
>  	mutex_lock(&rpmpd_lock);
>  
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project

-- 
~Vinod

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v7 3/4] arm64: dts: qcom: Add AOSS QMP node
  2019-05-01  4:37 ` [PATCH v7 3/4] arm64: dts: qcom: Add AOSS QMP node Bjorn Andersson
@ 2019-05-23 15:12   ` Doug Anderson
  0 siblings, 0 replies; 200+ results
From: Doug Anderson @ 2019-05-23 15:12 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, David Brown, Rob Herring, Mark Rutland, Stephen Boyd,
	linux-arm-msm, devicetree, LKML

Hi,

On Tue, Apr 30, 2019 at 9:37 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> The AOSS QMP provides a number of power domains, used for QDSS and
> PIL, add the node for this.
>
> Tested-by: Sibi Sankar <sibis@codeaurora.org>
> Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v6:
> - Added #clock-cells
>
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index fcb93300ca62..666bc88d3e81 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -14,6 +14,7 @@
>  #include <dt-bindings/interconnect/qcom,sdm845.h>
>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>  #include <dt-bindings/phy/phy-qcom-qusb2.h>
> +#include <dt-bindings/power/qcom-aoss-qmp.h>
>  #include <dt-bindings/power/qcom-rpmpd.h>
>  #include <dt-bindings/reset/qcom,sdm845-aoss.h>
>  #include <dt-bindings/reset/qcom,sdm845-pdc.h>
> @@ -2142,6 +2143,15 @@

Please avoid editing patches by hand.  I needed to manually change the
"15" above to "16" to apply.

-Doug

^ permalink raw reply	[relevance 0%]

* Re: [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor
  2019-04-12  7:39   ` Chanwoo Choi
@ 2019-05-27  8:23     ` Sibi Sankar
  2019-05-28  1:27       ` Chanwoo Choi
  0 siblings, 1 reply; 200+ results
From: Sibi Sankar @ 2019-05-27  8:23 UTC (permalink / raw)
  To: Chanwoo Choi
  Cc: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov, bjorn.andersson,
	david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, rnayak, linux-pm, evgreen, daidavid1, dianders,
	Saravana Kannan, linux-kernel-owner

Hey Chanwoo,

Thanks a lot for reviewing the patch. Like I
had indicated earlier we decided to go with
a simpler approach instead on qualcomm SoCs.
I am happy to re-spin this patch with your
comments addressed if we do find other users
for this feature.

On 2019-04-12 13:09, Chanwoo Choi wrote:
> Hi,
> 
> I agree this approach absolutely.
> Just I add some comments. Please check it.
> 
> On 19. 3. 29. 오전 12:28, Sibi Sankar wrote:
>> From: Saravana Kannan <skannan@codeaurora.org>
>> 
>> Many CPU architectures have caches that can scale independent of the
>> CPUs. Frequency scaling of the caches is necessary to make sure the 
>> cache
>> is not a performance bottleneck that leads to poor performance and
>> power. The same idea applies for RAM/DDR.
>> 
>> To achieve this, this patch add support for cpu based scaling to the
>> passive governor. This is accomplished by taking the current frequency
>> of each CPU frequency domain and then adjusts the frequency of the 
>> cache
>> (or any devfreq device) based on the frequency of the CPUs. It listens
>> to CPU frequency transition notifiers to keep itself up to date on the
>> current CPU frequency.
>> 
>> To decide the frequency of the device, the governor does one of the
>> following:
>> * Constructs a CPU frequency to device frequency mapping table from
>>   required-opps property of the devfreq device's opp_table
>> 
>> * Scales the device frequency in proportion to the CPU frequency. So, 
>> if
>>   the CPUs are running at their max frequency, the device runs at its
>>   max frequency. If the CPUs are running at their min frequency, the
>>   device runs at its min frequency. It is interpolated for frequencies
>>   in between.
>> 
>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>> [Sibi: Integrated cpu-freqmap governor into passive_governor]
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>>  drivers/devfreq/Kconfig            |   4 +
>>  drivers/devfreq/governor_passive.c | 276 
>> ++++++++++++++++++++++++++++-
>>  include/linux/devfreq.h            |  43 ++++-
>>  3 files changed, 315 insertions(+), 8 deletions(-)
>> 
>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>> index 6a172d338f6d..9a45f464a56b 100644
>> --- a/drivers/devfreq/Kconfig
>> +++ b/drivers/devfreq/Kconfig
>> @@ -72,6 +72,10 @@ config DEVFREQ_GOV_PASSIVE
>>  	  device. This governor does not change the frequency by itself
>>  	  through sysfs entries. The passive governor recommends that
>>  	  devfreq device uses the OPP table to get the frequency/voltage.
>> +	  Alternatively the governor can also be chosen to scale based on
>> +	  the online CPUs current frequency. A CPU frequency to device
>> +	  frequency mapping table(s) is auto-populated by the governor
>> +	  for this purpose.
>> 
>>  comment "DEVFREQ Drivers"
>> 
>> diff --git a/drivers/devfreq/governor_passive.c 
>> b/drivers/devfreq/governor_passive.c
>> index 3bc29acbd54e..2506682b233b 100644
>> --- a/drivers/devfreq/governor_passive.c
>> +++ b/drivers/devfreq/governor_passive.c
>> @@ -11,10 +11,63 @@
>>   */
>> 
>>  #include <linux/module.h>
>> +#include <linux/cpu.h>
>> +#include <linux/cpufreq.h>
>> +#include <linux/cpumask.h>
>>  #include <linux/device.h>
>>  #include <linux/devfreq.h>
>> +#include <linux/of.h>
>> +#include <linux/slab.h>
>>  #include "governor.h"
>> 
>> +static unsigned int xlate_cpufreq_to_devfreq(struct 
>> devfreq_passive_data *data,
>> +					     unsigned int cpu)
>> +{
>> +	unsigned int cpu_min, cpu_max;
>> +	struct devfreq *devfreq = (struct devfreq *)data->this;
>> +	unsigned int dev_min, dev_max, cpu_percent, cpu_freq = 0, freq = 0;
>> +	unsigned long *freq_table = devfreq->profile->freq_table;
>> +	struct device *dev = devfreq->dev.parent;
>> +	struct devfreq_map *map;
>> +	int opp_cnt, i;
>> +
>> +	if (!data->state[cpu] || data->state[cpu]->first_cpu != cpu) {
>> +		freq = 0;
>> +		goto out;
> 
> goto out -> return 0;
> 
>> +	}
>> +
>> +	/* Use Interpolation if map is not available */
>> +	cpu_freq = data->state[cpu]->freq;
>> +	if (!data->map) {
>> +		cpu_min = data->state[cpu]->min_freq;
>> +		cpu_max = data->state[cpu]->max_freq;
>> +		if (freq_table) {
>> +			dev_min = freq_table[0];
>> +			dev_max = freq_table[devfreq->profile->max_state - 1];
> 
> Actually, it is not always true. The devfreq recommend the ascending 
> order for
> 'freq_table'. But, it is not mandatory. Also, some devfreq device uses 
> the
> decending order for 'freq_table'. So, a patch[1] was considering the 
> order
> when getting the minimum/maximum frequency from freq_table.
> 
> If you want to get the minimum/maximum frequency, you have to consider 
> the order
> of 'freq_table' as the patch[1].
> 
> [1] df5cf4a36178 ("PM / devfreq: Fix handling of min/max_freq == 0")
> 
>              /* Get minimum frequency according to sorting order */
> +               if (freq_table[0] < freq_table[df->profile->max_state - 
> 1])
> +                       value = freq_table[0];
> +               else
> +                       value = freq_table[df->profile->max_state - 1];
> 
> 
>> +		} else {
>> +			if (devfreq->max_freq <= devfreq->min_freq)
>> +				return 0;
>> +			dev_min = devfreq->min_freq;
>> +			dev_max = devfreq->max_freq;
>> +		}
>> +
>> +		cpu_percent = ((cpu_freq - cpu_min) * 100) / cpu_max - cpu_min;
>> +		freq = dev_min + mult_frac(dev_max - dev_min, cpu_percent, 100);
>> +		goto out;
> 
> You don't need to jump 'out'. Instead, you better to use the 'else' 
> statement
> for if data->map is not NULL. I think that almost case when using this 
> patch
> will be available of data->map. In order to skip the likely 'false' 
> statement,
> I recommend the following sequence.
> 
> 	if (data->map) {
> 		map = data->map[cpu];
> 		...
> 	} else {
> 		/* Use Interpolation if map is not available */
> 	}
> 
> 
>> +	}
>> +
>> +	map = data->map[cpu];
>> +	opp_cnt = dev_pm_opp_get_opp_count(dev);
>> +	for (i = 0; i < opp_cnt; i++) {
>> +		freq = max(freq, map[i].dev_hz);
>> +		if (map[i].cpu_khz >= cpu_freq)
>> +			break;
>> +	}
>> +out:
>> +	dev_dbg(dev, "CPU%u: %d -> dev: %u\n", cpu, cpu_freq, freq);
> 
> IMO, I think it is not necessary. If you want to print log, you better 
> to print
> it on device driver instead of governor.
> 
>> +	return freq;
>> +}
>> +
>>  static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>>  					unsigned long *freq)
>>  {
>> @@ -23,6 +76,7 @@ static int devfreq_passive_get_target_freq(struct 
>> devfreq *devfreq,
>>  	struct devfreq *parent_devfreq = (struct devfreq *)p_data->parent;
>>  	unsigned long child_freq = ULONG_MAX;
>>  	struct dev_pm_opp *opp;
>> +	unsigned int cpu, tgt_freq = 0;
> 
> tgt means 'target'? If right, just use target_freq intead of 'tgt_freq'
> for the readability.
> 
>>  	int i, count, ret = 0;
>> 
>>  	/*
>> @@ -35,6 +89,14 @@ static int devfreq_passive_get_target_freq(struct 
>> devfreq *devfreq,
>>  		goto out;
>>  	}
>> 
>> +	if (p_data->cpufreq_type) {
>> +		for_each_possible_cpu(cpu)
>> +			tgt_freq = max(tgt_freq,
>> +				       xlate_cpufreq_to_devfreq(p_data, cpu));
>> +		*freq = tgt_freq;
> 
> You better to change from 'tgt_freq' to 'target_freq' for the 
> readability.
> 
>> +		goto out;
>> +	}
> 
> I think that 'goto out' using is not proper for supporting two case.
> Instead, you better to split out as following according to the type
> of parent device (devfreq device or cpufreq device).
> 
> 	switch (p_data->parent_type) {
> 	case DEVFREQ_PARENT_DEV:
> 		ret = get_target_freq_with_devfreq()
> 		break;
> 	case CPUFREQ_PARENT_DEV:
> 		ret = get_target_freq_with_cpufreq()
> 		break;
> 	default:
> 		dev_err(...)
> 		ret = -EINVAL;
> 		goto out;
> 	}
> 
> 	if (ret < 0) {
> 		/* exception handling for 'ret' value */
> 	}
> 
>> +
>>  	/*
>>  	 * If the parent and passive devfreq device uses the OPP table,
>>  	 * get the next frequency by using the OPP table.
>> @@ -149,6 +211,200 @@ static int devfreq_passive_notifier_call(struct 
>> notifier_block *nb,
>>  	return NOTIFY_DONE;
>>  }
>> 
>> +static int cpufreq_passive_notifier_call(struct notifier_block *nb,
>> +					 unsigned long event, void *ptr)
>> +{
>> +	struct devfreq_passive_data *data =
>> +			container_of(nb, struct devfreq_passive_data, nb);
>> +	struct devfreq *devfreq = (struct devfreq *)data->this;
>> +	struct cpufreq_freqs *freq = ptr;
>> +	struct devfreq_cpu_state *state;
> 
> nitpick. how about using 'cpu_state' instead of 'state'?
> in order to get the meaning from just variable name.
> 
>> +	int ret = 0;
>> +
>> +	if (event != CPUFREQ_POSTCHANGE)
>> +		goto out;
> 
> just 'return' is simple instead of 'goto out' because this case
> don't need to treat the any restoring code. And also, you have
> to check whether freq is NULL or not as following:
> 
> 	if (event != CPUFREQ_POSTCHANGE || !freq || data->state[freq->cpu])
> 		return ret;
> 	state = data->state[freq->cpu];
> 
>> +
>> +	state = data->state[freq->cpu];
>> +	if (!state)
>> +		goto out;
>> +
>> +	if (state->freq != freq->new) {
>> +		state->freq = freq->new;
> 
> You have to update the frequency after update_devfreq() is completed
> without error.
> 
>> +		mutex_lock(&devfreq->lock);
>> +		ret = update_devfreq(devfreq);
>> +		mutex_unlock(&devfreq->lock);
>> +		if (ret)
>> +			dev_err(&devfreq->dev, "Frequency update failed.\n");
> 
> Almost devfreq error used the following format: "Couldn't ..." .
> If there is no any specific reason to change the format for error log,
> 	"Couldnt update the frequency.\n"
> 
>> +	}> +out:
>> +	return ret;
> 
> Also, we can reduce the unneeded indentation as following:
> 
> 	if (state->freq == freq->new)
> 		return ret;
> 
> 	mutex_lock(&devfreq->lock);
> 	ret = update_devfreq(devfreq);
> 	mutex_unlock(&devfreq->lock);
> 	if (ret) {
> 		dev_err(&devfreq->dev, "Couldnt update the frequency.\n");
> 		return ret;
> 	}
> 	state->freq = freq->new;
> 
> 	return 0;
> 
>> +}
>> +
>> +static int cpufreq_passive_register(struct devfreq_passive_data 
>> **p_data)
>> +{
>> +	unsigned int cpu;
>> +	struct devfreq_map **cpu_map;
>> +	struct devfreq_map *map, *per_cpu_map;
>> +	struct devfreq_passive_data *data = *p_data;
>> +	struct devfreq *devfreq = (struct devfreq *)data->this;
>> +	int i, count = 0, opp_cnt = 0, ret = 0, iter_val = 0;
>> +	struct device_node *np, *opp_table_np, *cpu_np;
>> +	struct opp_table *opp_table, *cpu_opp_tbl;
>> +	struct device *dev = devfreq->dev.parent;
>> +	struct devfreq_cpu_state *state;
>> +	struct dev_pm_opp *opp, *cpu_opp;
>> +	struct cpufreq_policy *policy;
>> +	struct device *cpu_dev;
>> +	u64 cpu_khz, dev_hz;
>> +
>> +	get_online_cpus();
>> +	data->nb.notifier_call = cpufreq_passive_notifier_call;
>> +	ret = cpufreq_register_notifier(&data->nb,
>> +					CPUFREQ_TRANSITION_NOTIFIER);
>> +	if (ret)
>> +		return ret;
>> +
>> +	/* Populate devfreq_cpu_state */
>> +	for_each_online_cpu(cpu) {
>> +		if (data->state[cpu])
>> +			continue;
>> +
>> +		policy = cpufreq_cpu_get(cpu);
>> +		if (policy) {
>> +			state = kzalloc(sizeof(*state), GFP_KERNEL);
>> +			if (!state)
>> +				return -ENOMEM;
>> +
>> +			state->first_cpu = cpumask_first(policy->related_cpus);
>> +			state->freq = policy->cur;
>> +			state->min_freq = policy->cpuinfo.min_freq;
>> +			state->max_freq = policy->cpuinfo.max_freq;
>> +			data->state[cpu] = state;
>> +			cpufreq_cpu_put(policy);
>> +		} else {
>> +			return -EPROBE_DEFER;
>> +		}
>> +	}
>> +
>> +	opp_table_np = dev_pm_opp_of_get_opp_desc_node(dev);
>> +	if (!opp_table_np)
>> +		goto out;
>> +
>> +	opp_cnt = dev_pm_opp_get_opp_count(dev);
>> +	if (opp_cnt <= 0)
>> +		goto put_opp_table;
>> +
>> +	/* Allocate memory for devfreq_map*/
>> +	cpu_map = kcalloc(num_possible_cpus(), sizeof(*cpu_map), 
>> GFP_KERNEL);
>> +	if (!cpu_map)
>> +		return -ENOMEM;
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		per_cpu_map = kcalloc(opp_cnt, sizeof(*per_cpu_map),
>> +				      GFP_KERNEL);
>> +		if (!per_cpu_map)
>> +			return -ENOMEM;
>> +		cpu_map[cpu] = per_cpu_map;
>> +	}
>> +	data->map = cpu_map;
>> +
>> +	/* Populate devfreq_map */
>> +	opp_table = dev_pm_opp_get_opp_table(dev);
>> +	if (!opp_table)
>> +		return -ENOMEM;
>> +
>> +	for_each_available_child_of_node(opp_table_np, np) {
>> +		opp = dev_pm_opp_find_opp_of_np(opp_table, np);
>> +		if (IS_ERR(opp))
>> +			continue;
>> +
>> +		dev_hz = dev_pm_opp_get_freq(opp);
>> +		dev_pm_opp_put(opp);
>> +
>> +		count = of_count_phandle_with_args(np, "required-opps", NULL);
>> +		for (i = 0; i < count; i++) {
>> +			for_each_possible_cpu(cpu) {
>> +				cpu_dev = get_cpu_device(cpu);
>> +				if (!cpu_dev) {
>> +					dev_err(dev, "CPU get device failed.\n");
>> +					continue;
>> +				}
>> +
>> +				cpu_np = of_parse_required_opp(np, i);
>> +				if (!cpu_np) {
>> +					dev_err(dev, "Parsing required opp failed.\n");
>> +					continue;
>> +				}
>> +
>> +				/* Get cpu opp-table */
>> +				cpu_opp_tbl = dev_pm_opp_get_opp_table(cpu_dev);
>> +				if (!cpu_opp_tbl) {
>> +					dev_err(dev, "CPU opp table get failed.\n");
>> +					goto put_cpu_node;
>> +				}
>> +
>> +				/* Match the cpu opp node from required-opp with
>> +				 * the cpu-opp table */
>> +				cpu_opp = dev_pm_opp_find_opp_of_np(cpu_opp_tbl,
>> +								    cpu_np);
>> +				if (!cpu_opp) {
>> +					dev_dbg(dev, "CPU opp get failed.\n");
>> +					goto put_cpu_opp_table;
>> +				}
>> +
>> +				cpu_khz = dev_pm_opp_get_freq(cpu_opp);
>> +				if (cpu_opp && cpu_khz) {
>> +					/* Update freq-map if not already set */
>> +					map = cpu_map[cpu];
>> +					map[iter_val].cpu_khz = cpu_khz / 1000;
>> +					map[iter_val].dev_hz = dev_hz;
>> +				}
>> +				dev_pm_opp_put(cpu_opp);
>> +put_cpu_opp_table:
>> +				dev_pm_opp_put_opp_table(cpu_opp_tbl);
>> +put_cpu_node:
>> +				of_node_put(cpu_np);
>> +			}
>> +		}
>> +		iter_val++;
>> +	}
>> +	dev_pm_opp_put_opp_table(opp_table);
>> +put_opp_table:
>> +	of_node_put(opp_table_np);
>> +out:
>> +	put_online_cpus();
>> +
>> +	/* Update devfreq */
>> +	mutex_lock(&devfreq->lock);
>> +	ret = update_devfreq(devfreq);
>> +	mutex_unlock(&devfreq->lock);
>> +	if (ret)
>> +		dev_err(dev, "Frequency update failed.\n");
>> +
>> +	return ret;
>> +}
>> +
>> +static int cpufreq_passive_unregister(struct devfreq_passive_data 
>> **p_data)
>> +{
>> +	int cpu;
>> +	struct devfreq_passive_data *data = *p_data;
>> +
>> +	cpufreq_unregister_notifier(&data->nb,
>> +				    CPUFREQ_TRANSITION_NOTIFIER);
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		kfree(data->state[cpu]);
>> +		kfree(data->map[cpu]);
>> +		data->state[cpu] = NULL;
>> +		data->map[cpu] = NULL;
>> +	}
>> +
>> +	kfree(data->map);
>> +	data->map = NULL;
>> +
>> +	return 0;
>> +}
>> +
>>  static int devfreq_passive_event_handler(struct devfreq *devfreq,
>>  				unsigned int event, void *data)
>>  {
>> @@ -159,7 +415,7 @@ static int devfreq_passive_event_handler(struct 
>> devfreq *devfreq,
>>  	struct notifier_block *nb = &p_data->nb;
>>  	int ret = 0;
>> 
>> -	if (!parent)
>> +	if (!parent && !p_data->cpufreq_type)
>>  		return -EPROBE_DEFER;
> 
> It makes the fault for the existing devfreq devices with passive 
> governor.
> Please remove '!p_data->cpufreq_type' condition.
> 
>> 
>>  	switch (event) {
>> @@ -167,13 +423,21 @@ static int devfreq_passive_event_handler(struct 
>> devfreq *devfreq,
>>  		if (!p_data->this)
>>  			p_data->this = devfreq;
>> 
>> -		nb->notifier_call = devfreq_passive_notifier_call;
>> -		ret = devm_devfreq_register_notifier(dev, parent, nb,
>> -					DEVFREQ_TRANSITION_NOTIFIER);
>> +		if (p_data->cpufreq_type) {
>> +			ret = cpufreq_passive_register(&p_data);
>> +		} else {
>> +			nb->notifier_call = devfreq_passive_notifier_call;
>> +			ret = devm_devfreq_register_notifier(dev, parent, nb,
>> +						DEVFREQ_TRANSITION_NOTIFIER);
>> +		}
> 
> I suggested the my opinion aboyt 'cpufreq_type' variable below.
> You can separte it for more clready with using parent device type.
> 
> 		if (p_data->parent_type == DEVFREQ_PARENT_DEV)
> 			...
> 		else if (p_data->parent_type == CPUFREQ_PARENT_DEV)
> 			...
> 		else
> 			// error handling
> 
>>  		break;
>>  	case DEVFREQ_GOV_STOP:
>> -		devm_devfreq_unregister_notifier(dev, parent, nb,
>> -					DEVFREQ_TRANSITION_NOTIFIER);
>> +		if (p_data->cpufreq_type) {
>> +			cpufreq_passive_unregister(&p_data);
>> +		} else {
>> +			devm_devfreq_unregister_notifier(dev, parent, nb,
>> +						DEVFREQ_TRANSITION_NOTIFIER);
>> +		}
> 
> ditto.
> 
>>  		break;
>>  	default:
>>  		break;
>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>> index fbffa74bfc1b..e8235fbe49e6 100644
>> --- a/include/linux/devfreq.h
>> +++ b/include/linux/devfreq.h
>> @@ -265,6 +265,38 @@ struct devfreq_simple_ondemand_data {
>>  #endif
>> 
>>  #if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
>> +/**
>> + * struct devfreq_cpu_state - holds the per-cpu state
>> + * @freq:	holds the current frequency of the cpu.
>> + * @min_freq:	holds the min frequency of the cpu.
>> + * @max_freq:	holds the max frequency of the cpu.
>> + * @first_cpu:	holds the cpumask of the first cpu of a policy.
>> + *
>> + * This structure stores the required cpu_state of a cpu.
>> + * This is auto-populated by the governor.
>> + */
>> +struct devfreq_cpu_state {
>> +	unsigned int freq;
>> +	unsigned int min_freq;
>> +	unsigned int max_freq;
>> +	unsigned int first_cpu;
>> +};
>> +
>> +/**
>> + * struct devfreq_map - holds mapping from cpu frequency
>> + * to devfreq frequency
>> + * @cpu_khz:	holds the cpu frequency in Khz
>> + * @dev_hz:	holds the devfreq device frequency in Hz
>> + *
>> + * This structure stores the lookup table between cpu
>> + * and the devfreq device. This is auto-populated by the
>> + * governor.
>> + */
>> +struct devfreq_map {
> 
> How about changing the structure name as following or others?
> - devfreq_freq_map or devfreq_cpufreq_map or others.
> 
> Because this structure name guessing the meaning of mapping
> between devfreq frequency and cpufreq frequency.
> 
>> +	unsigned int cpu_khz;
>> +	unsigned int dev_hz;
>> +};
>> +
>>  /**
>>   * struct devfreq_passive_data - void *data fed to struct devfreq
>>   *	and devfreq_add_device
>> @@ -278,11 +310,13 @@ struct devfreq_simple_ondemand_data {
>>   *			the next frequency, should use this callback.
>>   * @this:	the devfreq instance of own device.
>>   * @nb:		the notifier block for DEVFREQ_TRANSITION_NOTIFIER list
>> + * @state:	holds the state min/max/current frequency of all online 
>> cpu's
> 
> As I commented above, how about using 'cpu_state' instead of 'state'?
> in order to get the meaning from just variable name.
> 
> nitpick. Also,  I think that you can skip 'holds' from the description
> of 'state' variable.
> 
> 
>> + * @map:	holds the maps between cpu frequency and device frequency
> 
> How about using 'cpufreq_map' instead of 'map' for the readability?
> IMHO, Because this variable is only used when parent device is cpu.
> I think that if you add to specify the meaningful prefix about cpu to
> variable name,
> it is easy to catch the meaning of variable.
> - map -> cpufreq_map.
> 
> nitpick. Also,  I think that you can skip 'holds' from the description
> of 'map' variable.
> 
>>   *
>>   * The devfreq_passive_data have to set the devfreq instance of 
>> parent
>>   * device with governors except for the passive governor. But, don't 
>> need to
>> - * initialize the 'this' and 'nb' field because the devfreq core will 
>> handle
>> - * them.
>> + * initialize the 'this', 'nb', 'state' and 'map' field because the 
>> devfreq
> 
> If you agree my opinion above,
> - state -> cpu_state.
> - map -> cpufreq_map
> 
>> + * core will handle them.
>>   */
>>  struct devfreq_passive_data {
>>  	/* Should set the devfreq instance of parent device */
>> @@ -291,9 +325,14 @@ struct devfreq_passive_data {
>>  	/* Optional callback to decide the next frequency of passvice device 
>> */
>>  	int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
>> 
>> +	/* Should be set if the devfreq device wants to be scaled with cpu*/
>> +	u8 cpufreq_type;
> 
> The devfreq devices with passive governor have always parent
> either devfreq device or cpufreq device. So, you better to specify
> the parent type as following: I think that it is more clear to check
> the type of parent device.
> 
> 	enum devfreq_parent_dev_type {
> 		DEVFREQ_PARENT_DEV,
> 		CPUFREQ_PARENT_DEV,
> 	};
> 
> 	enum devfreq_parent_dev_type parent_type;
> 
>> +
>>  	/* For passive governor's internal use. Don't need to set them */
>>  	struct devfreq *this;
>>  	struct notifier_block nb;
>> +	struct devfreq_cpu_state *state[NR_CPUS];
>> +	struct devfreq_map **map;
> 
> ditto.
> 
>>  };
>>  #endif
>> 
>> 

-- 
-- Sibi Sankar --
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

^ permalink raw reply	[relevance 6%]

* Re: [PATCH RFC 3/9] PM / devfreq: Add cpu based scaling support to passive_governor
  2019-05-27  8:23     ` Sibi Sankar
@ 2019-05-28  1:27       ` Chanwoo Choi
  0 siblings, 0 replies; 200+ results
From: Chanwoo Choi @ 2019-05-28  1:27 UTC (permalink / raw)
  To: Sibi Sankar
  Cc: robh+dt, andy.gross, myungjoo.ham, kyungmin.park, rjw,
	viresh.kumar, nm, sboyd, georgi.djakov, bjorn.andersson,
	david.brown, mark.rutland, linux-kernel, linux-arm-msm-owner,
	devicetree, rnayak, linux-pm, evgreen, daidavid1, dianders,
	Saravana Kannan, linux-kernel-owner

Hi Sibi,

On 19. 5. 27. 오후 5:23, Sibi Sankar wrote:
> Hey Chanwoo,
> 
> Thanks a lot for reviewing the patch. Like I
> had indicated earlier we decided to go with
> a simpler approach instead on qualcomm SoCs.
> I am happy to re-spin this patch with your
> comments addressed if we do find other users
> for this feature.

Actually, I think that this approach is necessary.
On many real released product like smartphone
have the dependency between cpufreq and devfreq
for memory bus bandwidth. For example, when playing
the video or get the 60fps without loss.

If possible, this patch should be ongoing on either
now or future. Thanks.

> 
> On 2019-04-12 13:09, Chanwoo Choi wrote:
>> Hi,
>>
>> I agree this approach absolutely.
>> Just I add some comments. Please check it.
>>
>> On 19. 3. 29. 오전 12:28, Sibi Sankar wrote:
>>> From: Saravana Kannan <skannan@codeaurora.org>
>>>
>>> Many CPU architectures have caches that can scale independent of the
>>> CPUs. Frequency scaling of the caches is necessary to make sure the cache
>>> is not a performance bottleneck that leads to poor performance and
>>> power. The same idea applies for RAM/DDR.
>>>
>>> To achieve this, this patch add support for cpu based scaling to the
>>> passive governor. This is accomplished by taking the current frequency
>>> of each CPU frequency domain and then adjusts the frequency of the cache
>>> (or any devfreq device) based on the frequency of the CPUs. It listens
>>> to CPU frequency transition notifiers to keep itself up to date on the
>>> current CPU frequency.
>>>
>>> To decide the frequency of the device, the governor does one of the
>>> following:
>>> * Constructs a CPU frequency to device frequency mapping table from
>>>   required-opps property of the devfreq device's opp_table
>>>
>>> * Scales the device frequency in proportion to the CPU frequency. So, if
>>>   the CPUs are running at their max frequency, the device runs at its
>>>   max frequency. If the CPUs are running at their min frequency, the
>>>   device runs at its min frequency. It is interpolated for frequencies
>>>   in between.
>>>
>>> Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
>>> [Sibi: Integrated cpu-freqmap governor into passive_governor]
>>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>>> ---
>>>  drivers/devfreq/Kconfig            |   4 +
>>>  drivers/devfreq/governor_passive.c | 276 ++++++++++++++++++++++++++++-
>>>  include/linux/devfreq.h            |  43 ++++-
>>>  3 files changed, 315 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
>>> index 6a172d338f6d..9a45f464a56b 100644
>>> --- a/drivers/devfreq/Kconfig
>>> +++ b/drivers/devfreq/Kconfig
>>> @@ -72,6 +72,10 @@ config DEVFREQ_GOV_PASSIVE
>>>        device. This governor does not change the frequency by itself
>>>        through sysfs entries. The passive governor recommends that
>>>        devfreq device uses the OPP table to get the frequency/voltage.
>>> +      Alternatively the governor can also be chosen to scale based on
>>> +      the online CPUs current frequency. A CPU frequency to device
>>> +      frequency mapping table(s) is auto-populated by the governor
>>> +      for this purpose.
>>>
>>>  comment "DEVFREQ Drivers"
>>>
>>> diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
>>> index 3bc29acbd54e..2506682b233b 100644
>>> --- a/drivers/devfreq/governor_passive.c
>>> +++ b/drivers/devfreq/governor_passive.c
>>> @@ -11,10 +11,63 @@
>>>   */
>>>
>>>  #include <linux/module.h>
>>> +#include <linux/cpu.h>
>>> +#include <linux/cpufreq.h>
>>> +#include <linux/cpumask.h>
>>>  #include <linux/device.h>
>>>  #include <linux/devfreq.h>
>>> +#include <linux/of.h>
>>> +#include <linux/slab.h>
>>>  #include "governor.h"
>>>
>>> +static unsigned int xlate_cpufreq_to_devfreq(struct devfreq_passive_data *data,
>>> +                         unsigned int cpu)
>>> +{
>>> +    unsigned int cpu_min, cpu_max;
>>> +    struct devfreq *devfreq = (struct devfreq *)data->this;
>>> +    unsigned int dev_min, dev_max, cpu_percent, cpu_freq = 0, freq = 0;
>>> +    unsigned long *freq_table = devfreq->profile->freq_table;
>>> +    struct device *dev = devfreq->dev.parent;
>>> +    struct devfreq_map *map;
>>> +    int opp_cnt, i;
>>> +
>>> +    if (!data->state[cpu] || data->state[cpu]->first_cpu != cpu) {
>>> +        freq = 0;
>>> +        goto out;
>>
>> goto out -> return 0;
>>
>>> +    }
>>> +
>>> +    /* Use Interpolation if map is not available */
>>> +    cpu_freq = data->state[cpu]->freq;
>>> +    if (!data->map) {
>>> +        cpu_min = data->state[cpu]->min_freq;
>>> +        cpu_max = data->state[cpu]->max_freq;
>>> +        if (freq_table) {
>>> +            dev_min = freq_table[0];
>>> +            dev_max = freq_table[devfreq->profile->max_state - 1];
>>
>> Actually, it is not always true. The devfreq recommend the ascending order for
>> 'freq_table'. But, it is not mandatory. Also, some devfreq device uses the
>> decending order for 'freq_table'. So, a patch[1] was considering the order
>> when getting the minimum/maximum frequency from freq_table.
>>
>> If you want to get the minimum/maximum frequency, you have to consider the order
>> of 'freq_table' as the patch[1].
>>
>> [1] df5cf4a36178 ("PM / devfreq: Fix handling of min/max_freq == 0")
>>
>>              /* Get minimum frequency according to sorting order */
>> +               if (freq_table[0] < freq_table[df->profile->max_state - 1])
>> +                       value = freq_table[0];
>> +               else
>> +                       value = freq_table[df->profile->max_state - 1];
>>
>>
>>> +        } else {
>>> +            if (devfreq->max_freq <= devfreq->min_freq)
>>> +                return 0;
>>> +            dev_min = devfreq->min_freq;
>>> +            dev_max = devfreq->max_freq;
>>> +        }
>>> +
>>> +        cpu_percent = ((cpu_freq - cpu_min) * 100) / cpu_max - cpu_min;
>>> +        freq = dev_min + mult_frac(dev_max - dev_min, cpu_percent, 100);
>>> +        goto out;
>>
>> You don't need to jump 'out'. Instead, you better to use the 'else' statement
>> for if data->map is not NULL. I think that almost case when using this patch
>> will be available of data->map. In order to skip the likely 'false' statement,
>> I recommend the following sequence.
>>
>>     if (data->map) {
>>         map = data->map[cpu];
>>         ...
>>     } else {
>>         /* Use Interpolation if map is not available */
>>     }
>>
>>
>>> +    }
>>> +
>>> +    map = data->map[cpu];
>>> +    opp_cnt = dev_pm_opp_get_opp_count(dev);
>>> +    for (i = 0; i < opp_cnt; i++) {
>>> +        freq = max(freq, map[i].dev_hz);
>>> +        if (map[i].cpu_khz >= cpu_freq)
>>> +            break;
>>> +    }
>>> +out:
>>> +    dev_dbg(dev, "CPU%u: %d -> dev: %u\n", cpu, cpu_freq, freq);
>>
>> IMO, I think it is not necessary. If you want to print log, you better to print
>> it on device driver instead of governor.
>>
>>> +    return freq;
>>> +}
>>> +
>>>  static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>>>                      unsigned long *freq)
>>>  {
>>> @@ -23,6 +76,7 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>>>      struct devfreq *parent_devfreq = (struct devfreq *)p_data->parent;
>>>      unsigned long child_freq = ULONG_MAX;
>>>      struct dev_pm_opp *opp;
>>> +    unsigned int cpu, tgt_freq = 0;
>>
>> tgt means 'target'? If right, just use target_freq intead of 'tgt_freq'
>> for the readability.
>>
>>>      int i, count, ret = 0;
>>>
>>>      /*
>>> @@ -35,6 +89,14 @@ static int devfreq_passive_get_target_freq(struct devfreq *devfreq,
>>>          goto out;
>>>      }
>>>
>>> +    if (p_data->cpufreq_type) {
>>> +        for_each_possible_cpu(cpu)
>>> +            tgt_freq = max(tgt_freq,
>>> +                       xlate_cpufreq_to_devfreq(p_data, cpu));
>>> +        *freq = tgt_freq;
>>
>> You better to change from 'tgt_freq' to 'target_freq' for the readability.
>>
>>> +        goto out;
>>> +    }
>>
>> I think that 'goto out' using is not proper for supporting two case.
>> Instead, you better to split out as following according to the type
>> of parent device (devfreq device or cpufreq device).
>>
>>     switch (p_data->parent_type) {
>>     case DEVFREQ_PARENT_DEV:
>>         ret = get_target_freq_with_devfreq()
>>         break;
>>     case CPUFREQ_PARENT_DEV:
>>         ret = get_target_freq_with_cpufreq()
>>         break;
>>     default:
>>         dev_err(...)
>>         ret = -EINVAL;
>>         goto out;
>>     }
>>
>>     if (ret < 0) {
>>         /* exception handling for 'ret' value */
>>     }
>>
>>> +
>>>      /*
>>>       * If the parent and passive devfreq device uses the OPP table,
>>>       * get the next frequency by using the OPP table.
>>> @@ -149,6 +211,200 @@ static int devfreq_passive_notifier_call(struct notifier_block *nb,
>>>      return NOTIFY_DONE;
>>>  }
>>>
>>> +static int cpufreq_passive_notifier_call(struct notifier_block *nb,
>>> +                     unsigned long event, void *ptr)
>>> +{
>>> +    struct devfreq_passive_data *data =
>>> +            container_of(nb, struct devfreq_passive_data, nb);
>>> +    struct devfreq *devfreq = (struct devfreq *)data->this;
>>> +    struct cpufreq_freqs *freq = ptr;
>>> +    struct devfreq_cpu_state *state;
>>
>> nitpick. how about using 'cpu_state' instead of 'state'?
>> in order to get the meaning from just variable name.
>>
>>> +    int ret = 0;
>>> +
>>> +    if (event != CPUFREQ_POSTCHANGE)
>>> +        goto out;
>>
>> just 'return' is simple instead of 'goto out' because this case
>> don't need to treat the any restoring code. And also, you have
>> to check whether freq is NULL or not as following:
>>
>>     if (event != CPUFREQ_POSTCHANGE || !freq || data->state[freq->cpu])
>>         return ret;
>>     state = data->state[freq->cpu];
>>
>>> +
>>> +    state = data->state[freq->cpu];
>>> +    if (!state)
>>> +        goto out;
>>> +
>>> +    if (state->freq != freq->new) {
>>> +        state->freq = freq->new;
>>
>> You have to update the frequency after update_devfreq() is completed
>> without error.
>>
>>> +        mutex_lock(&devfreq->lock);
>>> +        ret = update_devfreq(devfreq);
>>> +        mutex_unlock(&devfreq->lock);
>>> +        if (ret)
>>> +            dev_err(&devfreq->dev, "Frequency update failed.\n");
>>
>> Almost devfreq error used the following format: "Couldn't ..." .
>> If there is no any specific reason to change the format for error log,
>>     "Couldnt update the frequency.\n"
>>
>>> +    }> +out:
>>> +    return ret;
>>
>> Also, we can reduce the unneeded indentation as following:
>>
>>     if (state->freq == freq->new)
>>         return ret;
>>
>>     mutex_lock(&devfreq->lock);
>>     ret = update_devfreq(devfreq);
>>     mutex_unlock(&devfreq->lock);
>>     if (ret) {
>>         dev_err(&devfreq->dev, "Couldnt update the frequency.\n");
>>         return ret;
>>     }
>>     state->freq = freq->new;
>>
>>     return 0;
>>
>>> +}
>>> +
>>> +static int cpufreq_passive_register(struct devfreq_passive_data **p_data)
>>> +{
>>> +    unsigned int cpu;
>>> +    struct devfreq_map **cpu_map;
>>> +    struct devfreq_map *map, *per_cpu_map;
>>> +    struct devfreq_passive_data *data = *p_data;
>>> +    struct devfreq *devfreq = (struct devfreq *)data->this;
>>> +    int i, count = 0, opp_cnt = 0, ret = 0, iter_val = 0;
>>> +    struct device_node *np, *opp_table_np, *cpu_np;
>>> +    struct opp_table *opp_table, *cpu_opp_tbl;
>>> +    struct device *dev = devfreq->dev.parent;
>>> +    struct devfreq_cpu_state *state;
>>> +    struct dev_pm_opp *opp, *cpu_opp;
>>> +    struct cpufreq_policy *policy;
>>> +    struct device *cpu_dev;
>>> +    u64 cpu_khz, dev_hz;
>>> +
>>> +    get_online_cpus();
>>> +    data->nb.notifier_call = cpufreq_passive_notifier_call;
>>> +    ret = cpufreq_register_notifier(&data->nb,
>>> +                    CPUFREQ_TRANSITION_NOTIFIER);
>>> +    if (ret)
>>> +        return ret;
>>> +
>>> +    /* Populate devfreq_cpu_state */
>>> +    for_each_online_cpu(cpu) {
>>> +        if (data->state[cpu])
>>> +            continue;
>>> +
>>> +        policy = cpufreq_cpu_get(cpu);
>>> +        if (policy) {
>>> +            state = kzalloc(sizeof(*state), GFP_KERNEL);
>>> +            if (!state)
>>> +                return -ENOMEM;
>>> +
>>> +            state->first_cpu = cpumask_first(policy->related_cpus);
>>> +            state->freq = policy->cur;
>>> +            state->min_freq = policy->cpuinfo.min_freq;
>>> +            state->max_freq = policy->cpuinfo.max_freq;
>>> +            data->state[cpu] = state;
>>> +            cpufreq_cpu_put(policy);
>>> +        } else {
>>> +            return -EPROBE_DEFER;
>>> +        }
>>> +    }
>>> +
>>> +    opp_table_np = dev_pm_opp_of_get_opp_desc_node(dev);
>>> +    if (!opp_table_np)
>>> +        goto out;
>>> +
>>> +    opp_cnt = dev_pm_opp_get_opp_count(dev);
>>> +    if (opp_cnt <= 0)
>>> +        goto put_opp_table;
>>> +
>>> +    /* Allocate memory for devfreq_map*/
>>> +    cpu_map = kcalloc(num_possible_cpus(), sizeof(*cpu_map), GFP_KERNEL);
>>> +    if (!cpu_map)
>>> +        return -ENOMEM;
>>> +
>>> +    for_each_possible_cpu(cpu) {
>>> +        per_cpu_map = kcalloc(opp_cnt, sizeof(*per_cpu_map),
>>> +                      GFP_KERNEL);
>>> +        if (!per_cpu_map)
>>> +            return -ENOMEM;
>>> +        cpu_map[cpu] = per_cpu_map;
>>> +    }
>>> +    data->map = cpu_map;
>>> +
>>> +    /* Populate devfreq_map */
>>> +    opp_table = dev_pm_opp_get_opp_table(dev);
>>> +    if (!opp_table)
>>> +        return -ENOMEM;
>>> +
>>> +    for_each_available_child_of_node(opp_table_np, np) {
>>> +        opp = dev_pm_opp_find_opp_of_np(opp_table, np);
>>> +        if (IS_ERR(opp))
>>> +            continue;
>>> +
>>> +        dev_hz = dev_pm_opp_get_freq(opp);
>>> +        dev_pm_opp_put(opp);
>>> +
>>> +        count = of_count_phandle_with_args(np, "required-opps", NULL);
>>> +        for (i = 0; i < count; i++) {
>>> +            for_each_possible_cpu(cpu) {
>>> +                cpu_dev = get_cpu_device(cpu);
>>> +                if (!cpu_dev) {
>>> +                    dev_err(dev, "CPU get device failed.\n");
>>> +                    continue;
>>> +                }
>>> +
>>> +                cpu_np = of_parse_required_opp(np, i);
>>> +                if (!cpu_np) {
>>> +                    dev_err(dev, "Parsing required opp failed.\n");
>>> +                    continue;
>>> +                }
>>> +
>>> +                /* Get cpu opp-table */
>>> +                cpu_opp_tbl = dev_pm_opp_get_opp_table(cpu_dev);
>>> +                if (!cpu_opp_tbl) {
>>> +                    dev_err(dev, "CPU opp table get failed.\n");
>>> +                    goto put_cpu_node;
>>> +                }
>>> +
>>> +                /* Match the cpu opp node from required-opp with
>>> +                 * the cpu-opp table */
>>> +                cpu_opp = dev_pm_opp_find_opp_of_np(cpu_opp_tbl,
>>> +                                    cpu_np);
>>> +                if (!cpu_opp) {
>>> +                    dev_dbg(dev, "CPU opp get failed.\n");
>>> +                    goto put_cpu_opp_table;
>>> +                }
>>> +
>>> +                cpu_khz = dev_pm_opp_get_freq(cpu_opp);
>>> +                if (cpu_opp && cpu_khz) {
>>> +                    /* Update freq-map if not already set */
>>> +                    map = cpu_map[cpu];
>>> +                    map[iter_val].cpu_khz = cpu_khz / 1000;
>>> +                    map[iter_val].dev_hz = dev_hz;
>>> +                }
>>> +                dev_pm_opp_put(cpu_opp);
>>> +put_cpu_opp_table:
>>> +                dev_pm_opp_put_opp_table(cpu_opp_tbl);
>>> +put_cpu_node:
>>> +                of_node_put(cpu_np);
>>> +            }
>>> +        }
>>> +        iter_val++;
>>> +    }
>>> +    dev_pm_opp_put_opp_table(opp_table);
>>> +put_opp_table:
>>> +    of_node_put(opp_table_np);
>>> +out:
>>> +    put_online_cpus();
>>> +
>>> +    /* Update devfreq */
>>> +    mutex_lock(&devfreq->lock);
>>> +    ret = update_devfreq(devfreq);
>>> +    mutex_unlock(&devfreq->lock);
>>> +    if (ret)
>>> +        dev_err(dev, "Frequency update failed.\n");
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +static int cpufreq_passive_unregister(struct devfreq_passive_data **p_data)
>>> +{
>>> +    int cpu;
>>> +    struct devfreq_passive_data *data = *p_data;
>>> +
>>> +    cpufreq_unregister_notifier(&data->nb,
>>> +                    CPUFREQ_TRANSITION_NOTIFIER);
>>> +
>>> +    for_each_possible_cpu(cpu) {
>>> +        kfree(data->state[cpu]);
>>> +        kfree(data->map[cpu]);
>>> +        data->state[cpu] = NULL;
>>> +        data->map[cpu] = NULL;
>>> +    }
>>> +
>>> +    kfree(data->map);
>>> +    data->map = NULL;
>>> +
>>> +    return 0;
>>> +}
>>> +
>>>  static int devfreq_passive_event_handler(struct devfreq *devfreq,
>>>                  unsigned int event, void *data)
>>>  {
>>> @@ -159,7 +415,7 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
>>>      struct notifier_block *nb = &p_data->nb;
>>>      int ret = 0;
>>>
>>> -    if (!parent)
>>> +    if (!parent && !p_data->cpufreq_type)
>>>          return -EPROBE_DEFER;
>>
>> It makes the fault for the existing devfreq devices with passive governor.
>> Please remove '!p_data->cpufreq_type' condition.
>>
>>>
>>>      switch (event) {
>>> @@ -167,13 +423,21 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
>>>          if (!p_data->this)
>>>              p_data->this = devfreq;
>>>
>>> -        nb->notifier_call = devfreq_passive_notifier_call;
>>> -        ret = devm_devfreq_register_notifier(dev, parent, nb,
>>> -                    DEVFREQ_TRANSITION_NOTIFIER);
>>> +        if (p_data->cpufreq_type) {
>>> +            ret = cpufreq_passive_register(&p_data);
>>> +        } else {
>>> +            nb->notifier_call = devfreq_passive_notifier_call;
>>> +            ret = devm_devfreq_register_notifier(dev, parent, nb,
>>> +                        DEVFREQ_TRANSITION_NOTIFIER);
>>> +        }
>>
>> I suggested the my opinion aboyt 'cpufreq_type' variable below.
>> You can separte it for more clready with using parent device type.
>>
>>         if (p_data->parent_type == DEVFREQ_PARENT_DEV)
>>             ...
>>         else if (p_data->parent_type == CPUFREQ_PARENT_DEV)
>>             ...
>>         else
>>             // error handling
>>
>>>          break;
>>>      case DEVFREQ_GOV_STOP:
>>> -        devm_devfreq_unregister_notifier(dev, parent, nb,
>>> -                    DEVFREQ_TRANSITION_NOTIFIER);
>>> +        if (p_data->cpufreq_type) {
>>> +            cpufreq_passive_unregister(&p_data);
>>> +        } else {
>>> +            devm_devfreq_unregister_notifier(dev, parent, nb,
>>> +                        DEVFREQ_TRANSITION_NOTIFIER);
>>> +        }
>>
>> ditto.
>>
>>>          break;
>>>      default:
>>>          break;
>>> diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
>>> index fbffa74bfc1b..e8235fbe49e6 100644
>>> --- a/include/linux/devfreq.h
>>> +++ b/include/linux/devfreq.h
>>> @@ -265,6 +265,38 @@ struct devfreq_simple_ondemand_data {
>>>  #endif
>>>
>>>  #if IS_ENABLED(CONFIG_DEVFREQ_GOV_PASSIVE)
>>> +/**
>>> + * struct devfreq_cpu_state - holds the per-cpu state
>>> + * @freq:    holds the current frequency of the cpu.
>>> + * @min_freq:    holds the min frequency of the cpu.
>>> + * @max_freq:    holds the max frequency of the cpu.
>>> + * @first_cpu:    holds the cpumask of the first cpu of a policy.
>>> + *
>>> + * This structure stores the required cpu_state of a cpu.
>>> + * This is auto-populated by the governor.
>>> + */
>>> +struct devfreq_cpu_state {
>>> +    unsigned int freq;
>>> +    unsigned int min_freq;
>>> +    unsigned int max_freq;
>>> +    unsigned int first_cpu;
>>> +};
>>> +
>>> +/**
>>> + * struct devfreq_map - holds mapping from cpu frequency
>>> + * to devfreq frequency
>>> + * @cpu_khz:    holds the cpu frequency in Khz
>>> + * @dev_hz:    holds the devfreq device frequency in Hz
>>> + *
>>> + * This structure stores the lookup table between cpu
>>> + * and the devfreq device. This is auto-populated by the
>>> + * governor.
>>> + */
>>> +struct devfreq_map {
>>
>> How about changing the structure name as following or others?
>> - devfreq_freq_map or devfreq_cpufreq_map or others.
>>
>> Because this structure name guessing the meaning of mapping
>> between devfreq frequency and cpufreq frequency.
>>
>>> +    unsigned int cpu_khz;
>>> +    unsigned int dev_hz;
>>> +};
>>> +
>>>  /**
>>>   * struct devfreq_passive_data - void *data fed to struct devfreq
>>>   *    and devfreq_add_device
>>> @@ -278,11 +310,13 @@ struct devfreq_simple_ondemand_data {
>>>   *            the next frequency, should use this callback.
>>>   * @this:    the devfreq instance of own device.
>>>   * @nb:        the notifier block for DEVFREQ_TRANSITION_NOTIFIER list
>>> + * @state:    holds the state min/max/current frequency of all online cpu's
>>
>> As I commented above, how about using 'cpu_state' instead of 'state'?
>> in order to get the meaning from just variable name.
>>
>> nitpick. Also,  I think that you can skip 'holds' from the description
>> of 'state' variable.
>>
>>
>>> + * @map:    holds the maps between cpu frequency and device frequency
>>
>> How about using 'cpufreq_map' instead of 'map' for the readability?
>> IMHO, Because this variable is only used when parent device is cpu.
>> I think that if you add to specify the meaningful prefix about cpu to
>> variable name,
>> it is easy to catch the meaning of variable.
>> - map -> cpufreq_map.
>>
>> nitpick. Also,  I think that you can skip 'holds' from the description
>> of 'map' variable.
>>
>>>   *
>>>   * The devfreq_passive_data have to set the devfreq instance of parent
>>>   * device with governors except for the passive governor. But, don't need to
>>> - * initialize the 'this' and 'nb' field because the devfreq core will handle
>>> - * them.
>>> + * initialize the 'this', 'nb', 'state' and 'map' field because the devfreq
>>
>> If you agree my opinion above,
>> - state -> cpu_state.
>> - map -> cpufreq_map
>>
>>> + * core will handle them.
>>>   */
>>>  struct devfreq_passive_data {
>>>      /* Should set the devfreq instance of parent device */
>>> @@ -291,9 +325,14 @@ struct devfreq_passive_data {
>>>      /* Optional callback to decide the next frequency of passvice device */
>>>      int (*get_target_freq)(struct devfreq *this, unsigned long *freq);
>>>
>>> +    /* Should be set if the devfreq device wants to be scaled with cpu*/
>>> +    u8 cpufreq_type;
>>
>> The devfreq devices with passive governor have always parent
>> either devfreq device or cpufreq device. So, you better to specify
>> the parent type as following: I think that it is more clear to check
>> the type of parent device.
>>
>>     enum devfreq_parent_dev_type {
>>         DEVFREQ_PARENT_DEV,
>>         CPUFREQ_PARENT_DEV,
>>     };
>>
>>     enum devfreq_parent_dev_type parent_type;
>>
>>> +
>>>      /* For passive governor's internal use. Don't need to set them */
>>>      struct devfreq *this;
>>>      struct notifier_block nb;
>>> +    struct devfreq_cpu_state *state[NR_CPUS];
>>> +    struct devfreq_map **map;
>>
>> ditto.
>>
>>>  };
>>>  #endif
>>>
>>>
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

^ permalink raw reply	[relevance 0%]

* [PATCH v8 3/4] arm64: dts: qcom: Add AOSS QMP node
      [irrelevant] <20190531030057.18328-1-bjorn.andersson@linaro.org>
@ 2019-05-31  3:00 ` Bjorn Andersson
  2019-05-31  3:00 ` [PATCH v8 4/4] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
  1 sibling, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-05-31  3:00 UTC (permalink / raw)
  To: Andy Gross
  Cc: David Brown, Rob Herring, Mark Rutland, Doug Anderson,
	Arun Kumar Neelakantam, Vinod Koul, linux-arm-msm, devicetree,
	linux-kernel

The AOSS QMP provides a number of power domains, used for QDSS and
PIL, add the node for this.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v7:
- None

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index fcb93300ca62..b25c251b6503 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2142,6 +2142,16 @@
 			#reset-cells = <1>;
 		};
 
+		aoss_qmp: qmp@c300000 {
+			compatible = "qcom,sdm845-aoss-qmp";
+			reg = <0 0x0c300000 0 0x100000>;
+			interrupts = <GIC_SPI 389 IRQ_TYPE_EDGE_RISING>;
+			mboxes = <&apss_shared 0>;
+
+			#clock-cells = <0>;
+			#power-domain-cells = <1>;
+		};
+
 		spmi_bus: spmi@c440000 {
 			compatible = "qcom,spmi-pmic-arb";
 			reg = <0 0x0c440000 0 0x1100>,
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* [PATCH v8 4/4] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
      [irrelevant] <20190531030057.18328-1-bjorn.andersson@linaro.org>
  2019-05-31  3:00 ` [PATCH v8 3/4] arm64: dts: qcom: Add AOSS QMP node Bjorn Andersson
@ 2019-05-31  3:00 ` Bjorn Andersson
  1 sibling, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-05-31  3:00 UTC (permalink / raw)
  To: Andy Gross
  Cc: David Brown, Rob Herring, Mark Rutland, Doug Anderson,
	Arun Kumar Neelakantam, Vinod Koul, linux-arm-msm, devicetree,
	linux-kernel

From: Sibi Sankar <sibis@codeaurora.org>

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v7:
- None

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index b25c251b6503..978ceaec78cb 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1671,6 +1671,64 @@
 			};
 		};
 
+		mss_pil: remoteproc@4080000 {
+			compatible = "qcom,sdm845-mss-pil";
+			reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
+			reg-names = "qdsp6", "rmb";
+
+			interrupts-extended =
+				<&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog", "fatal", "ready",
+					  "handover", "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+				 <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+				 <&gcc GCC_BOOT_ROM_AHB_CLK>,
+				 <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+				 <&gcc GCC_MSS_SNOC_AXI_CLK>,
+				 <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+				 <&gcc GCC_PRNG_AHB_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "iface", "bus", "mem", "gpll0_mss",
+				      "snoc_axi", "mnoc_axi", "prng", "xo";
+
+			qcom,smem-states = <&modem_smp2p_out 0>;
+			qcom,smem-state-names = "stop";
+
+			resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+				 <&pdc_reset PDC_MODEM_SYNC_RESET>;
+			reset-names = "mss_restart", "pdc_reset";
+
+			qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000 0x24000>;
+
+			power-domains = <&aoss_qmp 2>,
+					<&rpmhpd SDM845_CX>,
+					<&rpmhpd SDM845_MX>,
+					<&rpmhpd SDM845_MSS>;
+			power-domain-names = "load_state", "cx", "mx", "mss";
+
+			mba {
+				memory-region = <&mba_region>;
+			};
+
+			mpss {
+				memory-region = <&mpss_region>;
+			};
+
+			glink-edge {
+				interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+				label = "modem";
+				qcom,remote-pid = <1>;
+				mboxes = <&apss_shared 12>;
+			};
+		};
+
 		gpucc: clock-controller@5090000 {
 			compatible = "qcom,sdm845-gpucc";
 			reg = <0 0x05090000 0 0x9000>;
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* [PATCH] arm64: dts: sdm845: Add iommus property to qup1
@ 2019-06-04 22:29 Stephen Boyd
  2019-06-04 22:37 ` Bjorn Andersson
  0 siblings, 1 reply; 200+ results
From: Stephen Boyd @ 2019-06-04 22:29 UTC (permalink / raw)
  To: Andy Gross; +Cc: linux-kernel, linux-arm-msm, Sibi Sankar

The SMMU that sits in front of the QUP needs to be programmed properly
so that the i2c geni driver can allocate DMA descriptors. Failure to do
this leads to faults when using devices such as an i2c touchscreen where
the transaction is larger than 32 bytes and we use a DMA buffer.

 arm-smmu 15000000.iommu: Unexpected global fault, this could be serious
 arm-smmu 15000000.iommu:         GFSR 0x00000002, GFSYNR0 0x00000002, GFSYNR1 0x000006c0, GFSYNR2 0x00000000

Add the right SID and mask so this works.

Cc: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index fcb93300ca62..2e57e861e17c 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -900,6 +900,7 @@
 			#address-cells = <2>;
 			#size-cells = <2>;
 			ranges;
+			iommus = <&apps_smmu 0x6c0 0x3>;
 			status = "disabled";
 
 			i2c8: i2c@a80000 {
-- 
Sent by a computer through tubes


^ permalink raw reply	[relevance 6%]

* Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1
  2019-06-04 22:29 [PATCH] arm64: dts: sdm845: Add iommus property to qup1 Stephen Boyd
@ 2019-06-04 22:37 ` Bjorn Andersson
  2019-06-04 22:46   ` Stephen Boyd
  2019-06-04 22:48   ` Doug Anderson
  0 siblings, 2 replies; 200+ results
From: Bjorn Andersson @ 2019-06-04 22:37 UTC (permalink / raw)
  To: Stephen Boyd; +Cc: Andy Gross, linux-kernel, linux-arm-msm, Sibi Sankar

On Tue 04 Jun 15:29 PDT 2019, Stephen Boyd wrote:

> The SMMU that sits in front of the QUP needs to be programmed properly
> so that the i2c geni driver can allocate DMA descriptors. Failure to do
> this leads to faults when using devices such as an i2c touchscreen where
> the transaction is larger than 32 bytes and we use a DMA buffer.
> 

I'm pretty sure I've run into this problem, but before we marked the
smmu bypass_disable and as such didn't get the fault, thanks.

>  arm-smmu 15000000.iommu: Unexpected global fault, this could be serious
>  arm-smmu 15000000.iommu:         GFSR 0x00000002, GFSYNR0 0x00000002, GFSYNR1 0x000006c0, GFSYNR2 0x00000000
> 
> Add the right SID and mask so this works.
> 
> Cc: Sibi Sankar <sibis@codeaurora.org>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> ---
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index fcb93300ca62..2e57e861e17c 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -900,6 +900,7 @@
>  			#address-cells = <2>;
>  			#size-cells = <2>;
>  			ranges;
> +			iommus = <&apps_smmu 0x6c0 0x3>;

According to the docs this stream belongs to TZ, the HLOS stream should
be 0x6c3.

Regards,
Bjorn

>  			status = "disabled";
>  
>  			i2c8: i2c@a80000 {
> -- 
> Sent by a computer through tubes
> 

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1
  2019-06-04 22:37 ` Bjorn Andersson
@ 2019-06-04 22:46   ` Stephen Boyd
  2019-06-04 22:59     ` Bjorn Andersson
  2019-06-05  4:55     ` Vivek Gautam
  2019-06-04 22:48   ` Doug Anderson
  1 sibling, 2 replies; 200+ results
From: Stephen Boyd @ 2019-06-04 22:46 UTC (permalink / raw)
  To: Bjorn Andersson; +Cc: Andy Gross, linux-kernel, linux-arm-msm, Sibi Sankar

Quoting Bjorn Andersson (2019-06-04 15:37:00)
> On Tue 04 Jun 15:29 PDT 2019, Stephen Boyd wrote:
> 
> > The SMMU that sits in front of the QUP needs to be programmed properly
> > so that the i2c geni driver can allocate DMA descriptors. Failure to do
> > this leads to faults when using devices such as an i2c touchscreen where
> > the transaction is larger than 32 bytes and we use a DMA buffer.
> > 
> 
> I'm pretty sure I've run into this problem, but before we marked the
> smmu bypass_disable and as such didn't get the fault, thanks.
> 
> >  arm-smmu 15000000.iommu: Unexpected global fault, this could be serious
> >  arm-smmu 15000000.iommu:         GFSR 0x00000002, GFSYNR0 0x00000002, GFSYNR1 0x000006c0, GFSYNR2 0x00000000
> > 
> > Add the right SID and mask so this works.
> > 
> > Cc: Sibi Sankar <sibis@codeaurora.org>
> > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > ---
> >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index fcb93300ca62..2e57e861e17c 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -900,6 +900,7 @@
> >                       #address-cells = <2>;
> >                       #size-cells = <2>;
> >                       ranges;
> > +                     iommus = <&apps_smmu 0x6c0 0x3>;
> 
> According to the docs this stream belongs to TZ, the HLOS stream should
> be 0x6c3.

Aye, I saw this line in the downstream kernel but it doesn't work for
me. If I specify <&apps_smmu 0x6c3 0x0> it still blows up. I wonder if
my firmware perhaps is missing some initialization here to make the QUP
operate in HLOS mode? Otherwise, I thought that the 0x3 at the end was
the mask and so it should be split off to the second cell in the DT
specifier but that seemed a little weird.


^ permalink raw reply	[relevance 0%]

* Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1
  2019-06-04 22:37 ` Bjorn Andersson
  2019-06-04 22:46   ` Stephen Boyd
@ 2019-06-04 22:48   ` Doug Anderson
  2019-06-04 22:56     ` Bjorn Andersson
  1 sibling, 1 reply; 200+ results
From: Doug Anderson @ 2019-06-04 22:48 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Stephen Boyd, Andy Gross, LKML, linux-arm-msm, Sibi Sankar

Hi,

On Tue, Jun 4, 2019 at 3:37 PM Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
>
> On Tue 04 Jun 15:29 PDT 2019, Stephen Boyd wrote:
>
> > The SMMU that sits in front of the QUP needs to be programmed properly
> > so that the i2c geni driver can allocate DMA descriptors. Failure to do
> > this leads to faults when using devices such as an i2c touchscreen where
> > the transaction is larger than 32 bytes and we use a DMA buffer.
> >
>
> I'm pretty sure I've run into this problem, but before we marked the
> smmu bypass_disable and as such didn't get the fault, thanks.
>
> >  arm-smmu 15000000.iommu: Unexpected global fault, this could be serious
> >  arm-smmu 15000000.iommu:         GFSR 0x00000002, GFSYNR0 0x00000002, GFSYNR1 0x000006c0, GFSYNR2 0x00000000
> >
> > Add the right SID and mask so this works.
> >
> > Cc: Sibi Sankar <sibis@codeaurora.org>
> > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > ---
> >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index fcb93300ca62..2e57e861e17c 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -900,6 +900,7 @@
> >                       #address-cells = <2>;
> >                       #size-cells = <2>;
> >                       ranges;
> > +                     iommus = <&apps_smmu 0x6c0 0x3>;
>
> According to the docs this stream belongs to TZ, the HLOS stream should
> be 0x6c3.

Since you've already got the docs in front of you, how about looking
up the value for qup0 so we can fix both of 'em?

-Doug

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1
  2019-06-04 22:48   ` Doug Anderson
@ 2019-06-04 22:56     ` Bjorn Andersson
  0 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-06-04 22:56 UTC (permalink / raw)
  To: Doug Anderson; +Cc: Stephen Boyd, Andy Gross, LKML, linux-arm-msm, Sibi Sankar

On Tue 04 Jun 15:48 PDT 2019, Doug Anderson wrote:

> Hi,
> 
> On Tue, Jun 4, 2019 at 3:37 PM Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> >
> > On Tue 04 Jun 15:29 PDT 2019, Stephen Boyd wrote:
> >
> > > The SMMU that sits in front of the QUP needs to be programmed properly
> > > so that the i2c geni driver can allocate DMA descriptors. Failure to do
> > > this leads to faults when using devices such as an i2c touchscreen where
> > > the transaction is larger than 32 bytes and we use a DMA buffer.
> > >
> >
> > I'm pretty sure I've run into this problem, but before we marked the
> > smmu bypass_disable and as such didn't get the fault, thanks.
> >
> > >  arm-smmu 15000000.iommu: Unexpected global fault, this could be serious
> > >  arm-smmu 15000000.iommu:         GFSR 0x00000002, GFSYNR0 0x00000002, GFSYNR1 0x000006c0, GFSYNR2 0x00000000
> > >
> > > Add the right SID and mask so this works.
> > >
> > > Cc: Sibi Sankar <sibis@codeaurora.org>
> > > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > > ---
> > >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > index fcb93300ca62..2e57e861e17c 100644
> > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > @@ -900,6 +900,7 @@
> > >                       #address-cells = <2>;
> > >                       #size-cells = <2>;
> > >                       ranges;
> > > +                     iommus = <&apps_smmu 0x6c0 0x3>;
> >
> > According to the docs this stream belongs to TZ, the HLOS stream should
> > be 0x6c3.
> 
> Since you've already got the docs in front of you, how about looking
> up the value for qup0 so we can fix both of 'em?
> 

Good thinking. QUP_1 is at stream 0x3.

Regards,
Bjorn

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1
  2019-06-04 22:46   ` Stephen Boyd
@ 2019-06-04 22:59     ` Bjorn Andersson
  2019-06-05  4:55     ` Vivek Gautam
  1 sibling, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-06-04 22:59 UTC (permalink / raw)
  To: Stephen Boyd, vivek.gautam
  Cc: Andy Gross, linux-kernel, linux-arm-msm, Sibi Sankar

On Tue 04 Jun 15:46 PDT 2019, Stephen Boyd wrote:

> Quoting Bjorn Andersson (2019-06-04 15:37:00)
> > On Tue 04 Jun 15:29 PDT 2019, Stephen Boyd wrote:
> > 
> > > The SMMU that sits in front of the QUP needs to be programmed properly
> > > so that the i2c geni driver can allocate DMA descriptors. Failure to do
> > > this leads to faults when using devices such as an i2c touchscreen where
> > > the transaction is larger than 32 bytes and we use a DMA buffer.
> > > 
> > 
> > I'm pretty sure I've run into this problem, but before we marked the
> > smmu bypass_disable and as such didn't get the fault, thanks.
> > 
> > >  arm-smmu 15000000.iommu: Unexpected global fault, this could be serious
> > >  arm-smmu 15000000.iommu:         GFSR 0x00000002, GFSYNR0 0x00000002, GFSYNR1 0x000006c0, GFSYNR2 0x00000000
> > > 
> > > Add the right SID and mask so this works.
> > > 
> > > Cc: Sibi Sankar <sibis@codeaurora.org>
> > > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > > ---
> > >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > index fcb93300ca62..2e57e861e17c 100644
> > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > @@ -900,6 +900,7 @@
> > >                       #address-cells = <2>;
> > >                       #size-cells = <2>;
> > >                       ranges;
> > > +                     iommus = <&apps_smmu 0x6c0 0x3>;
> > 
> > According to the docs this stream belongs to TZ, the HLOS stream should
> > be 0x6c3.
> 
> Aye, I saw this line in the downstream kernel but it doesn't work for
> me. If I specify <&apps_smmu 0x6c3 0x0> it still blows up. I wonder if
> my firmware perhaps is missing some initialization here to make the QUP
> operate in HLOS mode? Otherwise, I thought that the 0x3 at the end was
> the mask and so it should be split off to the second cell in the DT
> specifier but that seemed a little weird.
> 

Both 0x3 and 0x6c3 are documented as the actual HLOS stream id, with
mask of 0x0. 

Looping in Vivek as well.

Regards,
Bjorn

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1
  2019-06-04 22:46   ` Stephen Boyd
  2019-06-04 22:59     ` Bjorn Andersson
@ 2019-06-05  4:55     ` Vivek Gautam
  2019-06-05 20:56       ` Stephen Boyd
  1 sibling, 1 reply; 200+ results
From: Vivek Gautam @ 2019-06-05  4:55 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: Bjorn Andersson, Andy Gross, open list, linux-arm-msm, Sibi Sankar

On Wed, Jun 5, 2019 at 4:16 AM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Quoting Bjorn Andersson (2019-06-04 15:37:00)
> > On Tue 04 Jun 15:29 PDT 2019, Stephen Boyd wrote:
> >
> > > The SMMU that sits in front of the QUP needs to be programmed properly
> > > so that the i2c geni driver can allocate DMA descriptors. Failure to do
> > > this leads to faults when using devices such as an i2c touchscreen where
> > > the transaction is larger than 32 bytes and we use a DMA buffer.
> > >
> >
> > I'm pretty sure I've run into this problem, but before we marked the
> > smmu bypass_disable and as such didn't get the fault, thanks.
> >
> > >  arm-smmu 15000000.iommu: Unexpected global fault, this could be serious
> > >  arm-smmu 15000000.iommu:         GFSR 0x00000002, GFSYNR0 0x00000002, GFSYNR1 0x000006c0, GFSYNR2 0x00000000
> > >
> > > Add the right SID and mask so this works.
> > >
> > > Cc: Sibi Sankar <sibis@codeaurora.org>
> > > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > > ---
> > >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > index fcb93300ca62..2e57e861e17c 100644
> > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > @@ -900,6 +900,7 @@
> > >                       #address-cells = <2>;
> > >                       #size-cells = <2>;
> > >                       ranges;
> > > +                     iommus = <&apps_smmu 0x6c0 0x3>;
> >
> > According to the docs this stream belongs to TZ, the HLOS stream should
> > be 0x6c3.
>
> Aye, I saw this line in the downstream kernel but it doesn't work for
> me. If I specify <&apps_smmu 0x6c3 0x0> it still blows up. I wonder if
> my firmware perhaps is missing some initialization here to make the QUP
> operate in HLOS mode? Otherwise, I thought that the 0x3 at the end was
> the mask and so it should be split off to the second cell in the DT
> specifier but that seemed a little weird.

Two things here -
0x6c0 - TZ SID. Do you see above fault on MTP sdm845 devices?
0x6c3/0x6c6 - HLOS SIDs.

Cheza will throw faults for anything that is programmed with TZ on mtp
as all of that should be handled in HLOS. The firmwares of all these
peripherals assume that the SID reservation is done (whether in TZ or HLOS).

I am inclined to moving the iommus property for all 'TZ' to board dts files.
MTP wouldn't need those SIDs. So, the SOC level dtsi will have just the
HLOS SIDs.

P.S.
As you rightly said, the second cell in iommus property is the mask so that
the iommu is able to reserve all that SIDs that are covered with the
starting SID
and the mask.


Best regards
Vivek
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1
  2019-06-05  4:55     ` Vivek Gautam
@ 2019-06-05 20:56       ` Stephen Boyd
  2019-06-06 11:17         ` Vivek Gautam
  0 siblings, 1 reply; 200+ results
From: Stephen Boyd @ 2019-06-05 20:56 UTC (permalink / raw)
  To: Vivek Gautam
  Cc: Bjorn Andersson, Andy Gross, open list, linux-arm-msm, Sibi Sankar

Quoting Vivek Gautam (2019-06-04 21:55:26)
> On Wed, Jun 5, 2019 at 4:16 AM Stephen Boyd <swboyd@chromium.org> wrote:
> >
> > Quoting Bjorn Andersson (2019-06-04 15:37:00)
> > > On Tue 04 Jun 15:29 PDT 2019, Stephen Boyd wrote:
> > >
> > > > The SMMU that sits in front of the QUP needs to be programmed properly
> > > > so that the i2c geni driver can allocate DMA descriptors. Failure to do
> > > > this leads to faults when using devices such as an i2c touchscreen where
> > > > the transaction is larger than 32 bytes and we use a DMA buffer.
> > > >
> > >
> > > I'm pretty sure I've run into this problem, but before we marked the
> > > smmu bypass_disable and as such didn't get the fault, thanks.
> > >
> > > >  arm-smmu 15000000.iommu: Unexpected global fault, this could be serious
> > > >  arm-smmu 15000000.iommu:         GFSR 0x00000002, GFSYNR0 0x00000002, GFSYNR1 0x000006c0, GFSYNR2 0x00000000
> > > >
> > > > Add the right SID and mask so this works.
> > > >
> > > > Cc: Sibi Sankar <sibis@codeaurora.org>
> > > > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > > > ---
> > > >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > index fcb93300ca62..2e57e861e17c 100644
> > > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > @@ -900,6 +900,7 @@
> > > >                       #address-cells = <2>;
> > > >                       #size-cells = <2>;
> > > >                       ranges;
> > > > +                     iommus = <&apps_smmu 0x6c0 0x3>;
> > >
> > > According to the docs this stream belongs to TZ, the HLOS stream should
> > > be 0x6c3.
> >
> > Aye, I saw this line in the downstream kernel but it doesn't work for
> > me. If I specify <&apps_smmu 0x6c3 0x0> it still blows up. I wonder if
> > my firmware perhaps is missing some initialization here to make the QUP
> > operate in HLOS mode? Otherwise, I thought that the 0x3 at the end was
> > the mask and so it should be split off to the second cell in the DT
> > specifier but that seemed a little weird.
> 
> Two things here -
> 0x6c0 - TZ SID. Do you see above fault on MTP sdm845 devices?

No. I see the above fault on Cheza.

> 0x6c3/0x6c6 - HLOS SIDs.

Why are there two? I see some mentions of GSI mode near these SIDs so
maybe GSI has to be used for DMA here to get the above two SIDs at the
IOMMU? Otherwise if we do the non-GSI mode of DMA we're going to use the
"TZ" SID?

> 
> Cheza will throw faults for anything that is programmed with TZ on mtp
> as all of that should be handled in HLOS. The firmwares of all these
> peripherals assume that the SID reservation is done (whether in TZ or HLOS).
> 
> I am inclined to moving the iommus property for all 'TZ' to board dts files.
> MTP wouldn't need those SIDs. So, the SOC level dtsi will have just the
> HLOS SIDs.

So you're saying you'd like to have the SID be <&apps_smmu 0x6c3 0x0> in
the sdm845.dtsi file and then override this on Cheza because our SID is
different (possibly because we don't use GSI)? Why can't we program the
SID in Cheza firmware to match the "HLOS" SID of 0x6c3?

> 
> P.S.
> As you rightly said, the second cell in iommus property is the mask so that
> the iommu is able to reserve all that SIDs that are covered with the
> starting SID
> and the mask.
> 

Well if 0x6c6 is another possibility maybe it should be <&apps_smmu
0x6c0 0x7> to cover the 0x6c3 and 0x6c6 SIDs?


^ permalink raw reply	[relevance 0%]

* Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1
  2019-06-05 20:56       ` Stephen Boyd
@ 2019-06-06 11:17         ` Vivek Gautam
  0 siblings, 0 replies; 200+ results
From: Vivek Gautam @ 2019-06-06 11:17 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: Bjorn Andersson, Andy Gross, open list, linux-arm-msm, Sibi Sankar

Hi Stephen,

On Thu, Jun 6, 2019 at 2:27 AM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Quoting Vivek Gautam (2019-06-04 21:55:26)
> > On Wed, Jun 5, 2019 at 4:16 AM Stephen Boyd <swboyd@chromium.org> wrote:
> > >
> > > Quoting Bjorn Andersson (2019-06-04 15:37:00)
> > > > On Tue 04 Jun 15:29 PDT 2019, Stephen Boyd wrote:
> > > >
> > > > > The SMMU that sits in front of the QUP needs to be programmed properly
> > > > > so that the i2c geni driver can allocate DMA descriptors. Failure to do
> > > > > this leads to faults when using devices such as an i2c touchscreen where
> > > > > the transaction is larger than 32 bytes and we use a DMA buffer.
> > > > >
> > > >
> > > > I'm pretty sure I've run into this problem, but before we marked the
> > > > smmu bypass_disable and as such didn't get the fault, thanks.
> > > >
> > > > >  arm-smmu 15000000.iommu: Unexpected global fault, this could be serious
> > > > >  arm-smmu 15000000.iommu:         GFSR 0x00000002, GFSYNR0 0x00000002, GFSYNR1 0x000006c0, GFSYNR2 0x00000000
> > > > >
> > > > > Add the right SID and mask so this works.
> > > > >
> > > > > Cc: Sibi Sankar <sibis@codeaurora.org>
> > > > > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > > > > ---
> > > > >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
> > > > >  1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > > index fcb93300ca62..2e57e861e17c 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > > @@ -900,6 +900,7 @@
> > > > >                       #address-cells = <2>;
> > > > >                       #size-cells = <2>;
> > > > >                       ranges;
> > > > > +                     iommus = <&apps_smmu 0x6c0 0x3>;
> > > >
> > > > According to the docs this stream belongs to TZ, the HLOS stream should
> > > > be 0x6c3.
> > >
> > > Aye, I saw this line in the downstream kernel but it doesn't work for
> > > me. If I specify <&apps_smmu 0x6c3 0x0> it still blows up. I wonder if
> > > my firmware perhaps is missing some initialization here to make the QUP
> > > operate in HLOS mode? Otherwise, I thought that the 0x3 at the end was
> > > the mask and so it should be split off to the second cell in the DT
> > > specifier but that seemed a little weird.
> >
> > Two things here -
> > 0x6c0 - TZ SID. Do you see above fault on MTP sdm845 devices?
>
> No. I see the above fault on Cheza.

Right, expected.

>
> > 0x6c3/0x6c6 - HLOS SIDs.

My bad, the other SID is 0x6D6.

>
> Why are there two? I see some mentions of GSI mode near these SIDs so
> maybe GSI has to be used for DMA here to get the above two SIDs at the
> IOMMU? Otherwise if we do the non-GSI mode of DMA we're going to use the
> "TZ" SID?

Yea, one for GSI, and the other one for non-GSI DMA. I am unsure at this point
about the use of TZ SID, but i would assume this is the SID that's used by the
qup firmware, and therefore on MTP TZ programs this SID.

>
> >
> > Cheza will throw faults for anything that is programmed with TZ on mtp
> > as all of that should be handled in HLOS. The firmwares of all these
> > peripherals assume that the SID reservation is done (whether in TZ or HLOS).
> >
> > I am inclined to moving the iommus property for all 'TZ' to board dts files.
> > MTP wouldn't need those SIDs. So, the SOC level dtsi will have just the
> > HLOS SIDs.
>
> So you're saying you'd like to have the SID be <&apps_smmu 0x6c3 0x0> in
> the sdm845.dtsi file and then override this on Cheza because our SID is
> different (possibly because we don't use GSI)? Why can't we program the
> SID in Cheza firmware to match the "HLOS" SID of 0x6c3?

Sorry my bad, I missed the overriding part.
May be we add the lists of SIDs in board dts only. So, cheza dts will
have all these SIDs -
<&apps_smmu 0x6c0 0x3>   // for both 0x6c0 (TZ) and 0x6c3 (HLOS)
<&apps_smmu 0x6d6 0x0>   // if we want to use the GSI dma.
and
MTP will have
<&apps_smmu 0x6c3 0x0>
<&apps_smmu 0x6d6 0x0>
WDUT?

>
> >
> > P.S.
> > As you rightly said, the second cell in iommus property is the mask so that
> > the iommu is able to reserve all that SIDs that are covered with the
> > starting SID
> > and the mask.
> >
>
> Well if 0x6c6 is another possibility maybe it should be <&apps_smmu
> 0x6c0 0x7> to cover the 0x6c3 and 0x6c6 SIDs?

The other SID was 0x6D6.

Best regards
Vivek

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

^ permalink raw reply	[relevance 0%]

* [PATCH v9 3/4] arm64: dts: qcom: Add AOSS QMP node
      [irrelevant] <20190612044536.13940-1-bjorn.andersson@linaro.org>
@ 2019-06-12  4:45 ` Bjorn Andersson
  2019-06-12  4:45 ` [PATCH v9 4/4] arm64: dts: qcom: sdm845: Add Q6V5 MSS node Bjorn Andersson
      [irrelevant] ` <20190612044536.13940-3-bjorn.andersson@linaro.org>
  2 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-06-12  4:45 UTC (permalink / raw)
  To: unlisted-recipients:; (no To-header on input)
  Cc: Andy Gross, linux-arm-msm, devicetree, linux-kernel

The AOSS QMP provides a number of power domains, used for QDSS and
PIL, add the node for this.

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v8:
- None

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c5a5c5b086b1..c80881309f79 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2448,6 +2448,16 @@
 			#reset-cells = <1>;
 		};
 
+		aoss_qmp: qmp@c300000 {
+			compatible = "qcom,sdm845-aoss-qmp";
+			reg = <0 0x0c300000 0 0x100000>;
+			interrupts = <GIC_SPI 389 IRQ_TYPE_EDGE_RISING>;
+			mboxes = <&apss_shared 0>;
+
+			#clock-cells = <0>;
+			#power-domain-cells = <1>;
+		};
+
 		spmi_bus: spmi@c440000 {
 			compatible = "qcom,spmi-pmic-arb";
 			reg = <0 0x0c440000 0 0x1100>,
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* [PATCH v9 4/4] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
      [irrelevant] <20190612044536.13940-1-bjorn.andersson@linaro.org>
  2019-06-12  4:45 ` [PATCH v9 3/4] arm64: dts: qcom: Add AOSS QMP node Bjorn Andersson
@ 2019-06-12  4:45 ` Bjorn Andersson
      [irrelevant] ` <20190612044536.13940-3-bjorn.andersson@linaro.org>
  2 siblings, 0 replies; 200+ results
From: Bjorn Andersson @ 2019-06-12  4:45 UTC (permalink / raw)
  To: unlisted-recipients:; (no To-header on input)
  Cc: Andy Gross, linux-arm-msm, devicetree, linux-kernel

From: Sibi Sankar <sibis@codeaurora.org>

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v8:
- None

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 ++++++++++++++++++++++++++++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c80881309f79..601cfb078bd5 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1850,6 +1850,64 @@
 			};
 		};
 
+		mss_pil: remoteproc@4080000 {
+			compatible = "qcom,sdm845-mss-pil";
+			reg = <0 0x04080000 0 0x408>, <0 0x04180000 0 0x48>;
+			reg-names = "qdsp6", "rmb";
+
+			interrupts-extended =
+				<&intc GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+				<&modem_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+			interrupt-names = "wdog", "fatal", "ready",
+					  "handover", "stop-ack",
+					  "shutdown-ack";
+
+			clocks = <&gcc GCC_MSS_CFG_AHB_CLK>,
+				 <&gcc GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+				 <&gcc GCC_BOOT_ROM_AHB_CLK>,
+				 <&gcc GCC_MSS_GPLL0_DIV_CLK_SRC>,
+				 <&gcc GCC_MSS_SNOC_AXI_CLK>,
+				 <&gcc GCC_MSS_MFAB_AXIS_CLK>,
+				 <&gcc GCC_PRNG_AHB_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "iface", "bus", "mem", "gpll0_mss",
+				      "snoc_axi", "mnoc_axi", "prng", "xo";
+
+			qcom,smem-states = <&modem_smp2p_out 0>;
+			qcom,smem-state-names = "stop";
+
+			resets = <&aoss_reset AOSS_CC_MSS_RESTART>,
+				 <&pdc_reset PDC_MODEM_SYNC_RESET>;
+			reset-names = "mss_restart", "pdc_reset";
+
+			qcom,halt-regs = <&tcsr_mutex_regs 0x23000 0x25000 0x24000>;
+
+			power-domains = <&aoss_qmp 2>,
+					<&rpmhpd SDM845_CX>,
+					<&rpmhpd SDM845_MX>,
+					<&rpmhpd SDM845_MSS>;
+			power-domain-names = "load_state", "cx", "mx", "mss";
+
+			mba {
+				memory-region = <&mba_region>;
+			};
+
+			mpss {
+				memory-region = <&mpss_region>;
+			};
+
+			glink-edge {
+				interrupts = <GIC_SPI 449 IRQ_TYPE_EDGE_RISING>;
+				label = "modem";
+				qcom,remote-pid = <1>;
+				mboxes = <&apss_shared 12>;
+			};
+		};
+
 		gpucc: clock-controller@5090000 {
 			compatible = "qcom,sdm845-gpucc";
 			reg = <0 0x05090000 0 0x9000>;
-- 
2.18.0


^ permalink raw reply	[relevance 8%]

* Re: [PATCH v9 2/4] soc: qcom: Add AOSS QMP driver
      [irrelevant] ` <20190612044536.13940-3-bjorn.andersson@linaro.org>
@ 2019-06-12  9:28   ` Sibi Sankar
  0 siblings, 0 replies; 200+ results
From: Sibi Sankar @ 2019-06-12  9:28 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Andy Gross, linux-arm-msm, devicetree, linux-kernel, linux-arm-msm-owner

On 2019-06-12 10:15, Bjorn Andersson wrote:
> The Always On Subsystem (AOSS) Qualcomm Messaging Protocol (QMP) driver
> is used to communicate with the AOSS for certain side-channel requests,
> that are not available through the RPMh interface.
> 
> The communication is a very simple synchronous mechanism of messages
> being written in message RAM and a doorbell in the AOSS is rung. As the
> AOSS has processed the message length is cleared and an interrupt is
> fired by the AOSS as acknowledgment.
> 
> The driver exposes the QDSS clock as a clock and the low-power state
> associated with the remoteprocs in the system as a set of 
> power-domains.
> 

Tested-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>

> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Reviewed-by: Vinod Koul <vkoul@kernel.org>
> Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v8:
> - ret => time_left
> - static const the clk_init_data
> 
>  drivers/soc/qcom/Kconfig     |  12 +
>  drivers/soc/qcom/Makefile    |   1 +
>  drivers/soc/qcom/qcom_aoss.c | 480 +++++++++++++++++++++++++++++++++++
>  3 files changed, 493 insertions(+)
>  create mode 100644 drivers/soc/qcom/qcom_aoss.c
> 
> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
> index 880cf0290962..1ecd95a1c654 100644
> --- a/drivers/soc/qcom/Kconfig
> +++ b/drivers/soc/qcom/Kconfig
> @@ -4,6 +4,18 @@
>  #
>  menu "Qualcomm SoC drivers"
> 
> +config QCOM_AOSS_QMP
> +	tristate "Qualcomm AOSS Driver"
> +	depends on ARCH_QCOM || COMPILE_TEST
> +	depends on MAILBOX
> +	depends on COMMON_CLK
> +	select PM_GENERIC_DOMAINS
> +	help
> +	  This driver provides the means of communicating with and 
> controlling
> +	  the low-power state for resources related to the remoteproc
> +	  subsystems as well as controlling the debug clocks exposed by the 
> Always On
> +	  Subsystem (AOSS) using Qualcomm Messaging Protocol (QMP).
> +
>  config QCOM_COMMAND_DB
>  	bool "Qualcomm Command DB"
>  	depends on ARCH_QCOM || COMPILE_TEST
> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
> index ffe519b0cb66..eeb088beb15f 100644
> --- a/drivers/soc/qcom/Makefile
> +++ b/drivers/soc/qcom/Makefile
> @@ -1,5 +1,6 @@
>  # SPDX-License-Identifier: GPL-2.0
>  CFLAGS_rpmh-rsc.o := -I$(src)
> +obj-$(CONFIG_QCOM_AOSS_QMP) +=	qcom_aoss.o
>  obj-$(CONFIG_QCOM_GENI_SE) +=	qcom-geni-se.o
>  obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
>  obj-$(CONFIG_QCOM_GLINK_SSR) +=	glink_ssr.o
> diff --git a/drivers/soc/qcom/qcom_aoss.c 
> b/drivers/soc/qcom/qcom_aoss.c
> new file mode 100644
> index 000000000000..5f885196f4d0
> --- /dev/null
> +++ b/drivers/soc/qcom/qcom_aoss.c
> @@ -0,0 +1,480 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019, Linaro Ltd
> + */
> +#include <dt-bindings/power/qcom-aoss-qmp.h>
> +#include <linux/clk-provider.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/mailbox_client.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +
> +#define QMP_DESC_MAGIC			0x0
> +#define QMP_DESC_VERSION		0x4
> +#define QMP_DESC_FEATURES		0x8
> +
> +/* AOP-side offsets */
> +#define QMP_DESC_UCORE_LINK_STATE	0xc
> +#define QMP_DESC_UCORE_LINK_STATE_ACK	0x10
> +#define QMP_DESC_UCORE_CH_STATE		0x14
> +#define QMP_DESC_UCORE_CH_STATE_ACK	0x18
> +#define QMP_DESC_UCORE_MBOX_SIZE	0x1c
> +#define QMP_DESC_UCORE_MBOX_OFFSET	0x20
> +
> +/* Linux-side offsets */
> +#define QMP_DESC_MCORE_LINK_STATE	0x24
> +#define QMP_DESC_MCORE_LINK_STATE_ACK	0x28
> +#define QMP_DESC_MCORE_CH_STATE		0x2c
> +#define QMP_DESC_MCORE_CH_STATE_ACK	0x30
> +#define QMP_DESC_MCORE_MBOX_SIZE	0x34
> +#define QMP_DESC_MCORE_MBOX_OFFSET	0x38
> +
> +#define QMP_STATE_UP			GENMASK(15, 0)
> +#define QMP_STATE_DOWN			GENMASK(31, 16)
> +
> +#define QMP_MAGIC			0x4d41494c /* mail */
> +#define QMP_VERSION			1
> +
> +/* 64 bytes is enough to store the requests and provides padding to 4 
> bytes */
> +#define QMP_MSG_LEN			64
> +
> +/**
> + * struct qmp - driver state for QMP implementation
> + * @msgram: iomem referencing the message RAM used for communication
> + * @dev: reference to QMP device
> + * @mbox_client: mailbox client used to ring the doorbell on transmit
> + * @mbox_chan: mailbox channel used to ring the doorbell on transmit
> + * @offset: offset within @msgram where messages should be written
> + * @size: maximum size of the messages to be transmitted
> + * @event: wait_queue for synchronization with the IRQ
> + * @tx_lock: provides synchronization between multiple callers of 
> qmp_send()
> + * @qdss_clk: QDSS clock hw struct
> + * @pd_data: genpd data
> + */
> +struct qmp {
> +	void __iomem *msgram;
> +	struct device *dev;
> +
> +	struct mbox_client mbox_client;
> +	struct mbox_chan *mbox_chan;
> +
> +	size_t offset;
> +	size_t size;
> +
> +	wait_queue_head_t event;
> +
> +	struct mutex tx_lock;
> +
> +	struct clk_hw qdss_clk;
> +	struct genpd_onecell_data pd_data;
> +};
> +
> +struct qmp_pd {
> +	struct qmp *qmp;
> +	struct generic_pm_domain pd;
> +};
> +
> +#define to_qmp_pd_resource(res) container_of(res, struct qmp_pd, pd)
> +
> +static void qmp_kick(struct qmp *qmp)
> +{
> +	mbox_send_message(qmp->mbox_chan, NULL);
> +	mbox_client_txdone(qmp->mbox_chan, 0);
> +}
> +
> +static bool qmp_magic_valid(struct qmp *qmp)
> +{
> +	return readl(qmp->msgram + QMP_DESC_MAGIC) == QMP_MAGIC;
> +}
> +
> +static bool qmp_link_acked(struct qmp *qmp)
> +{
> +	return readl(qmp->msgram + QMP_DESC_MCORE_LINK_STATE_ACK) == 
> QMP_STATE_UP;
> +}
> +
> +static bool qmp_mcore_channel_acked(struct qmp *qmp)
> +{
> +	return readl(qmp->msgram + QMP_DESC_MCORE_CH_STATE_ACK) == 
> QMP_STATE_UP;
> +}
> +
> +static bool qmp_ucore_channel_up(struct qmp *qmp)
> +{
> +	return readl(qmp->msgram + QMP_DESC_UCORE_CH_STATE) == QMP_STATE_UP;
> +}
> +
> +static int qmp_open(struct qmp *qmp)
> +{
> +	int ret;
> +	u32 val;
> +
> +	if (!qmp_magic_valid(qmp)) {
> +		dev_err(qmp->dev, "QMP magic doesn't match\n");
> +		return -EINVAL;
> +	}
> +
> +	val = readl(qmp->msgram + QMP_DESC_VERSION);
> +	if (val != QMP_VERSION) {
> +		dev_err(qmp->dev, "unsupported QMP version %d\n", val);
> +		return -EINVAL;
> +	}
> +
> +	qmp->offset = readl(qmp->msgram + QMP_DESC_MCORE_MBOX_OFFSET);
> +	qmp->size = readl(qmp->msgram + QMP_DESC_MCORE_MBOX_SIZE);
> +	if (!qmp->size) {
> +		dev_err(qmp->dev, "invalid mailbox size\n");
> +		return -EINVAL;
> +	}
> +
> +	/* Ack remote core's link state */
> +	val = readl(qmp->msgram + QMP_DESC_UCORE_LINK_STATE);
> +	writel(val, qmp->msgram + QMP_DESC_UCORE_LINK_STATE_ACK);
> +
> +	/* Set local core's link state to up */
> +	writel(QMP_STATE_UP, qmp->msgram + QMP_DESC_MCORE_LINK_STATE);
> +
> +	qmp_kick(qmp);
> +
> +	ret = wait_event_timeout(qmp->event, qmp_link_acked(qmp), HZ);
> +	if (!ret) {
> +		dev_err(qmp->dev, "ucore didn't ack link\n");
> +		goto timeout_close_link;
> +	}
> +
> +	writel(QMP_STATE_UP, qmp->msgram + QMP_DESC_MCORE_CH_STATE);
> +
> +	qmp_kick(qmp);
> +
> +	ret = wait_event_timeout(qmp->event, qmp_ucore_channel_up(qmp), HZ);
> +	if (!ret) {
> +		dev_err(qmp->dev, "ucore didn't open channel\n");
> +		goto timeout_close_channel;
> +	}
> +
> +	/* Ack remote core's channel state */
> +	writel(QMP_STATE_UP, qmp->msgram + QMP_DESC_UCORE_CH_STATE_ACK);
> +
> +	qmp_kick(qmp);
> +
> +	ret = wait_event_timeout(qmp->event, qmp_mcore_channel_acked(qmp), 
> HZ);
> +	if (!ret) {
> +		dev_err(qmp->dev, "ucore didn't ack channel\n");
> +		goto timeout_close_channel;
> +	}
> +
> +	return 0;
> +
> +timeout_close_channel:
> +	writel(QMP_STATE_DOWN, qmp->msgram + QMP_DESC_MCORE_CH_STATE);
> +
> +timeout_close_link:
> +	writel(QM