In order to enable CDSP support for SDM660 SoC:
* add shared memory p2p nodes for CDSP
* add CDSP-specific smmu node
* add CDSP peripheral image loader node
Memory region for CDSP in SDM660 occupies the same spot as
TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
In sdm660.dtsi replace buffer_mem inherited from SDM630 with
cdsp_region, which is also larger in size.
SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
related nodes and add buffer_mem back.
Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm636.dtsi | 23 +++--
arch/arm64/boot/dts/qcom/sdm660.dtsi | 162 +++++++++++++++++++++++++++++++++++
3 files changed, 177 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index 8b1a45a4e56e..a6a1933229b9 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -563,7 +563,7 @@ modem_smp2p_in: slave-kernel {
};
};
- soc@0 {
+ soc: soc@0 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 0 0xffffffff>;
diff --git a/arch/arm64/boot/dts/qcom/sdm636.dtsi b/arch/arm64/boot/dts/qcom/sdm636.dtsi
index ae15d81fa3f9..38e6e3bfc3ce 100644
--- a/arch/arm64/boot/dts/qcom/sdm636.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm636.dtsi
@@ -7,15 +7,20 @@
#include "sdm660.dtsi"
-/*
- * According to the downstream DTS,
- * 636 is basically a 660 except for
- * different CPU frequencies, Adreno
- * 509 instead of 512 and lack of
- * turing IP. These differences will
- * be addressed when the aforementioned
- * peripherals will be enabled upstream.
- */
+/delete-node/ &remoteproc_cdsp;
+/delete-node/ &cdsp_smmu;
+/delete-node/ &cdsp_region;
+
+/ {
+ /delete-node/ smp2p-cdsp;
+
+ reserved-memory {
+ buffer_mem: tzbuffer@94a00000 {
+ reg = <0x0 0x94a00000 0x00 0x100000>;
+ no-map;
+ };
+ };
+};
&adreno_gpu {
compatible = "qcom,adreno-509.0", "qcom,adreno";
diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi b/arch/arm64/boot/dts/qcom/sdm660.dtsi
index ef4a563c0feb..d50cce25ccbe 100644
--- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
@@ -9,6 +9,37 @@
#include "sdm630.dtsi"
+/delete-node/ &buffer_mem;
+
+/ {
+ smp2p-cdsp {
+ compatible = "qcom,smp2p";
+ qcom,smem = <94>, <432>;
+ interrupts = <GIC_SPI 514 IRQ_TYPE_EDGE_RISING>;
+ mboxes = <&apcs_glb 30>;
+ 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>;
+ };
+ };
+
+ reserved-memory {
+ cdsp_region: cdsp@94a00000 {
+ reg = <0x0 0x94a00000 0x00 0x600000>;
+ no-map;
+ };
+ };
+};
+
&adreno_gpu {
compatible = "qcom,adreno-512.0", "qcom,adreno";
operating-points-v2 = <&gpu_sdm660_opp_table>;
@@ -247,6 +278,137 @@ &mmcc {
<0>;
};
+&soc {
+ cdsp_smmu: iommu@5180000 {
+ compatible = "qcom,sdm630-smmu-v2", "qcom,smmu-v2";
+ reg = <0x5180000 0x40000>;
+ #iommu-cells = <1>;
+
+ #global-interrupts = <2>;
+ interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 533 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 534 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 535 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 536 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 537 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 538 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 539 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 540 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 541 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 542 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 543 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 544 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 545 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 546 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 547 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 548 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 549 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_HLOS1_VOTE_TURING_ADSP_SMMU_CLK>;
+ clock-names = "bus";
+
+ power-domains = <&gcc HLOS1_VOTE_TURING_ADSP_GDSC>;
+
+ };
+
+ remoteproc_cdsp: remoteproc@1a300000 {
+ compatible = "qcom,sdm660-cdsp-pas";
+ reg = <0x1a300000 0x00100>;
+ interrupts-extended = <&intc GIC_SPI 518 IRQ_TYPE_EDGE_RISING>,
+ <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack";
+
+ clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>;
+ clock-names = "xo";
+
+ memory-region = <&cdsp_region>;
+ power-domains = <&rpmpd SDM660_VDDCX>;
+ power-domain-names = "cx";
+
+ qcom,smem-states = <&cdsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+
+ glink-edge {
+ interrupts = <GIC_SPI 513 IRQ_TYPE_EDGE_RISING>;
+
+ label = "turing";
+ mboxes = <&apcs_glb 29>;
+ 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@5 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <5>;
+ iommus = <&cdsp_smmu 3>;
+ };
+
+ compute-cb@6 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <6>;
+ iommus = <&cdsp_smmu 4>;
+ };
+
+ compute-cb@7 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <7>;
+ iommus = <&cdsp_smmu 5>;
+ };
+
+ compute-cb@8 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <8>;
+ iommus = <&cdsp_smmu 6>;
+ };
+
+ compute-cb@9 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <9>;
+ iommus = <&cdsp_smmu 7>;
+ };
+
+ compute-cb@10 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <10>;
+ iommus = <&cdsp_smmu 8>;
+ };
+
+ compute-cb@11 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <11>;
+ iommus = <&cdsp_smmu 9>;
+ };
+
+ compute-cb@12 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <12>;
+ iommus = <&cdsp_smmu 10>;
+ };
+
+ compute-cb@13 {
+ compatible = "qcom,fastrpc-compute-cb";
+ reg = <13>;
+ iommus = <&cdsp_smmu 11>;
+ };
+ };
+ };
+ };
+};
+
&tlmm {
compatible = "qcom,sdm660-pinctrl";
};
--
2.51.1
23.10.2025 22:51, Nickolay Goppen пишет:
> In order to enable CDSP support for SDM660 SoC:
> * add shared memory p2p nodes for CDSP
> * add CDSP-specific smmu node
> * add CDSP peripheral image loader node
>
> Memory region for CDSP in SDM660 occupies the same spot as
> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
> cdsp_region, which is also larger in size.
>
> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
> related nodes and add buffer_mem back.
>
> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> ---
> arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sdm636.dtsi | 23 +++--
> arch/arm64/boot/dts/qcom/sdm660.dtsi | 162 +++++++++++++++++++++++++++++++++++
> 3 files changed, 177 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> index 8b1a45a4e56e..a6a1933229b9 100644
> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> @@ -563,7 +563,7 @@ modem_smp2p_in: slave-kernel {
> };
> };
>
> - soc@0 {
> + soc: soc@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <0 0 0 0xffffffff>;
> diff --git a/arch/arm64/boot/dts/qcom/sdm636.dtsi b/arch/arm64/boot/dts/qcom/sdm636.dtsi
> index ae15d81fa3f9..38e6e3bfc3ce 100644
> --- a/arch/arm64/boot/dts/qcom/sdm636.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm636.dtsi
> @@ -7,15 +7,20 @@
>
> #include "sdm660.dtsi"
>
> -/*
> - * According to the downstream DTS,
> - * 636 is basically a 660 except for
> - * different CPU frequencies, Adreno
> - * 509 instead of 512 and lack of
> - * turing IP. These differences will
> - * be addressed when the aforementioned
> - * peripherals will be enabled upstream.
> - */
> +/delete-node/ &remoteproc_cdsp;
> +/delete-node/ &cdsp_smmu;
> +/delete-node/ &cdsp_region;
> +
> +/ {
> + /delete-node/ smp2p-cdsp;
> +
> + reserved-memory {
> + buffer_mem: tzbuffer@94a00000 {
> + reg = <0x0 0x94a00000 0x00 0x100000>;
> + no-map;
> + };
> + };
> +};
>
> &adreno_gpu {
> compatible = "qcom,adreno-509.0", "qcom,adreno";
> diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi b/arch/arm64/boot/dts/qcom/sdm660.dtsi
> index ef4a563c0feb..d50cce25ccbe 100644
> --- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
> @@ -9,6 +9,37 @@
>
> #include "sdm630.dtsi"
>
> +/delete-node/ &buffer_mem;
> +
> +/ {
> + smp2p-cdsp {
> + compatible = "qcom,smp2p";
> + qcom,smem = <94>, <432>;
> + interrupts = <GIC_SPI 514 IRQ_TYPE_EDGE_RISING>;
> + mboxes = <&apcs_glb 30>;
> + 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>;
> + };
> + };
> +
> + reserved-memory {
> + cdsp_region: cdsp@94a00000 {
> + reg = <0x0 0x94a00000 0x00 0x600000>;
> + no-map;
> + };
> + };
> +};
> +
> &adreno_gpu {
> compatible = "qcom,adreno-512.0", "qcom,adreno";
> operating-points-v2 = <&gpu_sdm660_opp_table>;
> @@ -247,6 +278,137 @@ &mmcc {
> <0>;
> };
>
> +&soc {
> + cdsp_smmu: iommu@5180000 {
> + compatible = "qcom,sdm630-smmu-v2", "qcom,smmu-v2";
> + reg = <0x5180000 0x40000>;
> + #iommu-cells = <1>;
> +
> + #global-interrupts = <2>;
> + interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 533 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 534 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 535 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 536 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 537 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 538 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 539 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 540 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 541 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 542 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 543 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 544 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 545 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 546 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 547 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 548 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 549 IRQ_TYPE_LEVEL_HIGH>;
> +
> + clocks = <&gcc GCC_HLOS1_VOTE_TURING_ADSP_SMMU_CLK>;
> + clock-names = "bus";
> +
> + power-domains = <&gcc HLOS1_VOTE_TURING_ADSP_GDSC>;
> +
> + };
> +
> + remoteproc_cdsp: remoteproc@1a300000 {
> + compatible = "qcom,sdm660-cdsp-pas";
> + reg = <0x1a300000 0x00100>;
> + interrupts-extended = <&intc GIC_SPI 518 IRQ_TYPE_EDGE_RISING>,
> + <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> + <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> + <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> + <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "wdog",
> + "fatal",
> + "ready",
> + "handover",
> + "stop-ack";
> +
> + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>;
> + clock-names = "xo";
> +
> + memory-region = <&cdsp_region>;
> + power-domains = <&rpmpd SDM660_VDDCX>;
> + power-domain-names = "cx";
> +
> + qcom,smem-states = <&cdsp_smp2p_out 0>;
> + qcom,smem-state-names = "stop";
> +
> + glink-edge {
> + interrupts = <GIC_SPI 513 IRQ_TYPE_EDGE_RISING>;
> +
> + label = "turing";
> + mboxes = <&apcs_glb 29>;
> + 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@5 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <5>;
> + iommus = <&cdsp_smmu 3>;
> + };
> +
> + compute-cb@6 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <6>;
> + iommus = <&cdsp_smmu 4>;
> + };
> +
> + compute-cb@7 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <7>;
> + iommus = <&cdsp_smmu 5>;
> + };
> +
> + compute-cb@8 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <8>;
> + iommus = <&cdsp_smmu 6>;
> + };
> +
> + compute-cb@9 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <9>;
> + iommus = <&cdsp_smmu 7>;
> + };
> +
> + compute-cb@10 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <10>;
> + iommus = <&cdsp_smmu 8>;
> + };
> +
> + compute-cb@11 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <11>;
> + iommus = <&cdsp_smmu 9>;
> + };
> +
> + compute-cb@12 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <12>;
> + iommus = <&cdsp_smmu 10>;
> + };
> +
> + compute-cb@13 {
> + compatible = "qcom,fastrpc-compute-cb";
> + reg = <13>;
> + iommus = <&cdsp_smmu 11>;
> + };
> + };
> + };
> + };
> +};
> +
> &tlmm {
> compatible = "qcom,sdm660-pinctrl";
> };
>
I've found out that all (both ADSP's and CDSP's) fastrpc-compute-cb's in
downstream are defined under the one node [1], and all of them are
handled by one adsprpc driver. There's a node [2], where a memory-region
is assigned to this driver.
Does this mean that both DSP's are using this one region for FastRPC?
[1]
https://github.com/pix106/android_kernel_xiaomi_southwest-4.19/blob/main/arch/arm64/boot/dts/vendor/qcom/sdm660.dtsi#L1349
[2]
https://github.com/pix106/android_kernel_xiaomi_southwest-4.19/blob/main/arch/arm64/boot/dts/vendor/qcom/sdm660.dtsi#L1342
--
Best regards,
Nickolay
11.12.2025 15:24, Nickolay Goppen пишет:
>
> 23.10.2025 22:51, Nickolay Goppen пишет:
>> In order to enable CDSP support for SDM660 SoC:
>> * add shared memory p2p nodes for CDSP
>> * add CDSP-specific smmu node
>> * add CDSP peripheral image loader node
>>
>> Memory region for CDSP in SDM660 occupies the same spot as
>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>> cdsp_region, which is also larger in size.
>>
>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>> related nodes and add buffer_mem back.
>>
>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>> ---
>> arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
>> arch/arm64/boot/dts/qcom/sdm636.dtsi | 23 +++--
>> arch/arm64/boot/dts/qcom/sdm660.dtsi | 162
>> +++++++++++++++++++++++++++++++++++
>> 3 files changed, 177 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> index 8b1a45a4e56e..a6a1933229b9 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> @@ -563,7 +563,7 @@ modem_smp2p_in: slave-kernel {
>> };
>> };
>> - soc@0 {
>> + soc: soc@0 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> ranges = <0 0 0 0xffffffff>;
>> diff --git a/arch/arm64/boot/dts/qcom/sdm636.dtsi
>> b/arch/arm64/boot/dts/qcom/sdm636.dtsi
>> index ae15d81fa3f9..38e6e3bfc3ce 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm636.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm636.dtsi
>> @@ -7,15 +7,20 @@
>> #include "sdm660.dtsi"
>> -/*
>> - * According to the downstream DTS,
>> - * 636 is basically a 660 except for
>> - * different CPU frequencies, Adreno
>> - * 509 instead of 512 and lack of
>> - * turing IP. These differences will
>> - * be addressed when the aforementioned
>> - * peripherals will be enabled upstream.
>> - */
>> +/delete-node/ &remoteproc_cdsp;
>> +/delete-node/ &cdsp_smmu;
>> +/delete-node/ &cdsp_region;
>> +
>> +/ {
>> + /delete-node/ smp2p-cdsp;
>> +
>> + reserved-memory {
>> + buffer_mem: tzbuffer@94a00000 {
>> + reg = <0x0 0x94a00000 0x00 0x100000>;
>> + no-map;
>> + };
>> + };
>> +};
>> &adreno_gpu {
>> compatible = "qcom,adreno-509.0", "qcom,adreno";
>> diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi
>> b/arch/arm64/boot/dts/qcom/sdm660.dtsi
>> index ef4a563c0feb..d50cce25ccbe 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
>> @@ -9,6 +9,37 @@
>> #include "sdm630.dtsi"
>> +/delete-node/ &buffer_mem;
>> +
>> +/ {
>> + smp2p-cdsp {
>> + compatible = "qcom,smp2p";
>> + qcom,smem = <94>, <432>;
>> + interrupts = <GIC_SPI 514 IRQ_TYPE_EDGE_RISING>;
>> + mboxes = <&apcs_glb 30>;
>> + 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>;
>> + };
>> + };
>> +
>> + reserved-memory {
>> + cdsp_region: cdsp@94a00000 {
>> + reg = <0x0 0x94a00000 0x00 0x600000>;
>> + no-map;
>> + };
>> + };
>> +};
>> +
>> &adreno_gpu {
>> compatible = "qcom,adreno-512.0", "qcom,adreno";
>> operating-points-v2 = <&gpu_sdm660_opp_table>;
>> @@ -247,6 +278,137 @@ &mmcc {
>> <0>;
>> };
>> +&soc {
>> + cdsp_smmu: iommu@5180000 {
>> + compatible = "qcom,sdm630-smmu-v2", "qcom,smmu-v2";
>> + reg = <0x5180000 0x40000>;
>> + #iommu-cells = <1>;
>> +
>> + #global-interrupts = <2>;
>> + interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 533 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 534 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 535 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 536 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 537 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 538 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 539 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 540 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 541 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 542 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 543 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 544 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 545 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 546 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 547 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 548 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 549 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> + clocks = <&gcc GCC_HLOS1_VOTE_TURING_ADSP_SMMU_CLK>;
>> + clock-names = "bus";
>> +
>> + power-domains = <&gcc HLOS1_VOTE_TURING_ADSP_GDSC>;
>> +
>> + };
>> +
>> + remoteproc_cdsp: remoteproc@1a300000 {
>> + compatible = "qcom,sdm660-cdsp-pas";
>> + reg = <0x1a300000 0x00100>;
>> + interrupts-extended = <&intc GIC_SPI 518 IRQ_TYPE_EDGE_RISING>,
>> + <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
>> + <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
>> + <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
>> + <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
>> + interrupt-names = "wdog",
>> + "fatal",
>> + "ready",
>> + "handover",
>> + "stop-ack";
>> +
>> + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>;
>> + clock-names = "xo";
>> +
>> + memory-region = <&cdsp_region>;
>> + power-domains = <&rpmpd SDM660_VDDCX>;
>> + power-domain-names = "cx";
>> +
>> + qcom,smem-states = <&cdsp_smp2p_out 0>;
>> + qcom,smem-state-names = "stop";
>> +
>> + glink-edge {
>> + interrupts = <GIC_SPI 513 IRQ_TYPE_EDGE_RISING>;
>> +
>> + label = "turing";
>> + mboxes = <&apcs_glb 29>;
>> + 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@5 {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <5>;
>> + iommus = <&cdsp_smmu 3>;
>> + };
>> +
>> + compute-cb@6 {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <6>;
>> + iommus = <&cdsp_smmu 4>;
>> + };
>> +
>> + compute-cb@7 {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <7>;
>> + iommus = <&cdsp_smmu 5>;
>> + };
>> +
>> + compute-cb@8 {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <8>;
>> + iommus = <&cdsp_smmu 6>;
>> + };
>> +
>> + compute-cb@9 {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <9>;
>> + iommus = <&cdsp_smmu 7>;
>> + };
>> +
>> + compute-cb@10 {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <10>;
>> + iommus = <&cdsp_smmu 8>;
>> + };
>> +
>> + compute-cb@11 {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <11>;
>> + iommus = <&cdsp_smmu 9>;
>> + };
>> +
>> + compute-cb@12 {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <12>;
>> + iommus = <&cdsp_smmu 10>;
>> + };
>> +
>> + compute-cb@13 {
>> + compatible = "qcom,fastrpc-compute-cb";
>> + reg = <13>;
>> + iommus = <&cdsp_smmu 11>;
>> + };
>> + };
>> + };
>> + };
>> +};
>> +
>> &tlmm {
>> compatible = "qcom,sdm660-pinctrl";
>> };
>>
> I've found out that all (both ADSP's and CDSP's) fastrpc-compute-cb's
> in downstream are defined under the one node [1], and all of them are
> handled by one adsprpc driver. There's a node [2], where a
> memory-region is assigned to this driver.
>
> Does this mean that both DSP's are using this one region for FastRPC?
>
> [1]
> https://github.com/pix106/android_kernel_xiaomi_southwest-4.19/blob/main/arch/arm64/boot/dts/vendor/qcom/sdm660.dtsi#L1349
>
> [2]
> https://github.com/pix106/android_kernel_xiaomi_southwest-4.19/blob/main/arch/arm64/boot/dts/vendor/qcom/sdm660.dtsi#L1342
>
>
I've also noticed that both DSP's are connected to the mas_crypto_c0 bus
[1].
Is this bus neccessary for DSP's to use the FastRPC?
[1]
https://github.com/pix106/android_kernel_xiaomi_southwest-4.19/blob/main/arch/arm64/boot/dts/vendor/qcom/sdm660.dtsi#L1963
--
Best regards,
Nickolay
On 12/11/25 3:30 PM, Nickolay Goppen wrote:
>
> 11.12.2025 15:24, Nickolay Goppen пишет:
>>
>> 23.10.2025 22:51, Nickolay Goppen пишет:
>>> In order to enable CDSP support for SDM660 SoC:
>>> * add shared memory p2p nodes for CDSP
>>> * add CDSP-specific smmu node
>>> * add CDSP peripheral image loader node
>>>
>>> Memory region for CDSP in SDM660 occupies the same spot as
>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>> cdsp_region, which is also larger in size.
>>>
>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>> related nodes and add buffer_mem back.
>>>
>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>> ---
>>> arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
>>> arch/arm64/boot/dts/qcom/sdm636.dtsi | 23 +++--
>>> arch/arm64/boot/dts/qcom/sdm660.dtsi | 162 +++++++++++++++++++++++++++++++++++
>>> 3 files changed, 177 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> index 8b1a45a4e56e..a6a1933229b9 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> @@ -563,7 +563,7 @@ modem_smp2p_in: slave-kernel {
>>> };
>>> };
>>> - soc@0 {
>>> + soc: soc@0 {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> ranges = <0 0 0 0xffffffff>;
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm636.dtsi b/arch/arm64/boot/dts/qcom/sdm636.dtsi
>>> index ae15d81fa3f9..38e6e3bfc3ce 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm636.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm636.dtsi
>>> @@ -7,15 +7,20 @@
>>> #include "sdm660.dtsi"
>>> -/*
>>> - * According to the downstream DTS,
>>> - * 636 is basically a 660 except for
>>> - * different CPU frequencies, Adreno
>>> - * 509 instead of 512 and lack of
>>> - * turing IP. These differences will
>>> - * be addressed when the aforementioned
>>> - * peripherals will be enabled upstream.
>>> - */
>>> +/delete-node/ &remoteproc_cdsp;
>>> +/delete-node/ &cdsp_smmu;
>>> +/delete-node/ &cdsp_region;
>>> +
>>> +/ {
>>> + /delete-node/ smp2p-cdsp;
>>> +
>>> + reserved-memory {
>>> + buffer_mem: tzbuffer@94a00000 {
>>> + reg = <0x0 0x94a00000 0x00 0x100000>;
>>> + no-map;
>>> + };
>>> + };
>>> +};
>>> &adreno_gpu {
>>> compatible = "qcom,adreno-509.0", "qcom,adreno";
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi b/arch/arm64/boot/dts/qcom/sdm660.dtsi
>>> index ef4a563c0feb..d50cce25ccbe 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
>>> @@ -9,6 +9,37 @@
>>> #include "sdm630.dtsi"
>>> +/delete-node/ &buffer_mem;
>>> +
>>> +/ {
>>> + smp2p-cdsp {
>>> + compatible = "qcom,smp2p";
>>> + qcom,smem = <94>, <432>;
>>> + interrupts = <GIC_SPI 514 IRQ_TYPE_EDGE_RISING>;
>>> + mboxes = <&apcs_glb 30>;
>>> + 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>;
>>> + };
>>> + };
>>> +
>>> + reserved-memory {
>>> + cdsp_region: cdsp@94a00000 {
>>> + reg = <0x0 0x94a00000 0x00 0x600000>;
>>> + no-map;
>>> + };
>>> + };
>>> +};
>>> +
>>> &adreno_gpu {
>>> compatible = "qcom,adreno-512.0", "qcom,adreno";
>>> operating-points-v2 = <&gpu_sdm660_opp_table>;
>>> @@ -247,6 +278,137 @@ &mmcc {
>>> <0>;
>>> };
>>> +&soc {
>>> + cdsp_smmu: iommu@5180000 {
>>> + compatible = "qcom,sdm630-smmu-v2", "qcom,smmu-v2";
>>> + reg = <0x5180000 0x40000>;
>>> + #iommu-cells = <1>;
>>> +
>>> + #global-interrupts = <2>;
>>> + interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 533 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 534 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 535 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 536 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 537 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 538 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 539 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 540 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 541 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 542 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 543 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 544 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 545 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 546 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 547 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 548 IRQ_TYPE_LEVEL_HIGH>,
>>> + <GIC_SPI 549 IRQ_TYPE_LEVEL_HIGH>;
>>> +
>>> + clocks = <&gcc GCC_HLOS1_VOTE_TURING_ADSP_SMMU_CLK>;
>>> + clock-names = "bus";
>>> +
>>> + power-domains = <&gcc HLOS1_VOTE_TURING_ADSP_GDSC>;
>>> +
>>> + };
>>> +
>>> + remoteproc_cdsp: remoteproc@1a300000 {
>>> + compatible = "qcom,sdm660-cdsp-pas";
>>> + reg = <0x1a300000 0x00100>;
>>> + interrupts-extended = <&intc GIC_SPI 518 IRQ_TYPE_EDGE_RISING>,
>>> + <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
>>> + <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
>>> + <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
>>> + <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
>>> + interrupt-names = "wdog",
>>> + "fatal",
>>> + "ready",
>>> + "handover",
>>> + "stop-ack";
>>> +
>>> + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>;
>>> + clock-names = "xo";
>>> +
>>> + memory-region = <&cdsp_region>;
>>> + power-domains = <&rpmpd SDM660_VDDCX>;
>>> + power-domain-names = "cx";
>>> +
>>> + qcom,smem-states = <&cdsp_smp2p_out 0>;
>>> + qcom,smem-state-names = "stop";
>>> +
>>> + glink-edge {
>>> + interrupts = <GIC_SPI 513 IRQ_TYPE_EDGE_RISING>;
>>> +
>>> + label = "turing";
>>> + mboxes = <&apcs_glb 29>;
>>> + 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@5 {
>>> + compatible = "qcom,fastrpc-compute-cb";
>>> + reg = <5>;
>>> + iommus = <&cdsp_smmu 3>;
>>> + };
>>> +
>>> + compute-cb@6 {
>>> + compatible = "qcom,fastrpc-compute-cb";
>>> + reg = <6>;
>>> + iommus = <&cdsp_smmu 4>;
>>> + };
>>> +
>>> + compute-cb@7 {
>>> + compatible = "qcom,fastrpc-compute-cb";
>>> + reg = <7>;
>>> + iommus = <&cdsp_smmu 5>;
>>> + };
>>> +
>>> + compute-cb@8 {
>>> + compatible = "qcom,fastrpc-compute-cb";
>>> + reg = <8>;
>>> + iommus = <&cdsp_smmu 6>;
>>> + };
>>> +
>>> + compute-cb@9 {
>>> + compatible = "qcom,fastrpc-compute-cb";
>>> + reg = <9>;
>>> + iommus = <&cdsp_smmu 7>;
>>> + };
>>> +
>>> + compute-cb@10 {
>>> + compatible = "qcom,fastrpc-compute-cb";
>>> + reg = <10>;
>>> + iommus = <&cdsp_smmu 8>;
>>> + };
>>> +
>>> + compute-cb@11 {
>>> + compatible = "qcom,fastrpc-compute-cb";
>>> + reg = <11>;
>>> + iommus = <&cdsp_smmu 9>;
>>> + };
>>> +
>>> + compute-cb@12 {
>>> + compatible = "qcom,fastrpc-compute-cb";
>>> + reg = <12>;
>>> + iommus = <&cdsp_smmu 10>;
>>> + };
>>> +
>>> + compute-cb@13 {
>>> + compatible = "qcom,fastrpc-compute-cb";
>>> + reg = <13>;
>>> + iommus = <&cdsp_smmu 11>;
>>> + };
>>> + };
>>> + };
>>> + };
>>> +};
>>> +
>>> &tlmm {
>>> compatible = "qcom,sdm660-pinctrl";
>>> };
>>>
>> I've found out that all (both ADSP's and CDSP's) fastrpc-compute-cb's in downstream are defined under the one node [1], and all of them are handled by one adsprpc driver. There's a node [2], where a memory-region is assigned to this driver.
>>
>> Does this mean that both DSP's are using this one region for FastRPC?
>>
>> [1] https://github.com/pix106/android_kernel_xiaomi_southwest-4.19/blob/main/arch/arm64/boot/dts/vendor/qcom/sdm660.dtsi#L1349
>>
>> [2] https://github.com/pix106/android_kernel_xiaomi_southwest-4.19/blob/main/arch/arm64/boot/dts/vendor/qcom/sdm660.dtsi#L1342
>>
> I've also noticed that both DSP's are connected to the mas_crypto_c0 bus [1].
>
> Is this bus neccessary for DSP's to use the FastRPC?
No, that's covered by the SCM device
Konrad
On 10/23/25 9:51 PM, Nickolay Goppen wrote:
> In order to enable CDSP support for SDM660 SoC:
> * add shared memory p2p nodes for CDSP
> * add CDSP-specific smmu node
> * add CDSP peripheral image loader node
>
> Memory region for CDSP in SDM660 occupies the same spot as
> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
> cdsp_region, which is also larger in size.
>
> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
> related nodes and add buffer_mem back.
>
> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> ---
[...]
> + label = "turing";
"cdsp"
> + mboxes = <&apcs_glb 29>;
> + qcom,remote-pid = <5>;
> +
> + fastrpc {
> + compatible = "qcom,fastrpc";
> + qcom,glink-channels = "fastrpcglink-apps-dsp";
> + label = "cdsp";
> + qcom,non-secure-domain;
This shouldn't matter, both a secure and a non-secure device is
created for CDSP
Konrad
24.10.2025 11:28, Konrad Dybcio пишет:
> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>> In order to enable CDSP support for SDM660 SoC:
>> * add shared memory p2p nodes for CDSP
>> * add CDSP-specific smmu node
>> * add CDSP peripheral image loader node
>>
>> Memory region for CDSP in SDM660 occupies the same spot as
>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>> cdsp_region, which is also larger in size.
>>
>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>> related nodes and add buffer_mem back.
>>
>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>> ---
> [...]
>
>> + label = "turing";
> "cdsp"
Ok, I'll change this in the next revision.
>> + mboxes = <&apcs_glb 29>;
>> + qcom,remote-pid = <5>;
>> +
>> + fastrpc {
>> + compatible = "qcom,fastrpc";
>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>> + label = "cdsp";
>> + qcom,non-secure-domain;
> This shouldn't matter, both a secure and a non-secure device is
> created for CDSP
I've added this property, because it is used in other SoC's, such as
SDM845 and SM6115 for both ADSP and CDSP
> Konrad
--
Best regards,
Nickolay
24.10.2025 16:58, Nickolay Goppen пишет:
>
> 24.10.2025 11:28, Konrad Dybcio пишет:
>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>> In order to enable CDSP support for SDM660 SoC:
>>> * add shared memory p2p nodes for CDSP
>>> * add CDSP-specific smmu node
>>> * add CDSP peripheral image loader node
>>>
>>> Memory region for CDSP in SDM660 occupies the same spot as
>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>> cdsp_region, which is also larger in size.
>>>
>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>> related nodes and add buffer_mem back.
>>>
>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>> ---
>> [...]
>>
>>> + label = "turing";
>> "cdsp"
> Ok, I'll change this in the next revision.
>>> + mboxes = <&apcs_glb 29>;
>>> + qcom,remote-pid = <5>;
>>> +
>>> + fastrpc {
>>> + compatible = "qcom,fastrpc";
>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>> + label = "cdsp";
>>> + qcom,non-secure-domain;
>> This shouldn't matter, both a secure and a non-secure device is
>> created for CDSP
> I've added this property, because it is used in other SoC's, such as
> SDM845 and SM6115 for both ADSP and CDSP
Is this property not neccessary anymore?
>> Konrad
>
--
Best regards,
Nickolay
On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>
> 24.10.2025 16:58, Nickolay Goppen пишет:
>>
>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>> In order to enable CDSP support for SDM660 SoC:
>>>> * add shared memory p2p nodes for CDSP
>>>> * add CDSP-specific smmu node
>>>> * add CDSP peripheral image loader node
>>>>
>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>> cdsp_region, which is also larger in size.
>>>>
>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>> related nodes and add buffer_mem back.
>>>>
>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>> ---
>>> [...]
>>>
>>>> + label = "turing";
>>> "cdsp"
>> Ok, I'll change this in the next revision.
>>>> + mboxes = <&apcs_glb 29>;
>>>> + qcom,remote-pid = <5>;
>>>> +
>>>> + fastrpc {
>>>> + compatible = "qcom,fastrpc";
>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>> + label = "cdsp";
>>>> + qcom,non-secure-domain;
>>> This shouldn't matter, both a secure and a non-secure device is
>>> created for CDSP
>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
> Is this property not neccessary anymore?
+Srini?
Konrad
On 11/3/25 12:52 PM, Konrad Dybcio wrote:
> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>
>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>
>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>> * add shared memory p2p nodes for CDSP
>>>>> * add CDSP-specific smmu node
>>>>> * add CDSP peripheral image loader node
>>>>>
>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>> cdsp_region, which is also larger in size.
>>>>>
>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>> related nodes and add buffer_mem back.
>>>>>
>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>> ---
>>>> [...]
>>>>
>>>>> + label = "turing";
>>>> "cdsp"
>>> Ok, I'll change this in the next revision.
>>>>> + mboxes = <&apcs_glb 29>;
>>>>> + qcom,remote-pid = <5>;
>>>>> +
>>>>> + fastrpc {
>>>>> + compatible = "qcom,fastrpc";
>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>> + label = "cdsp";
>>>>> + qcom,non-secure-domain;
>>>> This shouldn't matter, both a secure and a non-secure device is
>>>> created for CDSP
>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>> Is this property not neccessary anymore?
>
> +Srini?
That is true, we do not require this for CDSP, as CDSP allows both
unsigned and signed loading, we create both secured and non-secure node
by default. May be we can provide that clarity in yaml bindings so that
it gets caught during dtb checks.
However in ADSP case, we only support singed modules, due to historical
reasons how this driver evolved over years, we have this flag to allow
compatiblity for such users.
--srini>
> Konrad
On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>
>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>
>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>> * add shared memory p2p nodes for CDSP
>>>>>> * add CDSP-specific smmu node
>>>>>> * add CDSP peripheral image loader node
>>>>>>
>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>> cdsp_region, which is also larger in size.
>>>>>>
>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>> related nodes and add buffer_mem back.
>>>>>>
>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>> ---
>>>>> [...]
>>>>>
>>>>>> + label = "turing";
>>>>> "cdsp"
>>>> Ok, I'll change this in the next revision.
>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>> + qcom,remote-pid = <5>;
>>>>>> +
>>>>>> + fastrpc {
>>>>>> + compatible = "qcom,fastrpc";
>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>> + label = "cdsp";
>>>>>> + qcom,non-secure-domain;
>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>> created for CDSP
>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>> Is this property not neccessary anymore?
>>
>> +Srini?
>
> That is true, we do not require this for CDSP, as CDSP allows both
> unsigned and signed loading, we create both secured and non-secure node
> by default. May be we can provide that clarity in yaml bindings so that
> it gets caught during dtb checks.
>
>
> However in ADSP case, we only support singed modules, due to historical
> reasons how this driver evolved over years, we have this flag to allow
> compatiblity for such users.
Does that mean that we can only load signed modules on the ADSP, but
the driver behavior was previously such that unsigned modules were
allowed (which was presumably fine on devboards, but not on fused
devices)?
Konrad
On 11/12/25 1:52 PM, Konrad Dybcio wrote:
> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>
>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>
>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>> * add CDSP-specific smmu node
>>>>>>> * add CDSP peripheral image loader node
>>>>>>>
>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>
>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>> related nodes and add buffer_mem back.
>>>>>>>
>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>> ---
>>>>>> [...]
>>>>>>
>>>>>>> + label = "turing";
>>>>>> "cdsp"
>>>>> Ok, I'll change this in the next revision.
>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>> + qcom,remote-pid = <5>;
>>>>>>> +
>>>>>>> + fastrpc {
>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>> + label = "cdsp";
>>>>>>> + qcom,non-secure-domain;
>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>> created for CDSP
>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>> Is this property not neccessary anymore?
>>>
>>> +Srini?
>>
>> That is true, we do not require this for CDSP, as CDSP allows both
>> unsigned and signed loading, we create both secured and non-secure node
>> by default. May be we can provide that clarity in yaml bindings so that
>> it gets caught during dtb checks.
>>
>>
>> However in ADSP case, we only support singed modules, due to historical
>> reasons how this driver evolved over years, we have this flag to allow
>> compatiblity for such users.
>
> Does that mean that we can only load signed modules on the ADSP, but
> the driver behavior was previously such that unsigned modules were
> allowed (which was presumably fine on devboards, but not on fused
> devices)?
Yes, its true that we allowed full access to adsp device nodes when we
first started upstreaming fastrpc driver.
irrespective of the board only signed modules are supported on the ADSP.
I think there was one version of SoC i think 8016 or some older one
which had adsp with hvx which can load unsigned modules for compute
usecase only.
I have added @Ekansh for more clarity.
--srini
>
> Konrad
On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>> * add CDSP-specific smmu node
>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>
>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>
>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>
>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>> ---
>>>>>>> [...]
>>>>>>>
>>>>>>>> + label = "turing";
>>>>>>> "cdsp"
>>>>>> Ok, I'll change this in the next revision.
>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>> +
>>>>>>>> + fastrpc {
>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>> + label = "cdsp";
>>>>>>>> + qcom,non-secure-domain;
>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>> created for CDSP
>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>> Is this property not neccessary anymore?
>>>> +Srini?
>>> That is true, we do not require this for CDSP, as CDSP allows both
>>> unsigned and signed loading, we create both secured and non-secure node
>>> by default. May be we can provide that clarity in yaml bindings so that
>>> it gets caught during dtb checks.
>>>
>>>
>>> However in ADSP case, we only support singed modules, due to historical
>>> reasons how this driver evolved over years, we have this flag to allow
>>> compatiblity for such users.
>> Does that mean that we can only load signed modules on the ADSP, but
>> the driver behavior was previously such that unsigned modules were
>> allowed (which was presumably fine on devboards, but not on fused
>> devices)?
> Yes, its true that we allowed full access to adsp device nodes when we
> first started upstreaming fastrpc driver.
>
> irrespective of the board only signed modules are supported on the ADSP.
> I think there was one version of SoC i think 8016 or some older one
> which had adsp with hvx which can load unsigned modules for compute
> usecase only.
>
> I have added @Ekansh for more clarity.
>
> --srini
For all the available platforms, ADSP supports only signed modules. Unsigned
modules(as well as signed) are supported by CDSP and GDSP subsystems.
qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
The implications of adding this property would be the following:
on ADSP, SDSP, MDSP:
- Only non-secure device node(/dev/fastrpc-Xdsp) is created.
- Non-secure device node can be used for signed DSP PD offload.
on CDSP, GDSP:
- Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
are created, regardless of this property.
- Both the nodes can be used for signed and unsigned DSP PD offload.
Note: If the property is not added for CDSP/GDSP, only secure device node can
be used for signed PD offload, if non-secure device is used, the request gets
rejected[1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
//Ekansh
>
>
>> Konrad
On Thu, Nov 20, 2025 at 10:25:13AM +0530, Ekansh Gupta wrote:
>
>
> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
> > On 11/12/25 1:52 PM, Konrad Dybcio wrote:
> >> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
> >>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
> >>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
> >>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
> >>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
> >>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
> >>>>>>>> In order to enable CDSP support for SDM660 SoC:
> >>>>>>>> * add shared memory p2p nodes for CDSP
> >>>>>>>> * add CDSP-specific smmu node
> >>>>>>>> * add CDSP peripheral image loader node
> >>>>>>>>
> >>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
> >>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
> >>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
> >>>>>>>> cdsp_region, which is also larger in size.
> >>>>>>>>
> >>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
> >>>>>>>> related nodes and add buffer_mem back.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> >>>>>>>> ---
> >>>>>>> [...]
> >>>>>>>
> >>>>>>>> + label = "turing";
> >>>>>>> "cdsp"
> >>>>>> Ok, I'll change this in the next revision.
> >>>>>>>> + mboxes = <&apcs_glb 29>;
> >>>>>>>> + qcom,remote-pid = <5>;
> >>>>>>>> +
> >>>>>>>> + fastrpc {
> >>>>>>>> + compatible = "qcom,fastrpc";
> >>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
> >>>>>>>> + label = "cdsp";
> >>>>>>>> + qcom,non-secure-domain;
> >>>>>>> This shouldn't matter, both a secure and a non-secure device is
> >>>>>>> created for CDSP
> >>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
> >>>>> Is this property not neccessary anymore?
> >>>> +Srini?
> >>> That is true, we do not require this for CDSP, as CDSP allows both
> >>> unsigned and signed loading, we create both secured and non-secure node
> >>> by default. May be we can provide that clarity in yaml bindings so that
> >>> it gets caught during dtb checks.
> >>>
> >>>
> >>> However in ADSP case, we only support singed modules, due to historical
> >>> reasons how this driver evolved over years, we have this flag to allow
> >>> compatiblity for such users.
> >> Does that mean that we can only load signed modules on the ADSP, but
> >> the driver behavior was previously such that unsigned modules were
> >> allowed (which was presumably fine on devboards, but not on fused
> >> devices)?
> > Yes, its true that we allowed full access to adsp device nodes when we
> > first started upstreaming fastrpc driver.
> >
> > irrespective of the board only signed modules are supported on the ADSP.
> > I think there was one version of SoC i think 8016 or some older one
> > which had adsp with hvx which can load unsigned modules for compute
> > usecase only.
> >
> > I have added @Ekansh for more clarity.
> >
> > --srini
>
> For all the available platforms, ADSP supports only signed modules. Unsigned
Is it true for msm8916?
> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>
> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
> The implications of adding this property would be the following:
> on ADSP, SDSP, MDSP:
> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
> - Non-secure device node can be used for signed DSP PD offload.
>
> on CDSP, GDSP:
> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
> are created, regardless of this property.
> - Both the nodes can be used for signed and unsigned DSP PD offload.
>
> Note: If the property is not added for CDSP/GDSP, only secure device node can
> be used for signed PD offload, if non-secure device is used, the request gets
> rejected[1].
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
--
With best wishes
Dmitry
20.11.2025 07:55, Ekansh Gupta пишет:
>
> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>
>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>
>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>> ---
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>> + label = "turing";
>>>>>>>> "cdsp"
>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>> +
>>>>>>>>> + fastrpc {
>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>> + label = "cdsp";
>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>> created for CDSP
>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>> Is this property not neccessary anymore?
>>>>> +Srini?
>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>> unsigned and signed loading, we create both secured and non-secure node
>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>> it gets caught during dtb checks.
>>>>
>>>>
>>>> However in ADSP case, we only support singed modules, due to historical
>>>> reasons how this driver evolved over years, we have this flag to allow
>>>> compatiblity for such users.
>>> Does that mean that we can only load signed modules on the ADSP, but
>>> the driver behavior was previously such that unsigned modules were
>>> allowed (which was presumably fine on devboards, but not on fused
>>> devices)?
>> Yes, its true that we allowed full access to adsp device nodes when we
>> first started upstreaming fastrpc driver.
>>
>> irrespective of the board only signed modules are supported on the ADSP.
>> I think there was one version of SoC i think 8016 or some older one
>> which had adsp with hvx which can load unsigned modules for compute
>> usecase only.
>>
>> I have added @Ekansh for more clarity.
>>
>> --srini
> For all the available platforms, ADSP supports only signed modules. Unsigned
> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>
> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
> The implications of adding this property would be the following:
> on ADSP, SDSP, MDSP:
> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
> - Non-secure device node can be used for signed DSP PD offload.
>
> on CDSP, GDSP:
> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
> are created, regardless of this property.
> - Both the nodes can be used for signed and unsigned DSP PD offload.
>
> Note: If the property is not added for CDSP/GDSP, only secure device node can
> be used for signed PD offload, if non-secure device is used, the request gets
> rejected[1].
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>
> //Ekansh
Does this mean that the qcom,non-secure-domain property should be
dropped from both nodes?
>>
>>> Konrad
--
Best regards,
Nickolay
On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>
> 20.11.2025 07:55, Ekansh Gupta пишет:
>>
>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>
>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>
>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>> ---
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>> + label = "turing";
>>>>>>>>> "cdsp"
>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>> +
>>>>>>>>>> + fastrpc {
>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>> + label = "cdsp";
>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>> created for CDSP
>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>> Is this property not neccessary anymore?
>>>>>> +Srini?
>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>> it gets caught during dtb checks.
>>>>>
>>>>>
>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>> compatiblity for such users.
>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>> the driver behavior was previously such that unsigned modules were
>>>> allowed (which was presumably fine on devboards, but not on fused
>>>> devices)?
>>> Yes, its true that we allowed full access to adsp device nodes when we
>>> first started upstreaming fastrpc driver.
>>>
>>> irrespective of the board only signed modules are supported on the ADSP.
>>> I think there was one version of SoC i think 8016 or some older one
>>> which had adsp with hvx which can load unsigned modules for compute
>>> usecase only.
>>>
>>> I have added @Ekansh for more clarity.
>>>
>>> --srini
>> For all the available platforms, ADSP supports only signed modules. Unsigned
>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>
>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>> The implications of adding this property would be the following:
>> on ADSP, SDSP, MDSP:
>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>> - Non-secure device node can be used for signed DSP PD offload.
>>
>> on CDSP, GDSP:
>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>> are created, regardless of this property.
>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>
>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>> be used for signed PD offload, if non-secure device is used, the request gets
>> rejected[1].
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>
>> //Ekansh
> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
I checked again and found that unsigned module support for CDSP is
not available on this platform. Given this, the safest approach would
be to add the property for both ADSP and CDSP, ensuring that all
created device nodes can be used for signed PD offload. I can provide
a more definitive recommendation once I know the specific use cases
you plan to run.
//Ekansh
>>>
>>>> Konrad
>
On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>
>
> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>
>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>
>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>
>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>
>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>> ---
>>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>>> + label = "turing";
>>>>>>>>>> "cdsp"
>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>> +
>>>>>>>>>>> + fastrpc {
>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>> created for CDSP
>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>> Is this property not neccessary anymore?
>>>>>>> +Srini?
>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>> it gets caught during dtb checks.
>>>>>>
>>>>>>
>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>> compatiblity for such users.
>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>> the driver behavior was previously such that unsigned modules were
>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>> devices)?
>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>> first started upstreaming fastrpc driver.
>>>>
>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>> I think there was one version of SoC i think 8016 or some older one
>>>> which had adsp with hvx which can load unsigned modules for compute
>>>> usecase only.
>>>>
>>>> I have added @Ekansh for more clarity.
>>>>
>>>> --srini
>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>
>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>> The implications of adding this property would be the following:
>>> on ADSP, SDSP, MDSP:
>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>> - Non-secure device node can be used for signed DSP PD offload.
>>>
>>> on CDSP, GDSP:
>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>> are created, regardless of this property.
>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>
>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>> be used for signed PD offload, if non-secure device is used, the request gets
>>> rejected[1].
>>>
>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>
>>> //Ekansh
>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
> I checked again and found that unsigned module support for CDSP is
> not available on this platform. Given this, the safest approach would
> be to add the property for both ADSP and CDSP, ensuring that all
> created device nodes can be used for signed PD offload. I can provide
The property allows *unsigned* PD offload though
> a more definitive recommendation once I know the specific use cases
> you plan to run.
Why would the usecase affect this?
Konrad
On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>
>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>
>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>
>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>> ---
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>> "cdsp"
>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>> +
>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>> created for CDSP
>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>> +Srini?
>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>> it gets caught during dtb checks.
>>>>>>>
>>>>>>>
>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>> compatiblity for such users.
>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>> devices)?
>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>> first started upstreaming fastrpc driver.
>>>>>
>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>> usecase only.
>>>>>
>>>>> I have added @Ekansh for more clarity.
>>>>>
>>>>> --srini
>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>
>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>> The implications of adding this property would be the following:
>>>> on ADSP, SDSP, MDSP:
>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>
>>>> on CDSP, GDSP:
>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>> are created, regardless of this property.
>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>
>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>> rejected[1].
>>>>
>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>
>>>> //Ekansh
>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>> I checked again and found that unsigned module support for CDSP is
>> not available on this platform. Given this, the safest approach would
>> be to add the property for both ADSP and CDSP, ensuring that all
>> created device nodes can be used for signed PD offload. I can provide
> The property allows *unsigned* PD offload though
I don't think I can directly relate this property to unsigned PD offload. This is just
defining what type of device node will be created and whether the channel is secure
or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
of whether this property is added or not. If DSP does not support unsigned offload, it
should return failures for such requests.
>
>> a more definitive recommendation once I know the specific use cases
>> you plan to run.
> Why would the usecase affect this?
I'm saying this as per past discussions where some application was relying on non-secure
device node on some old platform(on postmarketOS)[1] and having this property in place.
So if similar usecase is being enabled here, the property might be required[1].
[1] https://lkml.org/lkml/2024/8/15/117
>
> Konrad
On Fri, Nov 21, 2025 at 01:41:21PM +0530, Ekansh Gupta wrote:
>
>
> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
> > On 11/20/25 11:54 AM, Ekansh Gupta wrote:
> >>
> >> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
> >>> 20.11.2025 07:55, Ekansh Gupta пишет:
> >>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
> >>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
> >>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
> >>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
> >>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
> >>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
> >>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
> >>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
> >>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
> >>>>>>>>>>>> * add shared memory p2p nodes for CDSP
> >>>>>>>>>>>> * add CDSP-specific smmu node
> >>>>>>>>>>>> * add CDSP peripheral image loader node
> >>>>>>>>>>>>
> >>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
> >>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
> >>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
> >>>>>>>>>>>> cdsp_region, which is also larger in size.
> >>>>>>>>>>>>
> >>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
> >>>>>>>>>>>> related nodes and add buffer_mem back.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> >>>>>>>>>>>> ---
> >>>>>>>>>>> [...]
> >>>>>>>>>>>
> >>>>>>>>>>>> + label = "turing";
> >>>>>>>>>>> "cdsp"
> >>>>>>>>>> Ok, I'll change this in the next revision.
> >>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
> >>>>>>>>>>>> + qcom,remote-pid = <5>;
> >>>>>>>>>>>> +
> >>>>>>>>>>>> + fastrpc {
> >>>>>>>>>>>> + compatible = "qcom,fastrpc";
> >>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
> >>>>>>>>>>>> + label = "cdsp";
> >>>>>>>>>>>> + qcom,non-secure-domain;
> >>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
> >>>>>>>>>>> created for CDSP
> >>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
> >>>>>>>>> Is this property not neccessary anymore?
> >>>>>>>> +Srini?
> >>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
> >>>>>>> unsigned and signed loading, we create both secured and non-secure node
> >>>>>>> by default. May be we can provide that clarity in yaml bindings so that
> >>>>>>> it gets caught during dtb checks.
> >>>>>>>
> >>>>>>>
> >>>>>>> However in ADSP case, we only support singed modules, due to historical
> >>>>>>> reasons how this driver evolved over years, we have this flag to allow
> >>>>>>> compatiblity for such users.
> >>>>>> Does that mean that we can only load signed modules on the ADSP, but
> >>>>>> the driver behavior was previously such that unsigned modules were
> >>>>>> allowed (which was presumably fine on devboards, but not on fused
> >>>>>> devices)?
> >>>>> Yes, its true that we allowed full access to adsp device nodes when we
> >>>>> first started upstreaming fastrpc driver.
> >>>>>
> >>>>> irrespective of the board only signed modules are supported on the ADSP.
> >>>>> I think there was one version of SoC i think 8016 or some older one
> >>>>> which had adsp with hvx which can load unsigned modules for compute
> >>>>> usecase only.
> >>>>>
> >>>>> I have added @Ekansh for more clarity.
> >>>>>
> >>>>> --srini
> >>>> For all the available platforms, ADSP supports only signed modules. Unsigned
> >>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
> >>>>
> >>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
> >>>> The implications of adding this property would be the following:
> >>>> on ADSP, SDSP, MDSP:
> >>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
> >>>> - Non-secure device node can be used for signed DSP PD offload.
> >>>>
> >>>> on CDSP, GDSP:
> >>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
> >>>> are created, regardless of this property.
> >>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
> >>>>
> >>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
> >>>> be used for signed PD offload, if non-secure device is used, the request gets
> >>>> rejected[1].
> >>>>
> >>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
> >>>>
> >>>> //Ekansh
> >>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
> >> I checked again and found that unsigned module support for CDSP is
> >> not available on this platform. Given this, the safest approach would
> >> be to add the property for both ADSP and CDSP, ensuring that all
> >> created device nodes can be used for signed PD offload. I can provide
> > The property allows *unsigned* PD offload though
> I don't think I can directly relate this property to unsigned PD offload. This is just
> defining what type of device node will be created and whether the channel is secure
> or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
> of whether this property is added or not. If DSP does not support unsigned offload, it
> should return failures for such requests.
Which part of the hardware and/or firmware interface does it define? If
it simply declared Linux behaviour, it is incorrect and probably should
be dropped.
> >
> >> a more definitive recommendation once I know the specific use cases
> >> you plan to run.
> > Why would the usecase affect this?
> I'm saying this as per past discussions where some application was relying on non-secure
> device node on some old platform(on postmarketOS)[1] and having this property in place.
> So if similar usecase is being enabled here, the property might be required[1].
DT files are not usecase-based.
>
> [1] https://lkml.org/lkml/2024/8/15/117
--
With best wishes
Dmitry
21.11.2025 15:09, Dmitry Baryshkov пишет:
> On Fri, Nov 21, 2025 at 01:41:21PM +0530, Ekansh Gupta wrote:
>>
>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>> +Srini?
>>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>>>> compatiblity for such users.
>>>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>>> devices)?
>>>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>
>>>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>>>> usecase only.
>>>>>>>
>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>
>>>>>>> --srini
>>>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>>>
>>>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>>>> The implications of adding this property would be the following:
>>>>>> on ADSP, SDSP, MDSP:
>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>
>>>>>> on CDSP, GDSP:
>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>>>> are created, regardless of this property.
>>>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>>>
>>>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>>>> rejected[1].
>>>>>>
>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>
>>>>>> //Ekansh
>>>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>>>> I checked again and found that unsigned module support for CDSP is
>>>> not available on this platform. Given this, the safest approach would
>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>> created device nodes can be used for signed PD offload. I can provide
>>> The property allows *unsigned* PD offload though
>> I don't think I can directly relate this property to unsigned PD offload. This is just
>> defining what type of device node will be created and whether the channel is secure
>> or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
>> of whether this property is added or not. If DSP does not support unsigned offload, it
>> should return failures for such requests.
> Which part of the hardware and/or firmware interface does it define? If
> it simply declared Linux behaviour, it is incorrect and probably should
> be dropped.
>
When I've removed the qcom,non-secure-domain property from cdsp and
tried to run hexagonrpcd via this command:
sudo -u fastrpc hexagonrpcd -f /dev/fastrpc-cdsp -R
/usr/share/qcom/sdm660/Xiaomi/clover/ -d cdsp -c
/usr/share/qcom/sdm660/Xiaomi/clover/dsp/cdsp/fastrpc_shell_3
It raised the following error:
qcom,fastrpc 1a300000.remoteproc:glink-edge.fastrpcglink-apps-dsp.-1.-1:
Error: Untrusted application trying to offload to signed PD
>>>> a more definitive recommendation once I know the specific use cases
>>>> you plan to run.
>>> Why would the usecase affect this?
>> I'm saying this as per past discussions where some application was relying on non-secure
>> device node on some old platform(on postmarketOS)[1] and having this property in place.
>> So if similar usecase is being enabled here, the property might be required[1].
> DT files are not usecase-based.
>
>> [1] https://lkml.org/lkml/2024/8/15/117
--
Best regards,
Nickolay
On 11/26/2025 7:30 PM, Nickolay Goppen wrote:
>
> 21.11.2025 15:09, Dmitry Baryshkov пишет:
>> On Fri, Nov 21, 2025 at 01:41:21PM +0530, Ekansh Gupta wrote:
>>>
>>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>>> +Srini?
>>>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>>>>> compatiblity for such users.
>>>>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>>>> devices)?
>>>>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>>
>>>>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>>>>> usecase only.
>>>>>>>>
>>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>>
>>>>>>>> --srini
>>>>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>>>>
>>>>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>>>>> The implications of adding this property would be the following:
>>>>>>> on ADSP, SDSP, MDSP:
>>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>>
>>>>>>> on CDSP, GDSP:
>>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>>>>> are created, regardless of this property.
>>>>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>>>>
>>>>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>>>>> rejected[1].
>>>>>>>
>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>>
>>>>>>> //Ekansh
>>>>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>>>>> I checked again and found that unsigned module support for CDSP is
>>>>> not available on this platform. Given this, the safest approach would
>>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>>> created device nodes can be used for signed PD offload. I can provide
>>>> The property allows *unsigned* PD offload though
>>> I don't think I can directly relate this property to unsigned PD offload. This is just
>>> defining what type of device node will be created and whether the channel is secure
>>> or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
>>> of whether this property is added or not. If DSP does not support unsigned offload, it
>>> should return failures for such requests.
>> Which part of the hardware and/or firmware interface does it define? If
>> it simply declared Linux behaviour, it is incorrect and probably should
>> be dropped.
>>
> When I've removed the qcom,non-secure-domain property from cdsp and tried to run hexagonrpcd via this command:
>
> sudo -u fastrpc hexagonrpcd -f /dev/fastrpc-cdsp -R /usr/share/qcom/sdm660/Xiaomi/clover/ -d cdsp -c /usr/share/qcom/sdm660/Xiaomi/clover/dsp/cdsp/fastrpc_shell_3
>
> It raised the following error:
>
> qcom,fastrpc 1a300000.remoteproc:glink-edge.fastrpcglink-apps-dsp.-1.-1: Error: Untrusted application trying to offload to signed PD
This is expected. With the property absent, Signed offload is only allowed with /dev/fastrpc-cdsp-secure.
>
>
>
>>>>> a more definitive recommendation once I know the specific use cases
>>>>> you plan to run.
>>>> Why would the usecase affect this?
>>> I'm saying this as per past discussions where some application was relying on non-secure
>>> device node on some old platform(on postmarketOS)[1] and having this property in place.
>>> So if similar usecase is being enabled here, the property might be required[1].
>> DT files are not usecase-based.
>>
>>> [1] https://lkml.org/lkml/2024/8/15/117
>
26.11.2025 17:00, Nickolay Goppen пишет:
>
> 21.11.2025 15:09, Dmitry Baryshkov пишет:
>> On Fri, Nov 21, 2025 at 01:41:21PM +0530, Ekansh Gupta wrote:
>>>
>>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not
>>>>>>>>>>>>>>> have CDSP).
>>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from
>>>>>>>>>>>>>>> sdm660.dtsi
>>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>>> + qcom,glink-channels =
>>>>>>>>>>>>>>> "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure
>>>>>>>>>>>>>> device is
>>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>>> I've added this property, because it is used in other
>>>>>>>>>>>>> SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>>> +Srini?
>>>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows
>>>>>>>>>> both
>>>>>>>>>> unsigned and signed loading, we create both secured and
>>>>>>>>>> non-secure node
>>>>>>>>>> by default. May be we can provide that clarity in yaml
>>>>>>>>>> bindings so that
>>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However in ADSP case, we only support singed modules, due to
>>>>>>>>>> historical
>>>>>>>>>> reasons how this driver evolved over years, we have this flag
>>>>>>>>>> to allow
>>>>>>>>>> compatiblity for such users.
>>>>>>>>> Does that mean that we can only load signed modules on the
>>>>>>>>> ADSP, but
>>>>>>>>> the driver behavior was previously such that unsigned modules
>>>>>>>>> were
>>>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>>>> devices)?
>>>>>>>> Yes, its true that we allowed full access to adsp device nodes
>>>>>>>> when we
>>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>>
>>>>>>>> irrespective of the board only signed modules are supported on
>>>>>>>> the ADSP.
>>>>>>>> I think there was one version of SoC i think 8016 or some older
>>>>>>>> one
>>>>>>>> which had adsp with hvx which can load unsigned modules for
>>>>>>>> compute
>>>>>>>> usecase only.
>>>>>>>>
>>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>>
>>>>>>>> --srini
>>>>>>> For all the available platforms, ADSP supports only signed
>>>>>>> modules. Unsigned
>>>>>>> modules(as well as signed) are supported by CDSP and GDSP
>>>>>>> subsystems.
>>>>>>>
>>>>>>> qcom,non-secure-domain property marks the corresponding DSP as
>>>>>>> non-secure DSP.
>>>>>>> The implications of adding this property would be the following:
>>>>>>> on ADSP, SDSP, MDSP:
>>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>>
>>>>>>> on CDSP, GDSP:
>>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and
>>>>>>> non-secure(/dev/fastrpc-Xdsp) devices
>>>>>>> are created, regardless of this property.
>>>>>>> - Both the nodes can be used for signed and unsigned DSP PD
>>>>>>> offload.
>>>>>>>
>>>>>>> Note: If the property is not added for CDSP/GDSP, only secure
>>>>>>> device node can
>>>>>>> be used for signed PD offload, if non-secure device is used, the
>>>>>>> request gets
>>>>>>> rejected[1].
>>>>>>>
>>>>>>> [1]
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>>
>>>>>>> //Ekansh
>>>>>> Does this mean that the qcom,non-secure-domain property should be
>>>>>> dropped from both nodes?
>>>>> I checked again and found that unsigned module support for CDSP is
>>>>> not available on this platform. Given this, the safest approach would
>>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>>> created device nodes can be used for signed PD offload. I can provide
>>>> The property allows *unsigned* PD offload though
>>> I don't think I can directly relate this property to unsigned PD
>>> offload. This is just
>>> defining what type of device node will be created and whether the
>>> channel is secure
>>> or not. There is a possibility of making unsigned PD request(on
>>> CDSP/GDSP) irrespective
>>> of whether this property is added or not. If DSP does not support
>>> unsigned offload, it
>>> should return failures for such requests.
>> Which part of the hardware and/or firmware interface does it define? If
>> it simply declared Linux behaviour, it is incorrect and probably should
>> be dropped.
>>
> When I've removed the qcom,non-secure-domain property from cdsp and
> tried to run hexagonrpcd via this command:
>
> sudo -u fastrpc hexagonrpcd -f /dev/fastrpc-cdsp -R
> /usr/share/qcom/sdm660/Xiaomi/clover/ -d cdsp -c
> /usr/share/qcom/sdm660/Xiaomi/clover/dsp/cdsp/fastrpc_shell_3
>
> It raised the following error:
>
> qcom,fastrpc
> 1a300000.remoteproc:glink-edge.fastrpcglink-apps-dsp.-1.-1: Error:
> Untrusted application trying to offload to signed PD
>
I've tried to add "hlos2_vote_turing_adsp_smmu_clk "as "iface" clock and
"hlos2_vote_turing_adsp_gdsc" as a second power-domain and cdsp_smmu
gave the following error:
hlos1_vote_turing_adsp_smmu_clk status stuck at 'off'
>
>
>>>>> a more definitive recommendation once I know the specific use cases
>>>>> you plan to run.
>>>> Why would the usecase affect this?
>>> I'm saying this as per past discussions where some application was
>>> relying on non-secure
>>> device node on some old platform(on postmarketOS)[1] and having this
>>> property in place.
>>> So if similar usecase is being enabled here, the property might be
>>> required[1].
>> DT files are not usecase-based.
>>
>>> [1] https://lkml.org/lkml/2024/8/15/117
>
--
Best regards,
Nickolay
21.11.2025 15:09, Dmitry Baryshkov пишет:
> On Fri, Nov 21, 2025 at 01:41:21PM +0530, Ekansh Gupta wrote:
>>
>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>> +Srini?
>>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>>>> compatiblity for such users.
>>>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>>> devices)?
>>>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>
>>>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>>>> usecase only.
>>>>>>>
>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>
>>>>>>> --srini
>>>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>>>
>>>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>>>> The implications of adding this property would be the following:
>>>>>> on ADSP, SDSP, MDSP:
>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>
>>>>>> on CDSP, GDSP:
>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>>>> are created, regardless of this property.
>>>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>>>
>>>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>>>> rejected[1].
>>>>>>
>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>
>>>>>> //Ekansh
>>>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>>>> I checked again and found that unsigned module support for CDSP is
>>>> not available on this platform. Given this, the safest approach would
>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>> created device nodes can be used for signed PD offload. I can provide
>>> The property allows *unsigned* PD offload though
>> I don't think I can directly relate this property to unsigned PD offload. This is just
>> defining what type of device node will be created and whether the channel is secure
>> or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
>> of whether this property is added or not. If DSP does not support unsigned offload, it
>> should return failures for such requests.
> Which part of the hardware and/or firmware interface does it define? If
> it simply declared Linux behaviour, it is incorrect and probably should
> be dropped.
I still don't understand, do I need this property or not?
>>>> a more definitive recommendation once I know the specific use cases
>>>> you plan to run.
>>> Why would the usecase affect this?
>> I'm saying this as per past discussions where some application was relying on non-secure
>> device node on some old platform(on postmarketOS)[1] and having this property in place.
>> So if similar usecase is being enabled here, the property might be required[1].
> DT files are not usecase-based.
>
>> [1] https://lkml.org/lkml/2024/8/15/117
--
Best regards,
Nickolay
23.11.2025 13:51, Nickolay Goppen пишет:
>
> 21.11.2025 15:09, Dmitry Baryshkov пишет:
>> On Fri, Nov 21, 2025 at 01:41:21PM +0530, Ekansh Gupta wrote:
>>>
>>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not
>>>>>>>>>>>>>>> have CDSP).
>>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from
>>>>>>>>>>>>>>> sdm660.dtsi
>>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>>> + qcom,glink-channels =
>>>>>>>>>>>>>>> "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure
>>>>>>>>>>>>>> device is
>>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>>> I've added this property, because it is used in other
>>>>>>>>>>>>> SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>>> +Srini?
>>>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows
>>>>>>>>>> both
>>>>>>>>>> unsigned and signed loading, we create both secured and
>>>>>>>>>> non-secure node
>>>>>>>>>> by default. May be we can provide that clarity in yaml
>>>>>>>>>> bindings so that
>>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However in ADSP case, we only support singed modules, due to
>>>>>>>>>> historical
>>>>>>>>>> reasons how this driver evolved over years, we have this flag
>>>>>>>>>> to allow
>>>>>>>>>> compatiblity for such users.
>>>>>>>>> Does that mean that we can only load signed modules on the
>>>>>>>>> ADSP, but
>>>>>>>>> the driver behavior was previously such that unsigned modules
>>>>>>>>> were
>>>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>>>> devices)?
>>>>>>>> Yes, its true that we allowed full access to adsp device nodes
>>>>>>>> when we
>>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>>
>>>>>>>> irrespective of the board only signed modules are supported on
>>>>>>>> the ADSP.
>>>>>>>> I think there was one version of SoC i think 8016 or some older
>>>>>>>> one
>>>>>>>> which had adsp with hvx which can load unsigned modules for
>>>>>>>> compute
>>>>>>>> usecase only.
>>>>>>>>
>>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>>
>>>>>>>> --srini
>>>>>>> For all the available platforms, ADSP supports only signed
>>>>>>> modules. Unsigned
>>>>>>> modules(as well as signed) are supported by CDSP and GDSP
>>>>>>> subsystems.
>>>>>>>
>>>>>>> qcom,non-secure-domain property marks the corresponding DSP as
>>>>>>> non-secure DSP.
>>>>>>> The implications of adding this property would be the following:
>>>>>>> on ADSP, SDSP, MDSP:
>>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>>
>>>>>>> on CDSP, GDSP:
>>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and
>>>>>>> non-secure(/dev/fastrpc-Xdsp) devices
>>>>>>> are created, regardless of this property.
>>>>>>> - Both the nodes can be used for signed and unsigned DSP PD
>>>>>>> offload.
>>>>>>>
>>>>>>> Note: If the property is not added for CDSP/GDSP, only secure
>>>>>>> device node can
>>>>>>> be used for signed PD offload, if non-secure device is used, the
>>>>>>> request gets
>>>>>>> rejected[1].
>>>>>>>
>>>>>>> [1]
>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>>
>>>>>>> //Ekansh
>>>>>> Does this mean that the qcom,non-secure-domain property should be
>>>>>> dropped from both nodes?
>>>>> I checked again and found that unsigned module support for CDSP is
>>>>> not available on this platform. Given this, the safest approach would
>>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>>> created device nodes can be used for signed PD offload. I can provide
>>>> The property allows *unsigned* PD offload though
>>> I don't think I can directly relate this property to unsigned PD
>>> offload. This is just
>>> defining what type of device node will be created and whether the
>>> channel is secure
>>> or not. There is a possibility of making unsigned PD request(on
>>> CDSP/GDSP) irrespective
>>> of whether this property is added or not. If DSP does not support
>>> unsigned offload, it
>>> should return failures for such requests.
>> Which part of the hardware and/or firmware interface does it define? If
>> it simply declared Linux behaviour, it is incorrect and probably should
>> be dropped.
> I still don't understand, do I need this property or not?
I've began testing the FastRPC on CDSP and the command
sudo fastrpc_test -d 3 -U 1 -t linux -a v68
has caused the following errors:
[ 60.810545] arm-smmu 5180000.iommu: Unhandled context fault:
fsr=0x402, iova=0xfffff000, fsynr=0x1, cbfrsynra=0x6, cb=3
[ 60.810588] arm-smmu 5180000.iommu: FSR = 00000402 [Format=2 TF],
SID=0x6
[ 60.810603] arm-smmu 5180000.iommu: FSYNR0 = 00000001 [S1CBNDX=0 PLVL=1]
[ 60.815657] qcom_q6v5_pas 1a300000.remoteproc: fatal error received:
:0:EX:kernel:0:frpck_0_0:77:PC=c0117de0
[ 60.815684] remoteproc remoteproc2: crash detected in cdsp: type
fatal error
[ 60.815738] remoteproc remoteproc2: handling crash #1 in cdsp
[ 60.815754] remoteproc remoteproc2: recovering cdsp
[ 60.819267] (NULL device *): Error: dsp information is incorrect err: -32
>>>>> a more definitive recommendation once I know the specific use cases
>>>>> you plan to run.
>>>> Why would the usecase affect this?
>>> I'm saying this as per past discussions where some application was
>>> relying on non-secure
>>> device node on some old platform(on postmarketOS)[1] and having this
>>> property in place.
>>> So if similar usecase is being enabled here, the property might be
>>> required[1].
>> DT files are not usecase-based.
>>
>>> [1] https://lkml.org/lkml/2024/8/15/117
>
--
Best regards,
Nickolay
24.11.2025 18:02, Nickolay Goppen пишет:
>
> 23.11.2025 13:51, Nickolay Goppen пишет:
>>
>> 21.11.2025 15:09, Dmitry Baryshkov пишет:
>>> On Fri, Nov 21, 2025 at 01:41:21PM +0530, Ekansh Gupta wrote:
>>>>
>>>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not
>>>>>>>>>>>>>>>> have CDSP).
>>>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from
>>>>>>>>>>>>>>>> sdm660.dtsi
>>>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>>>> + qcom,glink-channels =
>>>>>>>>>>>>>>>> "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure
>>>>>>>>>>>>>>> device is
>>>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>>>> I've added this property, because it is used in other
>>>>>>>>>>>>>> SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>>>> +Srini?
>>>>>>>>>>> That is true, we do not require this for CDSP, as CDSP
>>>>>>>>>>> allows both
>>>>>>>>>>> unsigned and signed loading, we create both secured and
>>>>>>>>>>> non-secure node
>>>>>>>>>>> by default. May be we can provide that clarity in yaml
>>>>>>>>>>> bindings so that
>>>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> However in ADSP case, we only support singed modules, due to
>>>>>>>>>>> historical
>>>>>>>>>>> reasons how this driver evolved over years, we have this
>>>>>>>>>>> flag to allow
>>>>>>>>>>> compatiblity for such users.
>>>>>>>>>> Does that mean that we can only load signed modules on the
>>>>>>>>>> ADSP, but
>>>>>>>>>> the driver behavior was previously such that unsigned modules
>>>>>>>>>> were
>>>>>>>>>> allowed (which was presumably fine on devboards, but not on
>>>>>>>>>> fused
>>>>>>>>>> devices)?
>>>>>>>>> Yes, its true that we allowed full access to adsp device nodes
>>>>>>>>> when we
>>>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>>>
>>>>>>>>> irrespective of the board only signed modules are supported on
>>>>>>>>> the ADSP.
>>>>>>>>> I think there was one version of SoC i think 8016 or some
>>>>>>>>> older one
>>>>>>>>> which had adsp with hvx which can load unsigned modules for
>>>>>>>>> compute
>>>>>>>>> usecase only.
>>>>>>>>>
>>>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>>>
>>>>>>>>> --srini
>>>>>>>> For all the available platforms, ADSP supports only signed
>>>>>>>> modules. Unsigned
>>>>>>>> modules(as well as signed) are supported by CDSP and GDSP
>>>>>>>> subsystems.
>>>>>>>>
>>>>>>>> qcom,non-secure-domain property marks the corresponding DSP as
>>>>>>>> non-secure DSP.
>>>>>>>> The implications of adding this property would be the following:
>>>>>>>> on ADSP, SDSP, MDSP:
>>>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>>>
>>>>>>>> on CDSP, GDSP:
>>>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and
>>>>>>>> non-secure(/dev/fastrpc-Xdsp) devices
>>>>>>>> are created, regardless of this property.
>>>>>>>> - Both the nodes can be used for signed and unsigned DSP PD
>>>>>>>> offload.
>>>>>>>>
>>>>>>>> Note: If the property is not added for CDSP/GDSP, only secure
>>>>>>>> device node can
>>>>>>>> be used for signed PD offload, if non-secure device is used,
>>>>>>>> the request gets
>>>>>>>> rejected[1].
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>>>
>>>>>>>> //Ekansh
>>>>>>> Does this mean that the qcom,non-secure-domain property should
>>>>>>> be dropped from both nodes?
>>>>>> I checked again and found that unsigned module support for CDSP is
>>>>>> not available on this platform. Given this, the safest approach
>>>>>> would
>>>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>>>> created device nodes can be used for signed PD offload. I can
>>>>>> provide
>>>>> The property allows *unsigned* PD offload though
>>>> I don't think I can directly relate this property to unsigned PD
>>>> offload. This is just
>>>> defining what type of device node will be created and whether the
>>>> channel is secure
>>>> or not. There is a possibility of making unsigned PD request(on
>>>> CDSP/GDSP) irrespective
>>>> of whether this property is added or not. If DSP does not support
>>>> unsigned offload, it
>>>> should return failures for such requests.
>>> Which part of the hardware and/or firmware interface does it define? If
>>> it simply declared Linux behaviour, it is incorrect and probably should
>>> be dropped.
>> I still don't understand, do I need this property or not?
>
> I've began testing the FastRPC on CDSP and the command
>
> sudo fastrpc_test -d 3 -U 1 -t linux -a v68
> has caused the following errors:
>
> [ 60.810545] arm-smmu 5180000.iommu: Unhandled context fault:
> fsr=0x402, iova=0xfffff000, fsynr=0x1, cbfrsynra=0x6, cb=3
> [ 60.810588] arm-smmu 5180000.iommu: FSR = 00000402 [Format=2
> TF], SID=0x6
> [ 60.810603] arm-smmu 5180000.iommu: FSYNR0 = 00000001 [S1CBNDX=0
> PLVL=1]
> [ 60.815657] qcom_q6v5_pas 1a300000.remoteproc: fatal error
> received: :0:EX:kernel:0:frpck_0_0:77:PC=c0117de0
> [ 60.815684] remoteproc remoteproc2: crash detected in cdsp: type
> fatal error
> [ 60.815738] remoteproc remoteproc2: handling crash #1 in cdsp
> [ 60.815754] remoteproc remoteproc2: recovering cdsp
> [ 60.819267] (NULL device *): Error: dsp information is incorrect
> err: -32
>
How to debug such issues?
>
>>>>>> a more definitive recommendation once I know the specific use cases
>>>>>> you plan to run.
>>>>> Why would the usecase affect this?
>>>> I'm saying this as per past discussions where some application was
>>>> relying on non-secure
>>>> device node on some old platform(on postmarketOS)[1] and having
>>>> this property in place.
>>>> So if similar usecase is being enabled here, the property might be
>>>> required[1].
>>> DT files are not usecase-based.
>>>
>>>> [1] https://lkml.org/lkml/2024/8/15/117
>>
--
Best regards,
Nickolay
02.12.2025 20:09, Nickolay Goppen пишет:
>
> 24.11.2025 18:02, Nickolay Goppen пишет:
>>
>> 23.11.2025 13:51, Nickolay Goppen пишет:
>>>
>>> 21.11.2025 15:09, Dmitry Baryshkov пишет:
>>>> On Fri, Nov 21, 2025 at 01:41:21PM +0530, Ekansh Gupta wrote:
>>>>>
>>>>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>>>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same
>>>>>>>>>>>>>>>>> spot as
>>>>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not
>>>>>>>>>>>>>>>>> have CDSP).
>>>>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from
>>>>>>>>>>>>>>>>> SDM630 with
>>>>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited
>>>>>>>>>>>>>>>>> from sdm660.dtsi
>>>>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure
>>>>>>>>>>>>>>>> device is
>>>>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>>>>> I've added this property, because it is used in other
>>>>>>>>>>>>>>> SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>>>>> +Srini?
>>>>>>>>>>>> That is true, we do not require this for CDSP, as CDSP
>>>>>>>>>>>> allows both
>>>>>>>>>>>> unsigned and signed loading, we create both secured and
>>>>>>>>>>>> non-secure node
>>>>>>>>>>>> by default. May be we can provide that clarity in yaml
>>>>>>>>>>>> bindings so that
>>>>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> However in ADSP case, we only support singed modules, due
>>>>>>>>>>>> to historical
>>>>>>>>>>>> reasons how this driver evolved over years, we have this
>>>>>>>>>>>> flag to allow
>>>>>>>>>>>> compatiblity for such users.
>>>>>>>>>>> Does that mean that we can only load signed modules on the
>>>>>>>>>>> ADSP, but
>>>>>>>>>>> the driver behavior was previously such that unsigned
>>>>>>>>>>> modules were
>>>>>>>>>>> allowed (which was presumably fine on devboards, but not on
>>>>>>>>>>> fused
>>>>>>>>>>> devices)?
>>>>>>>>>> Yes, its true that we allowed full access to adsp device
>>>>>>>>>> nodes when we
>>>>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>>>>
>>>>>>>>>> irrespective of the board only signed modules are supported
>>>>>>>>>> on the ADSP.
>>>>>>>>>> I think there was one version of SoC i think 8016 or some
>>>>>>>>>> older one
>>>>>>>>>> which had adsp with hvx which can load unsigned modules for
>>>>>>>>>> compute
>>>>>>>>>> usecase only.
>>>>>>>>>>
>>>>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>>>>
>>>>>>>>>> --srini
>>>>>>>>> For all the available platforms, ADSP supports only signed
>>>>>>>>> modules. Unsigned
>>>>>>>>> modules(as well as signed) are supported by CDSP and GDSP
>>>>>>>>> subsystems.
>>>>>>>>>
>>>>>>>>> qcom,non-secure-domain property marks the corresponding DSP as
>>>>>>>>> non-secure DSP.
>>>>>>>>> The implications of adding this property would be the following:
>>>>>>>>> on ADSP, SDSP, MDSP:
>>>>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>>>>
>>>>>>>>> on CDSP, GDSP:
>>>>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and
>>>>>>>>> non-secure(/dev/fastrpc-Xdsp) devices
>>>>>>>>> are created, regardless of this property.
>>>>>>>>> - Both the nodes can be used for signed and unsigned DSP PD
>>>>>>>>> offload.
>>>>>>>>>
>>>>>>>>> Note: If the property is not added for CDSP/GDSP, only secure
>>>>>>>>> device node can
>>>>>>>>> be used for signed PD offload, if non-secure device is used,
>>>>>>>>> the request gets
>>>>>>>>> rejected[1].
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>>>>
>>>>>>>>> //Ekansh
>>>>>>>> Does this mean that the qcom,non-secure-domain property should
>>>>>>>> be dropped from both nodes?
>>>>>>> I checked again and found that unsigned module support for CDSP is
>>>>>>> not available on this platform. Given this, the safest approach
>>>>>>> would
>>>>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>>>>> created device nodes can be used for signed PD offload. I can
>>>>>>> provide
>>>>>> The property allows *unsigned* PD offload though
>>>>> I don't think I can directly relate this property to unsigned PD
>>>>> offload. This is just
>>>>> defining what type of device node will be created and whether the
>>>>> channel is secure
>>>>> or not. There is a possibility of making unsigned PD request(on
>>>>> CDSP/GDSP) irrespective
>>>>> of whether this property is added or not. If DSP does not support
>>>>> unsigned offload, it
>>>>> should return failures for such requests.
>>>> Which part of the hardware and/or firmware interface does it
>>>> define? If
>>>> it simply declared Linux behaviour, it is incorrect and probably
>>>> should
>>>> be dropped.
>>> I still don't understand, do I need this property or not?
>>
>> I've began testing the FastRPC on CDSP and the command
>>
>> sudo fastrpc_test -d 3 -U 1 -t linux -a v68
>> has caused the following errors:
>>
>> [ 60.810545] arm-smmu 5180000.iommu: Unhandled context fault:
>> fsr=0x402, iova=0xfffff000, fsynr=0x1, cbfrsynra=0x6, cb=3
>> [ 60.810588] arm-smmu 5180000.iommu: FSR = 00000402 [Format=2
>> TF], SID=0x6
>> [ 60.810603] arm-smmu 5180000.iommu: FSYNR0 = 00000001 [S1CBNDX=0
>> PLVL=1]
>> [ 60.815657] qcom_q6v5_pas 1a300000.remoteproc: fatal error
>> received: :0:EX:kernel:0:frpck_0_0:77:PC=c0117de0
>> [ 60.815684] remoteproc remoteproc2: crash detected in cdsp: type
>> fatal error
>> [ 60.815738] remoteproc remoteproc2: handling crash #1 in cdsp
>> [ 60.815754] remoteproc remoteproc2: recovering cdsp
>> [ 60.819267] (NULL device *): Error: dsp information is incorrect
>> err: -32
>>
> How to debug such issues?
This issue occurs also when I'm trying to run a hexagonrpcd with the
following command (with copied from the dspso partition libs):
sudo -u fastrpc hexagonrpcd -f /dev/fastrpc-cdsp -R
/usr/share/qcom/sdm660/Xiaomi/clover/ -d cdsp -c
/usr/share/qcom/sdm660/Xiaomi/clover/dsp/cdsp/fastrpc_shell_3
>>
>>>>>>> a more definitive recommendation once I know the specific use cases
>>>>>>> you plan to run.
>>>>>> Why would the usecase affect this?
>>>>> I'm saying this as per past discussions where some application was
>>>>> relying on non-secure
>>>>> device node on some old platform(on postmarketOS)[1] and having
>>>>> this property in place.
>>>>> So if similar usecase is being enabled here, the property might be
>>>>> required[1].
>>>> DT files are not usecase-based.
>>>>
>>>>> [1] https://lkml.org/lkml/2024/8/15/117
>>>
--
Best regards,
Nickolay
On 12/8/25 8:49 AM, Nickolay Goppen wrote:
>
> 02.12.2025 20:09, Nickolay Goppen пишет:
>>
>> 24.11.2025 18:02, Nickolay Goppen пишет:
>>>
>>> 23.11.2025 13:51, Nickolay Goppen пишет:
>>>>
>>>> 21.11.2025 15:09, Dmitry Baryshkov пишет:
>>>>> On Fri, Nov 21, 2025 at 01:41:21PM +0530, Ekansh Gupta wrote:
>>>>>>
>>>>>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>>>>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>>>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>>>>>> +Srini?
>>>>>>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>>>>>>>> compatiblity for such users.
>>>>>>>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>>>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>>>>>>> devices)?
>>>>>>>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>>>>>
>>>>>>>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>>>>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>>>>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>>>>>>>> usecase only.
>>>>>>>>>>>
>>>>>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>>>>>
>>>>>>>>>>> --srini
>>>>>>>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>>>>>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>>>>>>>
>>>>>>>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>>>>>>>> The implications of adding this property would be the following:
>>>>>>>>>> on ADSP, SDSP, MDSP:
>>>>>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>>>>>
>>>>>>>>>> on CDSP, GDSP:
>>>>>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>>>>>>>> are created, regardless of this property.
>>>>>>>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>>>>>>>
>>>>>>>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>>>>>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>>>>>>>> rejected[1].
>>>>>>>>>>
>>>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>>>>>
>>>>>>>>>> //Ekansh
>>>>>>>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>>>>>>>> I checked again and found that unsigned module support for CDSP is
>>>>>>>> not available on this platform. Given this, the safest approach would
>>>>>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>>>>>> created device nodes can be used for signed PD offload. I can provide
>>>>>>> The property allows *unsigned* PD offload though
>>>>>> I don't think I can directly relate this property to unsigned PD offload. This is just
>>>>>> defining what type of device node will be created and whether the channel is secure
>>>>>> or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
>>>>>> of whether this property is added or not. If DSP does not support unsigned offload, it
>>>>>> should return failures for such requests.
>>>>> Which part of the hardware and/or firmware interface does it define? If
>>>>> it simply declared Linux behaviour, it is incorrect and probably should
>>>>> be dropped.
>>>> I still don't understand, do I need this property or not?
>>>
>>> I've began testing the FastRPC on CDSP and the command
>>>
>>> sudo fastrpc_test -d 3 -U 1 -t linux -a v68
>>> has caused the following errors:
>>>
>>> [ 60.810545] arm-smmu 5180000.iommu: Unhandled context fault: fsr=0x402, iova=0xfffff000, fsynr=0x1, cbfrsynra=0x6, cb=3
This iova looks a little suspicious..
>>> [ 60.810588] arm-smmu 5180000.iommu: FSR = 00000402 [Format=2 TF], SID=0x6
>>> [ 60.810603] arm-smmu 5180000.iommu: FSYNR0 = 00000001 [S1CBNDX=0 PLVL=1]
>>> [ 60.815657] qcom_q6v5_pas 1a300000.remoteproc: fatal error received: :0:EX:kernel:0:frpck_0_0:77:PC=c0117de0
>>> [ 60.815684] remoteproc remoteproc2: crash detected in cdsp: type fatal error
>>> [ 60.815738] remoteproc remoteproc2: handling crash #1 in cdsp
>>> [ 60.815754] remoteproc remoteproc2: recovering cdsp
>>> [ 60.819267] (NULL device *): Error: dsp information is incorrect err: -32
>>>
>> How to debug such issues?
>
> This issue occurs also when I'm trying to run a hexagonrpcd with the following command (with copied from the dspso partition libs):
>
> sudo -u fastrpc hexagonrpcd -f /dev/fastrpc-cdsp -R /usr/share/qcom/sdm660/Xiaomi/clover/ -d cdsp -c /usr/share/qcom/sdm660/Xiaomi/clover/dsp/cdsp/fastrpc_shell_3
Please open an issue on:
https://github.com/qualcomm/fastrpc/issues
Konrad
17.12.2025 16:37, Konrad Dybcio пишет: > sudo -u fastrpc hexagonrpcd -f /dev/fastrpc-cdsp -R > /usr/share/qcom/sdm660/Xiaomi/clover/ -d cdsp -c > /usr/share/qcom/sdm660/Xiaomi/clover/dsp/cdsp/fastrpc_shell_3 done https://github.com/qualcomm/fastrpc/issues/269 -- Best regards, Nickolay
On 11/24/2025 8:32 PM, Nickolay Goppen wrote:
>
> 23.11.2025 13:51, Nickolay Goppen пишет:
>>
>> 21.11.2025 15:09, Dmitry Baryshkov пишет:
>>> On Fri, Nov 21, 2025 at 01:41:21PM +0530, Ekansh Gupta wrote:
>>>>
>>>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>>>> +Srini?
>>>>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>>>>>> compatiblity for such users.
>>>>>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>>>>> devices)?
>>>>>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>>>
>>>>>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>>>>>> usecase only.
>>>>>>>>>
>>>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>>>
>>>>>>>>> --srini
>>>>>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>>>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>>>>>
>>>>>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>>>>>> The implications of adding this property would be the following:
>>>>>>>> on ADSP, SDSP, MDSP:
>>>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>>>
>>>>>>>> on CDSP, GDSP:
>>>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>>>>>> are created, regardless of this property.
>>>>>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>>>>>
>>>>>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>>>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>>>>>> rejected[1].
>>>>>>>>
>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>>>
>>>>>>>> //Ekansh
>>>>>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>>>>>> I checked again and found that unsigned module support for CDSP is
>>>>>> not available on this platform. Given this, the safest approach would
>>>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>>>> created device nodes can be used for signed PD offload. I can provide
>>>>> The property allows *unsigned* PD offload though
>>>> I don't think I can directly relate this property to unsigned PD offload. This is just
>>>> defining what type of device node will be created and whether the channel is secure
>>>> or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
>>>> of whether this property is added or not. If DSP does not support unsigned offload, it
>>>> should return failures for such requests.
>>> Which part of the hardware and/or firmware interface does it define? If
>>> it simply declared Linux behaviour, it is incorrect and probably should
>>> be dropped.
>> I still don't understand, do I need this property or not?
>
> I've began testing the FastRPC on CDSP and the command
>
> sudo fastrpc_test -d 3 -U 1 -t linux -a v68
> has caused the following errors:
>
> [ 60.810545] arm-smmu 5180000.iommu: Unhandled context fault: fsr=0x402, iova=0xfffff000, fsynr=0x1, cbfrsynra=0x6, cb=3
> [ 60.810588] arm-smmu 5180000.iommu: FSR = 00000402 [Format=2 TF], SID=0x6
> [ 60.810603] arm-smmu 5180000.iommu: FSYNR0 = 00000001 [S1CBNDX=0 PLVL=1]
> [ 60.815657] qcom_q6v5_pas 1a300000.remoteproc: fatal error received: :0:EX:kernel:0:frpck_0_0:77:PC=c0117de0
> [ 60.815684] remoteproc remoteproc2: crash detected in cdsp: type fatal error
> [ 60.815738] remoteproc remoteproc2: handling crash #1 in cdsp
> [ 60.815754] remoteproc remoteproc2: recovering cdsp
> [ 60.819267] (NULL device *): Error: dsp information is incorrect err: -32
Are you trying out only calculator or all the libs? If yes, can you please
help with creating an issue in the above mentioned github project?
On older platforms, I would suggest to only try with calculator as other
libs are not stable.
We are getting a better version of other test libs signed and will update
the project with new libs post signing.
//Ekansh
>
>
>>>>>> a more definitive recommendation once I know the specific use cases
>>>>>> you plan to run.
>>>>> Why would the usecase affect this?
>>>> I'm saying this as per past discussions where some application was relying on non-secure
>>>> device node on some old platform(on postmarketOS)[1] and having this property in place.
>>>> So if similar usecase is being enabled here, the property might be required[1].
>>> DT files are not usecase-based.
>>>
>>>> [1] https://lkml.org/lkml/2024/8/15/117
>>
24.11.2025 18:29, Ekansh Gupta пишет:
>
> On 11/24/2025 8:32 PM, Nickolay Goppen wrote:
>> 23.11.2025 13:51, Nickolay Goppen пишет:
>>> 21.11.2025 15:09, Dmitry Baryshkov пишет:
>>>> On Fri, Nov 21, 2025 at 01:41:21PM +0530, Ekansh Gupta wrote:
>>>>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>>>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>>>>> +Srini?
>>>>>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>>>>>>> compatiblity for such users.
>>>>>>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>>>>>> devices)?
>>>>>>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>>>>
>>>>>>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>>>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>>>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>>>>>>> usecase only.
>>>>>>>>>>
>>>>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>>>>
>>>>>>>>>> --srini
>>>>>>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>>>>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>>>>>>
>>>>>>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>>>>>>> The implications of adding this property would be the following:
>>>>>>>>> on ADSP, SDSP, MDSP:
>>>>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>>>>
>>>>>>>>> on CDSP, GDSP:
>>>>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>>>>>>> are created, regardless of this property.
>>>>>>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>>>>>>
>>>>>>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>>>>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>>>>>>> rejected[1].
>>>>>>>>>
>>>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>>>>
>>>>>>>>> //Ekansh
>>>>>>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>>>>>>> I checked again and found that unsigned module support for CDSP is
>>>>>>> not available on this platform. Given this, the safest approach would
>>>>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>>>>> created device nodes can be used for signed PD offload. I can provide
>>>>>> The property allows *unsigned* PD offload though
>>>>> I don't think I can directly relate this property to unsigned PD offload. This is just
>>>>> defining what type of device node will be created and whether the channel is secure
>>>>> or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
>>>>> of whether this property is added or not. If DSP does not support unsigned offload, it
>>>>> should return failures for such requests.
>>>> Which part of the hardware and/or firmware interface does it define? If
>>>> it simply declared Linux behaviour, it is incorrect and probably should
>>>> be dropped.
>>> I still don't understand, do I need this property or not?
>> I've began testing the FastRPC on CDSP and the command
>>
>> sudo fastrpc_test -d 3 -U 1 -t linux -a v68
>> has caused the following errors:
>>
>> [ 60.810545] arm-smmu 5180000.iommu: Unhandled context fault: fsr=0x402, iova=0xfffff000, fsynr=0x1, cbfrsynra=0x6, cb=3
>> [ 60.810588] arm-smmu 5180000.iommu: FSR = 00000402 [Format=2 TF], SID=0x6
>> [ 60.810603] arm-smmu 5180000.iommu: FSYNR0 = 00000001 [S1CBNDX=0 PLVL=1]
>> [ 60.815657] qcom_q6v5_pas 1a300000.remoteproc: fatal error received: :0:EX:kernel:0:frpck_0_0:77:PC=c0117de0
>> [ 60.815684] remoteproc remoteproc2: crash detected in cdsp: type fatal error
>> [ 60.815738] remoteproc remoteproc2: handling crash #1 in cdsp
>> [ 60.815754] remoteproc remoteproc2: recovering cdsp
>> [ 60.819267] (NULL device *): Error: dsp information is incorrect err: -32
> Are you trying out only calculator or all the libs? If yes, can you please
> help with creating an issue in the above mentioned github project?
>
> On older platforms, I would suggest to only try with calculator as other
> libs are not stable.
>
> We are getting a better version of other test libs signed and will update
> the project with new libs post signing.
>
> //Ekansh
I've tested the calculator only and it also fails. I think that the CDSP
has Hexagon version v60, that is lower than minimal v68 in the repo. I
can help with creating an issue, what should I do?
>>
>>>>>>> a more definitive recommendation once I know the specific use cases
>>>>>>> you plan to run.
>>>>>> Why would the usecase affect this?
>>>>> I'm saying this as per past discussions where some application was relying on non-secure
>>>>> device node on some old platform(on postmarketOS)[1] and having this property in place.
>>>>> So if similar usecase is being enabled here, the property might be required[1].
>>>> DT files are not usecase-based.
>>>>
>>>>> [1] https://lkml.org/lkml/2024/8/15/117
--
Best regards,
Nickolay
21.11.2025 11:11, Ekansh Gupta пишет:
>
> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>
>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>
>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>> ---
>>>>>>>>>>>> [...]
>>>>>>>>>>>>
>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>> "cdsp"
>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>> +
>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>>> created for CDSP
>>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>> +Srini?
>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>>> it gets caught during dtb checks.
>>>>>>>>
>>>>>>>>
>>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>>> compatiblity for such users.
>>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>> devices)?
>>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>>> first started upstreaming fastrpc driver.
>>>>>>
>>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>>> usecase only.
>>>>>>
>>>>>> I have added @Ekansh for more clarity.
>>>>>>
>>>>>> --srini
>>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>>
>>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>>> The implications of adding this property would be the following:
>>>>> on ADSP, SDSP, MDSP:
>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>
>>>>> on CDSP, GDSP:
>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>>> are created, regardless of this property.
>>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>>
>>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>>> rejected[1].
>>>>>
>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>
>>>>> //Ekansh
>>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>>> I checked again and found that unsigned module support for CDSP is
>>> not available on this platform. Given this, the safest approach would
>>> be to add the property for both ADSP and CDSP, ensuring that all
>>> created device nodes can be used for signed PD offload. I can provide
>> The property allows *unsigned* PD offload though
> I don't think I can directly relate this property to unsigned PD offload. This is just
> defining what type of device node will be created and whether the channel is secure
> or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
> of whether this property is added or not. If DSP does not support unsigned offload, it
> should return failures for such requests.
>>> a more definitive recommendation once I know the specific use cases
>>> you plan to run.
>> Why would the usecase affect this?
> I'm saying this as per past discussions where some application was relying on non-secure
> device node on some old platform(on postmarketOS)[1] and having this property in place.
> So if similar usecase is being enabled here, the property might be required[1].
I'm testing these changes on postmarketOS. However, sensors aren't
working through FastRPC on sdm660.
Is it better to leave this property for both nodes?
> [1] https://lkml.org/lkml/2024/8/15/117
>> Konrad
--
Best regards,
Nickolay
On Fri, Nov 21, 2025 at 11:18:31AM +0300, Nickolay Goppen wrote:
>
> 21.11.2025 11:11, Ekansh Gupta пишет:
> >
> > On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
> > > On 11/20/25 11:54 AM, Ekansh Gupta wrote:
> > > > On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
> > > > > 20.11.2025 07:55, Ekansh Gupta пишет:
> > > > > > On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
> > > > > > > On 11/12/25 1:52 PM, Konrad Dybcio wrote:
> > > > > > > > On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
> > > > > > > > > On 11/3/25 12:52 PM, Konrad Dybcio wrote:
> > > > > > > > > > On 10/31/25 12:30 PM, Nickolay Goppen wrote:
> > > > > > > > > > > 24.10.2025 16:58, Nickolay Goppen пишет:
> > > > > > > > > > > > 24.10.2025 11:28, Konrad Dybcio пишет:
> > > > > > > > > > > > > On 10/23/25 9:51 PM, Nickolay Goppen wrote:
> > > > > > > > > > > > > > In order to enable CDSP support for SDM660 SoC:
> > > > > > > > > > > > > > * add shared memory p2p nodes for CDSP
> > > > > > > > > > > > > > * add CDSP-specific smmu node
> > > > > > > > > > > > > > * add CDSP peripheral image loader node
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Memory region for CDSP in SDM660 occupies the same spot as
> > > > > > > > > > > > > > TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
> > > > > > > > > > > > > > In sdm660.dtsi replace buffer_mem inherited from SDM630 with
> > > > > > > > > > > > > > cdsp_region, which is also larger in size.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
> > > > > > > > > > > > > > related nodes and add buffer_mem back.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > [...]
> > > > > > > > > > > > >
> > > > > > > > > > > > > > + label = "turing";
> > > > > > > > > > > > > "cdsp"
> > > > > > > > > > > > Ok, I'll change this in the next revision.
> > > > > > > > > > > > > > + mboxes = <&apcs_glb 29>;
> > > > > > > > > > > > > > + qcom,remote-pid = <5>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + fastrpc {
> > > > > > > > > > > > > > + compatible = "qcom,fastrpc";
> > > > > > > > > > > > > > + qcom,glink-channels = "fastrpcglink-apps-dsp";
> > > > > > > > > > > > > > + label = "cdsp";
> > > > > > > > > > > > > > + qcom,non-secure-domain;
> > > > > > > > > > > > > This shouldn't matter, both a secure and a non-secure device is
> > > > > > > > > > > > > created for CDSP
> > > > > > > > > > > > I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
> > > > > > > > > > > Is this property not neccessary anymore?
> > > > > > > > > > +Srini?
> > > > > > > > > That is true, we do not require this for CDSP, as CDSP allows both
> > > > > > > > > unsigned and signed loading, we create both secured and non-secure node
> > > > > > > > > by default. May be we can provide that clarity in yaml bindings so that
> > > > > > > > > it gets caught during dtb checks.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > However in ADSP case, we only support singed modules, due to historical
> > > > > > > > > reasons how this driver evolved over years, we have this flag to allow
> > > > > > > > > compatiblity for such users.
> > > > > > > > Does that mean that we can only load signed modules on the ADSP, but
> > > > > > > > the driver behavior was previously such that unsigned modules were
> > > > > > > > allowed (which was presumably fine on devboards, but not on fused
> > > > > > > > devices)?
> > > > > > > Yes, its true that we allowed full access to adsp device nodes when we
> > > > > > > first started upstreaming fastrpc driver.
> > > > > > >
> > > > > > > irrespective of the board only signed modules are supported on the ADSP.
> > > > > > > I think there was one version of SoC i think 8016 or some older one
> > > > > > > which had adsp with hvx which can load unsigned modules for compute
> > > > > > > usecase only.
> > > > > > >
> > > > > > > I have added @Ekansh for more clarity.
> > > > > > >
> > > > > > > --srini
> > > > > > For all the available platforms, ADSP supports only signed modules. Unsigned
> > > > > > modules(as well as signed) are supported by CDSP and GDSP subsystems.
> > > > > >
> > > > > > qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
> > > > > > The implications of adding this property would be the following:
> > > > > > on ADSP, SDSP, MDSP:
> > > > > > - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
> > > > > > - Non-secure device node can be used for signed DSP PD offload.
> > > > > >
> > > > > > on CDSP, GDSP:
> > > > > > - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
> > > > > > are created, regardless of this property.
> > > > > > - Both the nodes can be used for signed and unsigned DSP PD offload.
> > > > > >
> > > > > > Note: If the property is not added for CDSP/GDSP, only secure device node can
> > > > > > be used for signed PD offload, if non-secure device is used, the request gets
> > > > > > rejected[1].
> > > > > >
> > > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
> > > > > >
> > > > > > //Ekansh
> > > > > Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
> > > > I checked again and found that unsigned module support for CDSP is
> > > > not available on this platform. Given this, the safest approach would
> > > > be to add the property for both ADSP and CDSP, ensuring that all
> > > > created device nodes can be used for signed PD offload. I can provide
> > > The property allows *unsigned* PD offload though
> > I don't think I can directly relate this property to unsigned PD offload. This is just
> > defining what type of device node will be created and whether the channel is secure
> > or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
> > of whether this property is added or not. If DSP does not support unsigned offload, it
> > should return failures for such requests.
> > > > a more definitive recommendation once I know the specific use cases
> > > > you plan to run.
> > > Why would the usecase affect this?
> > I'm saying this as per past discussions where some application was relying on non-secure
> > device node on some old platform(on postmarketOS)[1] and having this property in place.
> > So if similar usecase is being enabled here, the property might be required[1].
>
> I'm testing these changes on postmarketOS. However, sensors aren't working
> through FastRPC on sdm660.
How? Could you mention, what exactly doesn't work?
>
> Is it better to leave this property for both nodes?
>
> > [1] https://lkml.org/lkml/2024/8/15/117
> > > Konrad
>
> --
> Best regards,
> Nickolay
>
--
With best wishes
Dmitry
21.11.2025 15:11, Dmitry Baryshkov пишет:
> On Fri, Nov 21, 2025 at 11:18:31AM +0300, Nickolay Goppen wrote:
>> 21.11.2025 11:11, Ekansh Gupta пишет:
>>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>>> +Srini?
>>>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>>>>> compatiblity for such users.
>>>>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>>>> devices)?
>>>>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>>
>>>>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>>>>> usecase only.
>>>>>>>>
>>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>>
>>>>>>>> --srini
>>>>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>>>>
>>>>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>>>>> The implications of adding this property would be the following:
>>>>>>> on ADSP, SDSP, MDSP:
>>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>>
>>>>>>> on CDSP, GDSP:
>>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>>>>> are created, regardless of this property.
>>>>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>>>>
>>>>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>>>>> rejected[1].
>>>>>>>
>>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>>
>>>>>>> //Ekansh
>>>>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>>>>> I checked again and found that unsigned module support for CDSP is
>>>>> not available on this platform. Given this, the safest approach would
>>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>>> created device nodes can be used for signed PD offload. I can provide
>>>> The property allows *unsigned* PD offload though
>>> I don't think I can directly relate this property to unsigned PD offload. This is just
>>> defining what type of device node will be created and whether the channel is secure
>>> or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
>>> of whether this property is added or not. If DSP does not support unsigned offload, it
>>> should return failures for such requests.
>>>>> a more definitive recommendation once I know the specific use cases
>>>>> you plan to run.
>>>> Why would the usecase affect this?
>>> I'm saying this as per past discussions where some application was relying on non-secure
>>> device node on some old platform(on postmarketOS)[1] and having this property in place.
>>> So if similar usecase is being enabled here, the property might be required[1].
>> I'm testing these changes on postmarketOS. However, sensors aren't working
>> through FastRPC on sdm660.
> How? Could you mention, what exactly doesn't work?
I meant that smgr doesn't use the FastRPC
>> Is it better to leave this property for both nodes?
>>
>>> [1] https://lkml.org/lkml/2024/8/15/117
>>>> Konrad
>> --
>> Best regards,
>> Nickolay
>>
--
Best regards,
Nickolay
On 11/21/2025 1:48 PM, Nickolay Goppen wrote:
>
> 21.11.2025 11:11, Ekansh Gupta пишет:
>>
>> On 11/20/2025 5:17 PM, Konrad Dybcio wrote:
>>> On 11/20/25 11:54 AM, Ekansh Gupta wrote:
>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>> +Srini?
>>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>>>> compatiblity for such users.
>>>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>>> devices)?
>>>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>
>>>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>>>> usecase only.
>>>>>>>
>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>
>>>>>>> --srini
>>>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>>>
>>>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>>>> The implications of adding this property would be the following:
>>>>>> on ADSP, SDSP, MDSP:
>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>
>>>>>> on CDSP, GDSP:
>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>>>> are created, regardless of this property.
>>>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>>>
>>>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>>>> rejected[1].
>>>>>>
>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>
>>>>>> //Ekansh
>>>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>>>> I checked again and found that unsigned module support for CDSP is
>>>> not available on this platform. Given this, the safest approach would
>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>> created device nodes can be used for signed PD offload. I can provide
>>> The property allows *unsigned* PD offload though
>> I don't think I can directly relate this property to unsigned PD offload. This is just
>> defining what type of device node will be created and whether the channel is secure
>> or not. There is a possibility of making unsigned PD request(on CDSP/GDSP) irrespective
>> of whether this property is added or not. If DSP does not support unsigned offload, it
>> should return failures for such requests.
>>>> a more definitive recommendation once I know the specific use cases
>>>> you plan to run.
>>> Why would the usecase affect this?
>> I'm saying this as per past discussions where some application was relying on non-secure
>> device node on some old platform(on postmarketOS)[1] and having this property in place.
>> So if similar usecase is being enabled here, the property might be required[1].
>
> I'm testing these changes on postmarketOS. However, sensors aren't working through FastRPC on sdm660.
>
> Is it better to leave this property for both nodes?
Yes, I would suggest to have it for both nodes here due to the previously provided reason.
>
>> [1] https://lkml.org/lkml/2024/8/15/117
>>> Konrad
>
20.11.2025 13:54, Ekansh Gupta пишет:
>
> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>
>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>
>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>> ---
>>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>>> + label = "turing";
>>>>>>>>>> "cdsp"
>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>> +
>>>>>>>>>>> + fastrpc {
>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>> created for CDSP
>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>> Is this property not neccessary anymore?
>>>>>>> +Srini?
>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>> it gets caught during dtb checks.
>>>>>>
>>>>>>
>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>> compatiblity for such users.
>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>> the driver behavior was previously such that unsigned modules were
>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>> devices)?
>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>> first started upstreaming fastrpc driver.
>>>>
>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>> I think there was one version of SoC i think 8016 or some older one
>>>> which had adsp with hvx which can load unsigned modules for compute
>>>> usecase only.
>>>>
>>>> I have added @Ekansh for more clarity.
>>>>
>>>> --srini
>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>
>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>> The implications of adding this property would be the following:
>>> on ADSP, SDSP, MDSP:
>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>> - Non-secure device node can be used for signed DSP PD offload.
>>>
>>> on CDSP, GDSP:
>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>> are created, regardless of this property.
>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>
>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>> be used for signed PD offload, if non-secure device is used, the request gets
>>> rejected[1].
>>>
>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>
>>> //Ekansh
>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
> I checked again and found that unsigned module support for CDSP is
> not available on this platform. Given this, the safest approach would
> be to add the property for both ADSP and CDSP, ensuring that all
> created device nodes can be used for signed PD offload. I can provide
> a more definitive recommendation once I know the specific use cases
> you plan to run.
It would be nice to have some testing instructions or how-to, something
simple as "hello world" to be able to test it, to see if it works at all
> //Ekansh
>>>>> Konrad
--
Best regards,
Nickolay
On 11/20/2025 4:52 PM, Nickolay Goppen wrote:
> 20.11.2025 13:54, Ekansh Gupta пишет:
>>
>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>
>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>
>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>> ---
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>> "cdsp"
>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>> +
>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>> created for CDSP
>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>> +Srini?
>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>> it gets caught during dtb checks.
>>>>>>>
>>>>>>>
>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>> compatiblity for such users.
>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>> devices)?
>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>> first started upstreaming fastrpc driver.
>>>>>
>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>> usecase only.
>>>>>
>>>>> I have added @Ekansh for more clarity.
>>>>>
>>>>> --srini
>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>
>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>> The implications of adding this property would be the following:
>>>> on ADSP, SDSP, MDSP:
>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>
>>>> on CDSP, GDSP:
>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>> are created, regardless of this property.
>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>
>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>> rejected[1].
>>>>
>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>
>>>> //Ekansh
>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>> I checked again and found that unsigned module support for CDSP is
>> not available on this platform. Given this, the safest approach would
>> be to add the property for both ADSP and CDSP, ensuring that all
>> created device nodes can be used for signed PD offload. I can provide
>> a more definitive recommendation once I know the specific use cases
>> you plan to run.
>
> It would be nice to have some testing instructions or how-to, something simple as "hello world" to be able to test it, to see if it works at all
There are some test pre-builts available here along with how-to instructions:
https://github.com/qualcomm/fastrpc/tree/development/test
You can try running calculator from here for basic offload testing.
>
>
>> //Ekansh
>>>>>> Konrad
>
On Fri, Nov 21, 2025 at 01:28:09PM +0530, Ekansh Gupta wrote:
>
>
> On 11/20/2025 4:52 PM, Nickolay Goppen wrote:
> > 20.11.2025 13:54, Ekansh Gupta пишет:
> >>
> >> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
> >>> 20.11.2025 07:55, Ekansh Gupta пишет:
> >>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
> >>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
> >>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
> >>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
> >>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
> >>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
> >>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
> >>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
> >>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
> >>>>>>>>>>>> * add shared memory p2p nodes for CDSP
> >>>>>>>>>>>> * add CDSP-specific smmu node
> >>>>>>>>>>>> * add CDSP peripheral image loader node
> >>>>>>>>>>>>
> >>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
> >>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
> >>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
> >>>>>>>>>>>> cdsp_region, which is also larger in size.
> >>>>>>>>>>>>
> >>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
> >>>>>>>>>>>> related nodes and add buffer_mem back.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> >>>>>>>>>>>> ---
> >>>>>>>>>>> [...]
> >>>>>>>>>>>
> >>>>>>>>>>>> + label = "turing";
> >>>>>>>>>>> "cdsp"
> >>>>>>>>>> Ok, I'll change this in the next revision.
> >>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
> >>>>>>>>>>>> + qcom,remote-pid = <5>;
> >>>>>>>>>>>> +
> >>>>>>>>>>>> + fastrpc {
> >>>>>>>>>>>> + compatible = "qcom,fastrpc";
> >>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
> >>>>>>>>>>>> + label = "cdsp";
> >>>>>>>>>>>> + qcom,non-secure-domain;
> >>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
> >>>>>>>>>>> created for CDSP
> >>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
> >>>>>>>>> Is this property not neccessary anymore?
> >>>>>>>> +Srini?
> >>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
> >>>>>>> unsigned and signed loading, we create both secured and non-secure node
> >>>>>>> by default. May be we can provide that clarity in yaml bindings so that
> >>>>>>> it gets caught during dtb checks.
> >>>>>>>
> >>>>>>>
> >>>>>>> However in ADSP case, we only support singed modules, due to historical
> >>>>>>> reasons how this driver evolved over years, we have this flag to allow
> >>>>>>> compatiblity for such users.
> >>>>>> Does that mean that we can only load signed modules on the ADSP, but
> >>>>>> the driver behavior was previously such that unsigned modules were
> >>>>>> allowed (which was presumably fine on devboards, but not on fused
> >>>>>> devices)?
> >>>>> Yes, its true that we allowed full access to adsp device nodes when we
> >>>>> first started upstreaming fastrpc driver.
> >>>>>
> >>>>> irrespective of the board only signed modules are supported on the ADSP.
> >>>>> I think there was one version of SoC i think 8016 or some older one
> >>>>> which had adsp with hvx which can load unsigned modules for compute
> >>>>> usecase only.
> >>>>>
> >>>>> I have added @Ekansh for more clarity.
> >>>>>
> >>>>> --srini
> >>>> For all the available platforms, ADSP supports only signed modules. Unsigned
> >>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
> >>>>
> >>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
> >>>> The implications of adding this property would be the following:
> >>>> on ADSP, SDSP, MDSP:
> >>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
> >>>> - Non-secure device node can be used for signed DSP PD offload.
> >>>>
> >>>> on CDSP, GDSP:
> >>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
> >>>> are created, regardless of this property.
> >>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
> >>>>
> >>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
> >>>> be used for signed PD offload, if non-secure device is used, the request gets
> >>>> rejected[1].
> >>>>
> >>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
> >>>>
> >>>> //Ekansh
> >>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
> >> I checked again and found that unsigned module support for CDSP is
> >> not available on this platform. Given this, the safest approach would
> >> be to add the property for both ADSP and CDSP, ensuring that all
> >> created device nodes can be used for signed PD offload. I can provide
> >> a more definitive recommendation once I know the specific use cases
> >> you plan to run.
> >
> > It would be nice to have some testing instructions or how-to, something simple as "hello world" to be able to test it, to see if it works at all
> There are some test pre-builts available here along with how-to instructions:
> https://github.com/qualcomm/fastrpc/tree/development/test
>
> You can try running calculator from here for basic offload testing.
But this would test the signed binaries.
--
With best wishes
Dmitry
On 11/21/2025 5:36 PM, Dmitry Baryshkov wrote:
> On Fri, Nov 21, 2025 at 01:28:09PM +0530, Ekansh Gupta wrote:
>>
>> On 11/20/2025 4:52 PM, Nickolay Goppen wrote:
>>> 20.11.2025 13:54, Ekansh Gupta пишет:
>>>> On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>>>>> 20.11.2025 07:55, Ekansh Gupta пишет:
>>>>>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>>>>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>>>>>> On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:
>>>>>>>>> On 11/3/25 12:52 PM, Konrad Dybcio wrote:
>>>>>>>>>> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>>>>>>>>>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>>>>>>>>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>>>>>>>>>>> On 10/23/25 9:51 PM, Nickolay Goppen wrote:
>>>>>>>>>>>>>> In order to enable CDSP support for SDM660 SoC:
>>>>>>>>>>>>>> * add shared memory p2p nodes for CDSP
>>>>>>>>>>>>>> * add CDSP-specific smmu node
>>>>>>>>>>>>>> * add CDSP peripheral image loader node
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Memory region for CDSP in SDM660 occupies the same spot as
>>>>>>>>>>>>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
>>>>>>>>>>>>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
>>>>>>>>>>>>>> cdsp_region, which is also larger in size.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
>>>>>>>>>>>>>> related nodes and add buffer_mem back.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>>> + label = "turing";
>>>>>>>>>>>>> "cdsp"
>>>>>>>>>>>> Ok, I'll change this in the next revision.
>>>>>>>>>>>>>> + mboxes = <&apcs_glb 29>;
>>>>>>>>>>>>>> + qcom,remote-pid = <5>;
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + fastrpc {
>>>>>>>>>>>>>> + compatible = "qcom,fastrpc";
>>>>>>>>>>>>>> + qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>>>>>>>> + label = "cdsp";
>>>>>>>>>>>>>> + qcom,non-secure-domain;
>>>>>>>>>>>>> This shouldn't matter, both a secure and a non-secure device is
>>>>>>>>>>>>> created for CDSP
>>>>>>>>>>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>>>>>>>>>>> Is this property not neccessary anymore?
>>>>>>>>>> +Srini?
>>>>>>>>> That is true, we do not require this for CDSP, as CDSP allows both
>>>>>>>>> unsigned and signed loading, we create both secured and non-secure node
>>>>>>>>> by default. May be we can provide that clarity in yaml bindings so that
>>>>>>>>> it gets caught during dtb checks.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> However in ADSP case, we only support singed modules, due to historical
>>>>>>>>> reasons how this driver evolved over years, we have this flag to allow
>>>>>>>>> compatiblity for such users.
>>>>>>>> Does that mean that we can only load signed modules on the ADSP, but
>>>>>>>> the driver behavior was previously such that unsigned modules were
>>>>>>>> allowed (which was presumably fine on devboards, but not on fused
>>>>>>>> devices)?
>>>>>>> Yes, its true that we allowed full access to adsp device nodes when we
>>>>>>> first started upstreaming fastrpc driver.
>>>>>>>
>>>>>>> irrespective of the board only signed modules are supported on the ADSP.
>>>>>>> I think there was one version of SoC i think 8016 or some older one
>>>>>>> which had adsp with hvx which can load unsigned modules for compute
>>>>>>> usecase only.
>>>>>>>
>>>>>>> I have added @Ekansh for more clarity.
>>>>>>>
>>>>>>> --srini
>>>>>> For all the available platforms, ADSP supports only signed modules. Unsigned
>>>>>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>>>>>
>>>>>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>>>>>> The implications of adding this property would be the following:
>>>>>> on ADSP, SDSP, MDSP:
>>>>>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>>>>>> - Non-secure device node can be used for signed DSP PD offload.
>>>>>>
>>>>>> on CDSP, GDSP:
>>>>>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>>>>> are created, regardless of this property.
>>>>>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>>>>>
>>>>>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>>>>>> be used for signed PD offload, if non-secure device is used, the request gets
>>>>>> rejected[1].
>>>>>>
>>>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>>>>>
>>>>>> //Ekansh
>>>>> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
>>>> I checked again and found that unsigned module support for CDSP is
>>>> not available on this platform. Given this, the safest approach would
>>>> be to add the property for both ADSP and CDSP, ensuring that all
>>>> created device nodes can be used for signed PD offload. I can provide
>>>> a more definitive recommendation once I know the specific use cases
>>>> you plan to run.
>>> It would be nice to have some testing instructions or how-to, something simple as "hello world" to be able to test it, to see if it works at all
>> There are some test pre-builts available here along with how-to instructions:
>> https://github.com/qualcomm/fastrpc/tree/development/test
>>
>> You can try running calculator from here for basic offload testing.
> But this would test the signed binaries.
Yes, binaries available here are signed.
>
© 2016 - 2026 Red Hat, Inc.