[PATCH 1/2] dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region

[PATCH 1/2] dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region

[Daniel J Blueman]

In addition to the firmware-loaded codec carveout, some Iris platforms
need to declare an IOMMU IOVA reservation (a reserved-memory node with
iommu-addresses) to keep DMA away from IOVA ranges that earlier
firmware stages have already mapped through the SMMU.

Permit a second memory-region phandle for this purpose, and describe
the meaning of each entry so the ordering is unambiguous.

Signed-off-by: Daniel J Blueman <daniel@quora.org>
---
 Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
index 9c4b760508b5..6359e4953d42 100644
--- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
@@ -80,7 +80,11 @@ properties:
   dma-coherent: true

   memory-region:
-    maxItems: 1
+    minItems: 1
+    maxItems: 2
+    items:
+      - description: Firmware-loaded codec carveout
+      - description: IOMMU IOVA reservation region

   operating-points-v2: true

--
2.53.0

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

[Daniel J Blueman]

On X1-family hamoa platforms, Iris DMA below IOVA 0x25800000 (600MB)
triggers unhandled SMMU page faults that cause spontaneous device
reboots. This is readily reproduced with web pages that drive
multiple concurrent video decode streams, eg ui.com.

Add a reserved-memory IOVA reservation node covering [0, 0x25800000)
and reference it from the Iris node so the IOMMU layer keeps DMA
allocations above that boundary.

This applies to all current hamoa.dtsi consumers (X1E80100/X1P42100/
X1P64100 boards); other Iris-bearing SoCs (sm8550/sm8650/sa8775p/
qcs8300) do not include hamoa.dtsi thus not affected.

Backports also require the preceding binding patch ("dt-bindings:
media: qcom,sm8550-iris: Allow IOVA reservation memory-region");
without it, dtbs_check rejects the second memory-region entry.

Link: https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574
Cc: stable@vger.kernel.org
Signed-off-by: Daniel J Blueman <daniel@quora.org>
---
 arch/arm64/boot/dts/qcom/hamoa.dtsi | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 051dee076416..e2af0bc5e064 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -724,6 +724,15 @@ smem_mem: smem@ffe00000 {
 			hwlocks = <&tcsr_mutex 3>;
 			no-map;
 		};
+
+		/*
+		 * Iris DMA below IOVA 0x25800000 triggers unhandled SMMU
+		 * faults on hamoa platforms; reserve the range so the IOMMU
+		 * layer keeps allocations above this boundary.
+		 */
+		iris_iova: iris-iova {
+			iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+		};
 	};

 	qup_opp_table_100mhz: opp-table-qup100mhz {
@@ -5479,7 +5488,7 @@ &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
 			interconnect-names = "cpu-cfg",
 					     "video-mem";

-			memory-region = <&video_mem>;
+			memory-region = <&video_mem>, <&iris_iova>;

 			resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>;
 			reset-names = "bus";
--
2.53.0

Re: [PATCH 1/2] dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The binding schema fails to enforce the second `memory-region` item (IOVA reservation) for the `qcom,x1e80100-iris` compatible, which strictly requires it to prevent system reboots.
--

commit c0ad29924b6618f643fc065b86b7d5896e42b2ff
Author: Daniel J Blueman <daniel@quora.org>

dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region

In addition to the firmware-loaded codec carveout, some Iris platforms
need to declare an IOMMU IOVA reservation (a reserved-memory node with
iommu-addresses) to keep DMA away from IOVA ranges that earlier
firmware stages have already mapped through the SMMU.

> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index 9c4b760508b50..0d83bb86c6c3f 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -80,7 +80,11 @@ properties:
>    dma-coherent: true
>  
>    memory-region:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 2
> +    items:
> +      - description: Firmware-loaded codec carveout
> +      - description: IOMMU IOVA reservation region

[Severity: Medium]
Should the schema also enforce minItems: 2 for the qcom,x1e80100-iris
compatible in an allOf conditional block?

The commit message for the subsequent patch ("arm64: dts: qcom: hamoa: Reserve
low IOVA range for Iris") explicitly states that on X1-family hamoa platforms
(which use the qcom,x1e80100-iris compatible), missing the IOVA reservation
causes unhandled SMMU page faults and spontaneous device reboots.

Without an allOf constraint enforcing the second memory region item for this
compatible, incomplete device trees missing the mandatory reservation will pass
schema validation but cause runtime failures.

>  
>    operating-points-v2: true
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601041336.9497-1-daniel@quora.org?part=1

Re: [PATCH 1/2] dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region

[Rob Herring (Arm)]

On Mon, 01 Jun 2026 12:13:33 +0800, Daniel J Blueman wrote:
> In addition to the firmware-loaded codec carveout, some Iris platforms
> need to declare an IOMMU IOVA reservation (a reserved-memory node with
> iommu-addresses) to keep DMA away from IOVA ranges that earlier
> firmware stages have already mapped through the SMMU.
> 
> Permit a second memory-region phandle for this purpose, and describe
> the meaning of each entry so the ordering is unambiguous.
> 
> Signed-off-by: Daniel J Blueman <daniel@quora.org>
> ---
>  Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml: properties:memory-region: {'minItems': 1, 'maxItems': 2, 'items': [{'description': 'Firmware-loaded codec carveout'}, {'description': 'IOMMU IOVA reservation region'}]} should not be valid under {'required': ['maxItems']}
	hint: "maxItems" is not needed with an "items" list
	from schema $id: http://devicetree.org/meta-schemas/items.yaml

doc reference errors (make refcheckdocs):

See https://patchwork.kernel.org/project/devicetree/patch/20260601041336.9497-1-daniel@quora.org

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

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

[Bryan O'Donoghue]

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 ?

---
bod

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

[Val Packett]

On 6/2/26 7:26 AM, Bryan O'Donoghue 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 ? 


If you follow the Link:, you can see that it does come from qcom..

https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574

This series is basically a "hotfix" version of a more complicated series:

https://lore.kernel.org/linux-media/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/

that introduced an extra subnode that let the driver only use that 
restricted IOVA range for non-pixel buffers (only those actually need 
the restriction) but that resulted in a very long discussion and was 
kinda shelved because of that.. x_x


~val

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

[Bryan O'Donoghue]

On 02/06/2026 16:03, Val Packett wrote:
> 
> On 6/2/26 7:26 AM, Bryan O'Donoghue 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 ?
> 
> 
> If you follow the Link:, you can see that it does come from qcom..
> 
> https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574

A rhetorical and leading question - the commit log should just explain 
what is going on..

> This series is basically a "hotfix" version of a more complicated series:
> 
> https://lore.kernel.org/linux-media/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/


> that introduced an extra subnode that let the driver only use that
> restricted IOVA range for non-pixel buffers (only those actually need
> the restriction) but that resulted in a very long discussion and was
> kinda shelved because of that.. x_x
This and the subsequent require a Fixes:

I think this change is OK wrt to bindings because we are adding not 
subtracting - but I'd like the commit log to actually explain whats 
happening not give me links to random places.

---
bod

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

[Daniel J Blueman]

On Tue, 2 Jun 2026 at 18:27, Bryan O'Donoghue <bod@kernel.org> 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,
  Dan

[1] https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574

--
Daniel J Blueman

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

[Vikash Garodia]

On 6/2/2026 9:05 PM, Daniel J Blueman wrote:
> On Tue, 2 Jun 2026 at 18:27, Bryan O'Donoghue <bod@kernel.org> 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.

Keeping the region reserved, makes the non-pixel buffer always in the 
non secure range (601-..) and avoids the crash.

Downside of this design - It would eventually reserve 0-600MB un-map 
'able for all buffer types, like pixel as well which do not have any 
such restriction.

Forward looking design - create devices dynamically and set reserve 
regions for those specific device using the api [1], instead of applying 
one reserve for all.

[1] 
https://lore.kernel.org/all/20260119054936.3350128-1-busanna.reddy@oss.qualcomm.com/ 


> Thanks,
>    Dan
> 
> [1] https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574
> 
> --
> Daniel J Blueman

Re: [PATCH 1/2] dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region

[Frank Li]

On Mon, Jun 01, 2026 at 12:13:33PM +0800, Daniel J Blueman wrote:
> In addition to the firmware-loaded codec carveout, some Iris platforms
> need to declare an IOMMU IOVA reservation (a reserved-memory node with
> iommu-addresses) to keep DMA away from IOVA ranges that earlier
> firmware stages have already mapped through the SMMU.
>
> Permit a second memory-region phandle for this purpose, and describe
> the meaning of each entry so the ordering is unambiguous.
>
> Signed-off-by: Daniel J Blueman <daniel@quora.org>
> ---
>  Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index 9c4b760508b5..6359e4953d42 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -80,7 +80,11 @@ properties:
>    dma-coherent: true
>
>    memory-region:
> -    maxItems: 1
> +    minItems: 1
> +    maxItems: 2
> +    items:
> +      - description: Firmware-loaded codec carveout
> +      - description: IOMMU IOVA reservation region

Suppose you want to special iova space. does dma-ranges work for it?

bus {
     dma-ranges = <start size>;
     iris {
	...
     }
}

Frank
>
>    operating-points-v2: true
>
> --
> 2.53.0
>

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

[Val Packett]

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@kernel.org> 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)

> Keeping the region reserved, makes the non-pixel buffer always in the 
> non secure range (601-..) and avoids the crash.
>
> Downside of this design - It would eventually reserve 0-600MB un-map 
> 'able for all buffer types, like pixel as well which do not have any 
> such restriction.
>
> Forward looking design - create devices dynamically and set reserve 
> regions for those specific device using the api [1], instead of 
> applying one reserve for all.
>
> [1] 
> https://lore.kernel.org/all/20260119054936.3350128-1-busanna.reddy@oss.qualcomm.com/ 



~val

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

[Xilin Wu]

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@kernel.org> 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.

-- 
Best regards,
Xilin Wu <sophon@radxa.com>

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

[Bryan O'Donoghue]

On 08/06/2026 04:48, 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@kernel.org> 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?

Yes.

If the firmware has already provisioned SMMU entries for TZ SIDs then we 
would be adding duplicates from Linux, if not then we are claiming TZ 
SIDs which we can't actually access if we use them => those entries 
would need to be given out to a TZ driver/application of some sort which 
we don't have/support now/yet.


> 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)
> 
>> Keeping the region reserved, makes the non-pixel buffer always in the
>> non secure range (601-..) and avoids the crash.
>>
>> Downside of this design - It would eventually reserve 0-600MB un-map
>> 'able for all buffer types, like pixel as well which do not have any
>> such restriction.
>>
>> Forward looking design - create devices dynamically and set reserve
>> regions for those specific device using the api [1], instead of
>> applying one reserve for all.
>>
>> [1]
>> https://lore.kernel.org/all/20260119054936.3350128-1-busanna.reddy@oss.qualcomm.com/
> 
> 
> 
> ~val
> 
> 

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

[Bryan O'Donoghue]

On 04/06/2026 07:38, 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@kernel.org> 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.
> 
> Keeping the region reserved, makes the non-pixel buffer always in the
> non secure range (601-..) and avoids the crash.
> 
> Downside of this design - It would eventually reserve 0-600MB un-map
> 'able for all buffer types, like pixel as well which do not have any
> such restriction.
> 
> Forward looking design - create devices dynamically and set reserve
> regions for those specific device using the api [1], instead of applying
> one reserve for all.
> 
> [1]
> https://lore.kernel.org/all/20260119054936.3350128-1-busanna.reddy@oss.qualcomm.com/
The problem here is in the reponse to the email you linked:

https://lore.kernel.org/all/cfd23f75-8952-4463-abd5-815b995031b0@arm.com/

- Inheriting the parent's properties is wrong
- We should just have a bus

But that leads us to churning DT and we'd have to figure out how/why to 
do it purely for the purpose of differentiating SIDs within Iris. There 
is no separate hardware - its one VPU which needs to figure out its IOVA 
for different SIDs.

Krzysztof would rightly say no - again - to putting collateral into DT 
to differentiate pixel streams based on SID, because that's not a 
hardware property.

- You have pixel and non-pixel SIDs that have to hit Linux
- You have to keep non-pixel allocations >= 600 MB
- You can allow pixel < 600mb =>
   Daniel's patch is too restrictive

But what we can do is add information to the iris platform descriptors 
to enumerate what are the valid IOVA ranges for pixel and non-pixel data 
and then change the allocation code to operate from those platform-code 
described IOVAs.

No new iommu properties, not arguing about plonking SID/pixel-path data 
into DT.

Just teach the driver what the valid ranges are and allocate IOVAs based 
on those ranges.

I think Daniel's patch should be taken as it fixes a real bug for users 
right now but, I equally think its a NAK for any new SoC.

This IOVA allocation needs to be tackled correctly and IMO that needs to 
be and should be done via platform descriptors for valid ranges of IOVA.

No mad stuff about SIDs in DT, no lengthy arguments about adding strange 
iommu properties.

---
bod

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

[Daniel J Blueman]

On Thu, 4 Jun 2026 at 14:39, Vikash Garodia
<vikash.garodia@oss.qualcomm.com> wrote:
> On 6/2/2026 9:05 PM, Daniel J Blueman wrote:
> > On Tue, 2 Jun 2026 at 18:27, Bryan O'Donoghue <bod@kernel.org> 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 ?

With this patch, my Lenovo Slim 7x spontaneously rebooted after
opening 3 tabs of https://ui.com rather than 1 without it. No
crash/reboot is reproducible with the patch I proposed.

> 0-600MB range, VPU hardware would reserve this to generate different
> stream-IDs primarily for internal (non-pixel) buffers.

Thanks for the clearer description; I'll respin my patch with this and
the DT fixes shortly to get the X1 user experience under control until
a real fix.

@all I appreciate the ideas and discussion already ensured!

Dan
-- 
Daniel J Blueman

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

[Bryan O'Donoghue]

On 09/06/2026 14:01, Bryan O'Donoghue wrote:
> On 04/06/2026 07:38, 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@kernel.org> 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.
>>
>> Keeping the region reserved, makes the non-pixel buffer always in the
>> non secure range (601-..) and avoids the crash.
>>
>> Downside of this design - It would eventually reserve 0-600MB un-map
>> 'able for all buffer types, like pixel as well which do not have any
>> such restriction.
>>
>> Forward looking design - create devices dynamically and set reserve
>> regions for those specific device using the api [1], instead of applying
>> one reserve for all.
>>
>> [1]
>> https://lore.kernel.org/all/20260119054936.3350128-1- 
>> busanna.reddy@oss.qualcomm.com/
> The problem here is in the reponse to the email you linked:
> 
> https://lore.kernel.org/all/cfd23f75-8952-4463-abd5-815b995031b0@arm.com/
> 
> - Inheriting the parent's properties is wrong
> - We should just have a bus
> 
> But that leads us to churning DT and we'd have to figure out how/why to 
> do it purely for the purpose of differentiating SIDs within Iris. There 
> is no separate hardware - its one VPU which needs to figure out its IOVA 
> for different SIDs.
> 
> Krzysztof would rightly say no - again - to putting collateral into DT 
> to differentiate pixel streams based on SID, because that's not a 
> hardware property.
> 
> - You have pixel and non-pixel SIDs that have to hit Linux
> - You have to keep non-pixel allocations >= 600 MB
> - You can allow pixel < 600mb =>
>    Daniel's patch is too restrictive
> 
> But what we can do is add information to the iris platform descriptors 
> to enumerate what are the valid IOVA ranges for pixel and non-pixel data 
> and then change the allocation code to operate from those platform-code 
> described IOVAs.
> 
> No new iommu properties, not arguing about plonking SID/pixel-path data 
> into DT.
> 
> Just teach the driver what the valid ranges are and allocate IOVAs based 
> on those ranges.
> 
> I think Daniel's patch should be taken as it fixes a real bug for users 
> right now but, I equally think its a NAK for any new SoC.
> 
> This IOVA allocation needs to be tackled correctly and IMO that needs to 
> be and should be done via platform descriptors for valid ranges of IOVA.
> 
> No mad stuff about SIDs in DT, no lengthy arguments about adding strange 
> iommu properties.
> 
> ---
> bod

Please pause merging this patch until this thread bottoms out

https://lore.kernel.org/all/20260709-vpu_iommu_iova_handling-v1-7-72bb62cb2dfd@oss.qualcomm.com

---
bod