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

[Dmitry Baryshkov]

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

-- 
With best wishes
Dmitry