| Message ID | 20231027-sc7280-remoteprocs-v1-7-05ce95d9315a@fairphone.com |
|---|---|
| State | New |
| Headers | show |
| Series | Remoteprocs (ADSP, CDSP, WPSS) for SC7280 | expand |
On 27/10/2023 16:20, Luca Weiss wrote: > Add the node for the ADSP found on the SC7280 SoC, using standard > Qualcomm firmware. > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > yupik.dtsi since the other areas also seem to match that file there, > though I cannot be sure there. > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > --- > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > 2 files changed, 143 insertions(+) Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
On 10/27/2023 7:50 PM, Luca Weiss wrote: > Add the node for the ADSP found on the SC7280 SoC, using standard > Qualcomm firmware. > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > yupik.dtsi since the other areas also seem to match that file there, > though I cannot be sure there. > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > --- > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > 2 files changed, 143 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > index eb55616e0892..6e5a9d4c1fda 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { > no-map; > }; > > + cdsp_mem: memory@88f00000 { > + reg = <0x0 0x88f00000 0x0 0x1e00000>; > + no-map; > + }; > + Just a question, why to do it here, if chrome does not use this ? -Mukesh > camera_mem: memory@8ad00000 { > reg = <0x0 0x8ad00000 0x0 0x500000>; > no-map; > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi > index cc153f4e6979..e15646289bf7 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi > @@ -3815,6 +3815,144 @@ nsp_noc: interconnect@a0c0000 { > qcom,bcm-voters = <&apps_bcm_voter>; > }; > > + remoteproc_cdsp: remoteproc@a300000 { > + compatible = "qcom,sc7280-cdsp-pas"; > + reg = <0 0x0a300000 0 0x10000>; > + > + interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_LEVEL_HIGH>, > + <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, > + <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, > + <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, > + <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, > + <&cdsp_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; > + interrupt-names = "wdog", "fatal", "ready", "handover", > + "stop-ack", "shutdown-ack"; > + > + clocks = <&rpmhcc RPMH_CXO_CLK>; > + clock-names = "xo"; > + > + power-domains = <&rpmhpd SC7280_CX>, > + <&rpmhpd SC7280_MX>; > + power-domain-names = "cx", "mx"; > + > + interconnects = <&nsp_noc MASTER_CDSP_PROC 0 &mc_virt SLAVE_EBI1 0>; > + > + memory-region = <&cdsp_mem>; > + > + qcom,qmp = <&aoss_qmp>; > + > + qcom,smem-states = <&cdsp_smp2p_out 0>; > + qcom,smem-state-names = "stop"; > + > + status = "disabled"; > + > + glink-edge { > + interrupts-extended = <&ipcc IPCC_CLIENT_CDSP > + IPCC_MPROC_SIGNAL_GLINK_QMP > + IRQ_TYPE_EDGE_RISING>; > + mboxes = <&ipcc IPCC_CLIENT_CDSP > + IPCC_MPROC_SIGNAL_GLINK_QMP>; > + > + label = "cdsp"; > + qcom,remote-pid = <5>; > + > + fastrpc { > + compatible = "qcom,fastrpc"; > + qcom,glink-channels = "fastrpcglink-apps-dsp"; > + label = "cdsp"; > + qcom,non-secure-domain; > + #address-cells = <1>; > + #size-cells = <0>; > + > + compute-cb@1 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <1>; > + iommus = <&apps_smmu 0x11a1 0x0420>, > + <&apps_smmu 0x1181 0x0420>; > + }; > + > + compute-cb@2 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <2>; > + iommus = <&apps_smmu 0x11a2 0x0420>, > + <&apps_smmu 0x1182 0x0420>; > + }; > + > + compute-cb@3 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <3>; > + iommus = <&apps_smmu 0x11a3 0x0420>, > + <&apps_smmu 0x1183 0x0420>; > + }; > + > + compute-cb@4 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <4>; > + iommus = <&apps_smmu 0x11a4 0x0420>, > + <&apps_smmu 0x1184 0x0420>; > + }; > + > + compute-cb@5 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <5>; > + iommus = <&apps_smmu 0x11a5 0x0420>, > + <&apps_smmu 0x1185 0x0420>; > + }; > + > + compute-cb@6 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <6>; > + iommus = <&apps_smmu 0x11a6 0x0420>, > + <&apps_smmu 0x1186 0x0420>; > + }; > + > + compute-cb@7 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <7>; > + iommus = <&apps_smmu 0x11a7 0x0420>, > + <&apps_smmu 0x1187 0x0420>; > + }; > + > + compute-cb@8 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <8>; > + iommus = <&apps_smmu 0x11a8 0x0420>, > + <&apps_smmu 0x1188 0x0420>; > + }; > + > + /* note: secure cb9 in downstream */ > + > + compute-cb@11 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <11>; > + iommus = <&apps_smmu 0x11ab 0x0420>, > + <&apps_smmu 0x118b 0x0420>; > + }; > + > + compute-cb@12 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <12>; > + iommus = <&apps_smmu 0x11ac 0x0420>, > + <&apps_smmu 0x118c 0x0420>; > + }; > + > + compute-cb@13 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <13>; > + iommus = <&apps_smmu 0x11ad 0x0420>, > + <&apps_smmu 0x118d 0x0420>; > + }; > + > + compute-cb@14 { > + compatible = "qcom,fastrpc-compute-cb"; > + reg = <14>; > + iommus = <&apps_smmu 0x11ae 0x0420>, > + <&apps_smmu 0x118e 0x0420>; > + }; > + }; > + }; > + }; > + > usb_1: usb@a6f8800 { > compatible = "qcom,sc7280-dwc3", "qcom,dwc3"; > reg = <0 0x0a6f8800 0 0x400>; >
On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote: > > > On 10/27/2023 7:50 PM, Luca Weiss wrote: > > Add the node for the ADSP found on the SC7280 SoC, using standard > > Qualcomm firmware. > > > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > > yupik.dtsi since the other areas also seem to match that file there, > > though I cannot be sure there. > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > --- > > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > > 2 files changed, 143 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > index eb55616e0892..6e5a9d4c1fda 100644 > > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { > > no-map; > > }; > > > > + cdsp_mem: memory@88f00000 { > > + reg = <0x0 0x88f00000 0x0 0x1e00000>; > > + no-map; > > + }; > > + > > Just a question, why to do it here, if chrome does not use this ? Other memory regions in sc7280.dtsi also get referenced but not actually defined in that file, like mpss_mem and wpss_mem. Alternatively we can also try and solve this differently, but then we should probably also adjust mpss and wpss to be consistent. Apart from either declaring cdsp_mem in sc7280.dtsi or "/delete-property/ memory-region;" for CDSP I don't really have better ideas though. I also imagine these ChromeOS devices will want to enable cdsp at some point but I don't know any plans there. Regards Luca > > -Mukesh > > > camera_mem: memory@8ad00000 { > > reg = <0x0 0x8ad00000 0x0 0x500000>; > > no-map; > > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi > > index cc153f4e6979..e15646289bf7 100644 > > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi > > @@ -3815,6 +3815,144 @@ nsp_noc: interconnect@a0c0000 { > > qcom,bcm-voters = <&apps_bcm_voter>; > > }; > > > > + remoteproc_cdsp: remoteproc@a300000 { > > + compatible = "qcom,sc7280-cdsp-pas"; > > + reg = <0 0x0a300000 0 0x10000>; > > + > > + interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_LEVEL_HIGH>, > > + <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, > > + <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, > > + <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, > > + <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, > > + <&cdsp_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; > > + interrupt-names = "wdog", "fatal", "ready", "handover", > > + "stop-ack", "shutdown-ack"; > > + > > + clocks = <&rpmhcc RPMH_CXO_CLK>; > > + clock-names = "xo"; > > + > > + power-domains = <&rpmhpd SC7280_CX>, > > + <&rpmhpd SC7280_MX>; > > + power-domain-names = "cx", "mx"; > > + > > + interconnects = <&nsp_noc MASTER_CDSP_PROC 0 &mc_virt SLAVE_EBI1 0>; > > + > > + memory-region = <&cdsp_mem>; > > + > > + qcom,qmp = <&aoss_qmp>; > > + > > + qcom,smem-states = <&cdsp_smp2p_out 0>; > > + qcom,smem-state-names = "stop"; > > + > > + status = "disabled"; > > + > > + glink-edge { > > + interrupts-extended = <&ipcc IPCC_CLIENT_CDSP > > + IPCC_MPROC_SIGNAL_GLINK_QMP > > + IRQ_TYPE_EDGE_RISING>; > > + mboxes = <&ipcc IPCC_CLIENT_CDSP > > + IPCC_MPROC_SIGNAL_GLINK_QMP>; > > + > > + label = "cdsp"; > > + qcom,remote-pid = <5>; > > + > > + fastrpc { > > + compatible = "qcom,fastrpc"; > > + qcom,glink-channels = "fastrpcglink-apps-dsp"; > > + label = "cdsp"; > > + qcom,non-secure-domain; > > + #address-cells = <1>; > > + #size-cells = <0>; > > + > > + compute-cb@1 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <1>; > > + iommus = <&apps_smmu 0x11a1 0x0420>, > > + <&apps_smmu 0x1181 0x0420>; > > + }; > > + > > + compute-cb@2 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <2>; > > + iommus = <&apps_smmu 0x11a2 0x0420>, > > + <&apps_smmu 0x1182 0x0420>; > > + }; > > + > > + compute-cb@3 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <3>; > > + iommus = <&apps_smmu 0x11a3 0x0420>, > > + <&apps_smmu 0x1183 0x0420>; > > + }; > > + > > + compute-cb@4 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <4>; > > + iommus = <&apps_smmu 0x11a4 0x0420>, > > + <&apps_smmu 0x1184 0x0420>; > > + }; > > + > > + compute-cb@5 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <5>; > > + iommus = <&apps_smmu 0x11a5 0x0420>, > > + <&apps_smmu 0x1185 0x0420>; > > + }; > > + > > + compute-cb@6 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <6>; > > + iommus = <&apps_smmu 0x11a6 0x0420>, > > + <&apps_smmu 0x1186 0x0420>; > > + }; > > + > > + compute-cb@7 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <7>; > > + iommus = <&apps_smmu 0x11a7 0x0420>, > > + <&apps_smmu 0x1187 0x0420>; > > + }; > > + > > + compute-cb@8 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <8>; > > + iommus = <&apps_smmu 0x11a8 0x0420>, > > + <&apps_smmu 0x1188 0x0420>; > > + }; > > + > > + /* note: secure cb9 in downstream */ > > + > > + compute-cb@11 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <11>; > > + iommus = <&apps_smmu 0x11ab 0x0420>, > > + <&apps_smmu 0x118b 0x0420>; > > + }; > > + > > + compute-cb@12 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <12>; > > + iommus = <&apps_smmu 0x11ac 0x0420>, > > + <&apps_smmu 0x118c 0x0420>; > > + }; > > + > > + compute-cb@13 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <13>; > > + iommus = <&apps_smmu 0x11ad 0x0420>, > > + <&apps_smmu 0x118d 0x0420>; > > + }; > > + > > + compute-cb@14 { > > + compatible = "qcom,fastrpc-compute-cb"; > > + reg = <14>; > > + iommus = <&apps_smmu 0x11ae 0x0420>, > > + <&apps_smmu 0x118e 0x0420>; > > + }; > > + }; > > + }; > > + }; > > + > > usb_1: usb@a6f8800 { > > compatible = "qcom,sc7280-dwc3", "qcom,dwc3"; > > reg = <0 0x0a6f8800 0 0x400>; > >
Hi, On Mon, Oct 30, 2023 at 2:12 AM Luca Weiss <luca.weiss@fairphone.com> wrote: > > On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote: > > > > > > On 10/27/2023 7:50 PM, Luca Weiss wrote: > > > Add the node for the ADSP found on the SC7280 SoC, using standard > > > Qualcomm firmware. > > > > > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > > > yupik.dtsi since the other areas also seem to match that file there, > > > though I cannot be sure there. > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > --- > > > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > > > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > > > 2 files changed, 143 insertions(+) > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > index eb55616e0892..6e5a9d4c1fda 100644 > > > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { > > > no-map; > > > }; > > > > > > + cdsp_mem: memory@88f00000 { > > > + reg = <0x0 0x88f00000 0x0 0x1e00000>; > > > + no-map; > > > + }; > > > + > > > > Just a question, why to do it here, if chrome does not use this ? > > Other memory regions in sc7280.dtsi also get referenced but not actually > defined in that file, like mpss_mem and wpss_mem. Alternatively we can > also try and solve this differently, but then we should probably also > adjust mpss and wpss to be consistent. > > Apart from either declaring cdsp_mem in sc7280.dtsi or > "/delete-property/ memory-region;" for CDSP I don't really have better > ideas though. > > I also imagine these ChromeOS devices will want to enable cdsp at some > point but I don't know any plans there. Given that "remoteproc_cdsp" has status "disabled" in the dtsi, it feels like the dtsi shouldn't be reserving memory. I guess maybe memory regions can't be status "disabled"? -Doug
On Mon Oct 30, 2023 at 3:11 PM CET, Doug Anderson wrote: > Hi, > > On Mon, Oct 30, 2023 at 2:12 AM Luca Weiss <luca.weiss@fairphone.com> wrote: > > > > On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote: > > > > > > > > > On 10/27/2023 7:50 PM, Luca Weiss wrote: > > > > Add the node for the ADSP found on the SC7280 SoC, using standard > > > > Qualcomm firmware. > > > > > > > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > > > > yupik.dtsi since the other areas also seem to match that file there, > > > > though I cannot be sure there. > > > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > > --- > > > > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > > > > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > > > > 2 files changed, 143 insertions(+) > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > index eb55616e0892..6e5a9d4c1fda 100644 > > > > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { > > > > no-map; > > > > }; > > > > > > > > + cdsp_mem: memory@88f00000 { > > > > + reg = <0x0 0x88f00000 0x0 0x1e00000>; > > > > + no-map; > > > > + }; > > > > + > > > > > > Just a question, why to do it here, if chrome does not use this ? > > > > Other memory regions in sc7280.dtsi also get referenced but not actually > > defined in that file, like mpss_mem and wpss_mem. Alternatively we can > > also try and solve this differently, but then we should probably also > > adjust mpss and wpss to be consistent. > > > > Apart from either declaring cdsp_mem in sc7280.dtsi or > > "/delete-property/ memory-region;" for CDSP I don't really have better > > ideas though. > > > > I also imagine these ChromeOS devices will want to enable cdsp at some > > point but I don't know any plans there. > > Given that "remoteproc_cdsp" has status "disabled" in the dtsi, it > feels like the dtsi shouldn't be reserving memory. I guess maybe > memory regions can't be status "disabled"? Hi Doug, That's how it works in really any qcom dtsi though. I think in most/all cases normally the reserved-memory is already declared in the SoC dtsi file and also used with the memory-region property. I wouldn't be against adjusting sc7280.dtsi to match the way it's done in the other dtsi files though, so to have all the required labels already defined in the dtsi so it doesn't rely on these labels being defined in the device dts. In other words, currently if you include sc7280.dtsi and try to build, you first have to define the labels mpss_mem and wpss_mem (after this patch series also cdsp_mem and adsp_mem) for it to build. I'm quite neutral either way, let me know :) Regards Luca > > -Doug
Hi, On Mon, Oct 30, 2023 at 7:43 AM Luca Weiss <luca.weiss@fairphone.com> wrote: > > On Mon Oct 30, 2023 at 3:11 PM CET, Doug Anderson wrote: > > Hi, > > > > On Mon, Oct 30, 2023 at 2:12 AM Luca Weiss <luca.weiss@fairphone.com> wrote: > > > > > > On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote: > > > > > > > > > > > > On 10/27/2023 7:50 PM, Luca Weiss wrote: > > > > > Add the node for the ADSP found on the SC7280 SoC, using standard > > > > > Qualcomm firmware. > > > > > > > > > > The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 > > > > > yupik.dtsi since the other areas also seem to match that file there, > > > > > though I cannot be sure there. > > > > > > > > > > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> > > > > > --- > > > > > arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + > > > > > arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ > > > > > 2 files changed, 143 insertions(+) > > > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > > index eb55616e0892..6e5a9d4c1fda 100644 > > > > > --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > > +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi > > > > > @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { > > > > > no-map; > > > > > }; > > > > > > > > > > + cdsp_mem: memory@88f00000 { > > > > > + reg = <0x0 0x88f00000 0x0 0x1e00000>; > > > > > + no-map; > > > > > + }; > > > > > + > > > > > > > > Just a question, why to do it here, if chrome does not use this ? > > > > > > Other memory regions in sc7280.dtsi also get referenced but not actually > > > defined in that file, like mpss_mem and wpss_mem. Alternatively we can > > > also try and solve this differently, but then we should probably also > > > adjust mpss and wpss to be consistent. > > > > > > Apart from either declaring cdsp_mem in sc7280.dtsi or > > > "/delete-property/ memory-region;" for CDSP I don't really have better > > > ideas though. > > > > > > I also imagine these ChromeOS devices will want to enable cdsp at some > > > point but I don't know any plans there. > > > > Given that "remoteproc_cdsp" has status "disabled" in the dtsi, it > > feels like the dtsi shouldn't be reserving memory. I guess maybe > > memory regions can't be status "disabled"? > > Hi Doug, > > That's how it works in really any qcom dtsi though. I think in most/all > cases normally the reserved-memory is already declared in the SoC dtsi > file and also used with the memory-region property. > > I wouldn't be against adjusting sc7280.dtsi to match the way it's done > in the other dtsi files though, so to have all the required labels > already defined in the dtsi so it doesn't rely on these labels being > defined in the device dts. > > In other words, currently if you include sc7280.dtsi and try to build, > you first have to define the labels mpss_mem and wpss_mem (after this > patch series also cdsp_mem and adsp_mem) for it to build. > > I'm quite neutral either way, let me know :) I haven't done a ton of thinking about this, so if I'm spouting gibberish then feel free to ignore me. :-P It just feels weird that when all the "dtsi" files are combined and you look at what you end up on a sc7280 Chrome board that you'll be reserving 32MB of memory for a device that's set (in the same device tree) to be "disabled", right? ...the 32MB is completely wasted, I think. If we wanted to enable the CDSP we'd have to modify the device tree anyway, so it seems like that same modification would set the CDSP to "okay" and also reserve the memory... In that vein, it seems like maybe you could move the "cdsp_mem" to the SoC .dsti file with a status of "disabled". . I guess we don't do that elsewhere, but maybe we should be? As far as I can tell without testing it (just looking at fdt_scan_reserved_mem()) this should work... -Doug
diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi index eb55616e0892..6e5a9d4c1fda 100644 --- a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi @@ -29,6 +29,11 @@ adsp_mem: memory@86700000 { no-map; }; + cdsp_mem: memory@88f00000 { + reg = <0x0 0x88f00000 0x0 0x1e00000>; + no-map; + }; + camera_mem: memory@8ad00000 { reg = <0x0 0x8ad00000 0x0 0x500000>; no-map; diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi index cc153f4e6979..e15646289bf7 100644 --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi @@ -3815,6 +3815,144 @@ nsp_noc: interconnect@a0c0000 { qcom,bcm-voters = <&apps_bcm_voter>; }; + remoteproc_cdsp: remoteproc@a300000 { + compatible = "qcom,sc7280-cdsp-pas"; + reg = <0 0x0a300000 0 0x10000>; + + interrupts-extended = <&intc GIC_SPI 578 IRQ_TYPE_LEVEL_HIGH>, + <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", "fatal", "ready", "handover", + "stop-ack", "shutdown-ack"; + + clocks = <&rpmhcc RPMH_CXO_CLK>; + clock-names = "xo"; + + power-domains = <&rpmhpd SC7280_CX>, + <&rpmhpd SC7280_MX>; + power-domain-names = "cx", "mx"; + + interconnects = <&nsp_noc MASTER_CDSP_PROC 0 &mc_virt SLAVE_EBI1 0>; + + memory-region = <&cdsp_mem>; + + qcom,qmp = <&aoss_qmp>; + + qcom,smem-states = <&cdsp_smp2p_out 0>; + qcom,smem-state-names = "stop"; + + status = "disabled"; + + glink-edge { + interrupts-extended = <&ipcc IPCC_CLIENT_CDSP + IPCC_MPROC_SIGNAL_GLINK_QMP + IRQ_TYPE_EDGE_RISING>; + mboxes = <&ipcc IPCC_CLIENT_CDSP + IPCC_MPROC_SIGNAL_GLINK_QMP>; + + label = "cdsp"; + qcom,remote-pid = <5>; + + fastrpc { + compatible = "qcom,fastrpc"; + qcom,glink-channels = "fastrpcglink-apps-dsp"; + label = "cdsp"; + qcom,non-secure-domain; + #address-cells = <1>; + #size-cells = <0>; + + compute-cb@1 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <1>; + iommus = <&apps_smmu 0x11a1 0x0420>, + <&apps_smmu 0x1181 0x0420>; + }; + + compute-cb@2 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <2>; + iommus = <&apps_smmu 0x11a2 0x0420>, + <&apps_smmu 0x1182 0x0420>; + }; + + compute-cb@3 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <3>; + iommus = <&apps_smmu 0x11a3 0x0420>, + <&apps_smmu 0x1183 0x0420>; + }; + + compute-cb@4 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <4>; + iommus = <&apps_smmu 0x11a4 0x0420>, + <&apps_smmu 0x1184 0x0420>; + }; + + compute-cb@5 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <5>; + iommus = <&apps_smmu 0x11a5 0x0420>, + <&apps_smmu 0x1185 0x0420>; + }; + + compute-cb@6 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <6>; + iommus = <&apps_smmu 0x11a6 0x0420>, + <&apps_smmu 0x1186 0x0420>; + }; + + compute-cb@7 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <7>; + iommus = <&apps_smmu 0x11a7 0x0420>, + <&apps_smmu 0x1187 0x0420>; + }; + + compute-cb@8 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <8>; + iommus = <&apps_smmu 0x11a8 0x0420>, + <&apps_smmu 0x1188 0x0420>; + }; + + /* note: secure cb9 in downstream */ + + compute-cb@11 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <11>; + iommus = <&apps_smmu 0x11ab 0x0420>, + <&apps_smmu 0x118b 0x0420>; + }; + + compute-cb@12 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <12>; + iommus = <&apps_smmu 0x11ac 0x0420>, + <&apps_smmu 0x118c 0x0420>; + }; + + compute-cb@13 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <13>; + iommus = <&apps_smmu 0x11ad 0x0420>, + <&apps_smmu 0x118d 0x0420>; + }; + + compute-cb@14 { + compatible = "qcom,fastrpc-compute-cb"; + reg = <14>; + iommus = <&apps_smmu 0x11ae 0x0420>, + <&apps_smmu 0x118e 0x0420>; + }; + }; + }; + }; + usb_1: usb@a6f8800 { compatible = "qcom,sc7280-dwc3", "qcom,dwc3"; reg = <0 0x0a6f8800 0 0x400>;
Add the node for the ADSP found on the SC7280 SoC, using standard Qualcomm firmware. The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4 yupik.dtsi since the other areas also seem to match that file there, though I cannot be sure there. Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> --- arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi | 5 + arch/arm64/boot/dts/qcom/sc7280.dtsi | 138 +++++++++++++++++++++ 2 files changed, 143 insertions(+)