[PATCH v2 0/3] arm64: dts: qcom: Add support for SDM660 CDSP and ADSP FastRPC

[PATCH v2 0/3] arm64: dts: qcom: Add support for SDM660 CDSP and ADSP FastRPC

[Nickolay Goppen]

This series adds support for SDM660 CDSP remoteproc and also adds
FastRPC support for ADSP.

Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
---
Changes in v2:
- As suggested by Konrad reordered properties in the cdsp_smmu node.
- Fixed indentations for interrupts property for the cdsp_smmu.
- Fixed formatting for the CDSP node.
- Splitted ADSP-related commit to separate ones.
- Link to v1: https://lore.kernel.org/r/20251019-qcom-sdm660-cdsp-adsp-dts-v1-0-9ab5f2865a6e@mainlining.org

---
Nickolay Goppen (3):
      arm64: dts: qcom: sdm630/660: Add CDSP-related nodes
      arm64: dts: qcom: sdm630: Add missing vote clock and GDSC to lpass_smmu
      arm64: dts: qcom: sdm630: Add FastRPC nodes to ADSP

 arch/arm64/boot/dts/qcom/sdm630.dtsi |  40 ++++++++-
 arch/arm64/boot/dts/qcom/sdm636.dtsi |  23 +++--
 arch/arm64/boot/dts/qcom/sdm660.dtsi | 162 +++++++++++++++++++++++++++++++++++
 3 files changed, 215 insertions(+), 10 deletions(-)
---
base-commit: 93f3bab4310d4ff73027cc4f87174284d4977acf
change-id: 20251019-qcom-sdm660-cdsp-adsp-dts-8fabb670338e
prerequisite-change-id: 20251018-qcom-sdm660-cdsp-59ad56867a18:v2
prerequisite-patch-id: a8c9703aec1663b8226556ba1770bd6c5b4ef060
prerequisite-patch-id: 5a49b179c69e045e8003f28e8ef0e6e003c0064a
prerequisite-patch-id: dd158e1214a7e73ac0a8f1da9d3face61ad7d5bd

Best regards,
-- 
Nickolay Goppen <setotau@mainlining.org>

[PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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";
 };

-- 
2.51.1

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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"

> +			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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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
> Konrad

-- 
Best regards,
Nickolay

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Nickolay Goppen]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Konrad Dybcio]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Srinivas Kandagatla]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Konrad Dybcio]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Srinivas Kandagatla]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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

>
>
>> Konrad

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Nickolay Goppen]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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.

//Ekansh
>>>
>>>> Konrad
>

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Nickolay Goppen]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Ekansh Gupta]

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
>

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Dmitry Baryshkov]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Ekansh Gupta]

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.
>

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Konrad Dybcio]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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].

[1] https://lkml.org/lkml/2024/8/15/117
>
> Konrad

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Nickolay Goppen]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Ekansh Gupta]

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
>

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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?

> 
> 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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Nickolay Goppen]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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.

> >
> >> 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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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?
>>>> 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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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


>>>>> 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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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

>
>
>>>>>> 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
>>

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Nickolay Goppen]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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?
>
>>>>>> 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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Nickolay Goppen]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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



>>>> 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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Nickolay Goppen]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Ekansh Gupta]

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
>

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Dmitry Baryshkov]

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

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[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


-- 
Best regards,
Nickolay

Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

[Nickolay Goppen]

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

[PATCH v2 2/3] arm64: dts: qcom: sdm630: Add missing vote clock and GDSC to lpass_smmu

[Nickolay Goppen]

Add missing vote clock and GDSC to lpass_smmu node to allow FastRPC
services to probe properly.

Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
---
 arch/arm64/boot/dts/qcom/sdm630.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index a6a1933229b9..f4906ee3f0c3 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -1217,6 +1217,11 @@ lpass_smmu: iommu@5100000 {
 			reg = <0x05100000 0x40000>;
 			#iommu-cells = <1>;
 
+			clocks = <&gcc GCC_HLOS1_VOTE_LPASS_ADSP_SMMU_CLK>;
+			clock-names = "bus";
+
+			power-domains = <&gcc HLOS1_VOTE_LPASS_ADSP_GDSC>;
+
 			#global-interrupts = <2>;
 			interrupts =
 				<GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,

-- 
2.51.1

Re: [PATCH v2 2/3] arm64: dts: qcom: sdm630: Add missing vote clock and GDSC to lpass_smmu

[Konrad Dybcio]

On 10/23/25 9:52 PM, Nickolay Goppen wrote:
> Add missing vote clock and GDSC to lpass_smmu node to allow FastRPC
> services to probe properly.
> 
> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> ---

"to make sure the requires resources are enabled before
attempting to access the hardware"

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

[PATCH v2 3/3] arm64: dts: qcom: sdm630: Add FastRPC nodes to ADSP

[Nickolay Goppen]

Add FastRPC subnode with compute-cb subnodes to ADSP node.

Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
---
 arch/arm64/boot/dts/qcom/sdm630.dtsi | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index f4906ee3f0c3..2764666714e6 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -2342,6 +2342,39 @@ q6routing: routing {
 						};
 					};
 				};
