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


> 
> Konrad