Re: [PATCH] arm64: dts: qcom: x1e: bus is 40-bits (fix 64GB models)

[Jonathan Marek <jonathan@marek.ca>]

On 11/28/25 11:03 AM, Stephan Gerhold wrote:
> On Fri, Nov 28, 2025 at 09:39:52AM -0500, Jonathan Marek wrote:
>> On 11/28/25 5:26 AM, Stephan Gerhold wrote:

...

>>
>> I am using EL2.
>>
>> Without this patch, DMA buffers allocated in the upper 36-bit physical range
>> will try to use bounce buffers. The dma range from the dts is compared
>> against the physical address, not the virtual address.
> 
> I don't think this is the case for the dma-iommu layer. I debugged a
> crash caused by USB in EL1 on a 64 GiB device earlier this year and it
> was happily using buffers above the 36-bit physical range without using
> bounce buffers. There is some code inside dma-iommu for using swiotlb,
> but it's used only for "untrusted" PCI devices and some edge cases with
> unaligned/small buffers.
> 
>>
>> The crash I see is display driver crashes/freezes once a buffer is allocated
>> in the upper 36-bit range and it tries to use bounce buffers. This can
>> happens very quickly under load.
>>
> 
> You could be right about the MSM display driver though, since that
> bypasses dma-iommu and manages the IOMMU itself. I stared at the code a
> bit and I'm not immediately seeing where it would end up calling into
> swiotlb, but it might be hidden somewhere in the endless nesting.
> 

Looks like you are right about this, MSM driver ends up going through 
dma_direct_map_phys(), which decides to use bounce buffers. I didn't try 
to see if other drivers end up using bounce buffers, but it would make 
sense that only MSM driver is affected.

>> The same crash would happen for EL1 as well. I wasn't aware of the EL1
>> broken firmware when I sent this patch, but instead of display freezing I
>> guess the behavior would a hard reset now, which is a bit worse but still
>> unusable unles display/gpu driver is disabled.
>>
>> This patch is correct and should be applied regardless of broken-firmware
>> EL1 cases (where 64GB isn't usable anyway), but I guess the Fixes tag
>> can/should be dropped.
>>
> 
> Please clarify the commit message a bit and mention the two separate use
> cases (EL1 and EL2). I'll leave it up to Bjorn/Konrad to decide whether
> to merge it. At the end you are right and using 64 GiB RAM in EL1 is
> kind of a lost cause anyway.
> 
> Thanks,
> Stephan
>