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

From: Nickolay Goppen
Date: Mon Dec 08 2025 - 02:50:54 EST


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

+ 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