[PATCH 0/4] arm64: dts: qcom: sdm630/660 FastRPC fixes

[PATCH 0/4] arm64: dts: qcom: sdm630/660 FastRPC fixes

[Nickolay Goppen]

This series introduces fixes that make FastRPC on SDM660 work properly.
Currently only the calculator_example test passes on both ADSP and 
CDSP [1].
Also assign adsp_mem region to the ADSP's FastRPC node.

[1]: https://github.com/qualcomm/fastrpc/issues/269#issuecomment-4232125297

Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
---
Nickolay Goppen (4):
      arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly
      arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly
      arm64: dts: qcom: sdm630: describe adsp_mem region properly
      arm64: dts: qcom: sdm630: assign adsp_mem region to ADSP FastRPC node

 arch/arm64/boot/dts/qcom/sdm630.dtsi | 20 +++++++++++---------
 arch/arm64/boot/dts/qcom/sdm660.dtsi | 36 ++++++++++++++++++------------------
 2 files changed, 29 insertions(+), 27 deletions(-)
---
base-commit: e6efabc0afca02efa263aba533f35d90117ab283
change-id: 20260415-qcom-sdm660-cdsp-adsp-fastrpc-dts-fix-d0ca7632045a

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

[PATCH 1/4] arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly

[Nickolay Goppen]

Changing FastRPC compute-cbs' reg values to matching iommu streams
solves SMMU translation errors when trying to use FastRPC on CDSP
so change FastRPC compute-cbs' reg values that way

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

diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi b/arch/arm64/boot/dts/qcom/sdm660.dtsi
index 3fd6dd82a992..0fca9662c64a 100644
--- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
@@ -350,57 +350,57 @@ fastrpc {
 				#address-cells = <1>;
 				#size-cells = <0>;
 
-				compute-cb@5 {
+				compute-cb@3 {
 					compatible = "qcom,fastrpc-compute-cb";
-					reg = <5>;
+					reg = <3>;
 					iommus = <&cdsp_smmu 3>;
 				};
 
-				compute-cb@6 {
+				compute-cb@4 {
 					compatible = "qcom,fastrpc-compute-cb";
-					reg = <6>;
+					reg = <4>;
 					iommus = <&cdsp_smmu 4>;
 				};
 
-				compute-cb@7 {
+				compute-cb@5 {
 					compatible = "qcom,fastrpc-compute-cb";
-					reg = <7>;
+					reg = <5>;
 					iommus = <&cdsp_smmu 5>;
 				};
 
-				compute-cb@8 {
+				compute-cb@6 {
 					compatible = "qcom,fastrpc-compute-cb";
-					reg = <8>;
+					reg = <6>;
 					iommus = <&cdsp_smmu 6>;
 				};
 
-				compute-cb@9 {
+				compute-cb@7 {
 					compatible = "qcom,fastrpc-compute-cb";
-					reg = <9>;
+					reg = <7>;
 					iommus = <&cdsp_smmu 7>;
 				};
 
-				compute-cb@10 {
+				compute-cb@8 {
 					compatible = "qcom,fastrpc-compute-cb";
-					reg = <10>;
+					reg = <8>;
 					iommus = <&cdsp_smmu 8>;
 				};
 
-				compute-cb@11 {
+				compute-cb@9 {
 					compatible = "qcom,fastrpc-compute-cb";
-					reg = <11>;
+					reg = <9>;
 					iommus = <&cdsp_smmu 9>;
 				};
 
-				compute-cb@12 {
+				compute-cb@10 {
 					compatible = "qcom,fastrpc-compute-cb";
-					reg = <12>;
+					reg = <10>;
 					iommus = <&cdsp_smmu 10>;
 				};
 
-				compute-cb@13 {
+				compute-cb@11 {
 					compatible = "qcom,fastrpc-compute-cb";
-					reg = <13>;
+					reg = <11>;
 					iommus = <&cdsp_smmu 11>;
 				};
 			};

-- 
2.53.0

[PATCH 2/4] arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly

[Nickolay Goppen]

Changing FastRPC compute-cbs' reg values to matching iommu streams
solves SMMU translation errors when trying to use FastRPC on ADSP
so change FastRPC compute-cbs' reg values that way

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

diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index bef3213165d6..4b47efdb57b2 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -2459,27 +2459,27 @@ fastrpc {
 					#address-cells = <1>;
 					#size-cells = <0>;
 
-					compute-cb@1 {
+					compute-cb@3 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <1>;
+						reg = <3>;
 						iommus = <&lpass_smmu 3>;
 					};
 
-					compute-cb@2 {
+					compute-cb@7 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <2>;
+						reg = <7>;
 						iommus = <&lpass_smmu 7>;
 					};
 
-					compute-cb@3 {
+					compute-cb@8 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <3>;
+						reg = <8>;
 						iommus = <&lpass_smmu 8>;
 					};
 
-					compute-cb@4 {
+					compute-cb@9 {
 						compatible = "qcom,fastrpc-compute-cb";
-						reg = <4>;
+						reg = <9>;
 						iommus = <&lpass_smmu 9>;
 					};
 				};

-- 
2.53.0

[PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly

[Nickolay Goppen]

Downstream [1] this region is marked as shared and reusable so
describe it that way.

[1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448

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

diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index 4b47efdb57b2..13094b5e9339 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
 		};
 
 		adsp_mem: adsp-region@f6000000 {
+			compatible = "shared-dma-pool";
 			reg = <0x0 0xf6000000 0x0 0x800000>;
-			no-map;
+			reusable;
 		};
 
 		qseecom_mem: qseecom-region@f6800000 {

-- 
2.53.0

[PATCH 4/4] arm64: dts: qcom: sdm630: assign adsp_mem region to ADSP FastRPC node

[Nickolay Goppen]

Downstream [1] ADSP FastRPC node has the adsp_mem region assigned, so
assign it to the ADSP FastRPC node.

[1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L1693

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

diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index 13094b5e9339..19d80fbba57d 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -2456,6 +2456,7 @@ fastrpc {
 					compatible = "qcom,fastrpc";
 					qcom,glink-channels = "fastrpcglink-apps-dsp";
 					label = "adsp";
+					memory-region = <&adsp_mem>;
 					qcom,non-secure-domain;
 					#address-cells = <1>;
 					#size-cells = <0>;

-- 
2.53.0

Re: [PATCH 1/4] arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly

[Konrad Dybcio]

On 4/15/26 11:40 AM, Nickolay Goppen wrote:
> Changing FastRPC compute-cbs' reg values to matching iommu streams
> solves SMMU translation errors when trying to use FastRPC on CDSP
> so change FastRPC compute-cbs' reg values that way
> 
> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> ---

Fixes: c0c32a9e3493 ("arm64: dts: qcom: sdm630/660: Add CDSP-related nodes")

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

Konrad

Re: [PATCH 2/4] arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly

[Konrad Dybcio]

On 4/15/26 11:40 AM, Nickolay Goppen wrote:
> Changing FastRPC compute-cbs' reg values to matching iommu streams
> solves SMMU translation errors when trying to use FastRPC on ADSP
> so change FastRPC compute-cbs' reg values that way
> 
> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> ---

Fixes: af2ce7296643 ("arm64: dts: qcom: sdm630: Add FastRPC nodes to ADSP")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly

[Konrad Dybcio]

On 4/15/26 11:40 AM, Nickolay Goppen wrote:
> Downstream [1] this region is marked as shared and reusable so
> describe it that way.
> 
> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
> 
> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> ---

+Ekansh some insight, please?

We're giving away that memory via qcom_scm_assign_mem() anyway
and I would assume that making it not-"no-map" could introduce issues
when the OS tries to access that region

Konrad


>  arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> index 4b47efdb57b2..13094b5e9339 100644
> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>  		};
>  
>  		adsp_mem: adsp-region@f6000000 {
> +			compatible = "shared-dma-pool";
>  			reg = <0x0 0xf6000000 0x0 0x800000>;
> -			no-map;
> +			reusable;
>  		};
>  
>  		qseecom_mem: qseecom-region@f6800000 {
> 

Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly

[Nickolay Goppen]

15.04.2026 12:52, Konrad Dybcio wrote:
> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>> Downstream [1] this region is marked as shared and reusable so
>> describe it that way.
>>
>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>
>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>> ---
> +Ekansh some insight, please?
>
> We're giving away that memory via qcom_scm_assign_mem() anyway
> and I would assume that making it not-"no-map" could introduce issues
> when the OS tries to access that region

I've made it as sdm845 done [1].

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/sdm845.dtsi#n893

> Konrad
>
>
>>   arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> index 4b47efdb57b2..13094b5e9339 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>>   		};
>>   
>>   		adsp_mem: adsp-region@f6000000 {
>> +			compatible = "shared-dma-pool";
>>   			reg = <0x0 0xf6000000 0x0 0x800000>;
>> -			no-map;
>> +			reusable;
>>   		};
>>   
>>   		qseecom_mem: qseecom-region@f6800000 {
>>
-- 
Best regards,
Nickolay

Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly

[Ekansh Gupta]

On 15-04-2026 15:22, Konrad Dybcio wrote:
> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>> Downstream [1] this region is marked as shared and reusable so
>> describe it that way.
>>
>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>
>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>> ---
> 
> +Ekansh some insight, please?
> 
> We're giving away that memory via qcom_scm_assign_mem() anyway
> and I would assume that making it not-"no-map" could introduce issues
> when the OS tries to access that region
> 
With the current version and the upcoming planned enhancements, I don't
see any major benefits of making this as not-"no-map".

With posted enhancements[1], the plan is to qcom_scm_assign_mem() the
entire memory-region to lpass VMIDs. and un-assign it only during
fastrpc_rpmsg_remove(). There have been implementation in downstream
where this memory is dumped in case of SSR or audio PDR using minidump,
so marking it `reusable` might make sense there, but that dump logic is
not added upstream.

Upon checking the DT, I see a bigger problem here, this memory-region
looks to me unused, it's not added under fastrpc adsp node(ref. [2]).
Please correct me if I am wrong about this point.

[1]
https://lore.kernel.org/all/20260409062617.1182-1-jianping.li@oss.qualcomm.com/
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7500

//Ekansh
> Konrad
> 
> 
>>  arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> index 4b47efdb57b2..13094b5e9339 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>>  		};
>>  
>>  		adsp_mem: adsp-region@f6000000 {
>> +			compatible = "shared-dma-pool";
>>  			reg = <0x0 0xf6000000 0x0 0x800000>;
>> -			no-map;
>> +			reusable;
>>  		};
>>  
>>  		qseecom_mem: qseecom-region@f6800000 {
>>

Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly

[Nickolay Goppen]

I'm assigning this region in the fourth patch

17 апреля 2026 г. 18:15:45 GMT+03:00, Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> wrote:
>On 15-04-2026 15:22, Konrad Dybcio wrote:
>> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>>> Downstream [1] this region is marked as shared and reusable so
>>> describe it that way.
>>>
>>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>>
>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>> ---
>> 
>> +Ekansh some insight, please?
>> 
>> We're giving away that memory via qcom_scm_assign_mem() anyway
>> and I would assume that making it not-"no-map" could introduce issues
>> when the OS tries to access that region
>> 
>With the current version and the upcoming planned enhancements, I don't
>see any major benefits of making this as not-"no-map".
>
>With posted enhancements[1], the plan is to qcom_scm_assign_mem() the
>entire memory-region to lpass VMIDs. and un-assign it only during
>fastrpc_rpmsg_remove(). There have been implementation in downstream
>where this memory is dumped in case of SSR or audio PDR using minidump,
>so marking it `reusable` might make sense there, but that dump logic is
>not added upstream.
>
>Upon checking the DT, I see a bigger problem here, this memory-region
>looks to me unused, it's not added under fastrpc adsp node(ref. [2]).
>Please correct me if I am wrong about this point.
>
>[1]
>https://lore.kernel.org/all/20260409062617.1182-1-jianping.li@oss.qualcomm.com/
>[2]
>https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7500
>
>//Ekansh
>> Konrad
>> 
>> 
>>>  arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> index 4b47efdb57b2..13094b5e9339 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>>>  		};
>>>  
>>>  		adsp_mem: adsp-region@f6000000 {
>>> +			compatible = "shared-dma-pool";
>>>  			reg = <0x0 0xf6000000 0x0 0x800000>;
>>> -			no-map;
>>> +			reusable;
>>>  		};
>>>  
>>>  		qseecom_mem: qseecom-region@f6800000 {
>>>

Best regards
Nickolay

Re: [PATCH 1/4] arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly

[Dmitry Baryshkov]

On Wed, Apr 15, 2026 at 11:43:29AM +0200, Konrad Dybcio wrote:
> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
> > Changing FastRPC compute-cbs' reg values to matching iommu streams
> > solves SMMU translation errors when trying to use FastRPC on CDSP
> > so change FastRPC compute-cbs' reg values that way
> > 
> > Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> > ---
> 
> Fixes: c0c32a9e3493 ("arm64: dts: qcom: sdm630/660: Add CDSP-related nodes")

With Fixes in place:


Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>



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

-- 
With best wishes
Dmitry

Re: [PATCH 2/4] arm64: dts: qcom: sdm630: set adsp compute-cbs' regs properly

[Dmitry Baryshkov]

On Wed, Apr 15, 2026 at 11:50:09AM +0200, Konrad Dybcio wrote:
> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
> > Changing FastRPC compute-cbs' reg values to matching iommu streams
> > solves SMMU translation errors when trying to use FastRPC on ADSP
> > so change FastRPC compute-cbs' reg values that way
> > 
> > Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> > ---
> 
> Fixes: af2ce7296643 ("arm64: dts: qcom: sdm630: Add FastRPC nodes to ADSP")


Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>



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

-- 
With best wishes
Dmitry

Re: [PATCH 4/4] arm64: dts: qcom: sdm630: assign adsp_mem region to ADSP FastRPC node

[Dmitry Baryshkov]

On Wed, Apr 15, 2026 at 12:40:26PM +0300, Nickolay Goppen wrote:
> Downstream [1] ADSP FastRPC node has the adsp_mem region assigned, so
> assign it to the ADSP FastRPC node.
> 
> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L1693
> 
> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> ---
>  arch/arm64/boot/dts/qcom/sdm630.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>


-- 
With best wishes
Dmitry

Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly

[Ekansh Gupta]

On 17-04-2026 23:06, Nickolay Goppen wrote:
> I'm assigning this region in the fourth patch
Okay, I see. Thanks for pointing it out.
> 
> 17 апреля 2026 г. 18:15:45 GMT+03:00, Ekansh Gupta <ekansh.gupta@oss.qualcomm.com> wrote:
>> On 15-04-2026 15:22, Konrad Dybcio wrote:
>>> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>>>> Downstream [1] this region is marked as shared and reusable so
>>>> describe it that way.
>>>>
>>>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>>>
>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>> ---
>>>
>>> +Ekansh some insight, please?
>>>
>>> We're giving away that memory via qcom_scm_assign_mem() anyway
>>> and I would assume that making it not-"no-map" could introduce issues
>>> when the OS tries to access that region
>>>
>> With the current version and the upcoming planned enhancements, I don't
>> see any major benefits of making this as not-"no-map".
>>
>> With posted enhancements[1], the plan is to qcom_scm_assign_mem() the
>> entire memory-region to lpass VMIDs. and un-assign it only during
>> fastrpc_rpmsg_remove(). There have been implementation in downstream
>> where this memory is dumped in case of SSR or audio PDR using minidump,
>> so marking it `reusable` might make sense there, but that dump logic is
>> not added upstream.
>>
>> Upon checking the DT, I see a bigger problem here, this memory-region
>> looks to me unused, it's not added under fastrpc adsp node(ref. [2]).
>> Please correct me if I am wrong about this point.
>>
>> [1]
>> https://lore.kernel.org/all/20260409062617.1182-1-jianping.li@oss.qualcomm.com/
>> [2]
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7500
>>
>> //Ekansh
>>> Konrad
>>>
>>>
>>>>  arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>>> index 4b47efdb57b2..13094b5e9339 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>>>>  		};
>>>>  
>>>>  		adsp_mem: adsp-region@f6000000 {
>>>> +			compatible = "shared-dma-pool";
>>>>  			reg = <0x0 0xf6000000 0x0 0x800000>;
>>>> -			no-map;
>>>> +			reusable;
>>>>  		};
>>>>  
>>>>  		qseecom_mem: qseecom-region@f6800000 {
>>>>
> 
> Best regards
> Nickolay

Re: [PATCH 4/4] arm64: dts: qcom: sdm630: assign adsp_mem region to ADSP FastRPC node

[Ekansh Gupta]

On 15-04-2026 15:10, Nickolay Goppen wrote:
> Downstream [1] ADSP FastRPC node has the adsp_mem region assigned, so
> assign it to the ADSP FastRPC node.
> 
> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L1693
> 
> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> ---
>  arch/arm64/boot/dts/qcom/sdm630.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> index 13094b5e9339..19d80fbba57d 100644
> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> @@ -2456,6 +2456,7 @@ fastrpc {
>  					compatible = "qcom,fastrpc";
>  					qcom,glink-channels = "fastrpcglink-apps-dsp";
>  					label = "adsp";
> +					memory-region = <&adsp_mem>;
This memory-region won't really be useful without proper VMID
configuration. Please add LPASS and ADSP_HEAP VMIDs.

Ref:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7501

//Ekansh
>  					qcom,non-secure-domain;
>  					#address-cells = <1>;
>  					#size-cells = <0>;
> 

Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly

[Ekansh Gupta]

On 17-04-2026 20:45, Ekansh Gupta wrote:
> On 15-04-2026 15:22, Konrad Dybcio wrote:
>> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>>> Downstream [1] this region is marked as shared and reusable so
>>> describe it that way.
>>>
>>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>>
>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>> ---
>>
>> +Ekansh some insight, please?
>>
>> We're giving away that memory via qcom_scm_assign_mem() anyway
>> and I would assume that making it not-"no-map" could introduce issues
>> when the OS tries to access that region
>>
> With the current version and the upcoming planned enhancements, I don't
> see any major benefits of making this as not-"no-map".
> 
> With posted enhancements[1], the plan is to qcom_scm_assign_mem() the
> entire memory-region to lpass VMIDs. and un-assign it only during
> fastrpc_rpmsg_remove(). There have been implementation in downstream
> where this memory is dumped in case of SSR or audio PDR using minidump,
> so marking it `reusable` might make sense there, but that dump logic is
> not added upstream.
> 
> Upon checking the DT, I see a bigger problem here, this memory-region
> looks to me unused, it's not added under fastrpc adsp node(ref. [2]).
> Please correct me if I am wrong about this point.
> 
> [1]
> https://lore.kernel.org/all/20260409062617.1182-1-jianping.li@oss.qualcomm.com/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7500
Just had a new finding on this. There is one more reason why it is not
added as no-map in downstream. This audio PD carve-out region is not
defined for most of the platform's memory-map.

With a change to qcom_scm the memory during boot-up, issue was observed
on RB3Gen2[1], where EFI firmware was loaded in the memory region which
was causing boot-up issues.

So defining it as no-map might not be correct and it might need be
changed for all DT files.

I don't have a history of why it was added as a "no-map" region on
upstream but looks like same has been followed for almost all the
platforms. This needs to be modified based on the memory-maps and the
region needs to allocate memory in a dynamic manner.

[1] https://github.com/qualcomm-linux/kernel/pull/487

//Ekansh
> 
> //Ekansh
>> Konrad
>>
>>
>>>  arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> index 4b47efdb57b2..13094b5e9339 100644
>>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>>>  		};
>>>  
>>>  		adsp_mem: adsp-region@f6000000 {
>>> +			compatible = "shared-dma-pool";
>>>  			reg = <0x0 0xf6000000 0x0 0x800000>;
>>> -			no-map;
>>> +			reusable;
>>>  		};
>>>  
>>>  		qseecom_mem: qseecom-region@f6800000 {
>>>
> 

Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly

[Nickolay Goppen]

21.04.2026 11:29, Ekansh Gupta wrote:
> On 17-04-2026 20:45, Ekansh Gupta wrote:
>> On 15-04-2026 15:22, Konrad Dybcio wrote:
>>> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>>>> Downstream [1] this region is marked as shared and reusable so
>>>> describe it that way.
>>>>
>>>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>>>
>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>> ---
>>> +Ekansh some insight, please?
>>>
>>> We're giving away that memory via qcom_scm_assign_mem() anyway
>>> and I would assume that making it not-"no-map" could introduce issues
>>> when the OS tries to access that region
>>>
>> With the current version and the upcoming planned enhancements, I don't
>> see any major benefits of making this as not-"no-map".
>>
>> With posted enhancements[1], the plan is to qcom_scm_assign_mem() the
>> entire memory-region to lpass VMIDs. and un-assign it only during
>> fastrpc_rpmsg_remove(). There have been implementation in downstream
>> where this memory is dumped in case of SSR or audio PDR using minidump,
>> so marking it `reusable` might make sense there, but that dump logic is
>> not added upstream.
>>
>> Upon checking the DT, I see a bigger problem here, this memory-region
>> looks to me unused, it's not added under fastrpc adsp node(ref. [2]).
>> Please correct me if I am wrong about this point.
>>
>> [1]
>> https://lore.kernel.org/all/20260409062617.1182-1-jianping.li@oss.qualcomm.com/
>> [2]
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7500
> Just had a new finding on this. There is one more reason why it is not
> added as no-map in downstream. This audio PD carve-out region is not
> defined for most of the platform's memory-map.
>
> With a change to qcom_scm the memory during boot-up, issue was observed
> on RB3Gen2[1], where EFI firmware was loaded in the memory region which
> was causing boot-up issues.
>
> So defining it as no-map might not be correct and it might need be
> changed for all DT files.
So It needs to be set as not-"no-map"?
> I don't have a history of why it was added as a "no-map" region on
> upstream but looks like same has been followed for almost all the
> platforms. This needs to be modified based on the memory-maps and the
> region needs to allocate memory in a dynamic manner.
>
> [1] https://github.com/qualcomm-linux/kernel/pull/487
>
> //Ekansh
>> //Ekansh
>>> Konrad
>>>
>>>
>>>>   arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>>> index 4b47efdb57b2..13094b5e9339 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>>>>   		};
>>>>   
>>>>   		adsp_mem: adsp-region@f6000000 {
>>>> +			compatible = "shared-dma-pool";
>>>>   			reg = <0x0 0xf6000000 0x0 0x800000>;
>>>> -			no-map;
>>>> +			reusable;
>>>>   		};
>>>>   
>>>>   		qseecom_mem: qseecom-region@f6800000 {
>>>>
-- 
Best regards,
Nickolay

Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly

[Ekansh Gupta]

On 21-04-2026 14:02, Nickolay Goppen wrote:
> 
> 21.04.2026 11:29, Ekansh Gupta wrote:
>> On 17-04-2026 20:45, Ekansh Gupta wrote:
>>> On 15-04-2026 15:22, Konrad Dybcio wrote:
>>>> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>>>>> Downstream [1] this region is marked as shared and reusable so
>>>>> describe it that way.
>>>>>
>>>>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/
>>>>> blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>>>>
>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>> ---
>>>> +Ekansh some insight, please?
>>>>
>>>> We're giving away that memory via qcom_scm_assign_mem() anyway
>>>> and I would assume that making it not-"no-map" could introduce issues
>>>> when the OS tries to access that region
>>>>
>>> With the current version and the upcoming planned enhancements, I don't
>>> see any major benefits of making this as not-"no-map".
>>>
>>> With posted enhancements[1], the plan is to qcom_scm_assign_mem() the
>>> entire memory-region to lpass VMIDs. and un-assign it only during
>>> fastrpc_rpmsg_remove(). There have been implementation in downstream
>>> where this memory is dumped in case of SSR or audio PDR using minidump,
>>> so marking it `reusable` might make sense there, but that dump logic is
>>> not added upstream.
>>>
>>> Upon checking the DT, I see a bigger problem here, this memory-region
>>> looks to me unused, it's not added under fastrpc adsp node(ref. [2]).
>>> Please correct me if I am wrong about this point.
>>>
>>> [1]
>>> https://lore.kernel.org/all/20260409062617.1182-1-
>>> jianping.li@oss.qualcomm.com/
>>> [2]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/
>>> tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7500
>> Just had a new finding on this. There is one more reason why it is not
>> added as no-map in downstream. This audio PD carve-out region is not
>> defined for most of the platform's memory-map.
>>
>> With a change to qcom_scm the memory during boot-up, issue was observed
>> on RB3Gen2[1], where EFI firmware was loaded in the memory region which
>> was causing boot-up issues.
>>
>> So defining it as no-map might not be correct and it might need be
>> changed for all DT files.
> So It needs to be set as not-"no-map"?
Yes, that's correct, but I think the static address setting should also
be removed. As it is not present in memory-maps, I don't think assigning
some static address would be correct in this case.

Konrad, till now I have checked this for multiple platforms and I see
carveout defined only for lemans, monaco and hamoa. I believe, for other
platforms, we should move to `shared-dma-pool` with `alloc-ranges`.

>> I don't have a history of why it was added as a "no-map" region on
>> upstream but looks like same has been followed for almost all the
>> platforms. This needs to be modified based on the memory-maps and the
>> region needs to allocate memory in a dynamic manner.
>>
>> [1] https://github.com/qualcomm-linux/kernel/pull/487
>>
>> //Ekansh
>>> //Ekansh
>>>> Konrad
>>>>
>>>>
>>>>>   arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>>>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/
>>>>> boot/dts/qcom/sdm630.dtsi
>>>>> index 4b47efdb57b2..13094b5e9339 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>>>>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>>>>>           };
>>>>>             adsp_mem: adsp-region@f6000000 {
>>>>> +            compatible = "shared-dma-pool";
>>>>>               reg = <0x0 0xf6000000 0x0 0x800000>;
>>>>> -            no-map;
>>>>> +            reusable;
>>>>>           };
>>>>>             qseecom_mem: qseecom-region@f6800000 {
>>>>>

Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly

[Konrad Dybcio]

On 4/22/26 11:38 AM, Ekansh Gupta wrote:
> On 21-04-2026 14:02, Nickolay Goppen wrote:
>>
>> 21.04.2026 11:29, Ekansh Gupta wrote:
>>> On 17-04-2026 20:45, Ekansh Gupta wrote:
>>>> On 15-04-2026 15:22, Konrad Dybcio wrote:
>>>>> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>>>>>> Downstream [1] this region is marked as shared and reusable so
>>>>>> describe it that way.
>>>>>>
>>>>>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/
>>>>>> blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>>>>>
>>>>>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>>>>>> ---
>>>>> +Ekansh some insight, please?
>>>>>
>>>>> We're giving away that memory via qcom_scm_assign_mem() anyway
>>>>> and I would assume that making it not-"no-map" could introduce issues
>>>>> when the OS tries to access that region
>>>>>
>>>> With the current version and the upcoming planned enhancements, I don't
>>>> see any major benefits of making this as not-"no-map".
>>>>
>>>> With posted enhancements[1], the plan is to qcom_scm_assign_mem() the
>>>> entire memory-region to lpass VMIDs. and un-assign it only during
>>>> fastrpc_rpmsg_remove(). There have been implementation in downstream
>>>> where this memory is dumped in case of SSR or audio PDR using minidump,
>>>> so marking it `reusable` might make sense there, but that dump logic is
>>>> not added upstream.
>>>>
>>>> Upon checking the DT, I see a bigger problem here, this memory-region
>>>> looks to me unused, it's not added under fastrpc adsp node(ref. [2]).
>>>> Please correct me if I am wrong about this point.
>>>>
>>>> [1]
>>>> https://lore.kernel.org/all/20260409062617.1182-1-
>>>> jianping.li@oss.qualcomm.com/
>>>> [2]
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/
>>>> tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7500
>>> Just had a new finding on this. There is one more reason why it is not
>>> added as no-map in downstream. This audio PD carve-out region is not
>>> defined for most of the platform's memory-map.
>>>
>>> With a change to qcom_scm the memory during boot-up, issue was observed
>>> on RB3Gen2[1], where EFI firmware was loaded in the memory region which
>>> was causing boot-up issues.
>>>
>>> So defining it as no-map might not be correct and it might need be
>>> changed for all DT files.
>> So It needs to be set as not-"no-map"?
> Yes, that's correct, but I think the static address setting should also
> be removed. As it is not present in memory-maps, I don't think assigning
> some static address would be correct in this case.
> 
> Konrad, till now I have checked this for multiple platforms and I see
> carveout defined only for lemans, monaco and hamoa. I believe, for other
> platforms, we should move to `shared-dma-pool` with `alloc-ranges`.

I think so too. The only exception would be if the UEFI had already
allocated a fixed region for that, since the memory could otherwise be
wasted (as it would need(?) to be reserved anyway)

Konrad

Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly

[Dmitry Baryshkov]

On Tue, Apr 21, 2026 at 01:59:23PM +0530, Ekansh Gupta wrote:
> On 17-04-2026 20:45, Ekansh Gupta wrote:
> > On 15-04-2026 15:22, Konrad Dybcio wrote:
> >> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
> >>> Downstream [1] this region is marked as shared and reusable so
> >>> describe it that way.
> >>>
> >>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
> >>>
> >>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
> >>> ---
> >>
> >> +Ekansh some insight, please?
> >>
> >> We're giving away that memory via qcom_scm_assign_mem() anyway
> >> and I would assume that making it not-"no-map" could introduce issues
> >> when the OS tries to access that region
> >>
> > With the current version and the upcoming planned enhancements, I don't
> > see any major benefits of making this as not-"no-map".
> > 
> > With posted enhancements[1], the plan is to qcom_scm_assign_mem() the
> > entire memory-region to lpass VMIDs. and un-assign it only during
> > fastrpc_rpmsg_remove(). There have been implementation in downstream
> > where this memory is dumped in case of SSR or audio PDR using minidump,
> > so marking it `reusable` might make sense there, but that dump logic is
> > not added upstream.
> > 
> > Upon checking the DT, I see a bigger problem here, this memory-region
> > looks to me unused, it's not added under fastrpc adsp node(ref. [2]).
> > Please correct me if I am wrong about this point.
> > 
> > [1]
> > https://lore.kernel.org/all/20260409062617.1182-1-jianping.li@oss.qualcomm.com/
> > [2]
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7500
> Just had a new finding on this. There is one more reason why it is not
> added as no-map in downstream. This audio PD carve-out region is not
> defined for most of the platform's memory-map.
> 
> With a change to qcom_scm the memory during boot-up, issue was observed
> on RB3Gen2[1], where EFI firmware was loaded in the memory region which
> was causing boot-up issues.
> 
> So defining it as no-map might not be correct and it might need be
> changed for all DT files.

Just to point out. By removing the no-map you'd hide the issue instead
of solving it. The region would still be transferred to the ADSP (maybe
piece by piece), possibly causing crashed once bootloaders / EFI tries
to access those regions.

> 
> I don't have a history of why it was added as a "no-map" region on
> upstream but looks like same has been followed for almost all the
> platforms. This needs to be modified based on the memory-maps and the
> region needs to allocate memory in a dynamic manner.
> 
> [1] https://github.com/qualcomm-linux/kernel/pull/487
> 
> //Ekansh
> > 
> > //Ekansh
> >> Konrad
> >>
> >>
> >>>  arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
> >>>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> >>> index 4b47efdb57b2..13094b5e9339 100644
> >>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> >>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
> >>>  		};
> >>>  
> >>>  		adsp_mem: adsp-region@f6000000 {
> >>> +			compatible = "shared-dma-pool";
> >>>  			reg = <0x0 0xf6000000 0x0 0x800000>;
> >>> -			no-map;
> >>> +			reusable;
> >>>  		};
> >>>  
> >>>  		qseecom_mem: qseecom-region@f6800000 {
> >>>
> > 
> 

-- 
With best wishes
Dmitry