Re: [PATCH] arm64: dts: qcom: kodiak: avoid EFI overlap for ADSP remote heap

[Ekansh Gupta]

On 23-04-2026 14:58, Konrad Dybcio wrote:
> On 4/23/26 11:19 AM, Ekansh Gupta wrote:
>> On 23-04-2026 14:20, Konrad Dybcio wrote:
>>> On 4/23/26 8:35 AM, Jianping Li wrote:
>>>> On KODIAK platforms boot can fail when the DT "adsp-rpc-remote-heap"
>>>> reserved-memory region overlaps with firmware allocations (UEFI/EFI
>>>> runtime). The kernel then reports failure to reserve the region and
>>>> subsequent EFI runtime activity may trigger aborts.
>>>>
>>>> The remote heap node was described as a fixed "no-map" region, which
>>>> turns it into a hard carveout. Replace it with a "shared-dma-pool"
>>>> reserved memory region with reusable CMA-backed allocation, specifying
>>>> alignment and size.
>>>>
>>>> This avoids hard carveouts and reduces the chance of conflicting with
>>>> firmware memory maps while keeping an explicit pool for ADSP remote
>>>> heap usage.
>>>>
>>>> Fixes: 90a58ffa9c55 ("arm64: dts: qcom: kodiak: Add memory region for audiopd")
>>>> Cc: stable@xxxxxxxxxx
>>>> Signed-off-by: Jianping Li <jianping.li@xxxxxxxxxxxxxxxx>
>>>> ---
>>>>  arch/arm64/boot/dts/qcom/kodiak.dtsi | 9 ++++++---
>>>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> index 988ca5f7c8a0..420219823496 100644
>>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> @@ -191,9 +191,12 @@ rmtfs_mem: rmtfs@9c900000 {
>>>>  			qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>;
>>>>  		};
>>>>  
>>>> -		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap@9cb80000 {
>>>> -			reg = <0x0 0x9cb80000 0x0 0x800000>;
>>>> -			no-map;
>>>> +		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
>>>> +			compatible = "shared-dma-pool";
>>>> +			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
>>>
>>> Since DRAM starts at 0x8000_0000, is it intended to only allow this
>>> region to be in the lower 2 gigs?
>>>
>>> (it may very well be for some historical reasons)
>> yes, this is intentional. ADSP supports 32-bit address.
> 
> Okay, so I think this should be one of:
> 
> <0x0 0x80000000 0x0 0x80000000>;
SGTM.
> 
> (where we directly specify the DRAM start, which may just be form
> over function)
> 
> or:
> 
> <0x0 0x00000000 0x1 0x00000000>;
> 
> to cover 0x0000_0000 - 0xffff_ffff
> 
> Konrad