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

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