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

[Xilin Wu]

On 7/12/2026 8:14 PM, Dmitry Baryshkov wrote:
> On Mon, Jun 08, 2026 at 12:17:57PM +0800, Xilin Wu wrote:
> > 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.
>
> Hmm. The decoding is working on Lenovo X13s ([1]). It says 6.18, but it
> was the Iris driver patched to support SM8350 / SC8280XP, which I posted
> some time ago. For the reference, the firmware reports the version to
> be: video-firmware.1.1-b158087140355883dc40b004032856a8feb5d565.
>
> [1] https://github.com/lumag/fluster-tests/blob/trunk/iris-sc8280xp.md

Yeah, HFI Gen1 FW should work on SC8280XP. But what I'm using is HFI 
Gen2 FW, it reports: 
video-firmware.2.4.2-39cc47c1d64195c749014787e6ab938cc34a4071


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