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

[Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>]

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