Re: [RFC PATCH 07/11] arm64: dts: qcom: hamoa: Move Iris IOMMUs to sub nodes

[Vikash Garodia]

Hi Krzysztof,

On 7/13/2026 11:32 AM, Vikash Garodia wrote:
> On 7/12/2026 5:49 PM, Dmitry Baryshkov wrote:
> > On Fri, Jul 10, 2026 at 11:46:58PM +0100, Bryan O'Donoghue wrote:
> > > On 09/07/2026 13:35, Vikash Garodia wrote:
> > > > The Iris VPU has separate streams with different IOVA constraints. The
> > > > non-pixel stream must be limited to the 0-600 MB IOVA range, while the
> > > > pixel stream can use the full IOVA space.
> > >
> > >
> > > > Using a single set of IOMMU entries for the Iris node does not describe
> > > > these per-stream limits and can allow accesses outside the supported
> > > > range, which may lead to device crashes. One such issue was reported 
> > > > at:
> > > > https://gitlab.freedesktop.org/drm/msm/-/work_items/100
> > > >
> > > > Add non-pixel and pixel child nodes, move each stream ID to its
> > > > corresponding child node, and add a reserved IOVA range for the
> > > > non-pixel stream.
> > > >
> > > > Co-developed-by: Vishnu Reddy <busanna.reddy@xxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Vishnu Reddy <busanna.reddy@xxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Vikash Garodia <vikash.garodia@xxxxxxxxxxxxxxxx>
> > > The thing of it is, this _is_ a bugfix - perhaps its not one that can be
> > > backported, actually scratch that, this isn't possible to land in - 
> > > stable
> > > realistically.
> > >
> > > So what is needed here is a strategy for fixing -stable.
> >
> > I think, we need to start with defining, which platforms are affected.
> > sm8150+? SM8250+? SDM845+? MSM8996+?
>
> All platforms, including venus.
>
> > > That could be apply Daniel's patch and backport it with Fixes: - with
> > > mainline then say applying this change and reverting Daniel's patch
> > >
> > > or
> > >
> > > That could mean some other solution for -stable - up for debate - 
> > > what's not
> > > up for debate is this series needs to _address_ what happens to 
> > > stable for
> > > all of the target platforms - and then transition mainline to the new 
> > > and
> > > shiny way.
> > >
> > > That could mean
> > >
> > > - Applying Daniel's fix with Fixes: and cc-stable
> > > - That patch needs to be extended to _each_ Iris platform containing
> > >    this bug... all of them I think.
> > > - Updating bindings
> > > - Updating DT with new method simultaneously reverting Daniel's fix
>
> Ack. The proposal seems a good way to me addressing stable, i can work 
> towards this.
>
> Will wait for couple of days if there are any alternate suggestion on this.

I would like to seek you suggestion on handling for the -stable branch.
The approach proposed here is;

1. Pick the workaround from Daniel, and mark it as Fixes: and cc-stable. 
I have the series ready to post considering for all _iris_ platforms.

2. Update the bindings with subnode, and at the same time, *reverting* 
Daniel's fix on mainline.

This is due to the fact that #2 might not be easy to apply to all stable 
branches, #1 would serve as workaround to fix the bug in --stable trees.

Please suggest if this is fine with you or any other way you would like 
me to pursue.

Regards,
Vikash

> > > And I do mean doing that in one progressive series - a fixup for 
> > > mainline
> > > alone isn't enough.
>
> Regards,
> Vikash