Re: [PATCH 3/3] remoteproc: qcom_q6v5_pas: Unload lite firmware on ADSP
On 1/31/24 15:00, Abel Vesa wrote:
On 24-01-29 17:17:28, Dmitry Baryshkov wrote:
On Mon, 29 Jan 2024 at 15:35, Abel Vesa wrote:
From: Sibi Sankar
The UEFI loads a lite variant of the ADSP firmware to support charging
use cases. The kernel needs to unload and reload it with the firmware
that has full feature support for audio. This patch arbitarily shutsdown
the lite firmware before loading the full firmware.
Signed-off-by: Sibi Sankar
Signed-off-by: Abel Vesa
---
drivers/remoteproc/qcom_q6v5_pas.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
b/drivers/remoteproc/qcom_q6v5_pas.c
index 083d71f80e5c..4f6940368eb4 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -39,6 +39,7 @@ struct adsp_data {
const char *dtb_firmware_name;
int pas_id;
int dtb_pas_id;
+ int lite_pas_id;
unsigned int minidump_id;
bool auto_boot;
bool decrypt_shutdown;
@@ -72,6 +73,7 @@ struct qcom_adsp {
const char *dtb_firmware_name;
int pas_id;
int dtb_pas_id;
+ int lite_pas_id;
unsigned int minidump_id;
int crash_reason_smem;
bool decrypt_shutdown;
@@ -210,6 +212,10 @@ static int adsp_load(struct rproc *rproc, const struct
firmware *fw)
/* Store firmware handle to be used in adsp_start() */
adsp->firmware = fw;
+ /* WIP: Shutdown the ADSP if it's running a lite version of the
firmware*/
Why is it still marked as WIP?
AFAIU, there was more to be done here w.r.t. preloaded lite version
firmware.
Later, was agreed that that is not case.
So maybe I just need to drop the comment.
Sibi, can you confirm?
ack, this is the best we can currently do. Please drop the comment when
you re-spin the series. Thanks for sending this out.
-Sibi
+ if (adsp->lite_pas_id)
+ ret = qcom_scm_pas_shutdown(adsp->lite_pas_id);
+
if (adsp->dtb_pas_id) {
ret = request_firmware(>dtb_firmware,
adsp->dtb_firmware_name, adsp->dev);
if (ret) {
@@ -693,6 +699,7 @@ static int adsp_probe(struct platform_device *pdev)
adsp->rproc = rproc;
adsp->minidump_id = desc->minidump_id;
adsp->pas_id = desc->pas_id;
+ adsp->lite_pas_id = desc->lite_pas_id;
adsp->info_name = desc->sysmon_name;
adsp->decrypt_shutdown = desc->decrypt_shutdown;
adsp->region_assign_idx = desc->region_assign_idx;
@@ -990,6 +997,7 @@ static const struct adsp_data x1e80100_adsp_resource = {
.dtb_firmware_name = "adsp_dtb.mdt",
.pas_id = 1,
.dtb_pas_id = 0x24,
+ .lite_pas_id = 0x1f,
.minidump_id = 5,
.auto_boot = true,
.proxy_pd_names = (char*[]){
--
2.34.1
--
With best wishes
Dmitry
Re: [PATCH 4/6] dt-bindings: reset: pdc: Add PDC Global bindings
On 2021-03-14 03:07, Stephen Boyd wrote: Quoting Sibi Sankar (2021-03-08 21:51:49) Add PDC Global reset controller bindings for SC7280 SoCs. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml | 4 include/dt-bindings/reset/qcom,sdm845-pdc.h | 2 ++ 2 files changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml index d7d8cec9419f..831ea8d5d83f 100644 --- a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml +++ b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml @@ -21,6 +21,10 @@ properties: - const: "qcom,sc7180-pdc-global" - const: "qcom,sdm845-pdc-global" + - description: on SC7280 SoCs the following compatibles must be specified +items: + - const: "qcom,sc7280-pdc-global" Somehow this one can drop sdm845-pdc-global but aoss-cc can't? I missed replying to ^^. aoss-cc reset is identical to that found on SDM845 SoC but the pdc-reset differs in the number of resets and offset within the pdc register space. + - description: on SDM845 SoCs the following compatibles must be specified items: - const: "qcom,sdm845-pdc-global" -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 6/6] arm64: dts: qcom: sc7280: Add nodes to boot WPSS
On 2021-03-24 12:19, Sibi Sankar wrote:
On 2021-03-24 03:36, Stephen Boyd wrote:
Quoting Bjorn Andersson (2021-03-13 20:16:39)
On Sat 13 Mar 15:46 CST 2021, Stephen Boyd wrote:
> Quoting Sibi Sankar (2021-03-08 21:51:51)
> > Add miscellaneous nodes to boot the Wireless Processor Subsystem on
>
> Maybe add (WPSS) after the name so we know they're related.
>
> > SC7280 SoCs.
> >
> > Signed-off-by: Sibi Sankar
> > ---
> >
> > https://patchwork.kernel.org/project/linux-arm-msm/list/?series=438217
> > Depends on ipcc dt node enablement from ^^
> >
> > arch/arm64/boot/dts/qcom/sc7280.dtsi | 143
+++
> > 1 file changed, 143 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > index 18637c369c1d..4f03c468df51 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > @@ -244,12 +251,131 @@
> > reg = <0 0x8000 0 0>;
> > };
> >
> > + tcsr_mutex: hwlock {
> > + compatible = "qcom,tcsr-mutex";
> > + syscon = <_mutex_regs 0 0x1000>;
> > + #hwlock-cells = <1>;
> > + };
>
> Is this node in the right place? I think the node above it is 'memory'?
> In which case 'hwlock' comes before 'memory' alphabetically.
>
Thanks for spotting this, as it's no longer acceptable to have a
standalone "syscon" node I was asked to rewrite the binding for this
a
few months ago. So the tcsr_mutex should now be represented with a
reg
under /soc.
Oh nice, I wasn't aware.
> > + #interrupt-cells = <2>;
> > + };
> > + };
> > +
> > + smp2p-mpss {
> > + compatible = "qcom,smp2p";
> > + qcom,smem = <435>, <428>;
> > + interrupts-extended = < IPCC_CLIENT_MPSS
> > +IPCC_MPROC_SIGNAL_SMP2P
> > +IRQ_TYPE_EDGE_RISING>;
> > + mboxes = < IPCC_CLIENT_MPSS
> > + IPCC_MPROC_SIGNAL_SMP2P>;
> > +
> > + qcom,local-pid = <0>;
> > + qcom,remote-pid = <1>;
> > +
> > + modem_smp2p_out: master-kernel {
> > + qcom,entry-name = "master-kernel";
> > + #qcom,smem-state-cells = <1>;
> > + };
> > +
> > + modem_smp2p_in: slave-kernel {
> > + qcom,entry-name = "slave-kernel";
>
> Do these names need to have 'master' and 'slave' in them? We're trying
> to avoid these terms. See Documentation/process/coding-style.rst Section
> 4 naming.
>
They need to match the naming in the firmware, but I would welcome a
future change to something in line with the coding style and simply
more
descriptive.
Sibi can this be done? I think it's still pretty early days for the
firmware so hopefully the terms can be replaced with something
different.
I'll discuss the ask with the modem fw team and
get back.
Sorry for the delayed response. Looks
like it's something Qualcomm wouldn't
want to do mid-project since a number
of the fw images are re-used across
platforms. But this is something that
will be taken up on newer SoCs.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
[PATCH 10/12] arm64: dts: qcom: sm8250: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SM8250 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 4c0de12aaba6..0a5b747f55b9 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -11,7 +11,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -1881,13 +1880,14 @@
clocks = < RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <_qmp AOSS_QMP_LS_SLPI>,
- < SM8250_LCX>,
+ power-domains = < SM8250_LCX>,
< SM8250_LMX>;
- power-domain-names = "load_state", "lcx", "lmx";
+ power-domain-names = "lcx", "lmx";
memory-region = <_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_slpi_out 0>;
qcom,smem-state-names = "stop";
@@ -1947,12 +1947,12 @@
clocks = < RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <_qmp AOSS_QMP_LS_CDSP>,
- < SM8250_CX>;
- power-domain-names = "load_state", "cx";
+ power-domains = < SM8250_CX>;
memory-region = <_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_cdsp_out 0>;
qcom,smem-state-names = "stop";
@@ -2689,7 +2689,6 @@
IPCC_MPROC_SIGNAL_GLINK_QMP>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
};
spmi_bus: spmi@c44 {
@@ -3517,13 +3516,14 @@
clocks = < RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <_qmp AOSS_QMP_LS_LPASS>,
- < SM8250_LCX>,
+ power-domains = < SM8250_LCX>,
< SM8250_LMX>;
- power-domain-names = "load_state", "lcx", "lmx";
+ power-domain-names = "lcx", "lmx";
memory-region = <_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_adsp_out 0>;
qcom,smem-state-names = "stop";
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 11/12] arm64: dts: qcom: sm8350: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SM8350 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi
b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index ed0b51bc03ea..ddbe932e4066 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -7,7 +7,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -651,15 +650,16 @@
clocks = < RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <_qmp AOSS_QMP_LS_MODEM>,
- < 0>,
+ power-domains = < 0>,
< 12>;
- power-domain-names = "load_state", "cx", "mss";
+ power-domain-names = "cx", "mss";
interconnects = <_virt 0 _virt 1>;
memory-region = <_modem_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_modem_out 0>;
qcom,smem-state-names = "stop";
@@ -719,7 +719,6 @@
mboxes = < IPCC_CLIENT_AOP
IPCC_MPROC_SIGNAL_GLINK_QMP>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
};
spmi_bus: spmi@c44 {
@@ -1018,13 +1017,14 @@
clocks = < RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <_qmp AOSS_QMP_LS_SLPI>,
- < 4>,
+ power-domains = < 4>,
< 5>;
- power-domain-names = "load_state", "lcx", "lmx";
+ power-domain-names = "lcx", "lmx";
memory-region = <_slpi_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_slpi_out 0>;
qcom,smem-state-names = "stop";
@@ -1058,15 +1058,16 @@
clocks = < RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <_qmp AOSS_QMP_LS_CDSP>,
- < 0>,
+ power-domains = < 0>,
< 10>;
- power-domain-names = "load_state", "cx", "mxc";
+ power-domain-names = "cx", "mxc";
interconnects = <_noc 1 _virt 1>;
memory-region = <_cdsp_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_cdsp_out 0>;
qcom,smem-state-names = "stop";
@@ -1292,13 +1293,14 @@
clocks = < RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <_qmp AOSS_QMP_LS_LPASS>,
- < 4>,
+ power-domains = < 4>,
< 5>;
- power-domain-names = "load_state", "lcx", "lmx";
+ power-domain-names = "lcx", "lmx";
memory-region = <_adsp_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_adsp_out 0>;
qcom,smem-state-names = "stop";
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 08/12] arm64: dts: qcom: sdm845: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SDM845 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0a86fe71a66d..22bc69240d2b 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2984,6 +2984,8 @@
clock-names = "iface", "bus", "mem", "gpll0_mss",
"snoc_axi", "mnoc_axi", "prng", "xo";
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_smp2p_out 0>;
qcom,smem-state-names = "stop";
@@ -2993,11 +2995,10 @@
qcom,halt-regs = <_mutex_regs 0x23000 0x25000
0x24000>;
- power-domains = <_qmp 2>,
- < SDM845_CX>,
+ power-domains = < SDM845_CX>,
< SDM845_MX>,
< SDM845_MSS>;
- power-domain-names = "load_state", "cx", "mx", "mss";
+ power-domain-names = "cx", "mx", "mss";
mba {
memory-region = <_region>;
@@ -4582,7 +4583,6 @@
mboxes = <_shared 0>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
cx_cdev: cx {
#cooling-cells = <2>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 12/12] dt-bindings: soc: qcom: aoss: Delete unused power-domain definitions
Delete unused power-domain definitions exposed by AOSS QMP. Signed-off-by: Sibi Sankar --- include/dt-bindings/power/qcom-aoss-qmp.h | 14 -- 1 file changed, 14 deletions(-) delete mode 100644 include/dt-bindings/power/qcom-aoss-qmp.h diff --git a/include/dt-bindings/power/qcom-aoss-qmp.h b/include/dt-bindings/power/qcom-aoss-qmp.h deleted file mode 100644 index ec336d31dee4.. --- a/include/dt-bindings/power/qcom-aoss-qmp.h +++ /dev/null @@ -1,14 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/* Copyright (c) 2018, Linaro Ltd. */ - -#ifndef __DT_BINDINGS_POWER_QCOM_AOSS_QMP_H -#define __DT_BINDINGS_POWER_QCOM_AOSS_QMP_H - -#define AOSS_QMP_LS_CDSP 0 -#define AOSS_QMP_LS_LPASS 1 -#define AOSS_QMP_LS_MODEM 2 -#define AOSS_QMP_LS_SLPI 3 -#define AOSS_QMP_LS_SPSS 4 -#define AOSS_QMP_LS_VENUS 5 - -#endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 09/12] arm64: dts: qcom: sm8150: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SM8150 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 51235a9521c2..19f6bc268b9d 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -5,7 +5,6 @@
*/
#include
-#include
#include
#include
#include
@@ -1040,13 +1039,14 @@
clocks = < RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <_qmp AOSS_QMP_LS_SLPI>,
- < 3>,
+ power-domains = < 3>,
< 2>;
- power-domain-names = "load_state", "lcx", "lmx";
+ power-domain-names = "lcx", "lmx";
memory-region = <_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_smp2p_out 0>;
qcom,smem-state-names = "stop";
@@ -1486,13 +1486,14 @@
clocks = < RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <_qmp AOSS_QMP_LS_MODEM>,
- < 7>,
+ power-domains = < 7>,
< 0>;
- power-domain-names = "load_state", "cx", "mss";
+ power-domain-names = "cx", "mss";
memory-region = <_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_smp2p_out 0>;
qcom,smem-state-names = "stop";
@@ -2110,12 +2111,12 @@
clocks = < RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <_qmp AOSS_QMP_LS_CDSP>,
- < 7>;
- power-domain-names = "load_state", "cx";
+ power-domains = < 7>;
memory-region = <_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_smp2p_out 0>;
qcom,smem-state-names = "stop";
@@ -2339,7 +2340,6 @@
mboxes = <_shared 0>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
};
tsens0: thermal-sensor@c263000 {
@@ -2486,12 +2486,12 @@
clocks = < RPMH_CXO_CLK>;
clock-names = "xo";
- power-domains = <_qmp AOSS_QMP_LS_LPASS>,
- < 7>;
- power-domain-names = "load_state", "cx";
+ power-domains = < 7>;
memory-region = <_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_smp2p_out 0>;
qcom,smem-state-names = "stop";
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 06/12] arm64: dts: qcom: sc7180: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SC7180 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index a6da78d31fdd..6b55d74e2534 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -1998,14 +1997,15 @@
clock-names = "iface", "bus", "nav", "snoc_axi",
"mnoc_axi", "xo";
- power-domains = <_qmp AOSS_QMP_LS_MODEM>,
- < SC7180_CX>,
+ power-domains = < SC7180_CX>,
< SC7180_MX>,
< SC7180_MSS>;
- power-domain-names = "load_state", "cx", "mx", "mss";
+ power-domain-names = "cx", "mx", "mss";
memory-region = <_mem>;
+ qcom,qmp = <_qmp>;
+
qcom,smem-states = <_smp2p_out 0>;
qcom,smem-state-names = "stop";
@@ -3220,7 +3220,6 @@
mboxes = <_shared 0>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
};
spmi_bus: spmi@c44 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 07/12] arm64: dts: qcom: sc7280: Use QMP binding to control load state
Use the Qualcomm Mailbox Protocol (QMP) binding to control the load
state resources on SC7280 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 2cc478553935..0ee0e492b183 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
#include
@@ -835,7 +834,6 @@
IPCC_MPROC_SIGNAL_GLINK_QMP>;
#clock-cells = <0>;
- #power-domain-cells = <1>;
};
spmi_bus: spmi@c44 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 04/12] dt-bindings: remoteproc: qcom: Add QMP bindings
Add Qualcomm Mailbox Protocol (QMP) binding to replace the power domains exposed by the AOSS QMP node. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 69c49c7b2cff..494257010629 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -174,7 +174,12 @@ For the compatible string below the following supplies are required: must be "cx", "mx" qcom,sc7180-mss-pil: qcom,sdm845-mss-pil: - must be "cx", "mx", "mss", "load_state" + must be "cx", "mx", "mss" + +- qcom,qmp: + Usage: optional + Value type: + Definition: reference to the AOSS side-channel message RAM. - qcom,smem-states: Usage: required -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 05/12] remoteproc: qcom: q6v5: Use qmp_send to update co-processor load state
The power domains exposed by the AOSS QMP driver control the load state
resources linked to modem, adsp, cdsp remoteprocs. These are used to
notify the Always on Subsystem (AOSS) that a particular co-processor is
up/down. AOSS uses this information to wait for the co-processors to
suspend before starting its sleep sequence.
These co-processors enter low-power modes independent to that of the
application processor and the load state resources linked to them are
expected to remain unaltered across system suspend/resume cycles. To
achieve this behavior lets stop using the power-domains exposed by the
AOSS QMP node and replace them with generic qmp_send interface instead.
Signed-off-by: Sibi Sankar
---
drivers/remoteproc/qcom_q6v5.c | 57 +-
drivers/remoteproc/qcom_q6v5.h | 7 +++-
drivers/remoteproc/qcom_q6v5_adsp.c | 7 +++-
drivers/remoteproc/qcom_q6v5_mss.c | 44
drivers/remoteproc/qcom_q6v5_pas.c | 80 +
drivers/remoteproc/qcom_q6v5_wcss.c | 4 +-
6 files changed, 95 insertions(+), 104 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
index 9627a950928e..be78a286b3ec 100644
--- a/drivers/remoteproc/qcom_q6v5.c
+++ b/drivers/remoteproc/qcom_q6v5.c
@@ -16,8 +16,28 @@
#include "qcom_common.h"
#include "qcom_q6v5.h"
+#define Q6V5_LOAD_STATE_MSG_LEN64
#define Q6V5_PANIC_DELAY_MS200
+static int q6v5_load_state_toggle(struct qcom_q6v5 *q6v5, bool enable)
+{
+ char buf[Q6V5_LOAD_STATE_MSG_LEN] = {};
+ int ret;
+
+ if (IS_ERR(q6v5->qmp))
+ return 0;
+
+ snprintf(buf, sizeof(buf),
+"{class: image, res: load_state, name: %s, val: %s}",
+q6v5->load_state, enable ? "on" : "off");
+
+ ret = qmp_send(q6v5->qmp, buf, sizeof(buf));
+ if (ret)
+ dev_err(q6v5->dev, "failed to toggle load state\n");
+
+ return ret;
+}
+
/**
* qcom_q6v5_prepare() - reinitialize the qcom_q6v5 context before start
* @q6v5: reference to qcom_q6v5 context to be reinitialized
@@ -26,6 +46,12 @@
*/
int qcom_q6v5_prepare(struct qcom_q6v5 *q6v5)
{
+ int ret;
+
+ ret = q6v5_load_state_toggle(q6v5, true);
+ if (ret)
+ return ret;
+
reinit_completion(>start_done);
reinit_completion(>stop_done);
@@ -47,6 +73,7 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_prepare);
int qcom_q6v5_unprepare(struct qcom_q6v5 *q6v5)
{
disable_irq(q6v5->handover_irq);
+ q6v5_load_state_toggle(q6v5, false);
return !q6v5->handover_issued;
}
@@ -196,12 +223,13 @@ EXPORT_SYMBOL_GPL(qcom_q6v5_panic);
* @pdev: platform_device reference for acquiring resources
* @rproc: associated remoteproc instance
* @crash_reason: SMEM id for crash reason string, or 0 if none
+ * @load_state: load state resource string
* @handover: function to be called when proxy resources should be released
*
* Return: 0 on success, negative errno on failure
*/
int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct platform_device *pdev,
- struct rproc *rproc, int crash_reason,
+ struct rproc *rproc, int crash_reason, const char
*load_state,
void (*handover)(struct qcom_q6v5 *q6v5))
{
int ret;
@@ -210,6 +238,7 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct
platform_device *pdev,
q6v5->dev = >dev;
q6v5->crash_reason = crash_reason;
q6v5->handover = handover;
+ q6v5->load_state = kstrdup_const(load_state, GFP_KERNEL);
init_completion(>start_done);
init_completion(>stop_done);
@@ -286,9 +315,35 @@ int qcom_q6v5_init(struct qcom_q6v5 *q6v5, struct
platform_device *pdev,
return PTR_ERR(q6v5->state);
}
+ q6v5->qmp = qmp_get(>dev);
+ if (IS_ERR(q6v5->qmp)) {
+ if (PTR_ERR(q6v5->qmp) != -ENODEV) {
+ if (PTR_ERR(q6v5->qmp) != -EPROBE_DEFER)
+ dev_err(>dev, "failed to acquire load
state\n");
+ return PTR_ERR(q6v5->qmp);
+ }
+ } else {
+ if (!q6v5->load_state) {
+ dev_err(>dev, "load state resource string
empty\n");
+ return -EINVAL;
+ }
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(qcom_q6v5_init);
+/**
+ * qcom_q6v5_deinit() - deinitialize the q6v5 common struct
+ * @q6v5: reference to qcom_q6v5 context to be deinitialized
+ * @pdev: platform_device reference for acquiring resources
+ */
+void qcom_q6v5_deinit(struct qcom_q6v5 *q6v5, struct platform_device *pdev)
+{
+ if (!IS_ERR(q6v5->qmp))
+ qmp_put(pdev);
+}
+EXPORT_SYMBOL_GPL(qcom_q6v5
[PATCH 02/12] soc: qcom: aoss: Drop power domain support
The load state resources are expected to follow the life cycle of the
remote processor it tracks. However, modeling load state resources as
power-domains result in them getting turned off during system suspend
and thereby falling out of sync with the remote processors that are still
on. Fix this by replacing load state resource control through the generic
qmp message send interface instead.
Signed-off-by: Sibi Sankar
---
drivers/soc/qcom/qcom_aoss.c | 109 ++-
1 file changed, 3 insertions(+), 106 deletions(-)
diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
index 51b32f6d9bdb..f084ea9f6b66 100644
--- a/drivers/soc/qcom/qcom_aoss.c
+++ b/drivers/soc/qcom/qcom_aoss.c
@@ -2,7 +2,6 @@
/*
* Copyright (c) 2019, Linaro Ltd
*/
-#include
#include
#include
#include
@@ -11,7 +10,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -68,7 +66,6 @@ struct qmp_cooling_device {
* @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
* @cooling_devs: thermal cooling devices
*/
struct qmp {
@@ -87,20 +84,12 @@ struct qmp {
struct mutex tx_lock;
struct clk_hw qdss_clk;
- struct genpd_onecell_data pd_data;
struct qmp_cooling_device *cooling_devs;
#if IS_ENABLED(CONFIG_DEBUG_FS)
struct dentry *debugfs_file;
#endif /* CONFIG_DEBUG_FS */
};
-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);
@@ -329,95 +318,6 @@ static void qmp_qdss_clk_remove(struct qmp *qmp)
clk_hw_unregister(>qdss_clk);
}
-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 = >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([i].pd, NULL, true);
- if (ret < 0) {
- dev_err(dev, "failed to init genpd\n");
- goto unroll_genpds;
- }
-
- data->domains[i] = [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 = >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_cdev_get_max_state(struct thermal_cooling_device *cdev,
unsigned long *state)
{
@@ -636,13 +536,11 @@ static int qmp_probe(struct platform_device *pdev)
if (ret)
goto err_close_qmp;
- ret = qmp_pd_add(qmp);
- if (ret)
- goto err_remove_qdss_clk;
-
ret =
[PATCH 03/12] dt-bindings: remoteproc: qcom: pas: Add QMP bindings
Add Qualcomm Mailbox Protocol (QMP) binding to replace the power domains exposed by the AOSS QMP node. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt index 1c330a8941f9..bc2a09c3c045 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt @@ -123,17 +123,22 @@ on the Qualcomm ADSP Hexagon core. qcom,sm8150-cdsp-pas: qcom,sm8250-cdsp-pas: qcom,sm8350-cdsp-pas: - must be "cx", "load_state" + must be "cx" qcom,sc7180-mpss-pas: qcom,sm8150-mpss-pas: qcom,sm8350-mpss-pas: - must be "cx", "load_state", "mss" + must be "cx", "mss" qcom,sm8250-adsp-pas: qcom,sm8350-adsp-pas: qcom,sm8150-slpi-pas: qcom,sm8250-slpi-pas: qcom,sm8350-slpi-pas: - must be "lcx", "lmx", "load_state" + must be "lcx", "lmx" + +- qcom,qmp: + Usage: optional + Value type: + Definition: reference to the AOSS side-channel message RAM. - memory-region: Usage: required -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 01/12] dt-bindings: soc: qcom: aoss: Drop power-domain bindings
Drop power-domain bindings exposed by AOSS QMP node.
Signed-off-by: Sibi Sankar
---
.../devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
index 783dc81b0f26..c0ae051a5b76 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
@@ -9,8 +9,7 @@ Messaging Protocol (QMP)
The AOSS side channel exposes control over a set of resources, used to control
a set of debug related clocks and to affect the low power state of resources
-related to the secondary subsystems. These resources are exposed as a set of
-power-domains.
+related to the secondary subsystems.
- compatible:
Usage: required
@@ -46,14 +45,6 @@ power-domains.
Definition: must be 0
The single clock represents the QDSS clock.
-- #power-domain-cells:
- Usage: optional
- Value type:
- Definition: must be 1
- The provided power-domains are:
- CDSP state (0), LPASS state (1), modem state (2), SLPI
- state (3), SPSS state (4) and Venus state (5).
-
= SUBNODES
The AOSS side channel also provides the controls for three cooling devices,
these are expressed as subnodes of the QMP node. The name of the node is used
@@ -66,8 +57,7 @@ to identify the resource and must therefor be "cx", "mx" or
"ebi".
= EXAMPLE
-The following example represents the AOSS side-channel message RAM and the
-mechanism exposing the power-domains, as found in SDM845.
+The following example represents the AOSS side-channel message RAM as found in
SDM845.
aoss_qmp: qmp@c30 {
compatible = "qcom,sdm845-aoss-qmp";
@@ -75,8 +65,6 @@ mechanism exposing the power-domains, as found in SDM845.
interrupts = ;
mboxes = <_shared 0>;
- #power-domain-cells = <1>;
-
cx_cdev: cx {
#cooling-cells = <2>;
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 00/12] Use qmp_send to update co-processor load state
The power domains exposed by the AOSS QMP driver control the load state resources linked to modem, adsp, cdsp remoteprocs. These are used to notify the Always on Subsystem (AOSS) that a particular co-processor is up/down. AOSS uses this information to wait for the co-processors to suspend before starting its sleep sequence. These co-processors enter low-power modes independent to that of the application processor and the load state resources linked to them are expected to remain unaltered across system suspend/resume cycles. To achieve this behavior lets stop modeling them as power-domains and replace them with generic qmp_send interface instead. https://lore.kernel.org/lkml/20200913034603.GV3715@yoga/ Previous dicussion on dropping power-domain support from AOSS QMP driver https://lore.kernel.org/lkml/1617943188-23278-2-git-send-email-dee...@qti.qualcomm.com/ Depends on ^^ Sibi Sankar (12): dt-bindings: soc: qcom: aoss: Drop power-domain bindings soc: qcom: aoss: Drop power domain support dt-bindings: remoteproc: qcom: pas: Add QMP bindings dt-bindings: remoteproc: qcom: Add QMP bindings remoteproc: qcom: q6v5: Use qmp_send to update co-processor load state arm64: dts: qcom: sc7180: Use QMP binding to control load state arm64: dts: qcom: sc7280: Use QMP binding to control load state arm64: dts: qcom: sdm845: Use QMP binding to control load state arm64: dts: qcom: sm8150: Use QMP binding to control load state arm64: dts: qcom: sm8250: Use QMP binding to control load state arm64: dts: qcom: sm8350: Use QMP binding to control load state dt-bindings: soc: qcom: aoss: Delete unused power-domain definitions .../devicetree/bindings/remoteproc/qcom,adsp.txt | 11 ++- .../devicetree/bindings/remoteproc/qcom,q6v5.txt | 7 +- .../devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt | 16 +-- arch/arm64/boot/dts/qcom/sc7180.dtsi | 9 +- arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 - arch/arm64/boot/dts/qcom/sdm845.dtsi | 8 +- arch/arm64/boot/dts/qcom/sm8150.dtsi | 28 +++--- arch/arm64/boot/dts/qcom/sm8250.dtsi | 22 ++--- arch/arm64/boot/dts/qcom/sm8350.dtsi | 30 +++--- drivers/remoteproc/qcom_q6v5.c | 57 ++- drivers/remoteproc/qcom_q6v5.h | 7 +- drivers/remoteproc/qcom_q6v5_adsp.c| 7 +- drivers/remoteproc/qcom_q6v5_mss.c | 44 ++--- drivers/remoteproc/qcom_q6v5_pas.c | 80 --- drivers/remoteproc/qcom_q6v5_wcss.c| 4 +- drivers/soc/qcom/qcom_aoss.c | 109 + include/dt-bindings/power/qcom-aoss-qmp.h | 14 --- 17 files changed, 163 insertions(+), 292 deletions(-) delete mode 100644 include/dt-bindings/power/qcom-aoss-qmp.h -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] soc: qcom: mdt_loader: Validate that p_filesz < p_memsz
Hey Bjorn,
Thanks for the patch!
On 1/8/21 5:01 AM, Bjorn Andersson wrote:
The code validates that segments of p_memsz bytes of a segment will fit
in the provided memory region, but does not validate that p_filesz bytes
will, which means that an incorrectly crafted ELF header might write
beyond the provided memory region.
Fixes: 051fb70fd4ea ("remoteproc: qcom: Driver for the self-authenticating Hexagon
v5")
Signed-off-by: Bjorn Andersson
---
drivers/soc/qcom/mdt_loader.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
index e01d18e9ad2b..5180b5996830 100644
--- a/drivers/soc/qcom/mdt_loader.c
+++ b/drivers/soc/qcom/mdt_loader.c
@@ -230,6 +230,14 @@ static int __qcom_mdt_load(struct device *dev, const
struct firmware *fw,
break;
}
+ if (phdr->p_filesz > phdr->p_memsz) {
+ dev_err(dev,
+ "refusing to load segment %d with p_filesz >
p_memsz\n",
+ i);
+ ret = -EINVAL;
+ break;
+ }
+
Reviewed-by: Sibi Sankar
ptr = mem_region + offset;
if (phdr->p_filesz && phdr->p_offset < fw->size) {
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] soc: qcom: mdt_loader: Detect truncated read of segments
Hey Bjorn,
Thanks for the patch!
On 1/8/21 4:55 AM, Bjorn Andersson wrote:
Given that no validation of how much data the firmware loader read in
for a given segment truncated segment files would best case result in a
hash verification failure, without any indication of what went wrong.
Improve this by validating that the firmware loader did return the
amount of data requested.
Fixes: 445c2410a449 ("soc: qcom: mdt_loader: Use request_firmware_into_buf()")
Signed-off-by: Bjorn Andersson
---
drivers/soc/qcom/mdt_loader.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
index 24cd193dec55..e01d18e9ad2b 100644
--- a/drivers/soc/qcom/mdt_loader.c
+++ b/drivers/soc/qcom/mdt_loader.c
@@ -253,6 +253,14 @@ static int __qcom_mdt_load(struct device *dev, const
struct firmware *fw,
break;
}
+ if (seg_fw->size != phdr->p_filesz) {
+ dev_err(dev,
+ "failed to load segment %d from truncated
file %s\n",
+ i, fw_name);
+ ret = -EINVAL;
+ break;
seg_fw has to be released on error condition as well.
With ^^ fixed you can have my R-b.
Reviewed-by: Sibi Sankar
+ }
+
release_firmware(seg_fw);
}
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] arm64: dts: qcom: Move rmtfs memory region
Hey Sujit,
Thanks for the patch.
On 2021-03-30 07:16, Sujit Kautkar wrote:
Move rmtfs memory region so that it does not overlap with system
RAM (kernel data) when KAsan is enabled. This puts rmtfs right
after mba_mem which is not supposed to increase beyond 0x9460
Signed-off-by: Sujit Kautkar
---
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sc7180.dtsi | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index 07c8b2c926c0..fe052b477b72 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -45,7 +45,7 @@ trips {
/* Increase the size from 2MB to 8MB */
_mem {
- reg = <0x0 0x8440 0x0 0x80>;
+ reg = <0x0 0x9460 0x0 0x80>;
Sorry for the late comments. Can you
please do the same for sc7180-idp
as well?
Reviewed-by: Sibi Sankar
};
/ {
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 1ea3344ab62c..ac956488908f 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -110,9 +110,9 @@ tz_mem: memory@80b0 {
no-map;
};
- rmtfs_mem: memory@8440 {
+ rmtfs_mem: memory@9460 {
compatible = "qcom,rmtfs-mem";
- reg = <0x0 0x8440 0x0 0x20>;
+ reg = <0x0 0x9460 0x0 0x20>;
no-map;
qcom,client-id = <1>;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH 8/9] arm64: dts: qcom: sc7280: Add AOSS QMP node
On 2021-03-23 09:08, Stephen Boyd wrote:
Quoting Sibi Sankar (2021-03-08 21:58:21)
On 2021-02-27 19:26, Sai Prakash Ranjan wrote:
> On 2021-02-27 00:16, Stephen Boyd wrote:
>> Quoting Sai Prakash Ranjan (2021-02-25 23:51:00)
>>> On 2021-02-26 01:11, Stephen Boyd wrote:
>>> > Quoting Sai Prakash Ranjan (2021-02-25 01:30:24)
>>> >> Add a DT node for the AOSS QMP on SC7280 SoC.
>>> >>
>>> >> Signed-off-by: Sai Prakash Ranjan
>>> >> ---
>>> >> arch/arm64/boot/dts/qcom/sc7280.dtsi | 14 ++
>>> >> 1 file changed, 14 insertions(+)
>>> >>
>>> >> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> >> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> >> index 65c1e0f2fb56..cbd567ccc04e 100644
>>> >> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> >> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>>> >> @@ -9,6 +9,7 @@
>>> >> #include
>>> >> #include
>>> >> #include
>>> >> +#include
>>> >> #include
>>> >>
>>> >> / {
>>> >> @@ -368,6 +369,19 @@ pdc: interrupt-controller@b22 {
>>> >> interrupt-controller;
>>> >> };
>>> >>
>>> >> + aoss_qmp: qmp@c30 {
>>> >
>>> > power-domain-controller@c30? power-controller@c30?
>>> >
>>>
>>> Its an AOSS message RAM and all other SM* SoCs have as qmp@
>>> and the dt binding as well, I see only SM8150 with power-controller,
>>> that should probably be fixed?
>>
>> Node name should be generic while still being meaningful. Nobody knows
>> what qmp is, but power-controller makes sense. Can you fix this and
>> the
>> others to be power-controller?
>>
we probably would be changing them back
to qmp or something more generic soon
since the consensus was qmp wasn't a
power-controller. So not sure if its
worth the effort here.
Hmm alright. Maybe mailbox? qmp is not generic. What does it stand for?
qualcomm messaging protocol?
It's documented as ^^ in the git log
but I guess it should be called qualcomm
mailbox protocol instead. I don't think
it can be called mailbox since it doesn't
have mbox cells in its bindings.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH 6/6] arm64: dts: qcom: sc7280: Add nodes to boot WPSS
On 2021-03-24 03:36, Stephen Boyd wrote:
Quoting Bjorn Andersson (2021-03-13 20:16:39)
On Sat 13 Mar 15:46 CST 2021, Stephen Boyd wrote:
> Quoting Sibi Sankar (2021-03-08 21:51:51)
> > Add miscellaneous nodes to boot the Wireless Processor Subsystem on
>
> Maybe add (WPSS) after the name so we know they're related.
>
> > SC7280 SoCs.
> >
> > Signed-off-by: Sibi Sankar
> > ---
> >
> > https://patchwork.kernel.org/project/linux-arm-msm/list/?series=438217
> > Depends on ipcc dt node enablement from ^^
> >
> > arch/arm64/boot/dts/qcom/sc7280.dtsi | 143
+++
> > 1 file changed, 143 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > index 18637c369c1d..4f03c468df51 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > @@ -244,12 +251,131 @@
> > reg = <0 0x8000 0 0>;
> > };
> >
> > + tcsr_mutex: hwlock {
> > + compatible = "qcom,tcsr-mutex";
> > + syscon = <_mutex_regs 0 0x1000>;
> > + #hwlock-cells = <1>;
> > + };
>
> Is this node in the right place? I think the node above it is 'memory'?
> In which case 'hwlock' comes before 'memory' alphabetically.
>
Thanks for spotting this, as it's no longer acceptable to have a
standalone "syscon" node I was asked to rewrite the binding for this a
few months ago. So the tcsr_mutex should now be represented with a reg
under /soc.
Oh nice, I wasn't aware.
> > + #interrupt-cells = <2>;
> > + };
> > + };
> > +
> > + smp2p-mpss {
> > + compatible = "qcom,smp2p";
> > + qcom,smem = <435>, <428>;
> > + interrupts-extended = < IPCC_CLIENT_MPSS
> > +IPCC_MPROC_SIGNAL_SMP2P
> > +IRQ_TYPE_EDGE_RISING>;
> > + mboxes = < IPCC_CLIENT_MPSS
> > + IPCC_MPROC_SIGNAL_SMP2P>;
> > +
> > + qcom,local-pid = <0>;
> > + qcom,remote-pid = <1>;
> > +
> > + modem_smp2p_out: master-kernel {
> > + qcom,entry-name = "master-kernel";
> > + #qcom,smem-state-cells = <1>;
> > + };
> > +
> > + modem_smp2p_in: slave-kernel {
> > + qcom,entry-name = "slave-kernel";
>
> Do these names need to have 'master' and 'slave' in them? We're trying
> to avoid these terms. See Documentation/process/coding-style.rst Section
> 4 naming.
>
They need to match the naming in the firmware, but I would welcome a
future change to something in line with the coding style and simply
more
descriptive.
Sibi can this be done? I think it's still pretty early days for the
firmware so hopefully the terms can be replaced with something
different.
I'll discuss the ask with the modem fw team and
get back.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH] arm64: dts: qcom: sc7280: Add WPSS remoteproc node
On 2021-03-10 13:07, Rakesh Pillai wrote:
Add the WPSS remoteproc node in dts for
PIL loading.
Signed-off-by: Rakesh Pillai
---
- This change is dependent on the below patch series
1) https://lore.kernel.org/patchwork/project/lkml/list/?series=487403
2) https://lore.kernel.org/patchwork/project/lkml/list/?series=488365
---
arch/arm64/boot/dts/qcom/sc7280-idp.dts | 4 +++
arch/arm64/boot/dts/qcom/sc7280.dtsi| 47
+
2 files changed, 51 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dts
b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
index 950ecb2..603f56b 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-idp.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dts
@@ -26,6 +26,10 @@
status = "okay";
};
+_wpss {
+ status = "okay";
+};
+
{
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 8af6d77..26dd466 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -53,6 +53,16 @@
no-map;
reg = <0x0 0x80b0 0x0 0x10>;
};
+
+ wlan_fw_mem: memory@80c0 {
+ no-map;
+ reg = <0x0 0x80c0 0x0 0xc0>;
+ };
+
+ wpss_mem: memory@9ae0 {
+ no-map;
+ reg = <0x0 0x9ae0 0x0 0x190>;
+ };
The wpss mem shouldn't move into
board specific dt.
};
cpus {
@@ -305,6 +315,43 @@
};
};
+ remoteproc_wpss: remoteproc@8a0 {
+ compatible = "qcom,sc7280-wpss-pil";
please aim to add pas based
support to boot wpss as well.
+ reg = <0 0x08a0 0 0x1>;
+
+ interrupts-extended = < GIC_SPI 587
IRQ_TYPE_EDGE_RISING>,
+ <_smp2p_in 0 0>,
+ <_smp2p_in 1 0>,
+ <_smp2p_in 2 0>,
+ <_smp2p_in 3 0>,
+ <_smp2p_in 7 0>;
+ interrupt-names = "wdog", "fatal", "ready", "handover",
+ "stop-ack", "shutdown-ack";
+
+ memory-region = <_mem>;
+
looks like you missed adding clocks
and power-domains mentioned in the
bindings.
+ qcom,smem-states = <_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ resets = <_reset AOSS_CC_WCSS_RESTART>;
+ reset-names = "restart";
+
+ qcom,halt-regs = <_mutex_regs 0x37000>;
+
+ status = "disabled";
+
+ glink-edge {
+ interrupts-extended = < IPCC_CLIENT_WPSS
+
IPCC_MPROC_SIGNAL_GLINK_QMP
+
IRQ_TYPE_EDGE_RISING>;
+ mboxes = < IPCC_CLIENT_WPSS
+ IPCC_MPROC_SIGNAL_GLINK_QMP>;
+
+ label = "wpss";
+ qcom,remote-pid = <13>;
+ };
+ };
+
pdc: interrupt-controller@b22 {
compatible = "qcom,sc7280-pdc", "qcom,pdc";
reg = <0 0x0b22 0 0x3>;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH 2/2] remoteproc: qcom: q6v5_wpss: Add support for sc7280 WPSS
On 2021-03-10 12:58, Rakesh Pillai wrote:
Add support for PIL loading of WPSS processor for SC7280
WPSS boot will be requested by the wifi driver and hence
disable auto-boot for WPSS. Also add a separate shutdown
sequence handler for WPSS.
Signed-off-by: Rakesh Pillai
---
drivers/remoteproc/qcom_q6v5_adsp.c | 77
-
1 file changed, 76 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c
b/drivers/remoteproc/qcom_q6v5_adsp.c
index e024502..dc6b91d 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -58,6 +58,8 @@ struct adsp_pil_data {
const char *ssr_name;
const char *sysmon_name;
int ssctl_id;
+ bool is_wpss;
+ bool auto_boot;
const char **clk_ids;
int num_clks;
@@ -96,8 +98,54 @@ struct qcom_adsp {
struct qcom_rproc_glink glink_subdev;
struct qcom_rproc_ssr ssr_subdev;
struct qcom_sysmon *sysmon;
+
+ int (*shutdown)(struct qcom_adsp *adsp);
};
+static int qcom_wpss_shutdown(struct qcom_adsp *adsp)
+{
+ unsigned long timeout;
+ unsigned int val;
+ int ret;
+
+ regmap_write(adsp->halt_map, adsp->halt_lpass + LPASS_HALTREQ_REG,
1);
+
+ /* Wait for halt ACK from QDSP6 */
+ timeout = jiffies + msecs_to_jiffies(ACK_TIMEOUT);
+ for (;;) {
+ ret = regmap_read(adsp->halt_map,
+ adsp->halt_lpass + LPASS_HALTACK_REG, );
+ if (ret || val || time_after(jiffies, timeout))
+ break;
+
+ usleep_range(1000, 1100);
+ }
please use regmap_read_poll_timeout
instead.
+
+ /* Place the WPSS processor into reset */
+ reset_control_assert(adsp->restart);
+ /* wait after asserting subsystem restart from AOSS */
+ usleep_range(100, 105);
+ /* Remove the WPSS reset */
+ reset_control_deassert(adsp->restart);
+
+ usleep_range(100, 105);
usleep shouldn't be required since
aoss-reset drivers put in a usleep
of 200-300 on reset assert and de-assert.
+
+ regmap_write(adsp->halt_map, adsp->halt_lpass + LPASS_HALTREQ_REG,
0);
+
+ /* Wait for halt ACK from QDSP6 */
+ timeout = jiffies + msecs_to_jiffies(ACK_TIMEOUT);
+ for (;;) {
+ ret = regmap_read(adsp->halt_map,
+ adsp->halt_lpass + LPASS_HALTACK_REG, );
+ if (ret || !val || time_after(jiffies, timeout))
+ break;
+
+ usleep_range(1000, 1100);
+ }
please use regmap_read_poll_timeout
instead.
+
+ return 0;
+}
+
static int qcom_adsp_shutdown(struct qcom_adsp *adsp)
{
unsigned long timeout;
@@ -270,7 +318,7 @@ static int adsp_stop(struct rproc *rproc)
if (ret == -ETIMEDOUT)
dev_err(adsp->dev, "timed out on wait\n");
- ret = qcom_adsp_shutdown(adsp);
+ ret = adsp->shutdown(adsp);
if (ret)
dev_err(adsp->dev, "failed to shutdown: %d\n", ret);
@@ -439,6 +487,8 @@ static int adsp_probe(struct platform_device *pdev)
dev_err(>dev, "unable to allocate remoteproc\n");
return -ENOMEM;
}
+
+ rproc->auto_boot = desc->auto_boot;
rproc_coredump_set_elf_info(rproc, ELFCLASS32, EM_NONE);
adsp = (struct qcom_adsp *)rproc->priv;
@@ -447,6 +497,11 @@ static int adsp_probe(struct platform_device
*pdev)
adsp->info_name = desc->sysmon_name;
platform_set_drvdata(pdev, adsp);
+ if (desc->is_wpss)
+ adsp->shutdown = qcom_wpss_shutdown;
+ else
+ adsp->shutdown = qcom_adsp_shutdown;
+
ret = adsp_alloc_memory_region(adsp);
if (ret)
goto free_rproc;
@@ -515,6 +570,8 @@ static const struct adsp_pil_data
adsp_resource_init = {
.ssr_name = "lpass",
.sysmon_name = "adsp",
.ssctl_id = 0x14,
+ .is_wpss = false,
+ .auto_boot = true;
.clk_ids = (const char*[]) {
"sway_cbcr", "lpass_ahbs_aon_cbcr", "lpass_ahbm_aon_cbcr",
"qdsp6ss_xo", "qdsp6ss_sleep", "qdsp6ss_core", NULL
@@ -528,6 +585,8 @@ static const struct adsp_pil_data
cdsp_resource_init = {
.ssr_name = "cdsp",
.sysmon_name = "cdsp",
.ssctl_id = 0x17,
+ .is_wpss = false,
+ .auto_boot = true;
.clk_ids = (const char*[]) {
"sway", "tbu", "bimc", "ahb_aon", "q6ss_slave", "q6ss_master",
"q6_axim", NULL
@@ -535,7 +594,23 @@ static const struct adsp_pil_data
cdsp_resource_init = {
.num_clks = 7,
};
+static const struct adsp_pil_data wpss_resource_init = {
+ .crash_reason_smem = 626,
+ .firmware_name = "wpss.mdt",
+ .ssr_name = "wpss",
+ .sysmon_name = "wpss",
+ .ssctl_id = 0x19,
+ .is_wpss = true,
+ .auto_boot = false;
+ .clk_ids = (const
Re: [PATCH 1/2] dt-bindings: remoteproc: qcom: Add SC7280 WPSS support
On 2021-03-10 12:58, Rakesh Pillai wrote: Add WPSS PIL loading support for SC7280 SoCs. Signed-off-by: Rakesh Pillai --- .../bindings/remoteproc/qcom,hexagon-v56.txt | 35 -- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt b/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt index 1337a3d..edad5e8 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt @@ -9,6 +9,7 @@ on the Qualcomm Technology Inc. Hexagon v56 core. Definition: must be one of: "qcom,qcs404-cdsp-pil", "qcom,sdm845-adsp-pil" + "qcom,sc7280-wpss-pil" - reg: Usage: required @@ -24,7 +25,13 @@ on the Qualcomm Technology Inc. Hexagon v56 core. - interrupt-names: Usage: required Value type: - Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack" + Definition: The interrupts needed depends on the compatible string + qcom,sdm845-adsp-pil: + qcom,qcs404-cdsp-pil: + must be "wdog", "fatal", "ready", "handover", "stop-ack" + qcom,sc7280-wpss-pil: + must be "wdog", "fatal", "ready", "handover", "stop-ack" + "shutdown-ack" - clocks: Usage: required @@ -35,19 +42,17 @@ on the Qualcomm Technology Inc. Hexagon v56 core. - clock-names: Usage: required for SDM845 ADSP Value type: - Definition: List of clock input name strings sorted in the same - order as the clocks property. Definition must have - "xo", "sway_cbcr", "lpass_ahbs_aon_cbcr", - "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", "qdsp6ss_sleep" - and "qdsp6ss_core". - -- clock-names: - Usage: required for QCS404 CDSP - Value type: - Definition: List of clock input name strings sorted in the same - order as the clocks property. Definition must have - "xo", "sway", "tbu", "bimc", "ahb_aon", "q6ss_slave", - "q6ss_master", "q6_axim". + Definition: The clocks needed depends on the compatible string + qcom,sdm845-adsp-pil: + must be "xo", "sway_cbcr", "lpass_ahbs_aon_cbcr", + "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", "qdsp6ss_sleep", + "qdsp6ss_core" + qcom,qcs404-cdsp-pil: + must be "xo", "sway", "tbu", "bimc", "ahb_aon", "q6ss_slave", + "q6ss_master", "q6_axim" + qcom,sc7280-wpss-pil: + must be "gcc_wpss_ahb_bdg_mst_clk", "gcc_wpss_ahb_clk", + "gcc_wpss_rscp_clk" - power-domains: IIRC wpss requires both cx and mx. So you'll need to add driver code to support multiple power-domains. Usage: required @@ -65,7 +70,7 @@ on the Qualcomm Technology Inc. Hexagon v56 core. Definition: must be "pdc_sync" and "cc_lpass" - reset-names: -Usage: required for QCS404 CDSP +Usage: required for QCS404 CDSP, SC7280 WPSS Value type: Definition: must be "restart" -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 8/9] arm64: dts: qcom: sc7280: Add AOSS QMP node
On 2021-02-27 19:26, Sai Prakash Ranjan wrote:
On 2021-02-27 00:16, Stephen Boyd wrote:
Quoting Sai Prakash Ranjan (2021-02-25 23:51:00)
On 2021-02-26 01:11, Stephen Boyd wrote:
> Quoting Sai Prakash Ranjan (2021-02-25 01:30:24)
>> Add a DT node for the AOSS QMP on SC7280 SoC.
>>
>> Signed-off-by: Sai Prakash Ranjan
>> ---
>> arch/arm64/boot/dts/qcom/sc7280.dtsi | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> index 65c1e0f2fb56..cbd567ccc04e 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> @@ -9,6 +9,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> / {
>> @@ -368,6 +369,19 @@ pdc: interrupt-controller@b22 {
>> interrupt-controller;
>> };
>>
>> + aoss_qmp: qmp@c30 {
>
> power-domain-controller@c30? power-controller@c30?
>
Its an AOSS message RAM and all other SM* SoCs have as qmp@
and the dt binding as well, I see only SM8150 with power-controller,
that should probably be fixed?
Node name should be generic while still being meaningful. Nobody knows
what qmp is, but power-controller makes sense. Can you fix this and
the
others to be power-controller?
we probably would be changing them back
to qmp or something more generic soon
since the consensus was qmp wasn't a
power-controller. So not sure if its
worth the effort here.
Ok makes sense, I will post changing others as well and see if we get
any comments there.
Thanks,
Sai
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
[PATCH 5/6] reset: qcom: Add PDC Global reset signals for WPSS
Add PDC Global reset signals for Wireless Processor Subsystem (WPSS)
on SC7280 SoCs.
Signed-off-by: Sibi Sankar
---
drivers/reset/reset-qcom-pdc.c | 62 ++
1 file changed, 51 insertions(+), 11 deletions(-)
diff --git a/drivers/reset/reset-qcom-pdc.c b/drivers/reset/reset-qcom-pdc.c
index ab74bccd4a5b..bb7113ae6232 100644
--- a/drivers/reset/reset-qcom-pdc.c
+++ b/drivers/reset/reset-qcom-pdc.c
@@ -11,18 +11,26 @@
#include
-#define RPMH_PDC_SYNC_RESET0x100
+#define RPMH_SDM845_PDC_SYNC_RESET 0x100
+#define RPMH_SC7280_PDC_SYNC_RESET 0x1000
struct qcom_pdc_reset_map {
u8 bit;
};
+struct qcom_pdc_reset_desc {
+ const struct qcom_pdc_reset_map *resets;
+ unsigned int offset;
+ size_t num_resets;
+};
+
struct qcom_pdc_reset_data {
struct reset_controller_dev rcdev;
struct regmap *regmap;
+ const struct qcom_pdc_reset_desc *desc;
};
-static const struct regmap_config sdm845_pdc_regmap_config = {
+static const struct regmap_config pdc_regmap_config = {
.name = "pdc-reset",
.reg_bits = 32,
.reg_stride = 4,
@@ -44,6 +52,33 @@ static const struct qcom_pdc_reset_map sdm845_pdc_resets[] =
{
[PDC_MODEM_SYNC_RESET] = {9},
};
+static const struct qcom_pdc_reset_desc sdm845_pdc_reset_desc = {
+ .resets = sdm845_pdc_resets,
+ .offset = RPMH_SDM845_PDC_SYNC_RESET,
+ .num_resets = ARRAY_SIZE(sdm845_pdc_resets),
+};
+
+static const struct qcom_pdc_reset_map sc7280_pdc_resets[] = {
+ [PDC_APPS_SYNC_RESET] = {0},
+ [PDC_SP_SYNC_RESET] = {1},
+ [PDC_AUDIO_SYNC_RESET] = {2},
+ [PDC_SENSORS_SYNC_RESET] = {3},
+ [PDC_AOP_SYNC_RESET] = {4},
+ [PDC_DEBUG_SYNC_RESET] = {5},
+ [PDC_GPU_SYNC_RESET] = {6},
+ [PDC_DISPLAY_SYNC_RESET] = {7},
+ [PDC_COMPUTE_SYNC_RESET] = {8},
+ [PDC_MODEM_SYNC_RESET] = {9},
+ [PDC_WLAN_RF_SYNC_RESET] = {10},
+ [PDC_WPSS_SYNC_RESET] = {11},
+};
+
+static const struct qcom_pdc_reset_desc sc7280_pdc_reset_desc = {
+ .resets = sc7280_pdc_resets,
+ .offset = RPMH_SC7280_PDC_SYNC_RESET,
+ .num_resets = ARRAY_SIZE(sc7280_pdc_resets),
+};
+
static inline struct qcom_pdc_reset_data *to_qcom_pdc_reset_data(
struct reset_controller_dev *rcdev)
{
@@ -54,19 +89,18 @@ static int qcom_pdc_control_assert(struct
reset_controller_dev *rcdev,
unsigned long idx)
{
struct qcom_pdc_reset_data *data = to_qcom_pdc_reset_data(rcdev);
+ const struct qcom_pdc_reset_map *map = >desc->resets[idx];
- return regmap_update_bits(data->regmap, RPMH_PDC_SYNC_RESET,
- BIT(sdm845_pdc_resets[idx].bit),
- BIT(sdm845_pdc_resets[idx].bit));
+ return regmap_update_bits(data->regmap, data->desc->offset,
BIT(map->bit), BIT(map->bit));
}
static int qcom_pdc_control_deassert(struct reset_controller_dev *rcdev,
unsigned long idx)
{
struct qcom_pdc_reset_data *data = to_qcom_pdc_reset_data(rcdev);
+ const struct qcom_pdc_reset_map *map = >desc->resets[idx];
- return regmap_update_bits(data->regmap, RPMH_PDC_SYNC_RESET,
- BIT(sdm845_pdc_resets[idx].bit), 0);
+ return regmap_update_bits(data->regmap, data->desc->offset,
BIT(map->bit), 0);
}
static const struct reset_control_ops qcom_pdc_reset_ops = {
@@ -76,22 +110,27 @@ static const struct reset_control_ops qcom_pdc_reset_ops =
{
static int qcom_pdc_reset_probe(struct platform_device *pdev)
{
+ const struct qcom_pdc_reset_desc *desc;
struct qcom_pdc_reset_data *data;
struct device *dev = >dev;
void __iomem *base;
struct resource *res;
+ desc = device_get_match_data(>dev);
+ if (!desc)
+ return -EINVAL;
+
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
+ data->desc = desc;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(dev, res);
if (IS_ERR(base))
return PTR_ERR(base);
- data->regmap = devm_regmap_init_mmio(dev, base,
-_pdc_regmap_config);
+ data->regmap = devm_regmap_init_mmio(dev, base, _regmap_config);
if (IS_ERR(data->regmap)) {
dev_err(dev, "Unable to initialize regmap\n");
return PTR_ERR(data->regmap);
@@ -99,14 +138,15 @@ static int qcom_pdc_reset_probe(struct platform_device
*pdev)
data->rcdev.owner = THIS_MODULE;
data->rcdev.ops = _pdc_reset_ops;
- data->rcdev.nr_resets = ARRAY_SIZE(sdm845_pdc_resets
[PATCH 4/6] dt-bindings: reset: pdc: Add PDC Global bindings
Add PDC Global reset controller bindings for SC7280 SoCs. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml | 4 include/dt-bindings/reset/qcom,sdm845-pdc.h | 2 ++ 2 files changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml index d7d8cec9419f..831ea8d5d83f 100644 --- a/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml +++ b/Documentation/devicetree/bindings/reset/qcom,pdc-global.yaml @@ -21,6 +21,10 @@ properties: - const: "qcom,sc7180-pdc-global" - const: "qcom,sdm845-pdc-global" + - description: on SC7280 SoCs the following compatibles must be specified +items: + - const: "qcom,sc7280-pdc-global" + - description: on SDM845 SoCs the following compatibles must be specified items: - const: "qcom,sdm845-pdc-global" diff --git a/include/dt-bindings/reset/qcom,sdm845-pdc.h b/include/dt-bindings/reset/qcom,sdm845-pdc.h index 53c37f9c319a..03a0c0eb8147 100644 --- a/include/dt-bindings/reset/qcom,sdm845-pdc.h +++ b/include/dt-bindings/reset/qcom,sdm845-pdc.h @@ -16,5 +16,7 @@ #define PDC_DISPLAY_SYNC_RESET 7 #define PDC_COMPUTE_SYNC_RESET 8 #define PDC_MODEM_SYNC_RESET 9 +#define PDC_WLAN_RF_SYNC_RESET 10 +#define PDC_WPSS_SYNC_RESET11 #endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 6/6] arm64: dts: qcom: sc7280: Add nodes to boot WPSS
Add miscellaneous nodes to boot the Wireless Processor Subsystem on
SC7280 SoCs.
Signed-off-by: Sibi Sankar
---
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=438217
Depends on ipcc dt node enablement from ^^
arch/arm64/boot/dts/qcom/sc7280.dtsi | 143 +++
1 file changed, 143 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 18637c369c1d..4f03c468df51 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -10,6 +10,8 @@
#include
#include
#include
+#include
+#include
#include
/ {
@@ -50,6 +52,11 @@
no-map;
};
+ smem_mem: memory@8090 {
+ reg = <0x0 0x8090 0x0 0x20>;
+ no-map;
+ };
+
cpucp_mem: memory@80b0 {
no-map;
reg = <0x0 0x80b0 0x0 0x10>;
@@ -244,12 +251,131 @@
reg = <0 0x8000 0 0>;
};
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <_mutex_regs 0 0x1000>;
+ #hwlock-cells = <1>;
+ };
+
+ smem {
+ compatible = "qcom,smem";
+ memory-region = <_mem>;
+ hwlocks = <_mutex 3>;
+ };
+
firmware {
scm {
compatible = "qcom,scm-sc7280", "qcom,scm";
};
};
+ smp2p-adsp {
+ compatible = "qcom,smp2p";
+ qcom,smem = <443>, <429>;
+ interrupts-extended = < IPCC_CLIENT_LPASS
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+ mboxes = < IPCC_CLIENT_LPASS
+ IPCC_MPROC_SIGNAL_SMP2P>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <2>;
+
+ adsp_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ adsp_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
+ smp2p-cdsp {
+ compatible = "qcom,smp2p";
+ qcom,smem = <94>, <432>;
+ interrupts-extended = < IPCC_CLIENT_CDSP
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+ mboxes = < IPCC_CLIENT_CDSP
+ IPCC_MPROC_SIGNAL_SMP2P>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <5>;
+
+ cdsp_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ cdsp_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
+ smp2p-mpss {
+ compatible = "qcom,smp2p";
+ qcom,smem = <435>, <428>;
+ interrupts-extended = < IPCC_CLIENT_MPSS
+IPCC_MPROC_SIGNAL_SMP2P
+IRQ_TYPE_EDGE_RISING>;
+ mboxes = < IPCC_CLIENT_MPSS
+ IPCC_MPROC_SIGNAL_SMP2P>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <1>;
+
+ modem_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ modem_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ ipa_smp2p_out: ipa-ap-to-modem {
+ qcom,entry-name = "ipa";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ ipa_smp2p_in: ipa-modem-to-ap {
+ qcom,entry-name = "ipa";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
[PATCH 2/6] dt-bindings: mailbox: Add WPSS client index to IPCC
Add WPSS remote processor client index to Inter-Processor Communication Controller (IPCC) block. Signed-off-by: Sibi Sankar --- include/dt-bindings/mailbox/qcom-ipcc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/mailbox/qcom-ipcc.h b/include/dt-bindings/mailbox/qcom-ipcc.h index 4c23eefed5f3..eb91a6c05b71 100644 --- a/include/dt-bindings/mailbox/qcom-ipcc.h +++ b/include/dt-bindings/mailbox/qcom-ipcc.h @@ -29,5 +29,6 @@ #define IPCC_CLIENT_PCIE1 14 #define IPCC_CLIENT_PCIE2 15 #define IPCC_CLIENT_SPSS 16 +#define IPCC_CLIENT_WPSS 24 #endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 1/6] soc: qcom: smem: Update max processor count
Update max processor count to reflect the number of co-processors on SC7280 SoCs. Signed-off-by: Sibi Sankar --- drivers/soc/qcom/smem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c index cc4e0655a47b..4fb5aeeb0843 100644 --- a/drivers/soc/qcom/smem.c +++ b/drivers/soc/qcom/smem.c @@ -84,7 +84,7 @@ #define SMEM_GLOBAL_HOST 0xfffe /* Max number of processors/hosts in a system */ -#define SMEM_HOST_COUNT11 +#define SMEM_HOST_COUNT14 /** * struct smem_proc_comm - proc_comm communication struct (legacy) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 3/6] dt-bindings: reset: aoss: Add AOSS reset controller binding
Add AOSS reset controller bindings for SC7280 SoCs. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml index e2d85a1e1d63..a054757f4d9f 100644 --- a/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml +++ b/Documentation/devicetree/bindings/reset/qcom,aoss-reset.yaml @@ -21,6 +21,11 @@ properties: - const: "qcom,sc7180-aoss-cc" - const: "qcom,sdm845-aoss-cc" + - description: on SC7280 SoCs the following compatibles must be specified +items: + - const: "qcom,sc7280-aoss-cc" + - const: "qcom,sdm845-aoss-cc" + - description: on SDM845 SoCs the following compatibles must be specified items: - const: "qcom,sdm845-aoss-cc" -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 0/6] Enable miscellaneous hardware blocks to boot WPSS
This series enables miscellaneous hardware blocks to boot Wireless Processor Subsystem (WPSS) on SC7280 SoC. [1] https://lore.kernel.org/patchwork/cover/1389010/ The series depends on ^^ Sibi Sankar (6): soc: qcom: smem: Update max processor count dt-bindings: mailbox: Add WPSS client index to IPCC dt-bindings: reset: aoss: Add AOSS reset controller binding dt-bindings: reset: pdc: Add PDC Global bindings reset: qcom: Add PDC Global reset signals for WPSS arm64: dts: qcom: sc7280: Add nodes to boot WPSS .../devicetree/bindings/reset/qcom,aoss-reset.yaml | 5 + .../devicetree/bindings/reset/qcom,pdc-global.yaml | 4 + arch/arm64/boot/dts/qcom/sc7280.dtsi | 143 + drivers/reset/reset-qcom-pdc.c | 62 +++-- drivers/soc/qcom/smem.c| 2 +- include/dt-bindings/mailbox/qcom-ipcc.h| 1 + include/dt-bindings/reset/qcom,sdm845-pdc.h| 2 + 7 files changed, 207 insertions(+), 12 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH] arm64: dts: qcom: sm8250: Fix epss_l3 unit address
On 2021-02-12 01:06, Georgi Djakov wrote:
The unit address of the epss_l3 node is incorrect and does not match
the address of its "reg" property. Let's fix it.
Signed-off-by: Georgi Djakov
Thanks for catching it :)
Reviewed-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 947e1accae3a..80fe1cfe8271 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -3721,7 +3721,7 @@ apps_bcm_voter: bcm_voter {
};
};
- epss_l3: interconnect@18591000 {
+ epss_l3: interconnect@1859 {
compatible = "qcom,sm8250-epss-l3";
reg = <0 0x1859 0 0x1000>;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
[PATCH v2 2/2] arm64: dts: qcom: sc7180: Add DDR/L3 votes for the pro variant
Add DDR/L3 bandwidth votes for the pro variant of SC7180 SoC, as it support
frequencies upto 2.5 GHz.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 625e922c273d..05bc10a4c84d 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -527,6 +527,11 @@
opp-hz = /bits/ 64 <24>;
opp-peak-kBps = <8532000 23347200>;
};
+
+ cpu6_opp16: opp-255360 {
+ opp-hz = /bits/ 64 <255360>;
+ opp-peak-kBps = <8532000 23347200>;
+ };
};
memory@8000 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2 1/2] arm64: dts: qcom: sc7180-lite: Tweak DDR/L3 scaling on SC7180-lite
Tweak the DDR/L3 bandwidth votes on the lite variant of the SC7180 SoC
since the gold cores only support frequencies upto 2.1 GHz.
Signed-off-by: Sibi Sankar
---
V2:
* Updated the lite ddr/l3 cpufreq map to have better power numbers with
similar perf.
arch/arm64/boot/dts/qcom/sc7180-lite.dtsi | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
diff --git a/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
new file mode 100644
index ..d8ed1d7b4ec7
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * SC7180 lite device tree source
+ *
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+_opp10 {
+ opp-peak-kBps = <7216000 22425600>;
+};
+
+_opp11 {
+ opp-peak-kBps = <7216000 22425600>;
+};
+
+_opp12 {
+ opp-peak-kBps = <8532000 23347200>;
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 1/2] soc: qcom: aoss: Expose send for generic usecase
Hey Chris,
Thanks for the patch.
On 2020-11-03 08:49, Chris Lew wrote:
Not all upcoming usecases will have an interface to allow the aoss
driver to hook onto. Expose the send api and create a get function to
enable drivers to send their own messages to aoss.
Signed-off-by: Chris Lew
---
drivers/soc/qcom/qcom_aoss.c | 28 +++-
include/linux/soc/qcom/qcom_aoss.h | 33
+
2 files changed, 60 insertions(+), 1 deletion(-)
create mode 100644 include/linux/soc/qcom/qcom_aoss.h
diff --git a/drivers/soc/qcom/qcom_aoss.c
b/drivers/soc/qcom/qcom_aoss.c
index ed2c687c16b3..8f052db1880a 100644
--- a/drivers/soc/qcom/qcom_aoss.c
+++ b/drivers/soc/qcom/qcom_aoss.c
@@ -8,10 +8,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#define QMP_DESC_MAGIC 0x0
#define QMP_DESC_VERSION 0x4
@@ -222,12 +224,15 @@ static bool qmp_message_empty(struct qmp *qmp)
*
* Return: 0 on success, negative errno on failure
*/
-static int qmp_send(struct qmp *qmp, const void *data, size_t len)
+int qmp_send(struct qmp *qmp, const void *data, size_t len)
{
long time_left;
size_t tlen;
int ret;
+ if (!qmp || !data)
+ return -EINVAL;
+
if (WARN_ON(len + sizeof(u32) > qmp->size))
return -EINVAL;
@@ -261,6 +266,7 @@ static int qmp_send(struct qmp *qmp, const void
*data, size_t len)
return ret;
}
+EXPORT_SYMBOL_GPL(qmp_send);
static int qmp_qdss_clk_prepare(struct clk_hw *hw)
{
@@ -515,6 +521,26 @@ static void qmp_cooling_devices_remove(struct qmp
*qmp)
thermal_cooling_device_unregister(qmp->cooling_devs[i].cdev);
}
+/**
+ * qmp_get() - get a qmp handle from device tree node
+ * @np: of node of qmp device
+ *
+ * Return: handle to qmp device on success, ERR_PTR() on failure
+ */
+struct qmp_device *qmp_get(struct device_node *np)
+{
+ struct platform_device *pdev;
+ struct qmp *qmp;
Can we use this patch series to determine
the binding the client are expected to use
to point to the qmp phandle and have it
parsed here? This would mean that qmp_get
would take in device as input instead.
Bjorn suggested that clients use "qcom,qmp"
during an offline discussion. Let me know
what you think.
+
+ pdev = of_find_device_by_node(np);
+ if (!pdev)
+ return ERR_PTR(-EINVAL);
+
+ qmp = platform_get_drvdata(pdev);
+ return qmp ? qmp : ERR_PTR(-EPROBE_DEFER);
+}
+EXPORT_SYMBOL_GPL(qmp_get);
+
static int qmp_probe(struct platform_device *pdev)
{
struct resource *res;
diff --git a/include/linux/soc/qcom/qcom_aoss.h
b/include/linux/soc/qcom/qcom_aoss.h
new file mode 100644
index ..05fc0ed3a10d
--- /dev/null
+++ b/include/linux/soc/qcom/qcom_aoss.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#ifndef __QCOM_AOSS_H__
+#define __QCOM_AOSS_H__
+
+#include
+#include
+
+struct qmp;
+
+#if IS_ENABLED(CONFIG_QCOM_AOSS_QMP)
+
+int qmp_send(struct qmp *qmp, const void *data, size_t len);
+struct qmp_device *qmp_get(struct device_node *np);
+
+#else
+
+int qmp_send(struct qmp *qmp, const void *data, size_t len)
+{
+ return -ENODEV;
+}
+
+struct qmp *qmp_get(struct device_node *np)
+{
+ return ERR_PTR(-ENODEV);
+}
+
+#endif
+
+#endif
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH 1/2] arm64: dts: qcom: sc7180-lite: Tweak DDR/L3 scaling on SC7180-lite
On 2020-10-17 04:29, Doug Anderson wrote:
Hi,
On Thu, Oct 15, 2020 at 10:53 AM Sibi Sankar
wrote:
Tweak the DDR/L3 bandwidth votes on the lite variant of the SC7180 SoC
since the gold cores only support frequencies upto 2.1 GHz.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7180-lite.dtsi | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
diff --git a/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
new file mode 100644
index ..cff50275cfe1
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * SC7180 lite device tree source
+ *
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+_opp11 {
+ opp-peak-kBps = <8532000 22425600>;
+};
+
+_opp12 {
+ opp-peak-kBps = <8532000 23347200>;
+};
I guess this is OK, but something about it smells just a little
strange... I guess:
a) There's suddenly a big jump from opp10 to opp11. You don't use
7216000 at all anymore.
b) The fact that we need to do this at all feels like a sign that
somehow this wasn't designed quite right.
Just brainstorming a bit: If the higher memory rate wasn't useful for
OPP11/12 on the non-lite version of the chip, why are they useful for
that OPP on the lite version? I guess you're just trying to eek out
the last little bits of performance once the cpufreq is maxed out? It
Doug,
Really sorry about the delayed response,
running power tests and getting some fuse
info took longer than expected. Yes the
mapping table as expected is a trade off
between power/perf and it has been determined
that lite version would meet the power
numbers even with the high memory votes
at lower freqs.
190080 --> opp-peak-kBps = <7216000 22425600>;
199680 --> opp-peak-kBps = <7216000 22425600>;
211200 --> opp-peak-kBps = <8532000 23347200>;
^^ is the new recommendation from the perf/power
QC teams for lite and is expected to have better
power numbers with similar perf.
almost feels like a better way to do this (though it wouldn't be
monotonically increasing anymore so it wouldn't actually work) would
be to have a few "OPP" points at the top where the cpufreq stops
increasing and all you do is increase the memory frequency.
c) In theory we're supposed to be able to probe whether we're on the
normal, lite, or pro version, right? Anyway we could tweak this in
code so we don't have to know to include the right dtsi file?
Yes we can determine f_max by reading speed_bin
efuse values or by OSM table traversal (though
latter looks more like a hack) and use that
along with opp-supported-hw to identity supported
opps.
I would prefer If we can avoid doing ^^ if
we can get away with overloading the votes
in dt but I don't have any strong opinions
on this. So let me know how you want it done
and I'll fix it up accordingly in the next
re-spin.
-Doug
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
[PATCH 1/2] remoteproc: qcom_q6v5_mss: Replace ioremap with memremap
Fix the sparse warnings reported by the kernel test bot by replacing
ioremap calls with memremap.
Reported-by: kernel test robot
Signed-off-by: Sibi Sankar
---
I'll send out the patches to convert ioremap to memremap on other
qc remoteproc drivers once I get a chance to test them.
drivers/remoteproc/qcom_q6v5_mss.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 9a473cfef758..2c866b6da23c 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1194,7 +1194,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
goto release_firmware;
}
- ptr = ioremap_wc(qproc->mpss_phys + offset, phdr->p_memsz);
+ ptr = memremap(qproc->mpss_phys + offset, phdr->p_memsz,
MEMREMAP_WC);
if (!ptr) {
dev_err(qproc->dev,
"unable to map memory region: %pa+%zx-%x\n",
@@ -1209,7 +1209,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
"failed to load segment %d from
truncated file %s\n",
i, fw_name);
ret = -EINVAL;
- iounmap(ptr);
+ memunmap(ptr);
goto release_firmware;
}
@@ -1221,7 +1221,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
ptr, phdr->p_filesz);
if (ret) {
dev_err(qproc->dev, "failed to load %s\n",
fw_name);
- iounmap(ptr);
+ memunmap(ptr);
goto release_firmware;
}
@@ -1232,7 +1232,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
memset(ptr + phdr->p_filesz, 0,
phdr->p_memsz - phdr->p_filesz);
}
- iounmap(ptr);
+ memunmap(ptr);
size += phdr->p_memsz;
code_length = readl(qproc->rmb_base + RMB_PMI_CODE_LENGTH_REG);
@@ -1299,11 +1299,11 @@ static void qcom_q6v5_dump_segment(struct rproc *rproc,
}
if (!ret)
- ptr = ioremap_wc(qproc->mpss_phys + offset + cp_offset, size);
+ ptr = memremap(qproc->mpss_phys + offset + cp_offset, size,
MEMREMAP_WC);
if (ptr) {
memcpy(dest, ptr, size);
- iounmap(ptr);
+ memunmap(ptr);
} else {
memset(dest, 0xff, size);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 2/2] remoteproc: qcom_q6v5_mss: map/unmap MBA region before/after use
The application processor accessing the MBA region after assigning it to
the remote Q6 would lead to an XPU violation. Fix this by un-mapping the
MBA region post firmware copy and MBA text log dumps.
Signed-off-by: Sibi Sankar
---
drivers/remoteproc/qcom_q6v5_mss.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 2c866b6da23c..1b4a34325788 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -189,7 +189,6 @@ struct q6v5 {
size_t total_dump_size;
phys_addr_t mba_phys;
- void *mba_region;
size_t mba_size;
size_t dp_size;
@@ -408,7 +407,7 @@ static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int
*current_perm,
current_perm, next, perms);
}
-static void q6v5_debug_policy_load(struct q6v5 *qproc)
+static void q6v5_debug_policy_load(struct q6v5 *qproc, void *ptr)
{
const struct firmware *dp_fw;
@@ -416,7 +415,7 @@ static void q6v5_debug_policy_load(struct q6v5 *qproc)
return;
if (SZ_1M + dp_fw->size <= qproc->mba_size) {
- memcpy(qproc->mba_region + SZ_1M, dp_fw->data, dp_fw->size);
+ memcpy(ptr + SZ_1M, dp_fw->data, dp_fw->size);
qproc->dp_size = dp_fw->size;
}
@@ -426,6 +425,7 @@ static void q6v5_debug_policy_load(struct q6v5 *qproc)
static int q6v5_load(struct rproc *rproc, const struct firmware *fw)
{
struct q6v5 *qproc = rproc->priv;
+ void *ptr;
/* MBA is restricted to a maximum size of 1M */
if (fw->size > qproc->mba_size || fw->size > SZ_1M) {
@@ -433,8 +433,16 @@ static int q6v5_load(struct rproc *rproc, const struct
firmware *fw)
return -EINVAL;
}
- memcpy(qproc->mba_region, fw->data, fw->size);
- q6v5_debug_policy_load(qproc);
+ ptr = memremap(qproc->mba_phys, qproc->mba_size, MEMREMAP_WC);
+ if (!ptr) {
+ dev_err(qproc->dev, "unable to map memory region: %pa+%zx\n",
+ >mba_phys, qproc->mba_size);
+ return -EBUSY;
+ }
+
+ memcpy(ptr, fw->data, fw->size);
+ q6v5_debug_policy_load(qproc, ptr);
+ memunmap(ptr);
return 0;
}
@@ -541,6 +549,7 @@ static void q6v5_dump_mba_logs(struct q6v5 *qproc)
{
struct rproc *rproc = qproc->rproc;
void *data;
+ void *ptr;
if (!qproc->has_mba_logs)
return;
@@ -549,12 +558,16 @@ static void q6v5_dump_mba_logs(struct q6v5 *qproc)
qproc->mba_size))
return;
- data = vmalloc(MBA_LOG_SIZE);
- if (!data)
+ ptr = memremap(qproc->mba_phys, qproc->mba_size, MEMREMAP_WC);
+ if (!ptr)
return;
- memcpy(data, qproc->mba_region, MBA_LOG_SIZE);
- dev_coredumpv(>dev, data, MBA_LOG_SIZE, GFP_KERNEL);
+ data = vmalloc(MBA_LOG_SIZE);
+ if (data) {
+ memcpy(data, ptr, MBA_LOG_SIZE);
+ dev_coredumpv(>dev, data, MBA_LOG_SIZE, GFP_KERNEL);
+ }
+ memunmap(ptr);
}
static int q6v5proc_reset(struct q6v5 *qproc)
@@ -1605,12 +1618,6 @@ static int q6v5_alloc_memory_region(struct q6v5 *qproc)
qproc->mba_phys = r.start;
qproc->mba_size = resource_size();
- qproc->mba_region = devm_ioremap_wc(qproc->dev, qproc->mba_phys,
qproc->mba_size);
- if (!qproc->mba_region) {
- dev_err(qproc->dev, "unable to map memory region: %pa+%zx\n",
- , qproc->mba_size);
- return -EBUSY;
- }
if (!child) {
node = of_parse_phandle(qproc->dev->of_node,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 1/2] arm64: dts: qcom: sc7180-lite: Tweak DDR/L3 scaling on SC7180-lite
Tweak the DDR/L3 bandwidth votes on the lite variant of the SC7180 SoC
since the gold cores only support frequencies upto 2.1 GHz.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7180-lite.dtsi | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
diff --git a/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
new file mode 100644
index ..cff50275cfe1
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7180-lite.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * SC7180 lite device tree source
+ *
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+_opp11 {
+ opp-peak-kBps = <8532000 22425600>;
+};
+
+_opp12 {
+ opp-peak-kBps = <8532000 23347200>;
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] arm64: dts: qcom: sc7180-trogdor: Fixup modem memory region
The modem firmware memory requirements vary between 32M/140M on
no-lte/lte skus respectively, so fixup the modem memory region
to reflect the requirements.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7180-trogdor-lte-sku.dtsi | 4
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lte-sku.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lte-sku.dtsi
index 44956e3165a1..469aad4e5948 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor-lte-sku.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor-lte-sku.dtsi
@@ -9,6 +9,10 @@
label = "proximity-wifi-lte";
};
+_mem {
+ reg = <0x0 0x8600 0x0 0x8c0>;
+};
+
_mpss {
firmware-name = "qcom/sc7180-trogdor/modem/mba.mbn",
"qcom/sc7180-trogdor/modem/qdsp6sw.mbn";
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
index bf875589d364..92a1fe114da8 100644
--- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi
@@ -39,7 +39,7 @@
};
mpss_mem: memory@8600 {
- reg = <0x0 0x8600 0x0 0x8c0>;
+ reg = <0x0 0x8600 0x0 0x200>;
no-map;
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 2/2] arm64: dts: qcom: sc7180: Add DDR/L3 votes for the pro variant
Add DDR/L3 bandwidth votes for the pro variant of SC7180 SoC, as it support
frequencies upto 2.5 GHz.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index 6678f1e8e395..4a39c35119ce 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -525,6 +525,11 @@
opp-hz = /bits/ 64 <24>;
opp-peak-kBps = <8532000 23347200>;
};
+
+ cpu6_opp16: opp-255360 {
+ opp-hz = /bits/ 64 <255360>;
+ opp-peak-kBps = <8532000 23347200>;
+ };
};
memory@8000 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME flags
On 2020-09-22 01:26, Stephen Boyd wrote: Quoting Rafael J. Wysocki (2020-09-21 09:18:17) On Fri, Aug 21, 2020 at 10:49 PM Sibi Sankar wrote: > > Add GENPD_FLAG_NO_SUSPEND/RESUME flags to instruct genpd to keep the > status of the PM domain unaltered during suspend/resume respectively. > The flags are aimed at power domains coupled to co-processors which > enter low-power modes independent to that of the application processor. > > Specifically the flags are to be used by the power domains exposed > by the AOSS QMP driver linked to modem, adsp, cdsp remoteprocs. These > power domains are used to notify the Always on Subsystem (AOSS) that > a particular co-processor is up. AOSS uses this information to wait > for the co-processors to suspend before starting its sleep sequence. > The application processor powers off these power domains only if the > co-processor has crashed or powered off and remains unaltered during > system suspend/resume. > > Signed-off-by: Sibi Sankar Applied with the Ulf's R-by along with the [2/2] as 5.10 material, thanks! There was a bunch of discussion on this patch series and I thought the consensus was to not apply these patches and instead implement a custom qcom specific API that does this instead. https://lore.kernel.org/lkml/20200913034603.GV3715@yoga/ The power domains which were targeted to use the flags will be replaced by custom qcom specific API. So let's not pick up the patch series. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH v3] remoteproc: qcom_q6v5: Assign mpss region to Q6 before MBA boot
On secure devices which support warm reset, the MBA firmware requires
access to the modem region to clear them out. Hence provide Q6 access
to this region before MBA boot. This will be a nop during a modem SSR.
Signed-off-by: Sibi Sankar
---
V3:
* Fixup comment style [Stephen]
V2:
* Fixup comments [Bjorn]
drivers/remoteproc/qcom_q6v5_mss.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index c401bcc263fa..eb3457a6c3b7 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -931,6 +931,17 @@ static int q6v5_mba_load(struct q6v5 *qproc)
goto assert_reset;
}
+ /*
+* Some versions of the MBA firmware will upon boot wipe the MPSS
region as well, so provide
+* the Q6 access to this region.
+*/
+ ret = q6v5_xfer_mem_ownership(qproc, >mpss_perm, false, true,
+ qproc->mpss_phys, qproc->mpss_size);
+ if (ret) {
+ dev_err(qproc->dev, "assigning Q6 access to mpss memory failed:
%d\n", ret);
+ goto disable_active_clks;
+ }
+
/* Assign MBA image access in DDR to q6 */
ret = q6v5_xfer_mem_ownership(qproc, >mba_perm, false, true,
qproc->mba_phys, qproc->mba_size);
@@ -1135,10 +1146,9 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
max_addr = ALIGN(phdr->p_paddr + phdr->p_memsz, SZ_4K);
}
- /**
+ /*
* In case of a modem subsystem restart on secure devices, the modem
-* memory can be reclaimed only after MBA is loaded. For modem cold
-* boot this will be a nop
+* memory can be reclaimed only after MBA is loaded.
*/
q6v5_xfer_mem_ownership(qproc, >mpss_perm, true, false,
qproc->mpss_phys, qproc->mpss_size);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2] remoteproc: qcom_q6v5: Assign mpss region to Q6 before MBA boot
Stephen,
Thanks for taking time to review the
series.
On 2020-09-16 22:47, Stephen Boyd wrote:
Quoting Sibi Sankar (2020-09-16 07:52:52)
On secure devices which support warm reset, the MBA firmware requires
access to the modem region to clear them out. Hence provide Q6 access
to this region before MBA boot. This will be a nop during a modem SSR.
Does it need a Fixes: tag? Probably.
it doesn't really fix anything previously
committed. When SC7180 support was added,
mss driver still lacked secure boot support
and when Bjorn added secure boot support,
none of the secure devices necessarily
supported warm reset. So I'll skip adding
fixes tag.
Signed-off-by: Sibi Sankar
---
Trivia time!
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index c401bcc263fa..f989ca81d374 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -931,6 +931,16 @@ static int q6v5_mba_load(struct q6v5 *qproc)
goto assert_reset;
}
+ /* Some versions of the MBA firmware will upon boot wipe the
MPSS region as well, so provide
Should have /* on a line by itself.
+* the Q6 access to this region.
+*/
+ ret = q6v5_xfer_mem_ownership(qproc, >mpss_perm, false,
true,
+ qproc->mpss_phys,
qproc->mpss_size);
+ if (ret) {
+ dev_err(qproc->dev, "assigning Q6 access to mpss
memory failed: %d\n", ret);
+ goto disable_active_clks;
+ }
+
/* Assign MBA image access in DDR to q6 */
ret = q6v5_xfer_mem_ownership(qproc, >mba_perm, false,
true,
qproc->mba_phys,
qproc->mba_size);
@@ -1137,8 +1147,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
/**
Should be /* instead of /**, the latter is for kernel-doc which this is
not.
sure I'll get ^^ done in the next
re-spin.
* In case of a modem subsystem restart on secure devices, the
modem
-* memory can be reclaimed only after MBA is loaded. For modem
cold
-* boot this will be a nop
+* memory can be reclaimed only after MBA is loaded.
*/
q6v5_xfer_mem_ownership(qproc, >mpss_perm, true, false,
qproc->mpss_phys, qproc->mpss_size);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
[PATCH v2] remoteproc: Fixup coredump debugfs disable request
Fix the discrepancy observed between accepted input and read back value
while disabling remoteproc coredump through the coredump debugfs entry.
Fixes: 3afdc59e4390 ("remoteproc: Add coredump debugfs entry")
Cc: sta...@vger.kernel.org
Signed-off-by: Sibi Sankar
---
V2:
* Fixup commit message [Bjorn].
drivers/remoteproc/remoteproc_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_debugfs.c
b/drivers/remoteproc/remoteproc_debugfs.c
index 2e3b3e22e1d0..7ca823f6aa63 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -94,7 +94,7 @@ static ssize_t rproc_coredump_write(struct file *filp,
goto out;
}
- if (!strncmp(buf, "disable", count)) {
+ if (!strncmp(buf, "disabled", count)) {
rproc->dump_conf = RPROC_COREDUMP_DISABLED;
} else if (!strncmp(buf, "inline", count)) {
rproc->dump_conf = RPROC_COREDUMP_INLINE;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2] remoteproc: qcom_q6v5: Assign mpss region to Q6 before MBA boot
On secure devices which support warm reset, the MBA firmware requires
access to the modem region to clear them out. Hence provide Q6 access
to this region before MBA boot. This will be a nop during a modem SSR.
Signed-off-by: Sibi Sankar
---
V2:
* Fixup comments as suggested by Bjorn.
drivers/remoteproc/qcom_q6v5_mss.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index c401bcc263fa..f989ca81d374 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -931,6 +931,16 @@ static int q6v5_mba_load(struct q6v5 *qproc)
goto assert_reset;
}
+ /* Some versions of the MBA firmware will upon boot wipe the MPSS
region as well, so provide
+* the Q6 access to this region.
+*/
+ ret = q6v5_xfer_mem_ownership(qproc, >mpss_perm, false, true,
+ qproc->mpss_phys, qproc->mpss_size);
+ if (ret) {
+ dev_err(qproc->dev, "assigning Q6 access to mpss memory failed:
%d\n", ret);
+ goto disable_active_clks;
+ }
+
/* Assign MBA image access in DDR to q6 */
ret = q6v5_xfer_mem_ownership(qproc, >mba_perm, false, true,
qproc->mba_phys, qproc->mba_size);
@@ -1137,8 +1147,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
/**
* In case of a modem subsystem restart on secure devices, the modem
-* memory can be reclaimed only after MBA is loaded. For modem cold
-* boot this will be a nop
+* memory can be reclaimed only after MBA is loaded.
*/
q6v5_xfer_mem_ownership(qproc, >mpss_perm, true, false,
qproc->mpss_phys, qproc->mpss_size);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] remoteproc: Fixup coredump debugfs disable request
Hey Bjorn,
Thanks for taking time to review the
patch.
On 2020-09-15 20:48, Bjorn Andersson wrote:
On Tue 15 Sep 07:34 UTC 2020, Sibi Sankar wrote:
Currently the coredump debugfs entry takes in "disable" to set the
coredump state to "disabled". Let's just accept the expected state
instead.
I like this patch, but rather than arguing that it should match the
name
of the internal state I think you should either argue that when read
you
get "disabled" back or that "disabled" would make it consistent with
the
recovery.
Sure, I'll re-word the commit message.
I probably choose the read back argument
because that's what was odd about it in
the first place.
Regards,
Bjorn
Fixes: 3afdc59e43904 ("remoteproc: Add coredump debugfs entry")
Signed-off-by: Sibi Sankar
---
drivers/remoteproc/remoteproc_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_debugfs.c
b/drivers/remoteproc/remoteproc_debugfs.c
index 2e3b3e22e1d01..7ca823f6aa638 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -94,7 +94,7 @@ static ssize_t rproc_coredump_write(struct file
*filp,
goto out;
}
- if (!strncmp(buf, "disable", count)) {
+ if (!strncmp(buf, "disabled", count)) {
rproc->dump_conf = RPROC_COREDUMP_DISABLED;
} else if (!strncmp(buf, "inline", count)) {
rproc->dump_conf = RPROC_COREDUMP_INLINE;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
[PATCH] remoteproc: qcom_q6v5: Assign mpss region to Q6 before MBA cold boot
On secure devices which support warm reset, the modem subsystem requires
access to the mpss region to clear them out. Hence assign the mpss region
to Q6 before MBA cold boot. This will be a nop during a modem SSR.
Signed-off-by: Sibi Sankar
---
I didn't want to add any new flags for warm reset support because
calling xfer for mpss to q6 shouldn't have any side effects on
platforms that don't support warm resets.
drivers/remoteproc/qcom_q6v5_mss.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index c401bcc263fa5..cc5b7edc02c73 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -931,6 +931,18 @@ static int q6v5_mba_load(struct q6v5 *qproc)
goto assert_reset;
}
+ /**
+* On secure devices which support warm reboot, the modem subsystem's
cold boot is similar
+* to an SSR sequence i.e the mba requires access to the modem memory
to clear it out during
+* Q6 cold boot. For modem SSR it will be a nop.
+*/
+ ret = q6v5_xfer_mem_ownership(qproc, >mpss_perm, false, true,
+ qproc->mpss_phys, qproc->mpss_size);
+ if (ret) {
+ dev_err(qproc->dev, "assigning Q6 access to mpss memory failed:
%d\n", ret);
+ goto disable_active_clks;
+ }
+
/* Assign MBA image access in DDR to q6 */
ret = q6v5_xfer_mem_ownership(qproc, >mba_perm, false, true,
qproc->mba_phys, qproc->mba_size);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] soc: qcom: apr: Fixup the error displayed on lookup failure
APR client incorrectly prints out "ret" variable on pdr_add_lookup failure,
it should be printing the error value returned by the lookup instead.
Fixes: 8347356626028 ("soc: qcom: apr: Add avs/audio tracking functionality")
Signed-off-by: Sibi Sankar
---
drivers/soc/qcom/apr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/apr.c b/drivers/soc/qcom/apr.c
index 1f35b097c6356..7abfc8c4fdc72 100644
--- a/drivers/soc/qcom/apr.c
+++ b/drivers/soc/qcom/apr.c
@@ -328,7 +328,7 @@ static int of_apr_add_pd_lookups(struct device *dev)
pds = pdr_add_lookup(apr->pdr, service_name, service_path);
if (IS_ERR(pds) && PTR_ERR(pds) != -EALREADY) {
- dev_err(dev, "pdr add lookup failed: %d\n", ret);
+ dev_err(dev, "pdr add lookup failed: %ld\n",
PTR_ERR(pds));
return PTR_ERR(pds);
}
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] remoteproc: Fixup coredump debugfs disable request
Currently the coredump debugfs entry takes in "disable" to set the
coredump state to "disabled". Let's just accept the expected state
instead.
Fixes: 3afdc59e43904 ("remoteproc: Add coredump debugfs entry")
Signed-off-by: Sibi Sankar
---
drivers/remoteproc/remoteproc_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_debugfs.c
b/drivers/remoteproc/remoteproc_debugfs.c
index 2e3b3e22e1d01..7ca823f6aa638 100644
--- a/drivers/remoteproc/remoteproc_debugfs.c
+++ b/drivers/remoteproc/remoteproc_debugfs.c
@@ -94,7 +94,7 @@ static ssize_t rproc_coredump_write(struct file *filp,
goto out;
}
- if (!strncmp(buf, "disable", count)) {
+ if (!strncmp(buf, "disabled", count)) {
rproc->dump_conf = RPROC_COREDUMP_DISABLED;
} else if (!strncmp(buf, "inline", count)) {
rproc->dump_conf = RPROC_COREDUMP_INLINE;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH] soc: qcom: pdr: Fixup array type of get_domain_list_resp message
The array type of get_domain_list_resp is incorrectly marked as NO_ARRAY.
Due to which the following error was observed when using pdr helpers with
the downstream proprietary pd-mapper. Fix this up by marking it as
VAR_LEN_ARRAY instead.
Err logs:
qmi_decode_struct_elem: Fault in decoding: dl(2), db(27), tl(160), i(1), el(1)
failed to decode incoming message
PDR: tms/servreg get domain list txn wait failed: -14
PDR: service lookup for tms/servreg failed: -14
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers")
Reported-by: Rishabh Bhatnagar
Signed-off-by: Sibi Sankar
---
drivers/soc/qcom/pdr_internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/pdr_internal.h b/drivers/soc/qcom/pdr_internal.h
index 15b5002e4127b..ab9ae8cdfa54c 100644
--- a/drivers/soc/qcom/pdr_internal.h
+++ b/drivers/soc/qcom/pdr_internal.h
@@ -185,7 +185,7 @@ struct qmi_elem_info servreg_get_domain_list_resp_ei[] = {
.data_type = QMI_STRUCT,
.elem_len = SERVREG_DOMAIN_LIST_LENGTH,
.elem_size = sizeof(struct servreg_location_entry),
- .array_type = NO_ARRAY,
+ .array_type = VAR_LEN_ARRAY,
.tlv_type = 0x12,
.offset = offsetof(struct servreg_get_domain_list_resp,
domain_list),
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME flags
On 2020-08-25 23:23, Bjorn Andersson wrote: On Tue 25 Aug 02:20 CDT 2020, Stephen Boyd wrote: Quoting Bjorn Andersson (2020-08-24 09:42:12) > On Fri 21 Aug 14:41 PDT 2020, Stephen Boyd wrote: [..] > > I find it odd that this is modeled as a power domain instead of some > > Qualcomm specific message that the remoteproc driver sends to AOSS. Is > > there some sort of benefit the driver gets from using the power domain > > APIs for this vs. using a custom API? > > We need to send "up" and "down" notifications and this needs to happen > at the same time as other standard resources are enabled/disabled. > > Further more, at the time the all resources handled by the downstream > driver was either power-domains (per above understanding) or clocks, so > it made sense to me not to spin up a custom API. > So the benefit is not spinning up a custom API? I'm not Ulf, but it looks like this is hard to rationalize about as a power domain. It doesn't have any benefit to model it this way besides to make it possible to turn on with other power domains. This modem remoteproc drivers isn't SoC agnostic anyway, it relies on SMEM APIs, so standing up another small qmp_remoteproc_booted() and qmp_remoteproc_shutdown() API would avoid adding a genpd flag here that probably will never be used outside of this corner-case. There is also some get/put EPROBE_DEFER sort of logic to implement, but otherwise it would be possible to do this outside of power domains, and that seems better given that this isn't really a power domain to start with. In later platforms a few new users of the AOSS communication interface is introduced that certainly doesn't fit any existing API/framework in the kernel. So the plan was to pretty much expose qmp_send() to these drivers. My worry with using this interface is that we'll probably have to come up with some DT binding pieces and probably we'll end up adding yet another piece of hard coded information in the remoteproc drivers. But I'm not against us doing this work in favor of not having to introduce a one-off for this corner case. Bjorn/Stephen, So the consensus is to stop modelling aoss load_state as pds and expose qmp_send to drivers? Regards, Bjorn -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: R: [RFC PATCH v3 0/2] Add Krait Cache Scaling support
On 2020-09-03 12:23, Viresh Kumar wrote: On 31-08-20, 09:41, ansuels...@gmail.com wrote: On 31-08-20, Sibi wrote: > On 2020-08-24 16:10, Viresh Kumar wrote: > > +Vincent/Saravana/Sibi > > > > On 21-08-20, 16:00, Ansuel Smith wrote: > >> This adds Krait Cache scaling support using the cpufreq notifier. > >> I have some doubt about where this should be actually placed (clk or > >> cpufreq)? > >> Also the original idea was to create a dedicated cpufreq driver (like > >> it's done in > >> the codeaurora qcom repo) by copying the cpufreq-dt driver and adding > >> the cache > >> scaling logic but i still don't know what is better. Have a very > >> similar driver or > >> add a dedicated driver only for the cache using the cpufreq notifier > >> and do the > >> scale on every freq transition. > >> Thanks to everyone who will review or answer these questions. > > > > Saravana was doing something with devfreq to solve such issues if I > > wasn't mistaken. > > > > Sibi ? > > IIRC the final plan was to create a devfreq device > and devfreq-cpufreq based governor to scale them, this > way one can switch to a different governor if required. So in this case I should convert this patch to a devfreq driver- I think this should happen nevertheless. You are doing DVFS for a device which isn't a CPU and devfreq looks to be the right place of doing so. Isn't overkill to use a governor for such a task? (3 range based on the cpufreq?) I am not sure about the governor part here, maybe it won't be required ? Yeah I don't see it being needed in ^^ case as well. I just mentioned them as an advantage in case you wanted to switch to a different governor in the future. https://lore.kernel.org/lkml/d0bc8877-6d41-f54e-1c4c-2fadbb9dc...@samsung.com/ A devfreq governor tracking cpufreq was generally accepted but using a cpufreq notifier to achieve that was discouraged. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [RFC PATCH v3 0/2] Add Krait Cache Scaling support
On 2020-08-24 16:10, Viresh Kumar wrote: +Vincent/Saravana/Sibi On 21-08-20, 16:00, Ansuel Smith wrote: This adds Krait Cache scaling support using the cpufreq notifier. I have some doubt about where this should be actually placed (clk or cpufreq)? Also the original idea was to create a dedicated cpufreq driver (like it's done in the codeaurora qcom repo) by copying the cpufreq-dt driver and adding the cache scaling logic but i still don't know what is better. Have a very similar driver or add a dedicated driver only for the cache using the cpufreq notifier and do the scale on every freq transition. Thanks to everyone who will review or answer these questions. Saravana was doing something with devfreq to solve such issues if I wasn't mistaken. Sibi ? IIRC the final plan was to create a devfreq device and devfreq-cpufreq based governor to scale them, this way one can switch to a different governor if required. (I don't see if ^^ applies well for l2 though). In the interim until such a solution is acked on the list we just scale the resources directly from the cpufreq driver. On SDM845/SC7180 SoCs, L3 is modeled as a interconnect provider and is directly scaled from the cpufreq-hw driver. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME flags
On 2020-08-25 12:50, Stephen Boyd wrote: Quoting Bjorn Andersson (2020-08-24 09:42:12) On Fri 21 Aug 14:41 PDT 2020, Stephen Boyd wrote: > Quoting Sibi Sankar (2020-08-21 13:49:20) > > Add GENPD_FLAG_NO_SUSPEND/RESUME flags to instruct genpd to keep the > > status of the PM domain unaltered during suspend/resume respectively. > > The flags are aimed at power domains coupled to co-processors which > > enter low-power modes independent to that of the application processor. > > > > Specifically the flags are to be used by the power domains exposed > > by the AOSS QMP driver linked to modem, adsp, cdsp remoteprocs. These > > power domains are used to notify the Always on Subsystem (AOSS) that > > a particular co-processor is up. AOSS uses this information to wait > > for the co-processors to suspend before starting its sleep sequence. > > The application processor powers off these power domains only if the > > co-processor has crashed or powered off and remains unaltered during > > system suspend/resume. > > Why are these power domains instead of some QMP message sent during > remote proc power up? The understanding I gained as I researched this, was that with this property enabled resources related to the particular subsystem will be kept enabled when the apss enters some power save mode. So my interpretation was that it does "keep something powered". It looks like it tells AOSS that the processor is booted and to start considering these processors in the SoC wide system suspend sequence. Otherwise I guess the RPMh buckets associated with these remoteprocs don't count in the aggregation and sleep/wake sequences that AOSS runs through when putting the SoC into low power mode. I'm not sure it actually "keeps something powered" so much as it lets something be powered off. Sibi? That is just a part of equation i.e AOSS doesn't enter sleep until the remote processors enter RPMh assisted sleep. This also implies that if the respective remote processor has to come out of low power states it will need to wait for AOSS to come out of sleep. So clearly remote processors are dependent on certain resources to be enabled by the AOSS but the resources may not be restricted to just corners. Another question, why can't the processors tell AOSS themselves about their boot state? I guess because they may crash or be powered down and then AOSS wouldn't know? Fair enough I guess, but I don't think this is mentioned anywhere. > If this has been discussed before feel free to > disregard and please link to prior mailing list discussions. > There where some discussions related to the "QDSS clk" in that series, but I don't remember getting any feedback on modelling these things as power-domains. > I find it odd that this is modeled as a power domain instead of some > Qualcomm specific message that the remoteproc driver sends to AOSS. Is > there some sort of benefit the driver gets from using the power domain > APIs for this vs. using a custom API? We need to send "up" and "down" notifications and this needs to happen at the same time as other standard resources are enabled/disabled. Further more, at the time the all resources handled by the downstream driver was either power-domains (per above understanding) or clocks, so it made sense to me not to spin up a custom API. So the benefit is not spinning up a custom API? I'm not Ulf, but it looks like this is hard to rationalize about as a power domain. It doesn't have any benefit to model it this way besides to make it possible to turn on with other power domains. This modem remoteproc drivers isn't SoC agnostic anyway, it relies on SMEM APIs, so standing up another small qmp_remoteproc_booted() and qmp_remoteproc_shutdown() API would avoid adding a genpd flag here that probably will never be used outside of this corner-case. There is also some get/put EPROBE_DEFER sort of logic to implement, but otherwise it would be possible to do this outside of power domains, and that seems better given that this isn't really a power domain to start with. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH] soc: qcom: initialize local variable
On 2020-08-20 00:16, t...@redhat.com wrote:
From: Tom Rix
clang static analysis reports this problem
pdr_interface.c:596:6: warning: Branch condition evaluates
to a garbage value
if (!req.service_path[0])
^~~~
This check that req.service_path was set in an earlier loop.
However req is a stack variable and its initial value
is undefined.
So initialize req to 0.
Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart
helpers")
Tom,
Thanks for the patch.
Reviewed-by: Sibi Sankar
Signed-off-by: Tom Rix
---
drivers/soc/qcom/pdr_interface.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/pdr_interface.c
b/drivers/soc/qcom/pdr_interface.c
index 088dc99f77f3..f63135c09667 100644
--- a/drivers/soc/qcom/pdr_interface.c
+++ b/drivers/soc/qcom/pdr_interface.c
@@ -569,7 +569,7 @@ EXPORT_SYMBOL(pdr_add_lookup);
int pdr_restart_pd(struct pdr_handle *pdr, struct pdr_service *pds)
{
struct servreg_restart_pd_resp resp;
- struct servreg_restart_pd_req req;
+ struct servreg_restart_pd_req req = { 0 };
struct sockaddr_qrtr addr;
struct pdr_service *tmp;
struct qmi_txn txn;
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
[PATCH v2 2/2] soc: qcom: aoss: Use both GENPD_FLAG_NO_SUSPEND/RESUME flags
All the power domains exposed as part of the AOSS QMP driver require to
stay unaltered during suspend/resume. They are powered on when the remote
processors boots up and powered off on remote processor crash/shutdown.
Mark the power domains with GENPD_FLAG_NO_SUSPEND and GENPD_FLAG_NO_RESUME
to model this behavior.
Signed-off-by: Sibi Sankar
---
V2:
* Use the renamed flags
* Drop R-b/T-b
drivers/soc/qcom/qcom_aoss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
index ed2c687c16b31..da763ac6bca2f 100644
--- a/drivers/soc/qcom/qcom_aoss.c
+++ b/drivers/soc/qcom/qcom_aoss.c
@@ -366,6 +366,7 @@ static int qmp_pd_add(struct 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;
+ res[i].pd.flags = GENPD_FLAG_NO_SUSPEND | GENPD_FLAG_NO_RESUME;
ret = pm_genpd_init([i].pd, NULL, true);
if (ret < 0) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v2 1/2] PM / Domains: Add GENPD_FLAG_NO_SUSPEND/RESUME flags
Add GENPD_FLAG_NO_SUSPEND/RESUME flags to instruct genpd to keep the
status of the PM domain unaltered during suspend/resume respectively.
The flags are aimed at power domains coupled to co-processors which
enter low-power modes independent to that of the application processor.
Specifically the flags are to be used by the power domains exposed
by the AOSS QMP driver linked to modem, adsp, cdsp remoteprocs. These
power domains are used to notify the Always on Subsystem (AOSS) that
a particular co-processor is up. AOSS uses this information to wait
for the co-processors to suspend before starting its sleep sequence.
The application processor powers off these power domains only if the
co-processor has crashed or powered off and remains unaltered during
system suspend/resume.
Signed-off-by: Sibi Sankar
---
V2:
* Add more info in commit msg and description [Uffe/Kevin/Stephen]
* Rename and split functionality into two flags [Uffe]
* Drop R-b/T-b
drivers/base/power/domain.c | 6 --
include/linux/pm_domain.h | 10 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 2cb5e04cf86cd..a5df5916f30f8 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -129,6 +129,8 @@ static const struct genpd_lock_ops genpd_spin_ops = {
#define genpd_is_active_wakeup(genpd) (genpd->flags &
GENPD_FLAG_ACTIVE_WAKEUP)
#define genpd_is_cpu_domain(genpd) (genpd->flags & GENPD_FLAG_CPU_DOMAIN)
#define genpd_is_rpm_always_on(genpd) (genpd->flags &
GENPD_FLAG_RPM_ALWAYS_ON)
+#define genpd_is_no_suspend(genpd) (genpd->flags & GENPD_FLAG_NO_SUSPEND)
+#define genpd_is_no_resume(genpd) (genpd->flags & GENPD_FLAG_NO_RESUME)
static inline bool irq_safe_dev_in_no_sleep_domain(struct device *dev,
const struct generic_pm_domain *genpd)
@@ -949,7 +951,7 @@ static void genpd_sync_power_off(struct generic_pm_domain
*genpd, bool use_lock,
{
struct gpd_link *link;
- if (!genpd_status_on(genpd) || genpd_is_always_on(genpd))
+ if (!genpd_status_on(genpd) || genpd_is_always_on(genpd) ||
genpd_is_no_suspend(genpd))
return;
if (genpd->suspended_count != genpd->device_count
@@ -991,7 +993,7 @@ static void genpd_sync_power_on(struct generic_pm_domain
*genpd, bool use_lock,
{
struct gpd_link *link;
- if (genpd_status_on(genpd))
+ if (genpd_status_on(genpd) || genpd_is_no_resume(genpd))
return;
list_for_each_entry(link, >child_links, child_node) {
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index ee11502a575b0..568abdf2e89cf 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -55,6 +55,14 @@
*
* GENPD_FLAG_RPM_ALWAYS_ON: Instructs genpd to always keep the PM domain
* powered on except for system suspend.
+ *
+ * GENPD_FLAG_NO_SUSPEND: Instructs genpd to keep the PM domain powered
+ * on during suspend (if it's already powered on)
+ * and runtime PM controlled otherwise.
+ *
+ * GENPD_FLAG_NO_RESUME: Instructs genpd to keep the PM domain powered
+ * off during resume (if it's already powered off)
+ * and runtime PM controlled otherwise.
*/
#define GENPD_FLAG_PM_CLK (1U << 0)
#define GENPD_FLAG_IRQ_SAFE (1U << 1)
@@ -62,6 +70,8 @@
#define GENPD_FLAG_ACTIVE_WAKEUP (1U << 3)
#define GENPD_FLAG_CPU_DOMAIN (1U << 4)
#define GENPD_FLAG_RPM_ALWAYS_ON (1U << 5)
+#define GENPD_FLAG_NO_SUSPEND (1U << 6)
+#define GENPD_FLAG_NO_RESUME(1U << 7)
enum gpd_status {
GPD_STATE_ACTIVE = 0, /* PM domain is active */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 1/2] PM / Domains: Add GENPD_FLAG_SUSPEND_ON flag
On 2020-08-18 14:01, Ulf Hansson wrote: On Mon, 17 Aug 2020 at 18:49, Sibi Sankar wrote: On 2020-08-17 14:14, Ulf Hansson wrote: > On Thu, 13 Aug 2020 at 19:26, Sibi Sankar wrote: >> >> On 2020-08-13 18:04, Ulf Hansson wrote: >> > On Wed, 12 Aug 2020 at 19:03, Sibi Sankar wrote: >> >> >> >> Uffe, >> >> Thanks for taking time to review the >> >> series! >> >> >> >> On 2020-08-12 15:15, Ulf Hansson wrote: >> >> > On Tue, 11 Aug 2020 at 21:03, Sibi Sankar wrote: >> >> >> >> >> >> This is for power domains which needs to stay powered on for suspend >> >> >> but can be powered on/off as part of runtime PM. This flag is aimed at >> >> >> power domains coupled to remote processors which enter suspend states >> >> >> independent to that of the application processor. Such power domains >> >> >> are turned off only on remote processor crash/shutdown. >> >> > >> >> > As Kevin also requested, please elaborate more on the use case. >> >> > >> >> > Why exactly must the PM domain stay powered on during system suspend? >> >> > Is there a wakeup configured that needs to be managed - or is there a >> >> > co-processor/FW behaviour that needs to be obeyed to? >> >> >> >> Yes this is a co-processor behavior that >> >> needs to be obeyed. Specifically application >> >> processor notifies the Always on Subsystem >> >> (AOSS) that a particular co-processor is up >> >> using the power domains exposed by AOSS QMP >> >> driver. AOSS uses this information to wait >> >> for the co-processors to suspend before >> >> starting its sleep sequence. The application >> >> processor powers off these power domains only >> >> if the co-processor has crashed or powered >> >> off. >> > >> > Thanks for clarifying! >> > >> > Although, can you please elaborate a bit more on the actual use case? >> > What are the typical co-processor and what drivers are involved in >> > managing it? >> >> The co-processors using the power domains >> exposed by qcom_aoss driver are modem, >> audio dsp, compute dsp managed using >> qcom_q6v5_mss and qcom_q6v5_pas driver. >> >> > >> > As you may know, runtime PM becomes disabled during system suspend of >> > a device. Which means, if the driver tries to power off the >> > coprocessor (via calling pm_runtime_put() for example), somewhere in >> > the system suspend phase of the corresponding device, its attached PM >> > domain stays powered on when managed by genpd. >> >> The drivers aren't really expected >> do anything during suspend/resume >> pretty much because the co-processors >> enter low-power modes independent to >> that of the application processor. On >> co-processor crash the remoteproc core >> does a pm_stay_awake followed by a >> pm_relax after crash recovery. > > Okay, thanks again for clarifying. You have convinced me about the > need for a new flag to cope with these use cases. > > Would you mind updating the commit message with some of the > information you just provided? > > Additionally, to make it clear that the flag should be used to keep > the PM domain powered on during system suspend, but only if it's > already powered on - please rename the flag to GENPD_FLAG_NO_SUSPEND, > and update the corresponding description of it in the header file. Thanks, naming it ^^ makes more sense :) https://lore.kernel.org/lkml/340a7aafcf0301ff3158a4e211992...@codeaurora.org/ Also we wouldn't want to power on runtime suspended power domains with the NO_SUSPEND flag set, on resume as explained ^^. Do you agree with that as well? Actually no. Instead, I think that deserves a separate flag, as it may very well turn out that resuming can be skipped for other cases than "NO_SUSPEND". Therefore, please add a GENPD_FLAG_NO_RESUME for this. Thanks I'll do that in v2 Kind regards Uffe -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 1/2] PM / Domains: Add GENPD_FLAG_SUSPEND_ON flag
On 2020-08-17 14:14, Ulf Hansson wrote: On Thu, 13 Aug 2020 at 19:26, Sibi Sankar wrote: On 2020-08-13 18:04, Ulf Hansson wrote: > On Wed, 12 Aug 2020 at 19:03, Sibi Sankar wrote: >> >> Uffe, >> Thanks for taking time to review the >> series! >> >> On 2020-08-12 15:15, Ulf Hansson wrote: >> > On Tue, 11 Aug 2020 at 21:03, Sibi Sankar wrote: >> >> >> >> This is for power domains which needs to stay powered on for suspend >> >> but can be powered on/off as part of runtime PM. This flag is aimed at >> >> power domains coupled to remote processors which enter suspend states >> >> independent to that of the application processor. Such power domains >> >> are turned off only on remote processor crash/shutdown. >> > >> > As Kevin also requested, please elaborate more on the use case. >> > >> > Why exactly must the PM domain stay powered on during system suspend? >> > Is there a wakeup configured that needs to be managed - or is there a >> > co-processor/FW behaviour that needs to be obeyed to? >> >> Yes this is a co-processor behavior that >> needs to be obeyed. Specifically application >> processor notifies the Always on Subsystem >> (AOSS) that a particular co-processor is up >> using the power domains exposed by AOSS QMP >> driver. AOSS uses this information to wait >> for the co-processors to suspend before >> starting its sleep sequence. The application >> processor powers off these power domains only >> if the co-processor has crashed or powered >> off. > > Thanks for clarifying! > > Although, can you please elaborate a bit more on the actual use case? > What are the typical co-processor and what drivers are involved in > managing it? The co-processors using the power domains exposed by qcom_aoss driver are modem, audio dsp, compute dsp managed using qcom_q6v5_mss and qcom_q6v5_pas driver. > > As you may know, runtime PM becomes disabled during system suspend of > a device. Which means, if the driver tries to power off the > coprocessor (via calling pm_runtime_put() for example), somewhere in > the system suspend phase of the corresponding device, its attached PM > domain stays powered on when managed by genpd. The drivers aren't really expected do anything during suspend/resume pretty much because the co-processors enter low-power modes independent to that of the application processor. On co-processor crash the remoteproc core does a pm_stay_awake followed by a pm_relax after crash recovery. Okay, thanks again for clarifying. You have convinced me about the need for a new flag to cope with these use cases. Would you mind updating the commit message with some of the information you just provided? Additionally, to make it clear that the flag should be used to keep the PM domain powered on during system suspend, but only if it's already powered on - please rename the flag to GENPD_FLAG_NO_SUSPEND, and update the corresponding description of it in the header file. Thanks, naming it ^^ makes more sense :) https://lore.kernel.org/lkml/340a7aafcf0301ff3158a4e211992...@codeaurora.org/ Also we wouldn't want to power on runtime suspended power domains with the NO_SUSPEND flag set, on resume as explained ^^. Do you agree with that as well? [...] Kind regards Uffe -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 1/2] PM / Domains: Add GENPD_FLAG_SUSPEND_ON flag
On 2020-08-13 18:04, Ulf Hansson wrote:
On Wed, 12 Aug 2020 at 19:03, Sibi Sankar wrote:
Uffe,
Thanks for taking time to review the
series!
On 2020-08-12 15:15, Ulf Hansson wrote:
> On Tue, 11 Aug 2020 at 21:03, Sibi Sankar wrote:
>>
>> This is for power domains which needs to stay powered on for suspend
>> but can be powered on/off as part of runtime PM. This flag is aimed at
>> power domains coupled to remote processors which enter suspend states
>> independent to that of the application processor. Such power domains
>> are turned off only on remote processor crash/shutdown.
>
> As Kevin also requested, please elaborate more on the use case.
>
> Why exactly must the PM domain stay powered on during system suspend?
> Is there a wakeup configured that needs to be managed - or is there a
> co-processor/FW behaviour that needs to be obeyed to?
Yes this is a co-processor behavior that
needs to be obeyed. Specifically application
processor notifies the Always on Subsystem
(AOSS) that a particular co-processor is up
using the power domains exposed by AOSS QMP
driver. AOSS uses this information to wait
for the co-processors to suspend before
starting its sleep sequence. The application
processor powers off these power domains only
if the co-processor has crashed or powered
off.
Thanks for clarifying!
Although, can you please elaborate a bit more on the actual use case?
What are the typical co-processor and what drivers are involved in
managing it?
The co-processors using the power domains
exposed by qcom_aoss driver are modem,
audio dsp, compute dsp managed using
qcom_q6v5_mss and qcom_q6v5_pas driver.
As you may know, runtime PM becomes disabled during system suspend of
a device. Which means, if the driver tries to power off the
coprocessor (via calling pm_runtime_put() for example), somewhere in
the system suspend phase of the corresponding device, its attached PM
domain stays powered on when managed by genpd.
The drivers aren't really expected
do anything during suspend/resume
pretty much because the co-processors
enter low-power modes independent to
that of the application processor. On
co-processor crash the remoteproc core
does a pm_stay_awake followed by a
pm_relax after crash recovery.
Then in the suspend_noirq phase, genpd tries to power off the PM
domain, unless there are wakeups to consider.
Taking the above into account, wouldn't that mean that you potentially
may end up keeping the PM domain powered on, even if it actually can
be powered off in the suspend_noirq phase by genpd?
Kind regards
Uffe
>
>>
>> Signed-off-by: Sibi Sankar
>> ---
>> drivers/base/power/domain.c | 3 ++-
>> include/linux/pm_domain.h | 5 +
>> 2 files changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index 2cb5e04cf86cd..ba78ac4a450d4 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -129,6 +129,7 @@ static const struct genpd_lock_ops genpd_spin_ops
>> = {
>> #define genpd_is_active_wakeup(genpd) (genpd->flags &
>> GENPD_FLAG_ACTIVE_WAKEUP)
>> #define genpd_is_cpu_domain(genpd) (genpd->flags &
>> GENPD_FLAG_CPU_DOMAIN)
>> #define genpd_is_rpm_always_on(genpd) (genpd->flags &
>> GENPD_FLAG_RPM_ALWAYS_ON)
>> +#define genpd_is_suspend_on(genpd) (genpd->flags &
>> GENPD_FLAG_SUSPEND_ON)
>>
>> static inline bool irq_safe_dev_in_no_sleep_domain(struct device
>> *dev,
>> const struct generic_pm_domain *genpd)
>> @@ -949,7 +950,7 @@ static void genpd_sync_power_off(struct
>> generic_pm_domain *genpd, bool use_lock,
>> {
>> struct gpd_link *link;
>>
>> - if (!genpd_status_on(genpd) || genpd_is_always_on(genpd))
>> + if (!genpd_status_on(genpd) || genpd_is_always_on(genpd) ||
>> genpd_is_suspend_on(genpd))
>> return;
>>
>> if (genpd->suspended_count != genpd->device_count
>> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
>> index ee11502a575b0..3002a2d68936a 100644
>> --- a/include/linux/pm_domain.h
>> +++ b/include/linux/pm_domain.h
>> @@ -55,6 +55,10 @@
>> *
>> * GENPD_FLAG_RPM_ALWAYS_ON: Instructs genpd to always keep the PM
>> domain
>> * powered on except for system suspend.
>> + *
>> + * GENPD_FLAG_SUSPEND_ON: Instructs genpd to keep the PM domain
>> powered
>> + * on during suspend and runtime PM
>> controlled
>> + * otherwise.
>> */
>> #define GENPD_FLAG_PM_CLK (1U << 0)
>&g
Re: [PATCH 1/2] PM / Domains: Add GENPD_FLAG_SUSPEND_ON flag
Uffe,
Thanks for taking time to review the
series!
On 2020-08-12 15:15, Ulf Hansson wrote:
On Tue, 11 Aug 2020 at 21:03, Sibi Sankar wrote:
This is for power domains which needs to stay powered on for suspend
but can be powered on/off as part of runtime PM. This flag is aimed at
power domains coupled to remote processors which enter suspend states
independent to that of the application processor. Such power domains
are turned off only on remote processor crash/shutdown.
As Kevin also requested, please elaborate more on the use case.
Why exactly must the PM domain stay powered on during system suspend?
Is there a wakeup configured that needs to be managed - or is there a
co-processor/FW behaviour that needs to be obeyed to?
Yes this is a co-processor behavior that
needs to be obeyed. Specifically application
processor notifies the Always on Subsystem
(AOSS) that a particular co-processor is up
using the power domains exposed by AOSS QMP
driver. AOSS uses this information to wait
for the co-processors to suspend before
starting its sleep sequence. The application
processor powers off these power domains only
if the co-processor has crashed or powered
off.
Kind regards
Uffe
Signed-off-by: Sibi Sankar
---
drivers/base/power/domain.c | 3 ++-
include/linux/pm_domain.h | 5 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 2cb5e04cf86cd..ba78ac4a450d4 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -129,6 +129,7 @@ static const struct genpd_lock_ops genpd_spin_ops
= {
#define genpd_is_active_wakeup(genpd) (genpd->flags &
GENPD_FLAG_ACTIVE_WAKEUP)
#define genpd_is_cpu_domain(genpd) (genpd->flags &
GENPD_FLAG_CPU_DOMAIN)
#define genpd_is_rpm_always_on(genpd) (genpd->flags &
GENPD_FLAG_RPM_ALWAYS_ON)
+#define genpd_is_suspend_on(genpd) (genpd->flags &
GENPD_FLAG_SUSPEND_ON)
static inline bool irq_safe_dev_in_no_sleep_domain(struct device
*dev,
const struct generic_pm_domain *genpd)
@@ -949,7 +950,7 @@ static void genpd_sync_power_off(struct
generic_pm_domain *genpd, bool use_lock,
{
struct gpd_link *link;
- if (!genpd_status_on(genpd) || genpd_is_always_on(genpd))
+ if (!genpd_status_on(genpd) || genpd_is_always_on(genpd) ||
genpd_is_suspend_on(genpd))
return;
if (genpd->suspended_count != genpd->device_count
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index ee11502a575b0..3002a2d68936a 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -55,6 +55,10 @@
*
* GENPD_FLAG_RPM_ALWAYS_ON: Instructs genpd to always keep the PM
domain
* powered on except for system suspend.
+ *
+ * GENPD_FLAG_SUSPEND_ON: Instructs genpd to keep the PM domain
powered
+ * on during suspend and runtime PM
controlled
+ * otherwise.
*/
#define GENPD_FLAG_PM_CLK (1U << 0)
#define GENPD_FLAG_IRQ_SAFE (1U << 1)
@@ -62,6 +66,7 @@
#define GENPD_FLAG_ACTIVE_WAKEUP (1U << 3)
#define GENPD_FLAG_CPU_DOMAIN (1U << 4)
#define GENPD_FLAG_RPM_ALWAYS_ON (1U << 5)
+#define GENPD_FLAG_SUSPEND_ON (1U << 6)
enum gpd_status {
GPD_STATE_ACTIVE = 0, /* PM domain is active */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH 1/2] PM / Domains: Add GENPD_FLAG_SUSPEND_ON flag
Kevin,
Thanks for taking time to review the
series!
On 2020-08-12 05:49, Kevin Hilman wrote:
Sibi Sankar writes:
This is for power domains which needs to stay powered on for suspend
but can be powered on/off as part of runtime PM. This flag is aimed at
power domains coupled to remote processors which enter suspend states
independent to that of the application processor. Such power domains
are turned off only on remote processor crash/shutdown.
Signed-off-by: Sibi Sankar
Seems like a useful use-case, but i think there should be a bit more
description/documentation about what is the expected/desired behavior
during system suspsend when a power-domain with this flag is already
runtime-PM suspended. Similarily, on system resume, what is the
expected/desired behavior?
SUSPEND_ON flag is only aimed at
keeping power domains powered on
across suspend (only if its already
powered on). Also if the power domain
is runtime-PM suspended we wouldn't
want to power it on during resume.
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 0a5afca250d03..547c091618008 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1003,7 +1003,7 @@ static void genpd_sync_power_on(struct
generic_pm_domain *genpd, bool use_lock,
{
struct gpd_link *link;
- if (genpd_status_on(genpd))
+ if (genpd_status_on(genpd) || genpd_is_suspend_on(genpd))
return;
I'll add the ^^ diff in the next
re-spin to prevent power on of
a runtime-PM suspended power
domain.
Kevin
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH 1/2] PM / Domains: Add GENPD_FLAG_SUSPEND_ON flag
Hey Stephen, Thanks for taking time to review the series! On 2020-08-12 03:08, Stephen Boyd wrote: Quoting Sibi Sankar (2020-08-11 12:02:51) diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h index ee11502a575b0..3002a2d68936a 100644 --- a/include/linux/pm_domain.h +++ b/include/linux/pm_domain.h @@ -55,6 +55,10 @@ * * GENPD_FLAG_RPM_ALWAYS_ON: Instructs genpd to always keep the PM domain * powered on except for system suspend. + * + * GENPD_FLAG_SUSPEND_ON: Instructs genpd to keep the PM domain powered + * on during suspend and runtime PM controlled Maybe, "powered on across system suspend (if it is already powered on)" to match the hunk above that talks about system suspend for GENPD_FLAG_RPM_ALWAYS_ON. Otherwise someone may think that this powers on the genpd during suspend or powers it on during runtime suspend. Sure, I'll add ^^ in the next re-spin. + * otherwise. */ #define GENPD_FLAG_PM_CLK (1U << 0) #define GENPD_FLAG_IRQ_SAFE (1U << 1) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH 2/2] soc: qcom: aoss: Use GENPD_FLAG_SUSPEND_ON flag
All the power domains exposed as part of AOSS QMP driver require to stay
powered on for suspend. They are powered on when the remote processors
boots up and powered off on remote processor crash/shutdown. Mark the
power domains with GENPD_FLAG_SUSPEND_ON to model this behavior.
Signed-off-by: Sibi Sankar
---
drivers/soc/qcom/qcom_aoss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
index ed2c687c16b31..5a5b4bf928147 100644
--- a/drivers/soc/qcom/qcom_aoss.c
+++ b/drivers/soc/qcom/qcom_aoss.c
@@ -366,6 +366,7 @@ static int qmp_pd_add(struct 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;
+ res[i].pd.flags = GENPD_FLAG_SUSPEND_ON;
ret = pm_genpd_init([i].pd, NULL, true);
if (ret < 0) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 1/2] PM / Domains: Add GENPD_FLAG_SUSPEND_ON flag
This is for power domains which needs to stay powered on for suspend
but can be powered on/off as part of runtime PM. This flag is aimed at
power domains coupled to remote processors which enter suspend states
independent to that of the application processor. Such power domains
are turned off only on remote processor crash/shutdown.
Signed-off-by: Sibi Sankar
---
drivers/base/power/domain.c | 3 ++-
include/linux/pm_domain.h | 5 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 2cb5e04cf86cd..ba78ac4a450d4 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -129,6 +129,7 @@ static const struct genpd_lock_ops genpd_spin_ops = {
#define genpd_is_active_wakeup(genpd) (genpd->flags &
GENPD_FLAG_ACTIVE_WAKEUP)
#define genpd_is_cpu_domain(genpd) (genpd->flags & GENPD_FLAG_CPU_DOMAIN)
#define genpd_is_rpm_always_on(genpd) (genpd->flags &
GENPD_FLAG_RPM_ALWAYS_ON)
+#define genpd_is_suspend_on(genpd) (genpd->flags & GENPD_FLAG_SUSPEND_ON)
static inline bool irq_safe_dev_in_no_sleep_domain(struct device *dev,
const struct generic_pm_domain *genpd)
@@ -949,7 +950,7 @@ static void genpd_sync_power_off(struct generic_pm_domain
*genpd, bool use_lock,
{
struct gpd_link *link;
- if (!genpd_status_on(genpd) || genpd_is_always_on(genpd))
+ if (!genpd_status_on(genpd) || genpd_is_always_on(genpd) ||
genpd_is_suspend_on(genpd))
return;
if (genpd->suspended_count != genpd->device_count
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index ee11502a575b0..3002a2d68936a 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -55,6 +55,10 @@
*
* GENPD_FLAG_RPM_ALWAYS_ON: Instructs genpd to always keep the PM domain
* powered on except for system suspend.
+ *
+ * GENPD_FLAG_SUSPEND_ON: Instructs genpd to keep the PM domain powered
+ * on during suspend and runtime PM controlled
+ * otherwise.
*/
#define GENPD_FLAG_PM_CLK (1U << 0)
#define GENPD_FLAG_IRQ_SAFE (1U << 1)
@@ -62,6 +66,7 @@
#define GENPD_FLAG_ACTIVE_WAKEUP (1U << 3)
#define GENPD_FLAG_CPU_DOMAIN (1U << 4)
#define GENPD_FLAG_RPM_ALWAYS_ON (1U << 5)
+#define GENPD_FLAG_SUSPEND_ON (1U << 6)
enum gpd_status {
GPD_STATE_ACTIVE = 0, /* PM domain is active */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH] opp: Fix dev_pm_opp_set_rate() to not return early
On 2020-08-10 12:36, Rajendra Nayak wrote:
dev_pm_opp_set_rate() can now be called with freq = 0 inorder
to either drop performance or bandwidth votes or to disable
regulators on platforms which support them.
In such cases, a subsequent call to dev_pm_opp_set_rate() with
the same frequency ends up returning early because 'old_freq == freq'
Instead make it fall through and put back the dropped performance
and bandwidth votes and/or enable back the regulators.
Fixes: cd7ea582 ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to
drop performance votes")
Reported-by: Sajida Bhanu
Signed-off-by: Rajendra Nayak
Reviewed-by: Sibi Sankar
---
drivers/opp/core.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 0c8c74a..a994f30 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -901,6 +901,9 @@ int dev_pm_opp_set_rate(struct device *dev,
unsigned long target_freq)
/* Return early if nothing to do */
if (old_freq == freq) {
+ if (opp_table->required_opp_tables || opp_table->regulators ||
+ opp_table->paths)
+ goto skip_clk_only;
dev_dbg(dev, "%s: old/new frequencies (%lu Hz) are same, nothing to
do\n",
__func__, freq);
ret = 0;
@@ -919,6 +922,7 @@ int dev_pm_opp_set_rate(struct device *dev,
unsigned long target_freq)
goto put_opp_table;
}
+skip_clk_only:
temp_freq = old_freq;
old_opp = _find_freq_ceil(opp_table, _freq);
if (IS_ERR(old_opp)) {
@@ -954,8 +958,10 @@ int dev_pm_opp_set_rate(struct device *dev,
unsigned long target_freq)
IS_ERR(old_opp) ? NULL :
old_opp->supplies,
opp->supplies);
} else {
+ ret = 0;
/* Only frequency scaling */
- ret = _generic_set_opp_clk_only(dev, clk, freq);
+ if (freq != old_freq)
+ ret = _generic_set_opp_clk_only(dev, clk, freq);
}
/* Scaling down? Configure required OPPs after frequency */
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH 1/2] soc: qcom: aoss: Don't wait for IRQ if we might be in suspend/resume noirq
On 2020-08-06 04:32, Stephen Boyd wrote: +Sibi who wrote the code Quoting Doug Anderson (2020-08-05 13:24:06) On Wed, Aug 5, 2020 at 10:36 AM Stephen Boyd wrote: > > Why is the genpd being powered off at all? It looks like the driver is > written in a way that it doesn't expect this to happen. See where > adsp_pds_disable() is called from. Looks like the remoteproc "stop" > callback should be called or the driver should be detached. > > It sort of looks like the genpd is expected to be at the max level all > the time (it sets INT_MAX in adsp_pds_enable(), cool). In general in Linux there are some things that, at suspend time, get done behind a driver's back. The regulator API, for instance, allows for regulators to be turned off in suspend even if a driver leaves them on. Sure, it's good practice for a driver to be explicit but the regulator suspend states do allow for the more heavy-handed approach. I guess I assume that genpd is a bit similar. If a driver leaves a genpd on all the time then it will still be turned off at suspend time and then turned back on at resume time. It seems like it must be part of the genpd API. Specifically genpd_sync_power_off() says: "Check if the given PM domain can be powered off (during system suspend or hibernation) and do that if so." That makes it seem like it's how genpd works. Reading all the descriptions of things like GENPD_FLAG_ALWAYS_ON, GENPD_FLAG_ACTIVE_WAKEUP, GENPD_FLAG_RPM_ALWAYS_ON makes me even more convinced that it's normal (unless otherwise specified) for genpds to get turned off in suspend even if a driver just blindly left them on. Presumably if this "modem" genpd is supposed to stay on in suspend time it should have been marked "always on"? I'd guess we'd need to add "GENPD_FLAG_ALWAYS_ON" in some (or all?) cases in qmp_pd_add() if this was true? Agreed. I can't read the mind of Sibi so I can only guess that Sibi wasn't expecting this behavior by reading the driver structure. That could be a wrong assumption. > Maybe we need to > add some sort of suspend hooks to the remote proc driver instead? Where > those suspend hooks are called earlier and drop the genpd performance > state request but otherwise leave it enabled across suspend? I think you're saying: a) You think it's a bug today that the "modem" genpd is being powered off in suspend. Any evidence to back this up? b) Assuming it's a bug today, we should mark the "modem" as GENPD_FLAG_ALWAYS_ON. c) If there are genpds that sometimes should be left on in suspend but sometimes not (and that doesn't match up with what GENPD_FLAG_ACTIVE_WAKEUP does), then we'd have to pass GENPD_FLAG_ALWAYS_ON as a flag and then add suspend hooks to make the decision for us. Doug/Stephen, Yes this is a bug, we wouldn't want to disable aoss_qmp genpd for modem during suspend (when the modem is running). The qmp send for modem is the primary means through which aoss determines whether to wait for modem before proceeding to sleep. So looks like updating the flag with GENPD_FLAG_ACTIVE_WAKEUP is the way to go. But introducing another flag that doesn't touch genpd's during suspend/resume should also work. Did I understand that correctly? ...or are you suggesting that we work around the fact that qmp_pd_power_off() can't be called at "noirq" time by forcing it to suspend earlier? ...or am I just totally confused and you meant something else? > I know this isn't clearing the land mine that is calling this code from > noirq phase of suspend, but I'm just looking at the driver and thinking > that it never expected to be called from this phase of suspend to begin > with. You're saying that qmp_pd_power_off() wasn't expecting to be called from the noirq phase of suspend? Sure, I guess not given the bug. ...but once we fix the bug, it works fine, doesn't it? ...and it appears that it's part of the genpd API to be able to be called from the noirq phase. To me that means that, even if we were supposed to be keeping this particular PD on during suspend we should take my patch. So the summary is: I still think my patch is correct, but I could certainly still be convinced otherwise. I'm trying to say that the driver looks like it expects to power off the genpd in the adsp_stop() callback. That same callback sends some sort of message to the modem saying that it is being stopped (see qcom_q6v5_request_stop()). Turning the performance state down, or turning the power domain off completely, without telling the modem that it's happening like as is done in adsp_stop() looks wrong. But who knows, maybe the modem is happy with that and doesn't care? In general, the whole thing looks weird to me because I would expect the modem to take care of its own power requirements, including this "load_state" one. Anyway, I hope Sibi can clarify what's going on. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 1/2] soc: qcom: aoss: Don't wait for IRQ if we might be in suspend/resume noirq
On 2020-08-06 22:40, Doug Anderson wrote: Hi, On Thu, Aug 6, 2020 at 7:36 AM Sibi Sankar wrote: On 2020-08-06 04:32, Stephen Boyd wrote: > +Sibi who wrote the code > > Quoting Doug Anderson (2020-08-05 13:24:06) >> >> On Wed, Aug 5, 2020 at 10:36 AM Stephen Boyd >> wrote: >> > >> > Why is the genpd being powered off at all? It looks like the driver is >> > written in a way that it doesn't expect this to happen. See where >> > adsp_pds_disable() is called from. Looks like the remoteproc "stop" >> > callback should be called or the driver should be detached. >> > >> > It sort of looks like the genpd is expected to be at the max level all >> > the time (it sets INT_MAX in adsp_pds_enable(), cool). >> >> In general in Linux there are some things that, at suspend time, get >> done behind a driver's back. The regulator API, for instance, allows >> for regulators to be turned off in suspend even if a driver leaves >> them on. Sure, it's good practice for a driver to be explicit but the >> regulator suspend states do allow for the more heavy-handed approach. >> >> I guess I assume that genpd is a bit similar. If a driver leaves a >> genpd on all the time then it will still be turned off at suspend time >> and then turned back on at resume time. It seems like it must be part >> of the genpd API. Specifically genpd_sync_power_off() says: "Check if >> the given PM domain can be powered off (during system suspend or >> hibernation) and do that if so." That makes it seem like it's how >> genpd works. >> >> Reading all the descriptions of things like GENPD_FLAG_ALWAYS_ON, >> GENPD_FLAG_ACTIVE_WAKEUP, GENPD_FLAG_RPM_ALWAYS_ON makes me even more >> convinced that it's normal (unless otherwise specified) for genpds to >> get turned off in suspend even if a driver just blindly left them on. >> >> Presumably if this "modem" genpd is supposed to stay on in suspend >> time it should have been marked "always on"? I'd guess we'd need to >> add "GENPD_FLAG_ALWAYS_ON" in some (or all?) cases in qmp_pd_add() if >> this was true? > > Agreed. I can't read the mind of Sibi so I can only guess that Sibi > wasn't expecting this behavior by reading the driver structure. That > could be a wrong assumption. > >> >> >> > Maybe we need to >> > add some sort of suspend hooks to the remote proc driver instead? Where >> > those suspend hooks are called earlier and drop the genpd performance >> > state request but otherwise leave it enabled across suspend? >> >> I think you're saying: >> >> a) You think it's a bug today that the "modem" genpd is being powered >> off in suspend. Any evidence to back this up? >> >> b) Assuming it's a bug today, we should mark the "modem" as >> GENPD_FLAG_ALWAYS_ON. >> >> c) If there are genpds that sometimes should be left on in suspend but >> sometimes not (and that doesn't match up with what >> GENPD_FLAG_ACTIVE_WAKEUP does), then we'd have to pass >> GENPD_FLAG_ALWAYS_ON as a flag and then add suspend hooks to make the >> decision for us. Doug/Stephen, Yes this is a bug, we wouldn't want to disable aoss_qmp genpd for modem during suspend (when the modem is running). The qmp send for modem is the primary means through which aoss determines whether to wait for modem before proceeding to sleep. So looks like updating the flag with GENPD_FLAG_ACTIVE_WAKEUP is the way to go. But introducing another flag that doesn't touch genpd's during suspend/resume should also work. OK, sounds good. As per out-of-band conversation: * You'll plan to post a patch updating the flag. * There's still nothing here that says my patch is the wrong thing to do also. It seems like genpd poweroff routine are expected to be able to run at "noirq" time so we should make sure we are able to do that. I'm also curious: my patch doesn't affect the behavior. The genpd would be powered off with or without my patch, my patch just removes a pointless 1 second delay. Therefore I guess today there is some type of bug because the genpd is being turned off. What would be the visible impact of that bug? ...or is it somehow masked by something else keeping this power on so it wasn't an issue right now? I've been told AOSS decides to wait for modem suspend if its been notified that modem is on through qmp_send. AFAIK we never ran into this because AOSS sleep sequence starts after xo-shutdown which wont be reached in the presence of active rpmh votes from modem. Regardless we definitely want this genpd left untouched during suspend/resume. -Doug -Doug -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
[PATCH 3/7] interconnect: qcom: Lay the groundwork for adding EPSS support
Lay the groundwork for adding Epoch Subsystem (EPSS) L3 support on
SM8250.
Signed-off-by: Sibi Sankar
---
drivers/interconnect/qcom/osm-l3.c | 37 +-
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/drivers/interconnect/qcom/osm-l3.c
b/drivers/interconnect/qcom/osm-l3.c
index 00831c33e0fe5..27c9ece52efda 100644
--- a/drivers/interconnect/qcom/osm-l3.c
+++ b/drivers/interconnect/qcom/osm-l3.c
@@ -21,13 +21,13 @@
#define LUT_MAX_ENTRIES40U
#define LUT_SRCGENMASK(31, 30)
#define LUT_L_VAL GENMASK(7, 0)
-#define LUT_ROW_SIZE 32
#define CLK_HW_DIV 2
-/* Register offsets */
+/* OSM Register offsets */
#define REG_ENABLE 0x0
-#define REG_FREQ_LUT 0x110
-#define REG_PERF_STATE 0x920
+#define OSM_LUT_ROW_SIZE 32
+#define OSM_REG_FREQ_LUT 0x110
+#define OSM_REG_PERF_STATE 0x920
#define OSM_L3_MAX_LINKS 1
@@ -37,6 +37,7 @@
struct qcom_osm_l3_icc_provider {
void __iomem *base;
unsigned int max_state;
+ unsigned int reg_perf_state;
unsigned long lut_tables[LUT_MAX_ENTRIES];
struct icc_provider provider;
};
@@ -60,6 +61,9 @@ struct qcom_icc_node {
struct qcom_icc_desc {
struct qcom_icc_node **nodes;
size_t num_nodes;
+ unsigned int lut_row_size;
+ unsigned int reg_freq_lut;
+ unsigned int reg_perf_state;
};
#define DEFINE_QNODE(_name, _id, _buswidth, ...) \
@@ -82,6 +86,9 @@ static struct qcom_icc_node *sdm845_osm_l3_nodes[] = {
static const struct qcom_icc_desc sdm845_icc_osm_l3 = {
.nodes = sdm845_osm_l3_nodes,
.num_nodes = ARRAY_SIZE(sdm845_osm_l3_nodes),
+ .lut_row_size = OSM_LUT_ROW_SIZE,
+ .reg_freq_lut = OSM_REG_FREQ_LUT,
+ .reg_perf_state = OSM_REG_PERF_STATE,
};
DEFINE_QNODE(sc7180_osm_apps_l3, SC7180_MASTER_OSM_L3_APPS, 16,
SC7180_SLAVE_OSM_L3);
@@ -95,6 +102,9 @@ static struct qcom_icc_node *sc7180_osm_l3_nodes[] = {
static const struct qcom_icc_desc sc7180_icc_osm_l3 = {
.nodes = sc7180_osm_l3_nodes,
.num_nodes = ARRAY_SIZE(sc7180_osm_l3_nodes),
+ .lut_row_size = OSM_LUT_ROW_SIZE,
+ .reg_freq_lut = OSM_REG_FREQ_LUT,
+ .reg_perf_state = OSM_REG_PERF_STATE,
};
DEFINE_QNODE(sm8150_osm_apps_l3, SM8150_MASTER_OSM_L3_APPS, 32,
SM8150_SLAVE_OSM_L3);
@@ -108,6 +118,9 @@ static struct qcom_icc_node *sm8150_osm_l3_nodes[] = {
static const struct qcom_icc_desc sm8150_icc_osm_l3 = {
.nodes = sm8150_osm_l3_nodes,
.num_nodes = ARRAY_SIZE(sm8150_osm_l3_nodes),
+ .lut_row_size = OSM_LUT_ROW_SIZE,
+ .reg_freq_lut = OSM_REG_FREQ_LUT,
+ .reg_perf_state = OSM_REG_PERF_STATE,
};
static int qcom_icc_set(struct icc_node *src, struct icc_node *dst)
@@ -138,7 +151,7 @@ static int qcom_icc_set(struct icc_node *src, struct
icc_node *dst)
break;
}
- writel_relaxed(index, qp->base + REG_PERF_STATE);
+ writel_relaxed(index, qp->base + qp->reg_perf_state);
return 0;
}
@@ -193,9 +206,15 @@ static int qcom_osm_l3_probe(struct platform_device *pdev)
return -ENODEV;
}
+ desc = device_get_match_data(>dev);
+ if (!desc)
+ return -EINVAL;
+
+ qp->reg_perf_state = desc->reg_perf_state;
+
for (i = 0; i < LUT_MAX_ENTRIES; i++) {
- info = readl_relaxed(qp->base + REG_FREQ_LUT +
-i * LUT_ROW_SIZE);
+ info = readl_relaxed(qp->base + desc->reg_freq_lut +
+i * desc->lut_row_size);
src = FIELD_GET(LUT_SRC, info);
lval = FIELD_GET(LUT_L_VAL, info);
if (src)
@@ -214,10 +233,6 @@ static int qcom_osm_l3_probe(struct platform_device *pdev)
}
qp->max_state = i;
- desc = device_get_match_data(>dev);
- if (!desc)
- return -EINVAL;
-
qnodes = desc->nodes;
num_nodes = desc->num_nodes;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 7/7] arm64: dts: qcom: sm8250: Add EPSS L3 interconnect provider
Add Epoch Subsystem (EPSS) L3 interconnect provider node on SM8250
SoCs.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 73f02f712d035..2bcdb7a3b9fef 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2150,6 +2151,16 @@ apps_bcm_voter: bcm_voter {
compatible = "qcom,bcm-voter";
};
};
+
+ epss_l3: interconnect@18591000 {
+ compatible = "qcom,sm8250-epss-l3";
+ reg = <0 0x1859 0 0x1000>;
+
+ clocks = < RPMH_CXO_CLK>, < GPLL0>;
+ clock-names = "xo", "alternate";
+
+ #interconnect-cells = <1>;
+ };
};
timer {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 6/7] arm64: dts: qcom: sm8150: Add OSM L3 interconnect provider
Add Operation State Manager (OSM) L3 interconnect provider node on
SM8150 SoCs.
Signed-off-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 0f6d84e8fd299..8563afd205ee9 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1184,6 +1185,16 @@ apps_bcm_voter: bcm_voter {
};
};
+ osm_l3: interconnect@18321000 {
+ compatible = "qcom,sm8150-osm-l3";
+ reg = <0 0x18321000 0 0x1400>;
+
+ clocks = < RPMH_CXO_CLK>, < GPLL0>;
+ clock-names = "xo", "alternate";
+
+ #interconnect-cells = <1>;
+ };
+
cpufreq_hw: cpufreq@18323000 {
compatible = "qcom,cpufreq-hw";
reg = <0 0x18323000 0 0x1400>, <0 0x18325800 0 0x1400>,
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 1/7] dt-bindings: interconnect: Add OSM L3 DT binding on SM8150
Add Operation State Manager (OSM) L3 interconnect provider binding on SM8150 SoCs. Signed-off-by: Sibi Sankar --- Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index 91f70c9067d12..b6945c11eb46b 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -19,6 +19,7 @@ properties: enum: - qcom,sc7180-osm-l3 - qcom,sdm845-osm-l3 + - qcom,sm8150-osm-l3 reg: maxItems: 1 -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 5/7] interconnect: qcom: Add EPSS L3 support on SM8250
Add Epoch Subsystem (EPSS) L3 interconnect provider support on
SM8250 SoCs.
Signed-off-by: Sibi Sankar
---
drivers/interconnect/qcom/osm-l3.c | 23 +++
drivers/interconnect/qcom/sm8250.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/interconnect/qcom/osm-l3.c
b/drivers/interconnect/qcom/osm-l3.c
index 27c9ece52efda..cbf4ef04491df 100644
--- a/drivers/interconnect/qcom/osm-l3.c
+++ b/drivers/interconnect/qcom/osm-l3.c
@@ -17,6 +17,7 @@
#include "sc7180.h"
#include "sdm845.h"
#include "sm8150.h"
+#include "sm8250.h"
#define LUT_MAX_ENTRIES40U
#define LUT_SRCGENMASK(31, 30)
@@ -29,6 +30,11 @@
#define OSM_REG_FREQ_LUT 0x110
#define OSM_REG_PERF_STATE 0x920
+/* EPSS Register offsets */
+#define EPSS_LUT_ROW_SIZE 4
+#define EPSS_REG_FREQ_LUT 0x100
+#define EPSS_REG_PERF_STATE0x320
+
#define OSM_L3_MAX_LINKS 1
#define to_qcom_provider(_provider) \
@@ -123,6 +129,22 @@ static const struct qcom_icc_desc sm8150_icc_osm_l3 = {
.reg_perf_state = OSM_REG_PERF_STATE,
};
+DEFINE_QNODE(sm8250_epss_apps_l3, SM8250_MASTER_EPSS_L3_APPS, 32,
SM8250_SLAVE_EPSS_L3);
+DEFINE_QNODE(sm8250_epss_l3, SM8250_SLAVE_EPSS_L3, 32);
+
+static struct qcom_icc_node *sm8250_epss_l3_nodes[] = {
+ [MASTER_EPSS_L3_APPS] = _epss_apps_l3,
+ [SLAVE_EPSS_L3_SHARED] = _epss_l3,
+};
+
+static const struct qcom_icc_desc sm8250_icc_epss_l3 = {
+ .nodes = sm8250_epss_l3_nodes,
+ .num_nodes = ARRAY_SIZE(sm8250_epss_l3_nodes),
+ .lut_row_size = EPSS_LUT_ROW_SIZE,
+ .reg_freq_lut = EPSS_REG_FREQ_LUT,
+ .reg_perf_state = EPSS_REG_PERF_STATE,
+};
+
static int qcom_icc_set(struct icc_node *src, struct icc_node *dst)
{
struct qcom_osm_l3_icc_provider *qp;
@@ -288,6 +310,7 @@ static const struct of_device_id osm_l3_of_match[] = {
{ .compatible = "qcom,sc7180-osm-l3", .data = _icc_osm_l3 },
{ .compatible = "qcom,sdm845-osm-l3", .data = _icc_osm_l3 },
{ .compatible = "qcom,sm8150-osm-l3", .data = _icc_osm_l3 },
+ { .compatible = "qcom,sm8250-epss-l3", .data = _icc_epss_l3 },
{ }
};
MODULE_DEVICE_TABLE(of, osm_l3_of_match);
diff --git a/drivers/interconnect/qcom/sm8250.h
b/drivers/interconnect/qcom/sm8250.h
index 7eb6c709c30d1..b31fb431a20fc 100644
--- a/drivers/interconnect/qcom/sm8250.h
+++ b/drivers/interconnect/qcom/sm8250.h
@@ -158,5 +158,7 @@
#define SM8250_SLAVE_VSENSE_CTRL_CFG 147
#define SM8250_SNOC_CNOC_MAS 148
#define SM8250_SNOC_CNOC_SLV 149
+#define SM8250_MASTER_EPSS_L3_APPS 150
+#define SM8250_SLAVE_EPSS_L3 151
#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 0/7] Add L3 provider support for SM8150/SM8250
Add Operation State Manager (OSM) L3 provider support on SM8150 and Epoch Subsystem (EPSS) L3 provider support on SM8250 SoCs. Depends on: https://patchwork.kernel.org/cover/11687925/ Sibi Sankar (7): dt-bindings: interconnect: Add OSM L3 DT binding on SM8150 interconnect: qcom: Add OSM L3 support on SM8150 interconnect: qcom: Lay the groundwork for adding EPSS support dt-bindings: interconnect: Add EPSS L3 DT binding on SM8250 interconnect: qcom: Add EPSS L3 support on SM8250 arm64: dts: qcom: sm8150: Add OSM L3 interconnect provider arm64: dts: qcom: sm8250: Add EPSS L3 interconnect provider .../bindings/interconnect/qcom,osm-l3.yaml| 2 + arch/arm64/boot/dts/qcom/sm8150.dtsi | 11 +++ arch/arm64/boot/dts/qcom/sm8250.dtsi | 11 +++ drivers/interconnect/qcom/osm-l3.c| 75 --- drivers/interconnect/qcom/sm8150.h| 2 + drivers/interconnect/qcom/sm8250.h| 2 + .../dt-bindings/interconnect/qcom,osm-l3.h| 3 + 7 files changed, 95 insertions(+), 11 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH 2/7] interconnect: qcom: Add OSM L3 support on SM8150
Add Operation State Manager (OSM) L3 interconnect provider support on
SM8150 SoCs.
Signed-off-by: Sibi Sankar
---
drivers/interconnect/qcom/osm-l3.c | 15 +++
drivers/interconnect/qcom/sm8150.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/interconnect/qcom/osm-l3.c
b/drivers/interconnect/qcom/osm-l3.c
index 96fb9ff5ff2e8..00831c33e0fe5 100644
--- a/drivers/interconnect/qcom/osm-l3.c
+++ b/drivers/interconnect/qcom/osm-l3.c
@@ -16,6 +16,7 @@
#include "sc7180.h"
#include "sdm845.h"
+#include "sm8150.h"
#define LUT_MAX_ENTRIES40U
#define LUT_SRCGENMASK(31, 30)
@@ -96,6 +97,19 @@ static const struct qcom_icc_desc sc7180_icc_osm_l3 = {
.num_nodes = ARRAY_SIZE(sc7180_osm_l3_nodes),
};
+DEFINE_QNODE(sm8150_osm_apps_l3, SM8150_MASTER_OSM_L3_APPS, 32,
SM8150_SLAVE_OSM_L3);
+DEFINE_QNODE(sm8150_osm_l3, SM8150_SLAVE_OSM_L3, 32);
+
+static struct qcom_icc_node *sm8150_osm_l3_nodes[] = {
+ [MASTER_OSM_L3_APPS] = _osm_apps_l3,
+ [SLAVE_OSM_L3] = _osm_l3,
+};
+
+static const struct qcom_icc_desc sm8150_icc_osm_l3 = {
+ .nodes = sm8150_osm_l3_nodes,
+ .num_nodes = ARRAY_SIZE(sm8150_osm_l3_nodes),
+};
+
static int qcom_icc_set(struct icc_node *src, struct icc_node *dst)
{
struct qcom_osm_l3_icc_provider *qp;
@@ -258,6 +272,7 @@ static int qcom_osm_l3_probe(struct platform_device *pdev)
static const struct of_device_id osm_l3_of_match[] = {
{ .compatible = "qcom,sc7180-osm-l3", .data = _icc_osm_l3 },
{ .compatible = "qcom,sdm845-osm-l3", .data = _icc_osm_l3 },
+ { .compatible = "qcom,sm8150-osm-l3", .data = _icc_osm_l3 },
{ }
};
MODULE_DEVICE_TABLE(of, osm_l3_of_match);
diff --git a/drivers/interconnect/qcom/sm8150.h
b/drivers/interconnect/qcom/sm8150.h
index 3e01ac76ae1db..97996f64d799c 100644
--- a/drivers/interconnect/qcom/sm8150.h
+++ b/drivers/interconnect/qcom/sm8150.h
@@ -148,5 +148,7 @@
#define SM8150_SLAVE_VSENSE_CTRL_CFG 137
#define SM8150_SNOC_CNOC_MAS 138
#define SM8150_SNOC_CNOC_SLV 139
+#define SM8150_MASTER_OSM_L3_APPS 140
+#define SM8150_SLAVE_OSM_L3141
#endif
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH 4/7] dt-bindings: interconnect: Add EPSS L3 DT binding on SM8250
Add Epoch Subsystem (EPSS) L3 interconnect provider binding on SM8250 SoCs. Signed-off-by: Sibi Sankar --- .../devicetree/bindings/interconnect/qcom,osm-l3.yaml | 1 + include/dt-bindings/interconnect/qcom,osm-l3.h | 3 +++ 2 files changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index b6945c11eb46b..d6a95c3cb26f2 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -20,6 +20,7 @@ properties: - qcom,sc7180-osm-l3 - qcom,sdm845-osm-l3 - qcom,sm8150-osm-l3 + - qcom,sm8250-epss-l3 reg: maxItems: 1 diff --git a/include/dt-bindings/interconnect/qcom,osm-l3.h b/include/dt-bindings/interconnect/qcom,osm-l3.h index 54858ff7674d7..61ef649ae5655 100644 --- a/include/dt-bindings/interconnect/qcom,osm-l3.h +++ b/include/dt-bindings/interconnect/qcom,osm-l3.h @@ -9,4 +9,7 @@ #define MASTER_OSM_L3_APPS 0 #define SLAVE_OSM_L3 1 +#define MASTER_EPSS_L3_APPS0 +#define SLAVE_EPSS_L3_SHARED 1 + #endif -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v3 7/7] arm64: dts: qcom: sm8250: add interconnect nodes
On 2020-07-28 08:08, Jonathan Marek wrote:
Add the interconnect dts nodes for sm8250.
Signed-off-by: Jonathan Marek
Reviewed-by: Sibi Sankar
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 82
1 file changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 636e2196138c..945bd4a9d640 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -978,6 +979,55 @@ spi13: spi@a94000 {
};
};
+ config_noc: interconnect@150 {
+ compatible = "qcom,sm8250-config-noc";
+ reg = <0 0x0150 0 0xa580>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ system_noc: interconnect@162 {
+ compatible = "qcom,sm8250-system-noc";
+ reg = <0 0x0162 0 0x1c200>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ mc_virt: interconnect@163d000 {
+ compatible = "qcom,sm8250-mc-virt";
+ reg = <0 0x0163d000 0 0x1000>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e {
+ compatible = "qcom,sm8250-aggre1-noc";
+ reg = <0 0x016e 0 0x1f180>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre2_noc: interconnect@170 {
+ compatible = "qcom,sm8250-aggre2-noc";
+ reg = <0 0x0170 0 0x33000>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ compute_noc: interconnect@1733000 {
+ compatible = "qcom,sm8250-compute-noc";
+ reg = <0 0x01733000 0 0xa180>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ mmss_noc: interconnect@174 {
+ compatible = "qcom,sm8250-mmss-noc";
+ reg = <0 0x0174 0 0x1f080>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,sm8250-ufshc", "qcom,ufshc",
"jedec,ufs-2.0";
@@ -1050,6 +1100,13 @@ ufs_mem_phy_lanes: lanes@1d87400 {
};
};
+ ipa_virt: interconnect@1e0 {
+ compatible = "qcom,sm8250-ipa-virt";
+ reg = <0 0x01e0 0 0x1000>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
tcsr_mutex_regs: syscon@1f4 {
compatible = "syscon";
reg = <0x0 0x01f4 0x0 0x4>;
@@ -1364,6 +1421,27 @@ usb_2_ssphy: lane@88eb200 {
};
};
+ dc_noc: interconnect@90c {
+ compatible = "qcom,sm8250-dc-noc";
+ reg = <0 0x090c 0 0x4200>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ gem_noc: interconnect@910 {
+ compatible = "qcom,sm8250-gem-noc";
+ reg = <0 0x0910 0 0xb4000>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ npu_noc: interconnect@999 {
+ compatible = "qcom,sm8250-npu-noc";
+ reg = <0 0x0999 0 0x1600>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
usb_1: usb@a6f8800 {
compatible = "qcom,sm8250-dwc3", "qcom,dwc3";
reg = <0 0x0a6f8800 0 0x400>;
@@ -2359,6 +2437,10 @@ rpmhpd_
Re: [PATCH v3 6/7] arm64: dts: qcom: sm8150: add interconnect nodes
On 2020-07-28 08:08, Jonathan Marek wrote:
Add the interconnect dts nodes for sm8150.
Signed-off-by: Jonathan Marek
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 82
1 file changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 33ff99132f4f..e4689c27224b 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
/ {
@@ -440,6 +441,55 @@ uart2: serial@a9 {
};
};
+ config_noc: interconnect@150 {
+ compatible = "qcom,sm8150-config-noc";
+ reg = <0 0x0150 0 0x7400>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ system_noc: interconnect@162 {
+ compatible = "qcom,sm8150-system-noc";
+ reg = <0 0x0162 0 0x19400>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ mc_virt: interconnect@163a000 {
+ compatible = "qcom,sm8150-mc-virt";
+ reg = <0 0x0163a000 0 0x1000>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e {
+ compatible = "qcom,sm8150-aggre1-noc";
+ reg = <0 0x016e 0 0xd080>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre2_noc: interconnect@170 {
+ compatible = "qcom,sm8150-aggre2-noc";
+ reg = <0 0x0170 0 0x2>;
Though aggre2_noc might need a
larger space in the future lets
lands ^^ for now.
Reviewed-by: Sibi Sankar
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ compute_noc: interconnect@172 {
+ compatible = "qcom,sm8150-compute-noc";
+ reg = <0 0x0172 0 0x7000>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ mmss_noc: interconnect@174 {
+ compatible = "qcom,sm8150-mmss-noc";
+ reg = <0 0x0174 0 0x1c100>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,sm8150-ufshc", "qcom,ufshc",
"jedec,ufs-2.0";
@@ -510,6 +560,13 @@ ufs_mem_phy_lanes: lanes@1d87400 {
};
};
+ ipa_virt: interconnect@1e0 {
+ compatible = "qcom,sm8150-ipa-virt";
+ reg = <0 0x01e0 0 0x1000>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
tcsr_mutex_regs: syscon@1f4 {
compatible = "syscon";
reg = <0x0 0x01f4 0x0 0x4>;
@@ -860,6 +917,20 @@ usb_2_ssphy: lane@88eb200 {
};
};
+ dc_noc: interconnect@916 {
+ compatible = "qcom,sm8150-dc-noc";
+ reg = <0 0x0916 0 0x3200>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ gem_noc: interconnect@968 {
+ compatible = "qcom,sm8150-gem-noc";
+ reg = <0 0x0968 0 0x3e200>;
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
usb_1: usb@a6f8800 {
compatible = "qcom,sm8150-dwc3", "qcom,dwc3";
reg = <0 0x0a6f8800 0 0x400>;
@@ -950,6 +1021,13 @@ usb_2_dwc3: dwc3@a80 {
};
};
+ camnoc_virt: interconnect@ac0 {
+ compatible = "qcom,sm8150-camnoc-virt";
+ reg = <0 0x0ac
Re: [PATCH v3 5/7] interconnect: qcom: Add SM8250 interconnect provider driver
On 2020-07-28 08:08, Jonathan Marek wrote: Add driver for the Qualcomm interconnect buses found in SM8250 based platforms. The topology consists of several NoCs that are controlled by a remote processor that collects the aggregated bandwidth for each master-slave pairs. Based on SC7180 driver and generated from downstream dts. Signed-off-by: Jonathan Marek Reviewed-by: Sibi Sankar --- drivers/interconnect/qcom/Kconfig | 10 + drivers/interconnect/qcom/Makefile | 2 + drivers/interconnect/qcom/sm8250.c | 651 + drivers/interconnect/qcom/sm8250.h | 162 +++ 4 files changed, 825 insertions(+) create mode 100644 drivers/interconnect/qcom/sm8250.c create mode 100644 drivers/interconnect/qcom/sm8250.h diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig index 25486de5a38d..a8f93ba265f8 100644 --- a/drivers/interconnect/qcom/Kconfig +++ b/drivers/interconnect/qcom/Kconfig @@ -75,5 +75,15 @@ config INTERCONNECT_QCOM_SM8150 This is a driver for the Qualcomm Network-on-Chip on sm8150-based platforms. +config INTERCONNECT_QCOM_SM8250 + tristate "Qualcomm SM8250 interconnect driver" + depends on INTERCONNECT_QCOM + depends on (QCOM_RPMH && QCOM_COMMAND_DB && OF) || COMPILE_TEST + select INTERCONNECT_QCOM_RPMH + select INTERCONNECT_QCOM_BCM_VOTER + help + This is a driver for the Qualcomm Network-on-Chip on sm8250-based + platforms. + config INTERCONNECT_QCOM_SMD_RPM tristate diff --git a/drivers/interconnect/qcom/Makefile b/drivers/interconnect/qcom/Makefile index 1702ece67dc5..cf628f7990cd 100644 --- a/drivers/interconnect/qcom/Makefile +++ b/drivers/interconnect/qcom/Makefile @@ -9,6 +9,7 @@ icc-rpmh-obj:= icc-rpmh.o qnoc-sc7180-objs := sc7180.o qnoc-sdm845-objs := sdm845.o qnoc-sm8150-objs := sm8150.o +qnoc-sm8250-objs := sm8250.o icc-smd-rpm-objs := smd-rpm.o obj-$(CONFIG_INTERCONNECT_QCOM_BCM_VOTER) += icc-bcm-voter.o @@ -20,4 +21,5 @@ obj-$(CONFIG_INTERCONNECT_QCOM_RPMH) += icc-rpmh.o obj-$(CONFIG_INTERCONNECT_QCOM_SC7180) += qnoc-sc7180.o obj-$(CONFIG_INTERCONNECT_QCOM_SDM845) += qnoc-sdm845.o obj-$(CONFIG_INTERCONNECT_QCOM_SM8150) += qnoc-sm8150.o +obj-$(CONFIG_INTERCONNECT_QCOM_SM8250) += qnoc-sm8250.o obj-$(CONFIG_INTERCONNECT_QCOM_SMD_RPM) += icc-smd-rpm.o diff --git a/drivers/interconnect/qcom/sm8250.c b/drivers/interconnect/qcom/sm8250.c new file mode 100644 index ..9b58946f7898 --- /dev/null +++ b/drivers/interconnect/qcom/sm8250.c @@ -0,0 +1,651 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + * + */ + +#include +#include +#include +#include +#include +#include + +#include "bcm-voter.h" +#include "icc-rpmh.h" +#include "sm8250.h" + +DEFINE_QNODE(qhm_a1noc_cfg, SM8250_MASTER_A1NOC_CFG, 1, 4, SM8250_SLAVE_SERVICE_A1NOC); +DEFINE_QNODE(qhm_qspi, SM8250_MASTER_QSPI_0, 1, 4, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qup1, SM8250_MASTER_QUP_1, 1, 4, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qup2, SM8250_MASTER_QUP_2, 1, 4, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(qhm_tsif, SM8250_MASTER_TSIF, 1, 4, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_pcie3_modem, SM8250_MASTER_PCIE_2, 1, 8, SM8250_SLAVE_ANOC_PCIE_GEM_NOC_1); +DEFINE_QNODE(xm_sdc4, SM8250_MASTER_SDCC_4, 1, 8, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_ufs_mem, SM8250_MASTER_UFS_MEM, 1, 8, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_usb3_0, SM8250_MASTER_USB3, 1, 8, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_usb3_1, SM8250_MASTER_USB3_1, 1, 8, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(qhm_a2noc_cfg, SM8250_MASTER_A2NOC_CFG, 1, 4, SM8250_SLAVE_SERVICE_A2NOC); +DEFINE_QNODE(qhm_qdss_bam, SM8250_MASTER_QDSS_BAM, 1, 4, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qup0, SM8250_MASTER_QUP_0, 1, 4, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(qnm_cnoc, SM8250_MASTER_CNOC_A2NOC, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(qxm_crypto, SM8250_MASTER_CRYPTO_CORE_0, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(qxm_ipa, SM8250_MASTER_IPA, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_pcie3_0, SM8250_MASTER_PCIE, 1, 8, SM8250_SLAVE_ANOC_PCIE_GEM_NOC); +DEFINE_QNODE(xm_pcie3_1, SM8250_MASTER_PCIE_1, 1, 8, SM8250_SLAVE_ANOC_PCIE_GEM_NOC); +DEFINE_QNODE(xm_qdss_etr, SM8250_MASTER_QDSS_ETR, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_sdc2, SM8250_MASTER_SDCC_2, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_ufs_card, SM8250_MASTER_UFS_CARD, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(qnm_npu, SM8250_MASTER_NPU, 2, 32, SM8250_SLAVE_CDSP_MEM_NOC); +DEFINE_QNODE(qnm_snoc, SM8250_SNOC_CNOC_MAS, 1, 8, SM8250_SLAVE_CDSP_CFG, SM8250_SLAVE_CAMERA_CFG, SM8250_SLAVE_TLMM_SOUTH, SM8250_SLAVE_TLMM_NORTH, SM8250_SLAVE_SDCC_4, SM8250_SLAVE_TL
Re: [PATCH v3 4/7] interconnect: qcom: Add SM8150 interconnect provider driver
On 2020-07-28 08:08, Jonathan Marek wrote: Add driver for the Qualcomm interconnect buses found in SM8150 based platforms. The topology consists of several NoCs that are controlled by a remote processor that collects the aggregated bandwidth for each master-slave pairs. Based on SC7180 driver and generated from downstream dts. Signed-off-by: Jonathan Marek Reviewed-by: Sibi Sankar --- drivers/interconnect/qcom/Kconfig | 10 + drivers/interconnect/qcom/Makefile | 2 + drivers/interconnect/qcom/sm8150.c | 635 + drivers/interconnect/qcom/sm8150.h | 152 +++ 4 files changed, 799 insertions(+) create mode 100644 drivers/interconnect/qcom/sm8150.c create mode 100644 drivers/interconnect/qcom/sm8150.h diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig index a88f2f07bc27..25486de5a38d 100644 --- a/drivers/interconnect/qcom/Kconfig +++ b/drivers/interconnect/qcom/Kconfig @@ -65,5 +65,15 @@ config INTERCONNECT_QCOM_SDM845 This is a driver for the Qualcomm Network-on-Chip on sdm845-based platforms. +config INTERCONNECT_QCOM_SM8150 + tristate "Qualcomm SM8150 interconnect driver" + depends on INTERCONNECT_QCOM + depends on (QCOM_RPMH && QCOM_COMMAND_DB && OF) || COMPILE_TEST + select INTERCONNECT_QCOM_RPMH + select INTERCONNECT_QCOM_BCM_VOTER + help + This is a driver for the Qualcomm Network-on-Chip on sm8150-based + platforms. + config INTERCONNECT_QCOM_SMD_RPM tristate diff --git a/drivers/interconnect/qcom/Makefile b/drivers/interconnect/qcom/Makefile index 3a047fe6e45a..1702ece67dc5 100644 --- a/drivers/interconnect/qcom/Makefile +++ b/drivers/interconnect/qcom/Makefile @@ -8,6 +8,7 @@ qnoc-qcs404-objs:= qcs404.o icc-rpmh-obj := icc-rpmh.o qnoc-sc7180-objs := sc7180.o qnoc-sdm845-objs := sdm845.o +qnoc-sm8150-objs := sm8150.o icc-smd-rpm-objs := smd-rpm.o obj-$(CONFIG_INTERCONNECT_QCOM_BCM_VOTER) += icc-bcm-voter.o @@ -18,4 +19,5 @@ obj-$(CONFIG_INTERCONNECT_QCOM_QCS404) += qnoc-qcs404.o obj-$(CONFIG_INTERCONNECT_QCOM_RPMH) += icc-rpmh.o obj-$(CONFIG_INTERCONNECT_QCOM_SC7180) += qnoc-sc7180.o obj-$(CONFIG_INTERCONNECT_QCOM_SDM845) += qnoc-sdm845.o +obj-$(CONFIG_INTERCONNECT_QCOM_SM8150) += qnoc-sm8150.o obj-$(CONFIG_INTERCONNECT_QCOM_SMD_RPM) += icc-smd-rpm.o diff --git a/drivers/interconnect/qcom/sm8150.c b/drivers/interconnect/qcom/sm8150.c new file mode 100644 index ..9218efed04a0 --- /dev/null +++ b/drivers/interconnect/qcom/sm8150.c @@ -0,0 +1,635 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + * + */ + +#include +#include +#include +#include +#include +#include + +#include "bcm-voter.h" +#include "icc-rpmh.h" +#include "sm8150.h" + +DEFINE_QNODE(qhm_a1noc_cfg, SM8150_MASTER_A1NOC_CFG, 1, 4, SM8150_SLAVE_SERVICE_A1NOC); +DEFINE_QNODE(qhm_qup0, SM8150_MASTER_QUP_0, 1, 4, SM8150_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_emac, SM8150_MASTER_EMAC, 1, 8, SM8150_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_ufs_mem, SM8150_MASTER_UFS_MEM, 1, 8, SM8150_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_usb3_0, SM8150_MASTER_USB3, 1, 8, SM8150_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_usb3_1, SM8150_MASTER_USB3_1, 1, 8, SM8150_A1NOC_SNOC_SLV); +DEFINE_QNODE(qhm_a2noc_cfg, SM8150_MASTER_A2NOC_CFG, 1, 4, SM8150_SLAVE_SERVICE_A2NOC); +DEFINE_QNODE(qhm_qdss_bam, SM8150_MASTER_QDSS_BAM, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qspi, SM8150_MASTER_QSPI, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qup1, SM8150_MASTER_QUP_1, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qup2, SM8150_MASTER_QUP_2, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_sensorss_ahb, SM8150_MASTER_SENSORS_AHB, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_tsif, SM8150_MASTER_TSIF, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qnm_cnoc, SM8150_MASTER_CNOC_A2NOC, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qxm_crypto, SM8150_MASTER_CRYPTO_CORE_0, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qxm_ipa, SM8150_MASTER_IPA, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_pcie3_0, SM8150_MASTER_PCIE, 1, 8, SM8150_SLAVE_ANOC_PCIE_GEM_NOC); +DEFINE_QNODE(xm_pcie3_1, SM8150_MASTER_PCIE_1, 1, 8, SM8150_SLAVE_ANOC_PCIE_GEM_NOC); +DEFINE_QNODE(xm_qdss_etr, SM8150_MASTER_QDSS_ETR, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_sdc2, SM8150_MASTER_SDCC_2, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_sdc4, SM8150_MASTER_SDCC_4, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qxm_camnoc_hf0_uncomp, SM8150_MASTER_CAMNOC_HF0_UNCOMP, 1, 32, SM8150_SLAVE_CAMNOC_UNCOMP); +DEFINE_QNODE(qxm_camnoc_hf1_uncomp, SM8150_MASTER_CAMNOC_HF1_UNCOMP, 1, 32, SM8150_SLAVE_CAMNOC_UNCOMP); +DEFINE_QNODE(qxm_camnoc_sf_uncomp, SM8150_MASTER_CAMNOC_SF_UNCOMP, 1
Re: [PATCH v3 3/7] dt-bindings: interconnect: Add Qualcomm SM8250 DT bindings
On 2020-07-28 08:08, Jonathan Marek wrote: The Qualcomm SM8250 platform has several bus fabrics that could be controlled and tuned dynamically according to the bandwidth demand. Signed-off-by: Jonathan Marek Reviewed-by: Rob Herring Reviewed-by: Sibi Sankar --- .../bindings/interconnect/qcom,rpmh.yaml | 11 ++ .../dt-bindings/interconnect/qcom,sm8250.h| 172 ++ 2 files changed, 183 insertions(+) create mode 100644 include/dt-bindings/interconnect/qcom,sm8250.h diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index e95ccd7b4b5a..18c48a2ce191 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -56,6 +56,17 @@ properties: - qcom,sm8150-mc-virt - qcom,sm8150-mmss-noc - qcom,sm8150-system-noc + - qcom,sm8250-aggre1-noc + - qcom,sm8250-aggre2-noc + - qcom,sm8250-compute-noc + - qcom,sm8250-config-noc + - qcom,sm8250-dc-noc + - qcom,sm8250-gem-noc + - qcom,sm8250-ipa-virt + - qcom,sm8250-mc-virt + - qcom,sm8250-mmss-noc + - qcom,sm8250-npu-noc + - qcom,sm8250-system-noc '#interconnect-cells': const: 1 diff --git a/include/dt-bindings/interconnect/qcom,sm8250.h b/include/dt-bindings/interconnect/qcom,sm8250.h new file mode 100644 index ..1b4d9fbe888d --- /dev/null +++ b/include/dt-bindings/interconnect/qcom,sm8250.h @@ -0,0 +1,172 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Qualcomm SM8250 interconnect IDs + * + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + */ + +#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_SM8250_H +#define __DT_BINDINGS_INTERCONNECT_QCOM_SM8250_H + +#define MASTER_A1NOC_CFG 0 +#define MASTER_QSPI_0 1 +#define MASTER_QUP_1 2 +#define MASTER_QUP_2 3 +#define MASTER_TSIF4 +#define MASTER_PCIE_2 5 +#define MASTER_SDCC_4 6 +#define MASTER_UFS_MEM 7 +#define MASTER_USB38 +#define MASTER_USB3_1 9 +#define A1NOC_SNOC_SLV 10 +#define SLAVE_ANOC_PCIE_GEM_NOC_1 11 +#define SLAVE_SERVICE_A1NOC12 + +#define MASTER_A2NOC_CFG 0 +#define MASTER_QDSS_BAM1 +#define MASTER_QUP_0 2 +#define MASTER_CNOC_A2NOC 3 +#define MASTER_CRYPTO_CORE_0 4 +#define MASTER_IPA 5 +#define MASTER_PCIE6 +#define MASTER_PCIE_1 7 +#define MASTER_QDSS_ETR8 +#define MASTER_SDCC_2 9 +#define MASTER_UFS_CARD10 +#define A2NOC_SNOC_SLV 11 +#define SLAVE_ANOC_PCIE_GEM_NOC12 +#define SLAVE_SERVICE_A2NOC13 + +#define MASTER_NPU 0 +#define SLAVE_CDSP_MEM_NOC 1 + +#define SNOC_CNOC_MAS 0 +#define MASTER_QDSS_DAP1 +#define SLAVE_A1NOC_CFG2 +#define SLAVE_A2NOC_CFG3 +#define SLAVE_AHB2PHY_SOUTH4 +#define SLAVE_AHB2PHY_NORTH5 +#define SLAVE_AOSS 6 +#define SLAVE_CAMERA_CFG 7 +#define SLAVE_CLK_CTL 8 +#define SLAVE_CDSP_CFG 9 +#define SLAVE_RBCPR_CX_CFG 10 +#define SLAVE_RBCPR_MMCX_CFG 11 +#define SLAVE_RBCPR_MX_CFG 12 +#define SLAVE_CRYPTO_0_CFG 13 +#define SLAVE_CX_RDPM 14 +#define SLAVE_DCC_CFG 15 +#define SLAVE_CNOC_DDRSS 16 +#define SLAVE_DISPLAY_CFG 17 +#define SLAVE_GRAPHICS_3D_CFG 18 +#define SLAVE_IMEM_CFG 19 +#define SLAVE_IPA_CFG 20 +#define SLAVE_IPC_ROUTER_CFG 21 +#define SLAVE_LPASS22 +#define SLAVE_CNOC_MNOC_CFG23 +#define SLAVE_NPU_CFG 24 +#define SLAVE_PCIE_0_CFG 25 +#define SLAVE_PCIE_1_CFG 26 +#define SLAVE_PCIE_2_CFG 27 +#define SLAVE_PDM 28 +#define SLAVE_PIMEM_CFG29 +#define SLAVE_PRNG 30 +#define SLAVE_QDSS_CFG 31 +#define SLAVE_QSPI_0 32 +#define SLAVE_QUP_033 +#define SLAVE_QUP_134 +#define SLAVE_QUP_235 +#define SLAVE_SDCC_2 36 +#define SLAVE_SDCC_4 37 +#define SLAVE_SNOC_CFG 38 +#define SLAVE_TCSR 39 +#define SLAVE_TLMM_NORTH 40 +#define SLAVE_TLMM_SOUTH 41 +#define SLAVE_TLMM_WEST42 +#define SLAVE_TSIF
Re: [PATCH v3 2/7] dt-bindings: interconnect: Add Qualcomm SM8150 DT bindings
On 2020-07-28 08:08, Jonathan Marek wrote: The Qualcomm SM8150 platform has several bus fabrics that could be controlled and tuned dynamically according to the bandwidth demand. Signed-off-by: Jonathan Marek Reviewed-by: Rob Herring Reviewed-by: Sibi Sankar --- .../bindings/interconnect/qcom,rpmh.yaml | 11 ++ .../dt-bindings/interconnect/qcom,sm8150.h| 162 ++ 2 files changed, 173 insertions(+) create mode 100644 include/dt-bindings/interconnect/qcom,sm8150.h diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index 6a457f914bb5..e95ccd7b4b5a 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -45,6 +45,17 @@ properties: - qcom,sdm845-mem-noc - qcom,sdm845-mmss-noc - qcom,sdm845-system-noc + - qcom,sm8150-aggre1-noc + - qcom,sm8150-aggre2-noc + - qcom,sm8150-camnoc-noc + - qcom,sm8150-compute-noc + - qcom,sm8150-config-noc + - qcom,sm8150-dc-noc + - qcom,sm8150-gem-noc + - qcom,sm8150-ipa-virt + - qcom,sm8150-mc-virt + - qcom,sm8150-mmss-noc + - qcom,sm8150-system-noc '#interconnect-cells': const: 1 diff --git a/include/dt-bindings/interconnect/qcom,sm8150.h b/include/dt-bindings/interconnect/qcom,sm8150.h new file mode 100644 index ..a25684680c42 --- /dev/null +++ b/include/dt-bindings/interconnect/qcom,sm8150.h @@ -0,0 +1,162 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Qualcomm SM8150 interconnect IDs + * + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + */ + +#ifndef __DT_BINDINGS_INTERCONNECT_QCOM_SM8150_H +#define __DT_BINDINGS_INTERCONNECT_QCOM_SM8150_H + +#define MASTER_A1NOC_CFG 0 +#define MASTER_QUP_0 1 +#define MASTER_EMAC2 +#define MASTER_UFS_MEM 3 +#define MASTER_USB34 +#define MASTER_USB3_1 5 +#define A1NOC_SNOC_SLV 6 +#define SLAVE_SERVICE_A1NOC7 + +#define MASTER_A2NOC_CFG 0 +#define MASTER_QDSS_BAM1 +#define MASTER_QSPI2 +#define MASTER_QUP_1 3 +#define MASTER_QUP_2 4 +#define MASTER_SENSORS_AHB 5 +#define MASTER_TSIF6 +#define MASTER_CNOC_A2NOC 7 +#define MASTER_CRYPTO_CORE_0 8 +#define MASTER_IPA 9 +#define MASTER_PCIE10 +#define MASTER_PCIE_1 11 +#define MASTER_QDSS_ETR12 +#define MASTER_SDCC_2 13 +#define MASTER_SDCC_4 14 +#define A2NOC_SNOC_SLV 15 +#define SLAVE_ANOC_PCIE_GEM_NOC16 +#define SLAVE_SERVICE_A2NOC17 + +#define MASTER_CAMNOC_HF0_UNCOMP 0 +#define MASTER_CAMNOC_HF1_UNCOMP 1 +#define MASTER_CAMNOC_SF_UNCOMP2 +#define SLAVE_CAMNOC_UNCOMP3 + +#define MASTER_NPU 0 +#define SLAVE_CDSP_MEM_NOC 1 + +#define MASTER_SPDM0 +#define SNOC_CNOC_MAS 1 +#define MASTER_QDSS_DAP2 +#define SLAVE_A1NOC_CFG3 +#define SLAVE_A2NOC_CFG4 +#define SLAVE_AHB2PHY_SOUTH5 +#define SLAVE_AOP 6 +#define SLAVE_AOSS 7 +#define SLAVE_CAMERA_CFG 8 +#define SLAVE_CLK_CTL 9 +#define SLAVE_CDSP_CFG 10 +#define SLAVE_RBCPR_CX_CFG 11 +#define SLAVE_RBCPR_MMCX_CFG 12 +#define SLAVE_RBCPR_MX_CFG 13 +#define SLAVE_CRYPTO_0_CFG 14 +#define SLAVE_CNOC_DDRSS 15 +#define SLAVE_DISPLAY_CFG 16 +#define SLAVE_EMAC_CFG 17 +#define SLAVE_GLM 18 +#define SLAVE_GRAPHICS_3D_CFG 19 +#define SLAVE_IMEM_CFG 20 +#define SLAVE_IPA_CFG 21 +#define SLAVE_CNOC_MNOC_CFG22 +#define SLAVE_NPU_CFG 23 +#define SLAVE_PCIE_0_CFG 24 +#define SLAVE_PCIE_1_CFG 25 +#define SLAVE_NORTH_PHY_CFG26 +#define SLAVE_PIMEM_CFG27 +#define SLAVE_PRNG 28 +#define SLAVE_QDSS_CFG 29 +#define SLAVE_QSPI 30 +#define SLAVE_QUP_231 +#define SLAVE_QUP_132 +#define SLAVE_QUP_033 +#define SLAVE_SDCC_2 34 +#define SLAVE_SDCC_4 35 +#define SLAVE_SNOC_CFG 36 +#define SLAVE_SPDM_WRAPPER 37 +#define SLAVE_SPSS_CFG 38 +#define SLAVE_SSC_CFG 39 +#define SLAVE_TCSR
Re: [PATCH v3 1/7] dt-bindings: interconnect: single yaml file for RPMh interconnect drivers
On 2020-07-28 08:08, Jonathan Marek wrote:
These two bindings are almost identical, so combine them into one. This
will make it easier to add the sm8150 and sm8250 interconnect bindings.
Signed-off-by: Jonathan Marek
Reviewed-by: Sibi Sankar
---
.../{qcom,sdm845.yaml => qcom,rpmh.yaml} | 20 -
.../bindings/interconnect/qcom,sc7180.yaml| 85 ---
2 files changed, 17 insertions(+), 88 deletions(-)
rename
Documentation/devicetree/bindings/interconnect/{qcom,sdm845.yaml =>
qcom,rpmh.yaml} (76%)
delete mode 100644
Documentation/devicetree/bindings/interconnect/qcom,sc7180.yaml
diff --git
a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml
b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
similarity index 76%
rename from
Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml
rename to Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
index 74536747b51d..6a457f914bb5 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml
@@ -1,16 +1,17 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/interconnect/qcom,sdm845.yaml#
+$id: http://devicetree.org/schemas/interconnect/qcom,rpmh.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Qualcomm SDM845 Network-On-Chip Interconnect
+title: Qualcomm RPMh Network-On-Chip Interconnect
maintainers:
- Georgi Djakov
+ - Odelu Kukatla
description: |
- SDM845 interconnect providers support system bandwidth requirements
through
+ RPMh interconnect providers support system bandwidth requirements
through
RPMh hardware accelerators known as Bus Clock Manager (BCM). The
provider is
able to communicate with the BCM through the Resource State
Coordinator (RSC)
associated with each execution environment. Provider nodes must
point to at
@@ -23,6 +24,19 @@ properties:
compatible:
enum:
+ - qcom,sc7180-aggre1-noc
+ - qcom,sc7180-aggre2-noc
+ - qcom,sc7180-camnoc-virt
+ - qcom,sc7180-compute-noc
+ - qcom,sc7180-config-noc
+ - qcom,sc7180-dc-noc
+ - qcom,sc7180-gem-noc
+ - qcom,sc7180-ipa-virt
+ - qcom,sc7180-mc-virt
+ - qcom,sc7180-mmss-noc
+ - qcom,sc7180-npu-noc
+ - qcom,sc7180-qup-virt
+ - qcom,sc7180-system-noc
- qcom,sdm845-aggre1-noc
- qcom,sdm845-aggre2-noc
- qcom,sdm845-config-noc
diff --git
a/Documentation/devicetree/bindings/interconnect/qcom,sc7180.yaml
b/Documentation/devicetree/bindings/interconnect/qcom,sc7180.yaml
deleted file mode 100644
index d01bac80d416..
--- a/Documentation/devicetree/bindings/interconnect/qcom,sc7180.yaml
+++ /dev/null
@@ -1,85 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
-$id: http://devicetree.org/schemas/interconnect/qcom,sc7180.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: Qualcomm SC7180 Network-On-Chip Interconnect
-
-maintainers:
- - Odelu Kukatla
-
-description: |
- SC7180 interconnect providers support system bandwidth requirements
through
- RPMh hardware accelerators known as Bus Clock Manager (BCM). The
provider is
- able to communicate with the BCM through the Resource State
Coordinator (RSC)
- associated with each execution environment. Provider nodes must
point to at
- least one RPMh device child node pertaining to their RSC and each
provider
- can map to multiple RPMh resources.
-
-properties:
- reg:
-maxItems: 1
-
- compatible:
-enum:
- - qcom,sc7180-aggre1-noc
- - qcom,sc7180-aggre2-noc
- - qcom,sc7180-camnoc-virt
- - qcom,sc7180-compute-noc
- - qcom,sc7180-config-noc
- - qcom,sc7180-dc-noc
- - qcom,sc7180-gem-noc
- - qcom,sc7180-ipa-virt
- - qcom,sc7180-mc-virt
- - qcom,sc7180-mmss-noc
- - qcom,sc7180-npu-noc
- - qcom,sc7180-qup-virt
- - qcom,sc7180-system-noc
-
- '#interconnect-cells':
-const: 1
-
- qcom,bcm-voters:
-$ref: /schemas/types.yaml#/definitions/phandle-array
-description: |
- List of phandles to qcom,bcm-voter nodes that are required by
- this interconnect to send RPMh commands.
-
- qcom,bcm-voter-names:
-$ref: /schemas/types.yaml#/definitions/string-array
-description: |
- Names for each of the qcom,bcm-voters specified.
-
-required:
- - compatible
- - reg
- - '#interconnect-cells'
- - qcom,bcm-voters
-
-additionalProperties: false
-
-examples:
- - |
- #include
-
- config_noc: interconnect@150 {
-compatible = "qcom,sc7180-config-noc";
-reg = <0x0150 0x28000>;
-#interconnect-cells = <1>;
-qcom,bcm-voters = <_bcm_voter>;
- };
-
- system_noc: interconnect@162 {
-compatible = "qcom,sc7180-system-noc&q
Re: [PATCH 2/6] interconnect: qcom: Implement xlate_extended() to parse tags
Hey Georgi,
Thanks for the patch!
On 7/23/20 6:39 PM, Georgi Djakov wrote:
Implement a function to parse the arguments of the "interconnects" DT
property and populate the interconnect path tags if this information
is available.
Signed-off-by: Georgi Djakov
---
drivers/interconnect/qcom/icc-rpmh.c | 27 +++
drivers/interconnect/qcom/icc-rpmh.h | 1 +
2 files changed, 28 insertions(+)
diff --git a/drivers/interconnect/qcom/icc-rpmh.c
b/drivers/interconnect/qcom/icc-rpmh.c
index 3ac5182c9ab2..44144fabec32 100644
--- a/drivers/interconnect/qcom/icc-rpmh.c
+++ b/drivers/interconnect/qcom/icc-rpmh.c
@@ -6,6 +6,8 @@
#include
#include
#include
+#include
+#include
#include "bcm-voter.h"
#include "icc-rpmh.h"
@@ -92,6 +94,31 @@ int qcom_icc_set(struct icc_node *src, struct icc_node *dst)
}
EXPORT_SYMBOL_GPL(qcom_icc_set);
+struct icc_node_data *qcom_icc_xlate_extended(struct of_phandle_args *spec, void *data)
+{
+ struct icc_node_data *ndata;
+ struct icc_node *node;
+
+ if (!spec)
+ return ERR_PTR(-EINVAL);
+
you could probably skip ^^ check
Tested-by: Sibi Sankar
Reviewed-by: Sibi Sankar
+ node = of_icc_xlate_onecell(spec, data);
+ if (IS_ERR(node))
+ return ERR_CAST(node);
+
+ ndata = kzalloc(sizeof(*ndata), GFP_KERNEL);
+ if (!ndata)
+ return ERR_PTR(-ENOMEM);
+
+ ndata->node = node;
+
+ if (spec->args_count == 2)
+ ndata->tag = spec->args[1];
+
+ return ndata;
+}
+EXPORT_SYMBOL_GPL(qcom_icc_xlate_extended);
+
/**
* qcom_icc_bcm_init - populates bcm aux data and connect qnodes
* @bcm: bcm to be initialized
diff --git a/drivers/interconnect/qcom/icc-rpmh.h
b/drivers/interconnect/qcom/icc-rpmh.h
index 903d25e61984..1dac39bc255d 100644
--- a/drivers/interconnect/qcom/icc-rpmh.h
+++ b/drivers/interconnect/qcom/icc-rpmh.h
@@ -143,6 +143,7 @@ struct qcom_icc_desc {
int qcom_icc_aggregate(struct icc_node *node, u32 tag, u32 avg_bw,
u32 peak_bw, u32 *agg_avg, u32 *agg_peak);
int qcom_icc_set(struct icc_node *src, struct icc_node *dst);
+struct icc_node_data *qcom_icc_xlate_extended(struct of_phandle_args *spec,
void *data);
int qcom_icc_bcm_init(struct qcom_icc_bcm *bcm, struct device *dev);
void qcom_icc_pre_aggregate(struct icc_node *node);
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 4/6] arm64: dts: qcom: sdm845: Increase the number of interconnect cells
On 2020-07-23 18:39, Georgi Djakov wrote: Increase the number of interconnect-cells, as now we can include the tag information. The consumers can specify the path tag as an additional argument to the endpoints. Tested-by: Sibi Sankar Reviewed-by: Sibi Sankar https://patchwork.kernel.org/patch/11655409/ I'll replace the tag ids with the macros once ^^ lands. Signed-off-by: Georgi Djakov --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 44 ++-- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi index e506793407d8..94f5d27f2927 100644 --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi @@ -200,7 +200,7 @@ _CPU_SLEEP_1 dynamic-power-coefficient = <100>; qcom,freq-domain = <_hw 0>; operating-points-v2 = <_opp_table>; - interconnects = <_noc MASTER_APPSS_PROC _noc SLAVE_EBI1>, + interconnects = <_noc MASTER_APPSS_PROC 3 _noc SLAVE_EBI1 3>, <_l3 MASTER_OSM_L3_APPS _l3 SLAVE_OSM_L3>; #cooling-cells = <2>; next-level-cache = <_0>; @@ -225,7 +225,7 @@ _CPU_SLEEP_1 dynamic-power-coefficient = <100>; qcom,freq-domain = <_hw 0>; operating-points-v2 = <_opp_table>; - interconnects = <_noc MASTER_APPSS_PROC _noc SLAVE_EBI1>, + interconnects = <_noc MASTER_APPSS_PROC 3 _noc SLAVE_EBI1 3>, <_l3 MASTER_OSM_L3_APPS _l3 SLAVE_OSM_L3>; #cooling-cells = <2>; next-level-cache = <_100>; @@ -247,7 +247,7 @@ _CPU_SLEEP_1 dynamic-power-coefficient = <100>; qcom,freq-domain = <_hw 0>; operating-points-v2 = <_opp_table>; - interconnects = <_noc MASTER_APPSS_PROC _noc SLAVE_EBI1>, + interconnects = <_noc MASTER_APPSS_PROC 3 _noc SLAVE_EBI1 3>, <_l3 MASTER_OSM_L3_APPS _l3 SLAVE_OSM_L3>; #cooling-cells = <2>; next-level-cache = <_200>; @@ -269,7 +269,7 @@ _CPU_SLEEP_1 dynamic-power-coefficient = <100>; qcom,freq-domain = <_hw 0>; operating-points-v2 = <_opp_table>; - interconnects = <_noc MASTER_APPSS_PROC _noc SLAVE_EBI1>, + interconnects = <_noc MASTER_APPSS_PROC 3 _noc SLAVE_EBI1 3>, <_l3 MASTER_OSM_L3_APPS _l3 SLAVE_OSM_L3>; #cooling-cells = <2>; next-level-cache = <_300>; @@ -291,7 +291,7 @@ _CPU_SLEEP_1 dynamic-power-coefficient = <396>; qcom,freq-domain = <_hw 1>; operating-points-v2 = <_opp_table>; - interconnects = <_noc MASTER_APPSS_PROC _noc SLAVE_EBI1>, + interconnects = <_noc MASTER_APPSS_PROC 3 _noc SLAVE_EBI1 3>, <_l3 MASTER_OSM_L3_APPS _l3 SLAVE_OSM_L3>; #cooling-cells = <2>; next-level-cache = <_400>; @@ -313,7 +313,7 @@ _CPU_SLEEP_1 dynamic-power-coefficient = <396>; qcom,freq-domain = <_hw 1>; operating-points-v2 = <_opp_table>; - interconnects = <_noc MASTER_APPSS_PROC _noc SLAVE_EBI1>, + interconnects = <_noc MASTER_APPSS_PROC 3 _noc SLAVE_EBI1 3>, <_l3 MASTER_OSM_L3_APPS _l3 SLAVE_OSM_L3>; #cooling-cells = <2>; next-level-cache = <_500>; @@ -335,7 +335,7 @@ _CPU_SLEEP_1 dynamic-power-coefficient = <396>; qcom,freq-domain = <_hw 1>; operating-points-v2 = <_opp_table>; - interconnects = <_noc MASTER_APPSS_PROC _noc SLAVE_EBI1>, + interconnects = <_noc MASTER_APPSS_PROC 3 _noc SLAVE_EBI1 3>, <_l3 MASTER_OSM_L3_APPS _l3 SLAVE_OSM_L3>; #cooling-cells = <2>; next-level-cache = <_600>; @@ -357,7 +357,7 @@ _CPU_SLEEP_1 dynamic-power-coefficient = <396>; qcom,freq-domain = <_hw 1>; operating-points-v2 = <_opp_table>; - interconnects = <_noc MASTER_APPSS_PROC _noc SL
Re: [PATCH 3/6] interconnect: qcom: sdm845: Replace xlate with xlate_extended
On 2020-07-23 18:39, Georgi Djakov wrote: Use the qcom_icc_xlate_extended() in order to parse tags, that are specified as an additional arguments to the path endpoints in DT. Signed-off-by: Georgi Djakov Tested-by: Sibi Sankar Reviewed-by: Sibi Sankar --- drivers/interconnect/qcom/sdm845.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/interconnect/qcom/sdm845.c b/drivers/interconnect/qcom/sdm845.c index f6c7b969520d..3b81dbb71b0b 100644 --- a/drivers/interconnect/qcom/sdm845.c +++ b/drivers/interconnect/qcom/sdm845.c @@ -469,7 +469,7 @@ static int qnoc_probe(struct platform_device *pdev) provider->set = qcom_icc_set; provider->pre_aggregate = qcom_icc_pre_aggregate; provider->aggregate = qcom_icc_aggregate; - provider->xlate = of_icc_xlate_onecell; + provider->xlate_extended = qcom_icc_xlate_extended; INIT_LIST_HEAD(>nodes); provider->data = data; -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH 1/6] interconnect: Introduce xlate_extended() callback
Hey Georgi,
Thanks for the patch!
On 2020-07-23 18:39, Georgi Djakov wrote:
Currently there is the xlate() callback, which is provider-specific is
nit: currently xlate callback isn't
provider specific.
used for mapping the nodes from phandle arguments. This is fine for
simple
mappings, but the phandle arguments could contain an additional data,
such
as tag information. Let's create another callback xlate_extended() for
the
cases where providers want also populate the tagging data.
Signed-off-by: Georgi Djakov
Tested-by: Sibi Sankar
Reviewed-by: Sibi Sankar
---
drivers/interconnect/core.c | 73 ++-
include/linux/interconnect-provider.h | 17 ++-
2 files changed, 65 insertions(+), 25 deletions(-)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index befd111049c0..6ccf55818e68 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -336,12 +336,13 @@ EXPORT_SYMBOL_GPL(of_icc_xlate_onecell);
* Looks for interconnect provider under the node specified by @spec
and if
* found, uses xlate function of the provider to map phandle args to
node.
*
- * Returns a valid pointer to struct icc_node on success or ERR_PTR()
+ * Returns a valid pointer to struct icc_node_data on success or
ERR_PTR()
* on failure.
*/
-struct icc_node *of_icc_get_from_provider(struct of_phandle_args
*spec)
+struct icc_node_data *of_icc_get_from_provider(struct of_phandle_args
*spec)
{
struct icc_node *node = ERR_PTR(-EPROBE_DEFER);
+ struct icc_node_data *data = NULL;
struct icc_provider *provider;
if (!spec)
@@ -349,14 +350,33 @@ struct icc_node *of_icc_get_from_provider(struct
of_phandle_args *spec)
mutex_lock(_lock);
list_for_each_entry(provider, _providers, provider_list) {
- if (provider->dev->of_node == spec->np)
- node = provider->xlate(spec, provider->data);
- if (!IS_ERR(node))
- break;
+ if (provider->dev->of_node == spec->np) {
+ if (provider->xlate_extended) {
+ data = provider->xlate_extended(spec,
provider->data);
+ if (!IS_ERR(data)) {
+ node = data->node;
+ break;
+ }
+ } else {
+ node = provider->xlate(spec, provider->data);
+ if (!IS_ERR(node))
+ break;
+ }
+ }
}
mutex_unlock(_lock);
- return node;
+ if (IS_ERR(node))
+ return ERR_CAST(node);
+
+ if (!data) {
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return ERR_PTR(-ENOMEM);
+ data->node = node;
+ }
+
+ return data;
}
EXPORT_SYMBOL_GPL(of_icc_get_from_provider);
@@ -403,7 +423,7 @@ EXPORT_SYMBOL_GPL(devm_of_icc_get);
struct icc_path *of_icc_get_by_index(struct device *dev, int idx)
{
struct icc_path *path;
- struct icc_node *src_node, *dst_node;
+ struct icc_node_data *src_data, *dst_data;
struct device_node *np;
struct of_phandle_args src_args, dst_args;
int ret;
@@ -441,39 +461,46 @@ struct icc_path *of_icc_get_by_index(struct
device *dev, int idx)
of_node_put(dst_args.np);
- src_node = of_icc_get_from_provider(_args);
+ src_data = of_icc_get_from_provider(_args);
- if (IS_ERR(src_node)) {
- if (PTR_ERR(src_node) != -EPROBE_DEFER)
+ if (IS_ERR(src_data)) {
+ if (PTR_ERR(src_data) != -EPROBE_DEFER)
dev_err(dev, "error finding src node: %ld\n",
- PTR_ERR(src_node));
- return ERR_CAST(src_node);
+ PTR_ERR(src_data));
+ return ERR_CAST(src_data);
}
- dst_node = of_icc_get_from_provider(_args);
+ dst_data = of_icc_get_from_provider(_args);
- if (IS_ERR(dst_node)) {
- if (PTR_ERR(dst_node) != -EPROBE_DEFER)
+ if (IS_ERR(dst_data)) {
+ if (PTR_ERR(dst_data) != -EPROBE_DEFER)
dev_err(dev, "error finding dst node: %ld\n",
- PTR_ERR(dst_node));
- return ERR_CAST(dst_node);
+ PTR_ERR(dst_data));
+ kfree(src_data);
+ return ERR_CAST(dst_data);
}
mutex_lock(_lock);
- path = path_find(dev, src_node, dst_node);
+ path = path_find(dev, src_data->node, dst_data->node);
mutex_unlock(_lock);
if (IS_ERR(path)) {
dev_err(dev, &qu
Re: [PATCH v2 7/7] arm64: dts: qcom: sm8250: add interconnect nodes
On 2020-07-24 20:06, Jonathan Marek wrote:
On 7/24/20 10:13 AM, Sibi Sankar wrote:
Hey Jonathan,
Thanks for the patch! Please use the
suggested register space definitions
instead.
Thanks for the suggestions, I was unsure what to use for the sizes.
The reg field is unused by the upstream driver so it is hard to figure
out.
However, I'm not sure about some of your suggestions for the base
address. For example, for "mc_virt" you suggest 0x0163d000, and I have
0x0910. In the downstream dts, "mc_virt-base" is 0x910 and
qcom,base-offset for fab_mc_virt is 0. Do you have an explanation for
why your suggestion is so different?
AFAIK for providers with virt suffix the
register space definition is just an
arbitrary choice and doesn't matter.
Since mc_virt was just re-using gem_noc
address space I suggested we stick to
how it was done on sc7180 i.e place it
between system_noc and aggre1_noc.
On 2020-07-13 21:11, Jonathan Marek wrote:
Add the interconnect dts nodes for sm8250.
Signed-off-by: Jonathan Marek
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 82
1 file changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 636e2196138c..dfc1b7fa7d85 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
please fix ^^ sort order
/ {
interrupt-parent = <>;
@@ -978,6 +979,55 @@ spi13: spi@a94000 {
};
};
+ config_noc: interconnect@150 {
+ compatible = "qcom,sm8250-config-noc";
+ reg = <0 0x0150 0 0x1000>;
0x0150 0xa580
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ ipa_virt: interconnect@162 {
+ compatible = "qcom,sm8250-ipa-virt";
+ reg = <0 0x0162 0 0x1000>;
0x01e0 0x1000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ system_noc: interconnect@1632000 {
+ compatible = "qcom,sm8250-system-noc";
+ reg = <0 0x01632000 0 0x1000>;
0x0162 0x1C200
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e2000 {
+ compatible = "qcom,sm8250-aggre1-noc";
+ reg = <0 0x016e2000 0 0x1000>;
0x016e 0x1f180
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre2_noc: interconnect@1703000 {
+ compatible = "qcom,sm8250-aggre2-noc";
+ reg = <0 0x01703000 0 0x1000>;
0x0170 0x33000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ compute_noc: interconnect@1733000 {
+ compatible = "qcom,sm8250-compute-noc";
+ reg = <0 0x01733000 0 0x1000>;
0x01733000 0xd180
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ mmss_noc: interconnect@174a000 {
+ compatible = "qcom,sm8250-mmss-noc";
+ reg = <0 0x0174a000 0 0x1000>;
0x0174 0x1f080
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,sm8250-ufshc", "qcom,ufshc",
"jedec,ufs-2.0";
@@ -1364,6 +1414,34 @@ usb_2_ssphy: lane@88eb200 {
};
};
+ dc_noc: interconnect@90c {
+ compatible = "qcom,sm8250-dc-noc";
+ reg = <0 0x090c 0 0x1000>;
0x090c 0x4200
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ mc_virt: interconnect@910 {
+ compatible = "qcom,sm8250-mc-virt";
+ reg = <0 0x0910 0 0x1000>;
0x0163d000 0x1000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ gem_noc: interconnect@9121000 {
+ compatible = "qcom,sm8250-gem-noc";
+ reg = <0 0x09121000 0 0x1000>;
0x0910 0xb4000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ npu_noc: interconnect@999 {
+ compatible = "qcom,sm8250-npu-noc";
+ reg = <0 0x0999 0 0x1000>;
0x0999 0x1600
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = &l
Re: [PATCH v2 5/7] interconnect: qcom: Add SM8250 interconnect provider driver
Hey Jonathan, Thanks for the patch! On 2020-07-13 21:11, Jonathan Marek wrote: Add driver for the Qualcomm interconnect buses found in SM8250 based platforms. The topology consists of several NoCs that are controlled by a remote processor that collects the aggregated bandwidth for each master-slave pairs. Based on SC7180 driver and generated from downstream dts. Signed-off-by: Jonathan Marek --- drivers/interconnect/qcom/Kconfig | 10 + drivers/interconnect/qcom/Makefile | 2 + drivers/interconnect/qcom/sm8250.c | 655 + drivers/interconnect/qcom/sm8250.h | 163 +++ 4 files changed, 830 insertions(+) create mode 100644 drivers/interconnect/qcom/sm8250.c create mode 100644 drivers/interconnect/qcom/sm8250.h diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig index 25486de5a38d..a8f93ba265f8 100644 --- a/drivers/interconnect/qcom/Kconfig +++ b/drivers/interconnect/qcom/Kconfig @@ -75,5 +75,15 @@ config INTERCONNECT_QCOM_SM8150 This is a driver for the Qualcomm Network-on-Chip on sm8150-based platforms. +config INTERCONNECT_QCOM_SM8250 + tristate "Qualcomm SM8250 interconnect driver" + depends on INTERCONNECT_QCOM + depends on (QCOM_RPMH && QCOM_COMMAND_DB && OF) || COMPILE_TEST + select INTERCONNECT_QCOM_RPMH + select INTERCONNECT_QCOM_BCM_VOTER + help + This is a driver for the Qualcomm Network-on-Chip on sm8250-based + platforms. + config INTERCONNECT_QCOM_SMD_RPM tristate diff --git a/drivers/interconnect/qcom/Makefile b/drivers/interconnect/qcom/Makefile index 1702ece67dc5..cf628f7990cd 100644 --- a/drivers/interconnect/qcom/Makefile +++ b/drivers/interconnect/qcom/Makefile @@ -9,6 +9,7 @@ icc-rpmh-obj:= icc-rpmh.o qnoc-sc7180-objs := sc7180.o qnoc-sdm845-objs := sdm845.o qnoc-sm8150-objs := sm8150.o +qnoc-sm8250-objs := sm8250.o icc-smd-rpm-objs := smd-rpm.o obj-$(CONFIG_INTERCONNECT_QCOM_BCM_VOTER) += icc-bcm-voter.o @@ -20,4 +21,5 @@ obj-$(CONFIG_INTERCONNECT_QCOM_RPMH) += icc-rpmh.o obj-$(CONFIG_INTERCONNECT_QCOM_SC7180) += qnoc-sc7180.o obj-$(CONFIG_INTERCONNECT_QCOM_SDM845) += qnoc-sdm845.o obj-$(CONFIG_INTERCONNECT_QCOM_SM8150) += qnoc-sm8150.o +obj-$(CONFIG_INTERCONNECT_QCOM_SM8250) += qnoc-sm8250.o obj-$(CONFIG_INTERCONNECT_QCOM_SMD_RPM) += icc-smd-rpm.o diff --git a/drivers/interconnect/qcom/sm8250.c b/drivers/interconnect/qcom/sm8250.c new file mode 100644 index ..8e63c19e01c0 --- /dev/null +++ b/drivers/interconnect/qcom/sm8250.c @@ -0,0 +1,655 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + * + */ + +#include +#include +#include +#include +#include +#include + +#include "bcm-voter.h" +#include "icc-rpmh.h" +#include "sm8250.h" + +DEFINE_QNODE(qhm_a1noc_cfg, SM8250_MASTER_A1NOC_CFG, 1, 4, SM8250_SLAVE_SERVICE_A1NOC); +DEFINE_QNODE(qhm_qspi, SM8250_MASTER_QSPI_0, 1, 4, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qup1, SM8250_MASTER_QUP_1, 1, 4, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qup2, SM8250_MASTER_QUP_2, 1, 4, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(qhm_tsif, SM8250_MASTER_TSIF, 1, 4, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_pcie3_modem, SM8250_MASTER_PCIE_2, 1, 8, SM8250_SLAVE_ANOC_PCIE_GEM_NOC_1); +DEFINE_QNODE(xm_sdc4, SM8250_MASTER_SDCC_4, 1, 8, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_ufs_mem, SM8250_MASTER_UFS_MEM, 1, 8, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_usb3_0, SM8250_MASTER_USB3, 1, 8, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_usb3_1, SM8250_MASTER_USB3_1, 1, 8, SM8250_A1NOC_SNOC_SLV); +DEFINE_QNODE(qhm_a2noc_cfg, SM8250_MASTER_A2NOC_CFG, 1, 4, SM8250_SLAVE_SERVICE_A2NOC); +DEFINE_QNODE(qhm_qdss_bam, SM8250_MASTER_QDSS_BAM, 1, 4, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qup0, SM8250_MASTER_QUP_0, 1, 4, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(qnm_cnoc, SM8250_MASTER_CNOC_A2NOC, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(qxm_crypto, SM8250_MASTER_CRYPTO_CORE_0, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(qxm_ipa, SM8250_MASTER_IPA, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_pcie3_0, SM8250_MASTER_PCIE, 1, 8, SM8250_SLAVE_ANOC_PCIE_GEM_NOC); +DEFINE_QNODE(xm_pcie3_1, SM8250_MASTER_PCIE_1, 1, 8, SM8250_SLAVE_ANOC_PCIE_GEM_NOC); +DEFINE_QNODE(xm_qdss_etr, SM8250_MASTER_QDSS_ETR, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_sdc2, SM8250_MASTER_SDCC_2, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_ufs_card, SM8250_MASTER_UFS_CARD, 1, 8, SM8250_A2NOC_SNOC_SLV); +DEFINE_QNODE(qnm_npu, SM8250_MASTER_NPU, 2, 32, SM8250_SLAVE_CDSP_MEM_NOC); +DEFINE_QNODE(qnm_snoc, SM8250_SNOC_CNOC_MAS, 1, 8, SM8250_SLAVE_CDSP_CFG, SM8250_SLAVE_CAMERA_CFG, SM8250_SLAVE_TLMM_SOUTH, SM8250_SLAVE_TLMM_NORTH, SM8250_SLAVE_SDCC_4, SM8250_SLAVE_TLMM_WEST, SM8250_SLAVE_SDCC_2, SM8250_SLAVE_CNOC_MNOC_CFG,
Re: [PATCH v2 4/7] interconnect: qcom: Add SM8150 interconnect provider driver
Hey Jonathan, Thanks for the patch! On 2020-07-13 21:11, Jonathan Marek wrote: Add driver for the Qualcomm interconnect buses found in SM8150 based platforms. The topology consists of several NoCs that are controlled by a remote processor that collects the aggregated bandwidth for each master-slave pairs. Based on SC7180 driver and generated from downstream dts. Signed-off-by: Jonathan Marek --- drivers/interconnect/qcom/Kconfig | 10 + drivers/interconnect/qcom/Makefile | 2 + drivers/interconnect/qcom/sm8150.c | 639 + drivers/interconnect/qcom/sm8150.h | 153 +++ 4 files changed, 804 insertions(+) create mode 100644 drivers/interconnect/qcom/sm8150.c create mode 100644 drivers/interconnect/qcom/sm8150.h diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig index a88f2f07bc27..25486de5a38d 100644 --- a/drivers/interconnect/qcom/Kconfig +++ b/drivers/interconnect/qcom/Kconfig @@ -65,5 +65,15 @@ config INTERCONNECT_QCOM_SDM845 This is a driver for the Qualcomm Network-on-Chip on sdm845-based platforms. +config INTERCONNECT_QCOM_SM8150 + tristate "Qualcomm SM8150 interconnect driver" + depends on INTERCONNECT_QCOM + depends on (QCOM_RPMH && QCOM_COMMAND_DB && OF) || COMPILE_TEST + select INTERCONNECT_QCOM_RPMH + select INTERCONNECT_QCOM_BCM_VOTER + help + This is a driver for the Qualcomm Network-on-Chip on sm8150-based + platforms. + config INTERCONNECT_QCOM_SMD_RPM tristate diff --git a/drivers/interconnect/qcom/Makefile b/drivers/interconnect/qcom/Makefile index 3a047fe6e45a..1702ece67dc5 100644 --- a/drivers/interconnect/qcom/Makefile +++ b/drivers/interconnect/qcom/Makefile @@ -8,6 +8,7 @@ qnoc-qcs404-objs:= qcs404.o icc-rpmh-obj := icc-rpmh.o qnoc-sc7180-objs := sc7180.o qnoc-sdm845-objs := sdm845.o +qnoc-sm8150-objs := sm8150.o icc-smd-rpm-objs := smd-rpm.o obj-$(CONFIG_INTERCONNECT_QCOM_BCM_VOTER) += icc-bcm-voter.o @@ -18,4 +19,5 @@ obj-$(CONFIG_INTERCONNECT_QCOM_QCS404) += qnoc-qcs404.o obj-$(CONFIG_INTERCONNECT_QCOM_RPMH) += icc-rpmh.o obj-$(CONFIG_INTERCONNECT_QCOM_SC7180) += qnoc-sc7180.o obj-$(CONFIG_INTERCONNECT_QCOM_SDM845) += qnoc-sdm845.o +obj-$(CONFIG_INTERCONNECT_QCOM_SM8150) += qnoc-sm8150.o obj-$(CONFIG_INTERCONNECT_QCOM_SMD_RPM) += icc-smd-rpm.o diff --git a/drivers/interconnect/qcom/sm8150.c b/drivers/interconnect/qcom/sm8150.c new file mode 100644 index ..2b82fa8dd275 --- /dev/null +++ b/drivers/interconnect/qcom/sm8150.c @@ -0,0 +1,639 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) 2020, The Linux Foundation. All rights reserved. + * + */ + +#include +#include +#include +#include +#include +#include + +#include "bcm-voter.h" +#include "icc-rpmh.h" +#include "sm8150.h" + +DEFINE_QNODE(qhm_a1noc_cfg, SM8150_MASTER_A1NOC_CFG, 1, 4, SM8150_SLAVE_SERVICE_A1NOC); +DEFINE_QNODE(qhm_qup0, SM8150_MASTER_QUP_0, 1, 4, SM8150_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_emac, SM8150_MASTER_EMAC, 1, 8, SM8150_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_ufs_mem, SM8150_MASTER_UFS_MEM, 1, 8, SM8150_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_usb3_0, SM8150_MASTER_USB3, 1, 8, SM8150_A1NOC_SNOC_SLV); +DEFINE_QNODE(xm_usb3_1, SM8150_MASTER_USB3_1, 1, 8, SM8150_A1NOC_SNOC_SLV); +DEFINE_QNODE(qhm_a2noc_cfg, SM8150_MASTER_A2NOC_CFG, 1, 4, SM8150_SLAVE_SERVICE_A2NOC); +DEFINE_QNODE(qhm_qdss_bam, SM8150_MASTER_QDSS_BAM, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qspi, SM8150_MASTER_QSPI, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qup1, SM8150_MASTER_QUP_1, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_qup2, SM8150_MASTER_QUP_2, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_sensorss_ahb, SM8150_MASTER_SENSORS_AHB, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qhm_tsif, SM8150_MASTER_TSIF, 1, 4, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qnm_cnoc, SM8150_MASTER_CNOC_A2NOC, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qxm_crypto, SM8150_MASTER_CRYPTO_CORE_0, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qxm_ipa, SM8150_MASTER_IPA, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_pcie3_0, SM8150_MASTER_PCIE, 1, 8, SM8150_SLAVE_ANOC_PCIE_GEM_NOC); +DEFINE_QNODE(xm_pcie3_1, SM8150_MASTER_PCIE_1, 1, 8, SM8150_SLAVE_ANOC_PCIE_GEM_NOC); +DEFINE_QNODE(xm_qdss_etr, SM8150_MASTER_QDSS_ETR, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_sdc2, SM8150_MASTER_SDCC_2, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(xm_sdc4, SM8150_MASTER_SDCC_4, 1, 8, SM8150_A2NOC_SNOC_SLV); +DEFINE_QNODE(qxm_camnoc_hf0_uncomp, SM8150_MASTER_CAMNOC_HF0_UNCOMP, 1, 32, SM8150_SLAVE_CAMNOC_UNCOMP); +DEFINE_QNODE(qxm_camnoc_hf1_uncomp, SM8150_MASTER_CAMNOC_HF1_UNCOMP, 1, 32, SM8150_SLAVE_CAMNOC_UNCOMP); +DEFINE_QNODE(qxm_camnoc_sf_uncomp, SM8150_MASTER_CAMNOC_SF_UNCOMP, 1, 32, SM8150_SLAVE_CAMNOC_UNCOMP);
Re: [PATCH v2 6/7] arm64: dts: qcom: sm8150: add interconnect nodes
Hey Jonathan,
Thanks for the patch! Please use the
suggested register space definitions
instead.
On 2020-07-13 21:11, Jonathan Marek wrote:
Add the interconnect dts nodes for sm8150.
Signed-off-by: Jonathan Marek
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 82
1 file changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 33ff99132f4f..fa9cd9d60093 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
/ {
@@ -440,6 +441,69 @@ uart2: serial@a9 {
};
};
+ dc_noc: interconnect@14e {
+ compatible = "qcom,sm8150-dc-noc";
+ reg = <0 0x014e 0 0x1000>;
0x0916 0x3200
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ config_noc: interconnect@150 {
+ compatible = "qcom,sm8150-config-noc";
+ reg = <0 0x0150 0 0x1000>;
0x0150 0x7400
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ camnoc_virt: interconnect@162 {
+ compatible = "qcom,sm8150-camnoc-virt";
+ reg = <0 0x0162 0 0x1000>;
0x0ac0 0x1000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ ipa_virt: interconnect-ipa@162 {
+ compatible = "qcom,sm8150-ipa-virt";
+ reg = <0 0x0162 0 0x1000>;
0x01e0 0x1000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ system_noc: interconnect@1629000 {
+ compatible = "qcom,sm8150-system-noc";
+ reg = <0 0x0150 0 0x1000>;
0x0162 0x19400
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e4000 {
+ compatible = "qcom,sm8150-aggre1-noc";
+ reg = <0 0x016e4000 0 0x1000>;
0x016e 0xd080
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre2_noc: interconnect@1706000 {
+ compatible = "qcom,sm8150-aggre2-noc";
+ reg = <0 0x01706000 0 0x1000>;
0x0170 0x3b100
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ compute_noc: interconnect@172 {
+ compatible = "qcom,sm8150-compute-noc";
+ reg = <0 0x0172 0 0x1000>;
0x0172 0x7000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ mmss_noc: interconnect@1749000 {
+ compatible = "qcom,sm8150-mmss-noc";
+ reg = <0 0x01749000 0 0x1000>;
0x0174 0x1c100
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,sm8150-ufshc", "qcom,ufshc",
"jedec,ufs-2.0";
@@ -860,6 +924,20 @@ usb_2_ssphy: lane@88eb200 {
};
};
+ mc_virt: interconnect@968 {
+ compatible = "qcom,sm8150-mc-virt";
+ reg = <0 0x0968 0 0x1000>;
0x0163a000 0x1000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ gem_noc: interconnect@96ab000 {
+ compatible = "qcom,sm8150-gem-noc";
+ reg = <0 0x096ab000 0 0x1000>;
0x0968 0x3e200
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
usb_1: usb@a6f8800 {
compatible = "qcom,sm8150-dwc3", "qcom,dwc3";
reg = <0 0x0a6f8800 0 0x400>;
@@ -1280,6 +1358,10 @@ rpmhpd_opp_turbo_l1: opp11 {
};
};
};
+
+ apps_bcm_voter: bcm_voter {
+ compatible = "qcom,bcm-voter";
+ };
};
cpufreq_hw:
Re: [PATCH v2 7/7] arm64: dts: qcom: sm8250: add interconnect nodes
Hey Jonathan,
Thanks for the patch! Please use the
suggested register space definitions
instead.
On 2020-07-13 21:11, Jonathan Marek wrote:
Add the interconnect dts nodes for sm8250.
Signed-off-by: Jonathan Marek
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 82
1 file changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 636e2196138c..dfc1b7fa7d85 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
please fix ^^ sort order
/ {
interrupt-parent = <>;
@@ -978,6 +979,55 @@ spi13: spi@a94000 {
};
};
+ config_noc: interconnect@150 {
+ compatible = "qcom,sm8250-config-noc";
+ reg = <0 0x0150 0 0x1000>;
0x0150 0xa580
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ ipa_virt: interconnect@162 {
+ compatible = "qcom,sm8250-ipa-virt";
+ reg = <0 0x0162 0 0x1000>;
0x01e0 0x1000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ system_noc: interconnect@1632000 {
+ compatible = "qcom,sm8250-system-noc";
+ reg = <0 0x01632000 0 0x1000>;
0x0162 0x1C200
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre1_noc: interconnect@16e2000 {
+ compatible = "qcom,sm8250-aggre1-noc";
+ reg = <0 0x016e2000 0 0x1000>;
0x016e 0x1f180
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ aggre2_noc: interconnect@1703000 {
+ compatible = "qcom,sm8250-aggre2-noc";
+ reg = <0 0x01703000 0 0x1000>;
0x0170 0x33000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ compute_noc: interconnect@1733000 {
+ compatible = "qcom,sm8250-compute-noc";
+ reg = <0 0x01733000 0 0x1000>;
0x01733000 0xd180
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ mmss_noc: interconnect@174a000 {
+ compatible = "qcom,sm8250-mmss-noc";
+ reg = <0 0x0174a000 0 0x1000>;
0x0174 0x1f080
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
ufs_mem_hc: ufshc@1d84000 {
compatible = "qcom,sm8250-ufshc", "qcom,ufshc",
"jedec,ufs-2.0";
@@ -1364,6 +1414,34 @@ usb_2_ssphy: lane@88eb200 {
};
};
+ dc_noc: interconnect@90c {
+ compatible = "qcom,sm8250-dc-noc";
+ reg = <0 0x090c 0 0x1000>;
0x090c 0x4200
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ mc_virt: interconnect@910 {
+ compatible = "qcom,sm8250-mc-virt";
+ reg = <0 0x0910 0 0x1000>;
0x0163d000 0x1000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ gem_noc: interconnect@9121000 {
+ compatible = "qcom,sm8250-gem-noc";
+ reg = <0 0x09121000 0 0x1000>;
0x0910 0xb4000
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
+ npu_noc: interconnect@999 {
+ compatible = "qcom,sm8250-npu-noc";
+ reg = <0 0x0999 0 0x1000>;
0x0999 0x1600
+ #interconnect-cells = <1>;
+ qcom,bcm-voters = <_bcm_voter>;
+ };
+
usb_1: usb@a6f8800 {
compatible = "qcom,sm8250-dwc3", "qcom,dwc3";
reg = <0 0x0a6f8800 0 0x400>;
@@ -2359,6 +2437,10 @@ rpmhpd_opp_turbo_l1: opp10 {
};
};
};
+
+ apps_bcm_voter: bcm_voter {
+ compatible = "qcom,bcm-voter";
+ };
};
[PATCH v3 2/3] remoteproc: qcom_q6v5_mss: Validate modem blob firmware size before load
The following mem abort is observed when one of the modem blob firmware
size exceeds the allocated mpss region. Fix this by restricting the copy
size to segment size using request_firmware_into_buf before load.
Err Logs:
Unable to handle kernel paging request at virtual address
Mem abort info:
...
Call trace:
__memcpy+0x110/0x180
rproc_start+0xd0/0x190
rproc_boot+0x404/0x550
state_store+0x54/0xf8
dev_attr_store+0x44/0x60
sysfs_kf_write+0x58/0x80
kernfs_fop_write+0x140/0x230
vfs_write+0xc4/0x208
ksys_write+0x74/0xf8
...
Fixes: 051fb70fd4ea4 ("remoteproc: qcom: Driver for the self-authenticating
Hexagon v5")
Cc: sta...@vger.kernel.org
Signed-off-by: Sibi Sankar
---
drivers/remoteproc/qcom_q6v5_mss.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 4e72c9e30426c..f4aa61ba220dc 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -1174,15 +1174,14 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
} else if (phdr->p_filesz) {
/* Replace "xxx.xxx" with "xxx.bxx" */
sprintf(fw_name + fw_name_len - 3, "b%02d", i);
- ret = request_firmware(_fw, fw_name, qproc->dev);
+ ret = request_firmware_into_buf(_fw, fw_name,
qproc->dev,
+ ptr, phdr->p_filesz);
if (ret) {
dev_err(qproc->dev, "failed to load %s\n",
fw_name);
iounmap(ptr);
goto release_firmware;
}
- memcpy(ptr, seg_fw->data, seg_fw->size);
-
release_firmware(seg_fw);
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3 1/3] remoteproc: qcom_q6v5_mss: Validate MBA firmware size before load
The following mem abort is observed when the mba firmware size exceeds
the allocated mba region. MBA firmware size is restricted to a maximum
size of 1M and remaining memory region is used by modem debug policy
firmware when available. Hence verify whether the MBA firmware size lies
within the allocated memory region and is not greater than 1M before
loading.
Err Logs:
Unable to handle kernel paging request at virtual address
Mem abort info:
...
Call trace:
__memcpy+0x110/0x180
rproc_start+0x40/0x218
rproc_boot+0x5b4/0x608
state_store+0x54/0xf8
dev_attr_store+0x44/0x60
sysfs_kf_write+0x58/0x80
kernfs_fop_write+0x140/0x230
vfs_write+0xc4/0x208
ksys_write+0x74/0xf8
__arm64_sys_write+0x24/0x30
...
Fixes: 051fb70fd4ea4 ("remoteproc: qcom: Driver for the self-authenticating
Hexagon v5")
Cc: sta...@vger.kernel.org
Signed-off-by: Sibi Sankar
---
drivers/remoteproc/qcom_q6v5_mss.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 718acebae777f..4e72c9e30426c 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -412,6 +412,12 @@ static int q6v5_load(struct rproc *rproc, const struct
firmware *fw)
{
struct q6v5 *qproc = rproc->priv;
+ /* MBA is restricted to a maximum size of 1M */
+ if (fw->size > qproc->mba_size || fw->size > SZ_1M) {
+ dev_err(qproc->dev, "MBA firmware load failed\n");
+ return -EINVAL;
+ }
+
memcpy(qproc->mba_region, fw->data, fw->size);
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3 3/3] remoteproc: qcom_q6v5_mss: Add modem debug policy support
Add modem debug policy support which will enable coredumps and live
debug support when the msadp firmware is present on secure devices.
Signed-off-by: Sibi Sankar
---
v3:
* Fix dp_fw leak and create a separate func for dp load [Bjorn]
* Reset dp_size on mba_reclaim
v2:
* Use request_firmware_direct [Bjorn]
* Use Bjorn's template to show if debug policy is present
* Add size check to prevent memcpy out of bounds [Bjorn]
drivers/remoteproc/qcom_q6v5_mss.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index f4aa61ba220dc..da99c8504a346 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -191,6 +191,7 @@ struct q6v5 {
phys_addr_t mba_phys;
void *mba_region;
size_t mba_size;
+ size_t dp_size;
phys_addr_t mpss_phys;
phys_addr_t mpss_reloc;
@@ -408,6 +409,21 @@ static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int
*current_perm,
current_perm, next, perms);
}
+static void q6v5_debug_policy_load(struct q6v5 *qproc)
+{
+ const struct firmware *dp_fw;
+
+ if (request_firmware_direct(_fw, "msadp", qproc->dev))
+ return;
+
+ if (SZ_1M + dp_fw->size <= qproc->mba_size) {
+ memcpy(qproc->mba_region + SZ_1M, dp_fw->data, dp_fw->size);
+ qproc->dp_size = dp_fw->size;
+ }
+
+ release_firmware(dp_fw);
+}
+
static int q6v5_load(struct rproc *rproc, const struct firmware *fw)
{
struct q6v5 *qproc = rproc->priv;
@@ -419,6 +435,7 @@ static int q6v5_load(struct rproc *rproc, const struct
firmware *fw)
}
memcpy(qproc->mba_region, fw->data, fw->size);
+ q6v5_debug_policy_load(qproc);
return 0;
}
@@ -928,6 +945,10 @@ static int q6v5_mba_load(struct q6v5 *qproc)
}
writel(qproc->mba_phys, qproc->rmb_base + RMB_MBA_IMAGE_REG);
+ if (qproc->dp_size) {
+ writel(qproc->mba_phys + SZ_1M, qproc->rmb_base +
RMB_PMI_CODE_START_REG);
+ writel(qproc->dp_size, qproc->rmb_base +
RMB_PMI_CODE_LENGTH_REG);
+ }
ret = q6v5proc_reset(qproc);
if (ret)
@@ -996,6 +1017,7 @@ static void q6v5_mba_reclaim(struct q6v5 *qproc)
u32 val;
qproc->dump_mba_loaded = false;
+ qproc->dp_size = 0;
q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_q6);
q6v5proc_halt_axi_port(qproc, qproc->halt_map, qproc->halt_modem);
@@ -1290,7 +1312,8 @@ static int q6v5_start(struct rproc *rproc)
if (ret)
return ret;
- dev_info(qproc->dev, "MBA booted, loading mpss\n");
+ dev_info(qproc->dev, "MBA booted with%s debug policy, loading mpss\n",
+qproc->dp_size ? "" : "out");
ret = q6v5_mpss_load(qproc);
if (ret)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v3 0/3] Add modem debug features
The series adds support for the following modem debug features: * Modem debug policy which enables coredumps/live debug on secure devices * MBA text logs extraction on SC7180 SoCs The series also includes fixes for a couple of mem aborts seen when mba/modem blob size exceeds mba/mpss regions respectively. V3: * Drop mba text log extraction support since its already picked up by Bjorn * Fix dp_fw leak and create a separate func for dp load [Bjorn] * Reset dp_size on mba_reclaim * 2 new patches are included and they validate mba/modem blob size before load V2: * Use request_firmware_direct [Bjorn] * Use Bjorn's template to show if debug policy is present * Add size check to prevent memcpy out of bounds [Bjorn] * Don't dump logs in mba_reclaim path [Bjorn] * Move has_mba_logs check to q6v5_dump_mba_logs [Bjorn] * SDM845 mss was incorrectly marked to support mba logs * Drop patch 3 where mba text logs are added to imem Sibi Sankar (3): remoteproc: qcom_q6v5_mss: Validate MBA firmware size before load remoteproc: qcom_q6v5_mss: Validate modem blob firmware size before load remoteproc: qcom_q6v5_mss: Add modem debug policy support drivers/remoteproc/qcom_q6v5_mss.c | 36 ++ 1 file changed, 32 insertions(+), 4 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 1/2] remoteproc: qcom_q6v5_mss: Add modem debug policy support
On 2020-07-22 09:24, Bjorn Andersson wrote:
On Tue 21 Jul 04:29 PDT 2020, Sibi Sankar wrote:
Add modem debug policy support which will enable coredumps and live
debug support when the msadp firmware is present on secure devices.
Signed-off-by: Sibi Sankar
---
v2:
* Use request_firmware_direct [Bjorn]
* Use Bjorn's template to show if debug policy is present
* Add size check to prevent memcpy out of bounds [Bjorn]
drivers/remoteproc/qcom_q6v5_mss.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c
b/drivers/remoteproc/qcom_q6v5_mss.c
index 0b6f260eb5349..49cd16e050533 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -189,6 +189,7 @@ struct q6v5 {
phys_addr_t mba_phys;
void *mba_region;
size_t mba_size;
+ size_t dp_size;
phys_addr_t mpss_phys;
phys_addr_t mpss_reloc;
@@ -408,6 +409,14 @@ static int q6v5_xfer_mem_ownership(struct q6v5
*qproc, int *current_perm,
static int q6v5_load(struct rproc *rproc, const struct firmware *fw)
{
struct q6v5 *qproc = rproc->priv;
+ const struct firmware *dp_fw;
+
+ if (!request_firmware_direct(_fw, "msadp", qproc->dev) &&
fw->size <= SZ_1M &&
+ (SZ_1M + dp_fw->size) <= qproc->mba_size) {
+ memcpy(qproc->mba_region + SZ_1M, dp_fw->data, dp_fw->size);
+ qproc->dp_size = dp_fw->size;
+ release_firmware(dp_fw);
If request_firmware_direct() succeeds, but return a firmware blob
bigger
than mba_size - SZ_1M you won't get here and will end up leaking dp_fw.
Additionally, there really isn't a need for requesting the firmware in
the first place if fw->size > SZ_1M.
So I think it's better if you break this out in it's own function where
you don't need to squeeze everything into one or two conditionals.
I'll fix dp_fw leak and move it
to a new func. Thanks for the
review.
Regards,
Bjorn
+ }
memcpy(qproc->mba_region, fw->data, fw->size);
@@ -896,6 +905,10 @@ static int q6v5_mba_load(struct q6v5 *qproc)
}
writel(qproc->mba_phys, qproc->rmb_base + RMB_MBA_IMAGE_REG);
+ if (qproc->dp_size) {
+ writel(qproc->mba_phys + SZ_1M, qproc->rmb_base +
RMB_PMI_CODE_START_REG);
+ writel(qproc->dp_size, qproc->rmb_base +
RMB_PMI_CODE_LENGTH_REG);
+ }
ret = q6v5proc_reset(qproc);
if (ret)
@@ -1257,7 +1270,8 @@ static int q6v5_start(struct rproc *rproc)
if (ret)
return ret;
- dev_info(qproc->dev, "MBA booted, loading mpss\n");
+ dev_info(qproc->dev, "MBA booted with%s debug policy, loading
mpss\n",
+qproc->dp_size ? "" : "out");
ret = q6v5_mpss_load(qproc);
if (ret)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
Re: [PATCH] interconnect: Do not skip aggregation for disabled paths
Hey Georgi,
Thanks for the patch!
On 2020-07-21 17:37, Georgi Djakov wrote:
When an interconnect path is being disabled, currently we don't
aggregate
the requests for it afterwards. But the re-aggregation step shouldn't
be
skipped, as it may leave the nodes with outdated bandwidth data. This
outdated data may actually keep the path still enabled and prevent the
device from going into lower power states.
Reported-by: Atul Dhudase
Fixes: 7d374b209083 ("interconnect: Add helpers for enabling/disabling
a path")
Signed-off-by: Georgi Djakov
---
Reviewed-by: Sibi Sankar
drivers/interconnect/core.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 37d5ec970cc1..5174dcb31ab7 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -243,6 +243,7 @@ static int aggregate_requests(struct icc_node
*node)
{
struct icc_provider *p = node->provider;
struct icc_req *r;
+ u32 avg_bw, peak_bw;
node->avg_bw = 0;
node->peak_bw = 0;
@@ -251,9 +252,14 @@ static int aggregate_requests(struct icc_node
*node)
p->pre_aggregate(node);
hlist_for_each_entry(r, >req_list, req_node) {
- if (!r->enabled)
- continue;
- p->aggregate(node, r->tag, r->avg_bw, r->peak_bw,
+ if (r->enabled) {
+ avg_bw = r->avg_bw;
+ peak_bw = r->peak_bw;
+ } else {
+ avg_bw = 0;
+ peak_bw = 0;
+ }
+ p->aggregate(node, r->tag, avg_bw, peak_bw,
>avg_bw, >peak_bw);
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
