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

[Xilin Wu]

On 6/8/2026 11:48 AM, Val Packett wrote:
> 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@xxxxxxxxxx> 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)

I'm not sure if we're having the same issue. Without adding that SID on 
sc8280xp (HFI Gen2 FW), it fails to decode anything and crashes 
instantly. From the trustzone log inside the crashdump, I can see that 
the buffer isn't actually in the 0-600MB range.

--
Best regards,
Xilin Wu <sophon@xxxxxxxxx>