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@xxxxxxxxxxxxxx>
>>>>>> ---
>>>>> +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@xxxxxxxxxxxxxxxx/
>>>> [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