Re: [PATCH 1/2] arm64: dts: qcom: agatti: Fix IOMMU DT properties

[Vikash Garodia]

Hi Sumit,

On 1/2/2026 5:22 PM, Sumit Garg wrote:
> On Fri, Jan 02, 2026 at 03:32:57PM +0530, Vikash Garodia wrote:
> > On 12/29/2025 12:50 PM, Sumit Garg wrote:
> > > Hey Everyone,
> > >
> > > On Mon, Dec 29, 2025 at 12:37 PM Sumit Garg <sumit.garg@xxxxxxxxxxxxxxxx> wrote:
> > > > Fix IOMMU DT propeties for GPU, display and video peripherals via
> > > > dropping SMMU stream IDs which relates to secure context bank.
> > > >
> > > > This problem only surfaced when the Gunyah based firmware stack is
> > > > ported on Agatti replacing the legacy QHEE based firmware stack. Assigning
> > > > Linux kernel (HLOS) VMID to secure context bank stream IDs is treated
> > > > as a fault by Gunyah hypervisor which were previously ignored by QHEE
> > > > hypervisor.
> > > >
> > > > The DT changes should be backwards compatible with legacy QHEE based
> > > > firmware stack too.
> > > >
> > > > Suggested-by: Prakash Gupta <guptap@xxxxxxxxxxxxxxxx>
> > > > Signed-off-by: Sumit Garg <sumit.garg@xxxxxxxxxxxxxxxx>
> > > > ---
> > > >    arch/arm64/boot/dts/qcom/agatti.dtsi | 11 +++--------
> > > >    1 file changed, 3 insertions(+), 8 deletions(-)
> > >
> > > Looks like I messed up this patch-set with email delivery leading to
> > > non-delivery. I resent it properly again here [1]. Apologies for the
> > > noise.
> > >
> > > [1] https://lore.kernel.org/lkml/20251229070712.456138-1-sumit.garg@xxxxxxxxxxxxxxxx/
> > >
> > > -Sumit
> > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/agatti.dtsi b/arch/arm64/boot/dts/qcom/agatti.dtsi
> > > > index 8bf5c5583fc2..e705eb24160a 100644
> > > > --- a/arch/arm64/boot/dts/qcom/agatti.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/agatti.dtsi
> > > > @@ -1613,8 +1613,7 @@ gpu: gpu@5900000 {
> > > >                                            &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>;
> > > >                           interconnect-names = "gfx-mem";
> > > >
> > > > -                       iommus = <&adreno_smmu 0 1>,
> > > > -                                <&adreno_smmu 2 0>;
> > > > +                       iommus = <&adreno_smmu 0 1>;
> > > >                           operating-points-v2 = <&gpu_opp_table>;
> > > >                           power-domains = <&rpmpd QCM2290_VDDCX>;
> > > >                           qcom,gmu = <&gmu_wrapper>;
> > > > @@ -1895,8 +1894,7 @@ mdss: display-subsystem@5e00000 {
> > > >
> > > >                           power-domains = <&dispcc MDSS_GDSC>;
> > > >
> > > > -                       iommus = <&apps_smmu 0x420 0x2>,
> > > > -                                <&apps_smmu 0x421 0x0>;
> > > > +                       iommus = <&apps_smmu 0x420 0x2>;
> > > >                           interconnects = <&mmrt_virt MASTER_MDP0 RPM_ALWAYS_TAG
> > > >                                            &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>,
> > > >                                           <&bimc MASTER_APPSS_PROC RPM_ALWAYS_TAG
> > > > @@ -2339,10 +2337,7 @@ venus: video-codec@5a00000 {
> > > >
> > > >                           memory-region = <&pil_video_mem>;
> > > >                           iommus = <&apps_smmu 0x860 0x0>,
> > > > -                                <&apps_smmu 0x880 0x0>,
> > > > -                                <&apps_smmu 0x861 0x04>,
> > > > -                                <&apps_smmu 0x863 0x0>,
> > > > -                                <&apps_smmu 0x804 0xe0>;
> > > > +                                <&apps_smmu 0x880 0x0>;
> >
> > Are you planning to update the binding [1] with this change ?
>
> Yeah I am planning to update bindings as per changes posted here [1].

I tried a similar approach for the very same usecase [1], and what i 
learnt is that we cannot describe a range of iommus given the fact that 
there is no hardware which exist with *min* count of iommus interface. 
It is suppose to be a fixed number of iommus interface, OR i interpreted 
it differently then ?

[1] 
https://lore.kernel.org/all/20251017-knp_video-v2-1-f568ce1a4be3@xxxxxxxxxxxxxxxx/

> > If so, how to
> > handle the case of iommus for gunyah based vs non-gunyah based ?
>
> Currently Agatti doesn't have any support for Linux running in EL2. This
> patch-set is just trying to enable Gunyah based stack.
>
> [1] https://lore.kernel.org/all/aVOFL3jmNrFNiYV0@sumit-xelite/
>
> -Sumit