Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
From: Bryan O'Donoghue
Date: Sat Aug 08 2026 - 05:55:37 EST
On 08/08/2026 05:37, Vishnu Reddy wrote:
I think that is an entirely reasonable reading of the text
On 8/7/2026 9:54 PM, Rob Herring wrote:
On Fri, Aug 07, 2026 at 12:03:50PM +0300, Dmitry Baryshkov wrote:
On Fri, Aug 07, 2026 at 01:54:48PM +0530, Vikash Garodia wrote:I think this is an abuse of /reserved-memory. reserved-memory is
From: Daniel J Blueman <daniel@xxxxxxxxx>I don't like the idea of this series, because it _again_ doesn't tell us
On X1-family hamoa platforms, the Iris VPU reserves IOVA addresses
below 0x25800000 (600MB), primarily for secure non-pixel buffers. DMA
into that range, from any other stream id would triggers unhandled SMMU
page faults that cause spontaneous device reboots. This is readily
reproduced with one or more browser tabs driving multiple concurrent
video decode streams.
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.
Link: https://github.com/qualcomm-linux/kernel-topics/issues/1157#issuecomment-4458933574
Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec")
Cc: stable@xxxxxxxxxxxxxxx
Signed-off-by: Daniel J Blueman <daniel@xxxxxxxxx>
Signed-off-by: Vikash Garodia <vikash.garodia@xxxxxxxxxxxxxxxx>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 8a96ea1bdb9c4c409b2af997680d8c13fed0643e..87f424765d513c97b06303bceb75ca9f176d2ace 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -666,6 +666,17 @@ smem_mem: smem@ffe00000 {
hwlocks = <&tcsr_mutex 3>;
no-map;
};
+
+ /*
+ * The Iris VPU reserves IOVA below 0x25800000 (600MB),
+ * primarily for non-pixel buffers using different Stream IDs.
+ * DMA into that range triggers unhandled SMMU faults and
+ * spontaneous reboots, so reserve it to keep IOMMU
+ * allocations above this boundary.
+ */
+ iris_iova: iris-iova {
+ iommu-addresses = <&iris 0x0 0x0 0x0 0x25800000>;
+ };
};
qup_opp_table_100mhz: opp-table-qup100mhz {
@@ -5439,7 +5450,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>;
the truth about the hardware. This typicall ends up with bigger problems
later on, when it starts to affect other bits and pieces.
I don't want to NAK it, but I'd strongly ask to reconsider it.
reserved *physical* memory. Reserved IOVA is a property on top of that.
I'm surprised this passes validation. If it does, I may go fix that.
As per the reserved-memory.yaml schema document, the iommu-addresses
property for IOVA reservation into /reserved-memory is allowed — it's
documented for IOVA carveout reservations:
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml#L56
Quote:
"If no "reg" property is specified, the "iommu-addresses" property
defines carveout regions in the IOVA space for the given device. This
can be useful if a certain memory region should not be mapped through
the IOMMU."
Which is exactly what this series does. Excludes a specific IOVA range from being allocated for this device.
---
bod