+
+				fastrpc {
+					compatible = "qcom,fastrpc";
+					qcom,glink-channels = "fastrpcglink-apps-dsp";
+					label = "adsp";
+					qcom,non-secure-domain;
+					#address-cells = <1>;
+					#size-cells = <0>;
+
+					compute-cb@1 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <1>;
+						iommus = <&lpass_smmu 3>;
+					};
+
+					compute-cb@2 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <2>;
+						iommus = <&lpass_smmu 7>;
+					};
+
+					compute-cb@3 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <3>;
+						iommus = <&lpass_smmu 8>;
+					};
+
+					compute-cb@4 {
+						compatible = "qcom,fastrpc-compute-cb";
+						reg = <4>;
+						iommus = <&lpass_smmu 9>;
+					};
+				};
 			};
 		};
 

-- 
2.51.1

Re: [PATCH v2 3/3] arm64: dts: qcom: sdm630: Add FastRPC nodes to ADSP

[Konrad Dybcio]

On 10/23/25 9:52 PM, Nickolay Goppen wrote:
> Add FastRPC subnode with compute-cb subnodes to ADSP node.
> 
> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> ---
>  arch/arm64/boot/dts/qcom/sdm630.dtsi | 33 +++++++++++++++++++++++++++++++++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> index f4906ee3f0c3..2764666714e6 100644
> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> @@ -2342,6 +2342,39 @@ q6routing: routing {
>  						};
>  					};
>  				};
> +
> +				fastrpc {
> +					compatible = "qcom,fastrpc";
> +					qcom,glink-channels = "fastrpcglink-apps-dsp";
> +					label = "adsp";
> +					qcom,non-secure-domain;

I'm not sure this property is valid

Konrad

Re: [PATCH v2 3/3] arm64: dts: qcom: sdm630: Add FastRPC nodes to ADSP

[Nickolay Goppen]

24.10.2025 11:26, Konrad Dybcio пишет:
> On 10/23/25 9:52 PM, Nickolay Goppen wrote:
>> Add FastRPC subnode with compute-cb subnodes to ADSP node.
>>
>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>> ---
>>   arch/arm64/boot/dts/qcom/sdm630.dtsi | 33 +++++++++++++++++++++++++++++++++
>>   1 file changed, 33 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> index f4906ee3f0c3..2764666714e6 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> @@ -2342,6 +2342,39 @@ q6routing: routing {
>>   						};
>>   					};
>>   				};
>> +
>> +				fastrpc {
>> +					compatible = "qcom,fastrpc";
>> +					qcom,glink-channels = "fastrpcglink-apps-dsp";
>> +					label = "adsp";
>> +					qcom,non-secure-domain;
> I'm not sure this property is valid

I've looked into FastRPC driver and found out, that the 
"qcom,non-secure-domain" property isn't valid at least for adsp

>
> Konrad

-- 
Best regards,
Nickolay

Re: [PATCH v2 3/3] arm64: dts: qcom: sdm630: Add FastRPC nodes to ADSP

[Nickolay Goppen]

09.11.2025 01:22, Nickolay Goppen пишет:
>
> 24.10.2025 11:26, Konrad Dybcio пишет:
>> On 10/23/25 9:52 PM, Nickolay Goppen wrote:
>>> Add FastRPC subnode with compute-cb subnodes to ADSP node.
>>>
>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>> ---
>>>   arch/arm64/boot/dts/qcom/sdm630.dtsi | 33 
>>> +++++++++++++++++++++++++++++++++
>>>   1 file changed, 33 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi 
>>> b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> index f4906ee3f0c3..2764666714e6 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> @@ -2342,6 +2342,39 @@ q6routing: routing {
>>>                           };
>>>                       };
>>>                   };
>>> +
>>> +                fastrpc {
>>> +                    compatible = "qcom,fastrpc";
>>> +                    qcom,glink-channels = "fastrpcglink-apps-dsp";
>>> +                    label = "adsp";
>>> +                    qcom,non-secure-domain;
>> I'm not sure this property is valid
>
> I've looked into FastRPC driver and found out, that the 
> "qcom,non-secure-domain" property isn't valid at least for adsp
>
nvm, it's used when registering the FastRPC device.
>>
>> Konrad
>
-- 
Best regards,
Nickolay