public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
	Nickolay Goppen <setotau@mainlining.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>
Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	~postmarketos/upstreaming@lists.sr.ht
Subject: Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly
Date: Fri, 17 Apr 2026 20:45:45 +0530	[thread overview]
Message-ID: <54b1be0d-1ec3-405c-b1ff-bc759b80e7bc@oss.qualcomm.com> (raw)
In-Reply-To: <70d4dbe7-0e5b-4065-858e-b5a57bbf45e3@oss.qualcomm.com>

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


  parent reply	other threads:[~2026-04-17 15:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-15  9:40 [PATCH 0/4] arm64: dts: qcom: sdm630/660 FastRPC fixes Nickolay Goppen
2026-04-15  9:40 ` [PATCH 1/4] arm64: dts: qcom: sdm660: set cdsp compute-cbs' regs properly Nickolay Goppen
2026-04-15  9:43   ` Konrad Dybcio
2026-04-15  9:40 ` [PATCH 2/4] arm64: dts: qcom: sdm630: set adsp " Nickolay Goppen
2026-04-15  9:50   ` Konrad Dybcio
2026-04-15  9:40 ` [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly Nickolay Goppen
2026-04-15  9:52   ` Konrad Dybcio
2026-04-15 10:03     ` Nickolay Goppen
2026-04-17 15:15     ` Ekansh Gupta [this message]
2026-04-17 17:36       ` Nickolay Goppen
2026-04-15  9:40 ` [PATCH 4/4] arm64: dts: qcom: sdm630: assign adsp_mem region to ADSP FastRPC node Nickolay Goppen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54b1be0d-1ec3-405c-b1ff-bc759b80e7bc@oss.qualcomm.com \
    --to=ekansh.gupta@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=setotau@mainlining.org \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox