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

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

[Sumit Garg]

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@qti.qualcomm.com>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/agatti.dtsi | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

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>;
 
 			interconnects = <&mmnrt_virt MASTER_VIDEO_P0 RPM_ALWAYS_TAG
 					 &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>,
-- 
2.51.0

[PATCH 2/2] arm64: dts: qcom: agatti: Address Gunyah memory alignment needs

[Sumit Garg]

Gunyah hypervisor requires it's memory start address to be 2MB aligned.
So the address map for Agatti is updated to incorporate that requirement.
This should be a backwards compatible DT change which should work with
legacy QHEE based firmware stack too.

Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/agatti.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/agatti.dtsi b/arch/arm64/boot/dts/qcom/agatti.dtsi
index e705eb24160a..153916980ac0 100644
--- a/arch/arm64/boot/dts/qcom/agatti.dtsi
+++ b/arch/arm64/boot/dts/qcom/agatti.dtsi
@@ -298,8 +298,8 @@ reserved_memory: reserved-memory {
 		#size-cells = <2>;
 		ranges;
 
-		hyp_mem: hyp@45700000 {
-			reg = <0x0 0x45700000 0x0 0x600000>;
+		hyp_mem: hyp@45600000 {
+			reg = <0x0 0x45600000 0x0 0x700000>;
 			no-map;
 		};
 
-- 
2.51.0

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

[Sumit Garg]

From: Sumit Garg <sumit.garg@oss.qualcomm.com>

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@qti.qualcomm.com>
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/agatti.dtsi | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

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>;
 
 			interconnects = <&mmnrt_virt MASTER_VIDEO_P0 RPM_ALWAYS_TAG
 					 &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>,
-- 
2.51.0

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

[Sumit Garg]

Hey Everyone,

On Mon, Dec 29, 2025 at 12:37 PM Sumit Garg <sumit.garg@oss.qualcomm.com> 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@qti.qualcomm.com>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
>  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@oss.qualcomm.com/

-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>;
>
>                         interconnects = <&mmnrt_virt MASTER_VIDEO_P0 RPM_ALWAYS_TAG
>                                          &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>,
> --
> 2.51.0
>

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

[Konrad Dybcio]

On 12/29/25 8:12 AM, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> 
> 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@qti.qualcomm.com>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---

This will need to be resolved by something like iommu-map anyway

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad

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

[Dmitry Baryshkov]

On Mon, Dec 29, 2025 at 12:42:57PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> 
> 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.

We are porting the underlaying layer. Can we make it to behave in a way
similar to the _existing_ software? If DT was a part of the firmware, it
would have been fine to perform such updates. But as it is not, we
really should try not to break the interface boundary between firmware
and the kernel.

I'm fine with the change, but I think we should make sure that Gunyah
doesn't break existing device trees.

> 
> The DT changes should be backwards compatible with legacy QHEE based
> firmware stack too.
> 
> Suggested-by: Prakash Gupta <guptap@qti.qualcomm.com>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/agatti.dtsi | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 

-- 
With best wishes
Dmitry

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

[Rob Herring]

On Mon, 29 Dec 2025 12:42:57 +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> 
> 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@qti.qualcomm.com>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/agatti.dtsi | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: attempting to guess base-commit...
 Base: tags/next-20251219 (exact match)
 Base: tags/next-20251219 (use --merge-base to override)

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20251229071258.456254-1-sumit.garg@kernel.org:

arch/arm64/boot/dts/qcom/qrb2210-rb1.dtb: display-subsystem@5e00000 (qcom,qcm2290-mdss): iommus: [[38, 1056, 2]] is too short
	from schema $id: http://devicetree.org/schemas/display/msm/qcom,qcm2290-mdss.yaml
arch/arm64/boot/dts/qcom/qrb2210-rb1.dtb: video-codec@5a00000 (qcom,qcm2290-venus): iommus: [[38, 2144, 0], [38, 2176, 0]] is too short
	from schema $id: http://devicetree.org/schemas/media/qcom,qcm2290-venus.yaml

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

[Akhil P Oommen]

On 12/29/2025 12:42 PM, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> 
> 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@qti.qualcomm.com>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>

Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>

-Akhil

> ---
>  arch/arm64/boot/dts/qcom/agatti.dtsi | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> 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>;
>  
>  			interconnects = <&mmnrt_virt MASTER_VIDEO_P0 RPM_ALWAYS_TAG
>  					 &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>,

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

[Sumit Garg]

On Mon, Dec 29, 2025 at 10:00:02PM +0200, Dmitry Baryshkov wrote:
> On Mon, Dec 29, 2025 at 12:42:57PM +0530, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > 
> > 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.
> 
> We are porting the underlaying layer. Can we make it to behave in a way
> similar to the _existing_ software? If DT was a part of the firmware, it
> would have been fine to perform such updates. But as it is not, we
> really should try not to break the interface boundary between firmware
> and the kernel.

I support your viewpoint. But in this current case Linux kernel VMID mapping
for secure context bank stream IDs is incorrect. As Konrad mentioned in the
other thread that for secure media streaming use-cases, it rather requires
proper representation via iommu-map such that appropriate VMID can be mapped.

> 
> I'm fine with the change, but I think we should make sure that Gunyah
> doesn't break existing device trees.

Sure, this change isn't breaking any DT ABI but brings compliance to
usage of stream IDs.

-Sumit

> 
> > 
> > The DT changes should be backwards compatible with legacy QHEE based
> > firmware stack too.
> > 
> > Suggested-by: Prakash Gupta <guptap@qti.qualcomm.com>
> > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > ---
> >  arch/arm64/boot/dts/qcom/agatti.dtsi | 11 +++--------
> >  1 file changed, 3 insertions(+), 8 deletions(-)
> > 
> 
> -- 
> With best wishes
> Dmitry
> 

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

[Dmitry Baryshkov]

On Tue, Dec 30, 2025 at 10:45:38AM +0530, Sumit Garg wrote:
> On Mon, Dec 29, 2025 at 10:00:02PM +0200, Dmitry Baryshkov wrote:
> > On Mon, Dec 29, 2025 at 12:42:57PM +0530, Sumit Garg wrote:
> > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > 
> > > 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.
> > 
> > We are porting the underlaying layer. Can we make it to behave in a way
> > similar to the _existing_ software? If DT was a part of the firmware, it
> > would have been fine to perform such updates. But as it is not, we
> > really should try not to break the interface boundary between firmware
> > and the kernel.
> 
> I support your viewpoint. But in this current case Linux kernel VMID mapping
> for secure context bank stream IDs is incorrect. As Konrad mentioned in the
> other thread that for secure media streaming use-cases, it rather requires
> proper representation via iommu-map such that appropriate VMID can be mapped.

Yes, I understand this part. I'm basically suggesting that Gunyah should
ignore this SID when programming the actual SMMU (probably like QHEE
did).

> 
> > 
> > I'm fine with the change, but I think we should make sure that Gunyah
> > doesn't break existing device trees.
> 
> Sure, this change isn't breaking any DT ABI but brings compliance to
> usage of stream IDs.

Actually, it does, as you can see from Rob's email. You didn't perform
make dtbs_check while submitting this patch.

-- 
With best wishes
Dmitry

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

[Sumit Garg]

On Tue, Dec 30, 2025 at 09:05:28AM +0200, Dmitry Baryshkov wrote:
> On Tue, Dec 30, 2025 at 10:45:38AM +0530, Sumit Garg wrote:
> > On Mon, Dec 29, 2025 at 10:00:02PM +0200, Dmitry Baryshkov wrote:
> > > On Mon, Dec 29, 2025 at 12:42:57PM +0530, Sumit Garg wrote:
> > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > 
> > > > 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.
> > > 
> > > We are porting the underlaying layer. Can we make it to behave in a way
> > > similar to the _existing_ software? If DT was a part of the firmware, it
> > > would have been fine to perform such updates. But as it is not, we
> > > really should try not to break the interface boundary between firmware
> > > and the kernel.
> > 
> > I support your viewpoint. But in this current case Linux kernel VMID mapping
> > for secure context bank stream IDs is incorrect. As Konrad mentioned in the
> > other thread that for secure media streaming use-cases, it rather requires
> > proper representation via iommu-map such that appropriate VMID can be mapped.
> 
> Yes, I understand this part. I'm basically suggesting that Gunyah should
> ignore this SID when programming the actual SMMU (probably like QHEE
> did).

TBH, I generally dislike as to why the firmware based hypervisor
behaviour should be encoded in the DT. One can always argue that Gunyah
is doing the right thing given the purpose of SMMU stream IDs. And if
Gunyah has to change that behaviour since Agatti DT was based on QHEE
behaviour then the same behaviour will get replicated on all other Qcom
SoCs.

So, I would suggest that kernel should follow the expected behaviour
which is to not program HLOS VMID for stream IDs dedicated for secure
context bank.

> 
> > 
> > > 
> > > I'm fine with the change, but I think we should make sure that Gunyah
> > > doesn't break existing device trees.
> > 
> > Sure, this change isn't breaking any DT ABI but brings compliance to
> > usage of stream IDs.
> 
> Actually, it does, as you can see from Rob's email. You didn't perform
> make dtbs_check while submitting this patch.

Okay, I missed that. Looks like the GPU DT node already defined minItems
for the iommus property but the others didn't. I will add following
change in the next version to fix the warnings.

Irrespective on that, the DT forwards and backwards ABI compatibility is
being maintained with the changes being proposed in this patch-set.

diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
index f0cdb5422688..e5e62c5bab42 100644
--- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
+++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
@@ -33,6 +33,7 @@ properties:
       - const: core

   iommus:
+    minItems: 1
     maxItems: 2

   interconnects:
diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
index 3f3ee82fc878..8d4371697867 100644
--- a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
@@ -42,6 +42,7 @@ properties:
       - const: vcodec0_bus

   iommus:
+    minItems: 2
     maxItems: 5

   interconnects:

-Sumit

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

[Akhil P Oommen]

On 12/30/2025 12:35 PM, Dmitry Baryshkov wrote:
> On Tue, Dec 30, 2025 at 10:45:38AM +0530, Sumit Garg wrote:
>> On Mon, Dec 29, 2025 at 10:00:02PM +0200, Dmitry Baryshkov wrote:
>>> On Mon, Dec 29, 2025 at 12:42:57PM +0530, Sumit Garg wrote:
>>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>>
>>>> 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.
>>>
>>> We are porting the underlaying layer. Can we make it to behave in a way
>>> similar to the _existing_ software? If DT was a part of the firmware, it
>>> would have been fine to perform such updates. But as it is not, we
>>> really should try not to break the interface boundary between firmware
>>> and the kernel.
>>
>> I support your viewpoint. But in this current case Linux kernel VMID mapping
>> for secure context bank stream IDs is incorrect. As Konrad mentioned in the
>> other thread that for secure media streaming use-cases, it rather requires
>> proper representation via iommu-map such that appropriate VMID can be mapped.
> 
> Yes, I understand this part. I'm basically suggesting that Gunyah should
> ignore this SID when programming the actual SMMU (probably like QHEE
> did).

But the existing DT description for Agatti GPU is buggy. SID 2 is for
secure access from GPU and it should not be mixed with non-secure
access. We haven't hit any issue so far because the KMD doesn't have
support for secure usecase yet.

At least for the GPU property, I feel that the right thing to do is to
correct the buggy description.

-Akhil

> 
>>
>>>
>>> I'm fine with the change, but I think we should make sure that Gunyah
>>> doesn't break existing device trees.
>>
>> Sure, this change isn't breaking any DT ABI but brings compliance to
>> usage of stream IDs.
> 
> Actually, it does, as you can see from Rob's email. You didn't perform
> make dtbs_check while submitting this patch.
> 

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

[Dmitry Baryshkov]

On Tue, Dec 30, 2025 at 06:16:05PM +0530, Akhil P Oommen wrote:
> On 12/30/2025 12:35 PM, Dmitry Baryshkov wrote:
> > On Tue, Dec 30, 2025 at 10:45:38AM +0530, Sumit Garg wrote:
> >> On Mon, Dec 29, 2025 at 10:00:02PM +0200, Dmitry Baryshkov wrote:
> >>> On Mon, Dec 29, 2025 at 12:42:57PM +0530, Sumit Garg wrote:
> >>>> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >>>>
> >>>> 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.
> >>>
> >>> We are porting the underlaying layer. Can we make it to behave in a way
> >>> similar to the _existing_ software? If DT was a part of the firmware, it
> >>> would have been fine to perform such updates. But as it is not, we
> >>> really should try not to break the interface boundary between firmware
> >>> and the kernel.
> >>
> >> I support your viewpoint. But in this current case Linux kernel VMID mapping
> >> for secure context bank stream IDs is incorrect. As Konrad mentioned in the
> >> other thread that for secure media streaming use-cases, it rather requires
> >> proper representation via iommu-map such that appropriate VMID can be mapped.
> > 
> > Yes, I understand this part. I'm basically suggesting that Gunyah should
> > ignore this SID when programming the actual SMMU (probably like QHEE
> > did).
> 
> But the existing DT description for Agatti GPU is buggy. SID 2 is for
> secure access from GPU and it should not be mixed with non-secure
> access. We haven't hit any issue so far because the KMD doesn't have
> support for secure usecase yet.
> 
> At least for the GPU property, I feel that the right thing to do is to
> correct the buggy description.

I do not doubt the change, we should not be mapping secure SIDs. However
I very much dislike the fact that changing the bootloader makes us
perform this change.

> 
> -Akhil
> 
> > 
> >>
> >>>
> >>> I'm fine with the change, but I think we should make sure that Gunyah
> >>> doesn't break existing device trees.
> >>
> >> Sure, this change isn't breaking any DT ABI but brings compliance to
> >> usage of stream IDs.
> > 
> > Actually, it does, as you can see from Rob's email. You didn't perform
> > make dtbs_check while submitting this patch.
> > 
> 

-- 
With best wishes
Dmitry

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

[Vikash Garodia]

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@oss.qualcomm.com> 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@qti.qualcomm.com>
>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>> ---
>>   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@oss.qualcomm.com/
> 
> -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 ? If so, how 
to handle the case of iommus for gunyah based vs non-gunyah based ?

[1] 
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/media/qcom%2Cqcm2290-venus.yaml#L45

Regards,
Vikash
>>
>>                          interconnects = <&mmnrt_virt MASTER_VIDEO_P0 RPM_ALWAYS_TAG
>>                                           &bimc SLAVE_EBI1 RPM_ALWAYS_TAG>,
>> --
>> 2.51.0
>>

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

[Sumit Garg]

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@oss.qualcomm.com> 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@qti.qualcomm.com>
> > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > ---
> > >   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@oss.qualcomm.com/
> > 
> > -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].

> 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

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

[Bjorn Andersson]

On Tue, Dec 30, 2025 at 01:24:23PM +0530, Sumit Garg wrote:
> On Tue, Dec 30, 2025 at 09:05:28AM +0200, Dmitry Baryshkov wrote:
> > On Tue, Dec 30, 2025 at 10:45:38AM +0530, Sumit Garg wrote:
> > > On Mon, Dec 29, 2025 at 10:00:02PM +0200, Dmitry Baryshkov wrote:
> > > > On Mon, Dec 29, 2025 at 12:42:57PM +0530, Sumit Garg wrote:
> > > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > 
> > > > > 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.
> > > > 
> > > > We are porting the underlaying layer. Can we make it to behave in a way
> > > > similar to the _existing_ software? If DT was a part of the firmware, it
> > > > would have been fine to perform such updates. But as it is not, we
> > > > really should try not to break the interface boundary between firmware
> > > > and the kernel.
> > > 
> > > I support your viewpoint. But in this current case Linux kernel VMID mapping
> > > for secure context bank stream IDs is incorrect. As Konrad mentioned in the
> > > other thread that for secure media streaming use-cases, it rather requires
> > > proper representation via iommu-map such that appropriate VMID can be mapped.
> > 
> > Yes, I understand this part. I'm basically suggesting that Gunyah should
> > ignore this SID when programming the actual SMMU (probably like QHEE
> > did).
> 
> TBH, I generally dislike as to why the firmware based hypervisor
> behaviour should be encoded in the DT.

The DeviceTree describes the world to the operating system. If there is
a hypervisor (or secure world, or other configuration) that is affecting
the (hardware or firmware) interfaces that needs to either be
discoverable at runtime, or represented in the description of those
interfaces.

> One can always argue that Gunyah
> is doing the right thing given the purpose of SMMU stream IDs. And if
> Gunyah has to change that behaviour since Agatti DT was based on QHEE
> behaviour then the same behaviour will get replicated on all other Qcom
> SoCs.
> 

Yes, you can see that mess in sdm845, sc7180, sc7280, and the various
*-el2.dtso; all cases where we need to describe the variations of the
hardware and firmware interfaces presented to the operating system.

> So, I would suggest that kernel should follow the expected behaviour
> which is to not program HLOS VMID for stream IDs dedicated for secure
> context bank.
> 

I agree. As discussed elsewhere, we might still need to manage the
secure context banks in some cases, but that needs special handling
anyways.

Moreover, it's two context banks (unsecure and secure), but the current
description defines a single context bank capturing both the unsecure
and secure streams.

Regards,
Bjorn

> > 
> > > 
> > > > 
> > > > I'm fine with the change, but I think we should make sure that Gunyah
> > > > doesn't break existing device trees.
> > > 
> > > Sure, this change isn't breaking any DT ABI but brings compliance to
> > > usage of stream IDs.
> > 
> > Actually, it does, as you can see from Rob's email. You didn't perform
> > make dtbs_check while submitting this patch.
> 
> Okay, I missed that. Looks like the GPU DT node already defined minItems
> for the iommus property but the others didn't. I will add following
> change in the next version to fix the warnings.
> 
> Irrespective on that, the DT forwards and backwards ABI compatibility is
> being maintained with the changes being proposed in this patch-set.
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
> index f0cdb5422688..e5e62c5bab42 100644
> --- a/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcm2290-mdss.yaml
> @@ -33,6 +33,7 @@ properties:
>        - const: core
> 
>    iommus:
> +    minItems: 1
>      maxItems: 2
> 
>    interconnects:
> diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> index 3f3ee82fc878..8d4371697867 100644
> --- a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
> @@ -42,6 +42,7 @@ properties:
>        - const: vcodec0_bus
> 
>    iommus:
> +    minItems: 2
>      maxItems: 5
> 
>    interconnects:
> 
> -Sumit

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

[Sumit Garg]

On Sat, Jan 03, 2026 at 09:43:57AM -0600, Bjorn Andersson wrote:
> On Tue, Dec 30, 2025 at 01:24:23PM +0530, Sumit Garg wrote:
> > On Tue, Dec 30, 2025 at 09:05:28AM +0200, Dmitry Baryshkov wrote:
> > > On Tue, Dec 30, 2025 at 10:45:38AM +0530, Sumit Garg wrote:
> > > > On Mon, Dec 29, 2025 at 10:00:02PM +0200, Dmitry Baryshkov wrote:
> > > > > On Mon, Dec 29, 2025 at 12:42:57PM +0530, Sumit Garg wrote:
> > > > > > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > 
> > > > > > 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.
> > > > > 
> > > > > We are porting the underlaying layer. Can we make it to behave in a way
> > > > > similar to the _existing_ software? If DT was a part of the firmware, it
> > > > > would have been fine to perform such updates. But as it is not, we
> > > > > really should try not to break the interface boundary between firmware
> > > > > and the kernel.
> > > > 
> > > > I support your viewpoint. But in this current case Linux kernel VMID mapping
> > > > for secure context bank stream IDs is incorrect. As Konrad mentioned in the
> > > > other thread that for secure media streaming use-cases, it rather requires
> > > > proper representation via iommu-map such that appropriate VMID can be mapped.
> > > 
> > > Yes, I understand this part. I'm basically suggesting that Gunyah should
> > > ignore this SID when programming the actual SMMU (probably like QHEE
> > > did).
> > 
> > TBH, I generally dislike as to why the firmware based hypervisor
> > behaviour should be encoded in the DT.
> 
> The DeviceTree describes the world to the operating system. If there is
> a hypervisor (or secure world, or other configuration) that is affecting
> the (hardware or firmware) interfaces that needs to either be
> discoverable at runtime, or represented in the description of those
> interfaces.

I would always favour discoverable firmware interfaces like EFI or
TEE/TZ based interfaces rather than encoding such information in the DT.

> 
> > One can always argue that Gunyah
> > is doing the right thing given the purpose of SMMU stream IDs. And if
> > Gunyah has to change that behaviour since Agatti DT was based on QHEE
> > behaviour then the same behaviour will get replicated on all other Qcom
> > SoCs.
> > 
> 
> Yes, you can see that mess in sdm845, sc7180, sc7280, and the various
> *-el2.dtso; all cases where we need to describe the variations of the
> hardware and firmware interfaces presented to the operating system.

AFAIU, the major problem here is that the DT for Qcom platforms is a subset
of the hardware information for the OS to initially only run at non-secure
EL1. Then came in requirment that we need to run Linux at EL2 for which
the information wasn't there in DT leading to this *-el2.dtso mess.

I would rather like to see the DT descibing the overall hardware
applicable to the apps processor rather than a subset such that the TZ,
Hypervisor and the kernel can consume the same DT based on ownership
hints.

I suppose the Qcom IOMMU driver can be the first one to consume such DT
information based on the hints. However, this is something which is out
of scope for this patch-set which tries to fix DT as per existing
expectations.

> 
> > So, I would suggest that kernel should follow the expected behaviour
> > which is to not program HLOS VMID for stream IDs dedicated for secure
> > context bank.
> > 
> 
> I agree. As discussed elsewhere, we might still need to manage the
> secure context banks in some cases, but that needs special handling
> anyways.
> 
> Moreover, it's two context banks (unsecure and secure), but the current
> description defines a single context bank capturing both the unsecure
> and secure streams.

Agree, I will spin up a v2 with DT bindings changes.

-Sumit

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@oss.qualcomm.com> 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@qti.qualcomm.com>
>>>> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
>>>> ---
>>>>    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@oss.qualcomm.com/
>>>
>>> -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@oss.qualcomm.com/

> 
>> 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

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

[Dmitry Baryshkov]

On Mon, Jan 05, 2026 at 12:51:09PM +0530, Vikash Garodia wrote:
> 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@oss.qualcomm.com> 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@qti.qualcomm.com>
> > > > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > ---
> > > > >    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@oss.qualcomm.com/
> > > > 
> > > > -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
> ?

You've interpreted it correctly. Sumit will need to drop the extra items
from the corresponding iommus property definition.

> 
> [1] https://lore.kernel.org/all/20251017-knp_video-v2-1-f568ce1a4be3@oss.qualcomm.com/
> 
> > 
> > > 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
> 

-- 
With best wishes
Dmitry

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

[Sumit Garg]

On Tue, Jan 06, 2026 at 04:38:43AM +0200, Dmitry Baryshkov wrote:
> On Mon, Jan 05, 2026 at 12:51:09PM +0530, Vikash Garodia wrote:
> > 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@oss.qualcomm.com> 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@qti.qualcomm.com>
> > > > > > Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> > > > > > ---
> > > > > >    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@oss.qualcomm.com/
> > > > > 
> > > > > -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
> > ?
> 
> You've interpreted it correctly. Sumit will need to drop the extra items
> from the corresponding iommus property definition.

Thanks for the heads up. I will follow this advice instead.

-Sumit