Re: [PATCH 2/2] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris

[Val Packett <val@packett.cool>]

On 6/4/26 3:38 AM, Vikash Garodia wrote:
>
>
> On 6/2/2026 9:05 PM, Daniel J Blueman wrote:
>> On Tue, 2 Jun 2026 at 18:27, Bryan O'Donoghue <bod@kernel.org> wrote:
>>>
>>> On 01/06/2026 05:13, Daniel J Blueman wrote:
>>>> On X1-family hamoa platforms, Iris DMA below IOVA 0x25800000 (600MB)
>>>> triggers unhandled SMMU page faults
>>>
>>> How do we know that is a correct address - does it come from qcom
>>> documentation or trial and error ?
>>
>> @Vikash, beyond your comment I linked in the patch [1] kindly cite a
>> source for the different stream-ID <600MB behaviour, and share
>> specifics, eg if silicon, firmware, or driver and constraint, defect
>> or otherwise, so I can include a definitive description.
>>
>> Also good to know if my workaround is good for long-term, or on the
>> other hand handling streams <600MB is important/useful.
>>
>
> Thanks Daniel for raising this patch. Did you also try the memory fix 
> i mentioned in the bug [1] discussion ?
>
> Coming to 600MB, this have been the VPU hardware restriction all the 
> while since venus days, and since address could not go deeper all the 
> way lower than 600MB, the issue never popped up earlier.
>
> Consider the memory layout split as below (Iris device range is capped 
> to 0xe0000000)
>
> |-----600MB-----|-----(0xe0000000 - 600MB)-----|----IO reg--|
>
> 0-600MB range, VPU hardware would reserve this to generate different 
> stream-IDs primarily for internal (non-pixel) buffers.
>
> 0-600 --> VPU would generate *secure* stream ID for non-pixel buffers
> 601 - 0xe0000000 --> VPU would generate non-secure stream ID for 
> non-pixel buffers.
>
> When many concurrent sessions were tried, non-pixel buffers were 
> mapped into 0-600MB range, and VPU generated secure ID for those. 
> Since those were not associated with the iommus configured for iris 
> node, it led to USF (un-identified stream fault) and device would crash.

Umm.. is anything *actually* preventing us from adding the "secure" SID 
to the iommu node?

I just saw a patch for sc8280xp that did just add an "extra" SID for iris:

https://github.com/strongtz/linux-radxa-qcom/commit/e92850f792498c3a72d72d667503a29bf6bb0a31

and I'm wondering if that's about the same exact issue.. (Adding sophon@ 
to Cc: here)

> Keeping the region reserved, makes the non-pixel buffer always in the 
> non secure range (601-..) and avoids the crash.
>
> Downside of this design - It would eventually reserve 0-600MB un-map 
> 'able for all buffer types, like pixel as well which do not have any 
> such restriction.
>
> Forward looking design - create devices dynamically and set reserve 
> regions for those specific device using the api [1], instead of 
> applying one reserve for all.
>
> [1] 
> https://lore.kernel.org/all/20260119054936.3350128-1-busanna.reddy@oss.qualcomm.com/ 



~val