Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes
From: Nickolay Goppen
Date: Thu Nov 20 2025 - 02:57:52 EST
20.11.2025 07:55, Ekansh Gupta пишет:
Does this mean that the qcom,non-secure-domain property should be dropped from both nodes?
On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
On 11/12/25 1:52 PM, Konrad Dybcio wrote:For all the available platforms, ADSP supports only signed modules. Unsigned
On 11/10/25 6:41 PM, Srinivas Kandagatla wrote:Yes, its true that we allowed full access to adsp device nodes when we
On 11/3/25 12:52 PM, Konrad Dybcio wrote:Does that mean that we can only load signed modules on the ADSP, but
On 10/31/25 12:30 PM, Nickolay Goppen wrote:That is true, we do not require this for CDSP, as CDSP allows both
24.10.2025 16:58, Nickolay Goppen пишет:+Srini?
24.10.2025 11:28, Konrad Dybcio пишет:Is this property not neccessary anymore?
On 10/23/25 9:51 PM, Nickolay Goppen wrote:Ok, I'll change this in the next revision.
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"
I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP+ mboxes = <&apcs_glb 29>;This shouldn't matter, both a secure and a non-secure device is
+ qcom,remote-pid = <5>;
+
+ fastrpc {
+ compatible = "qcom,fastrpc";
+ qcom,glink-channels = "fastrpcglink-apps-dsp";
+ label = "cdsp";
+ qcom,non-secure-domain;
created for CDSP
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.
the driver behavior was previously such that unsigned modules were
allowed (which was presumably fine on devboards, but not on fused
devices)?
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
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
--
Best regards,
Nickolay