Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
Vikash Garodia <[email protected]>
| Newsgroups | org.kernel.vger.linux-devicetree,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media,org.kernel.vger.stable |
|---|---|
| Message-ID | <[email protected]> |
On 8/7/2026 2:33 PM, Dmitry Baryshkov wrote: > On Fri, Aug 07, 2026 at 01:54:48PM +0530, Vikash Garodia wrote: >> From: Daniel J Blueman <[email protected]> >> >> 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: [email protected] >> Signed-off-by: Daniel J Blueman <[email protected]> >> Signed-off-by: Vikash Garodia <[email protected]> >> --- >> 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>; > > I don't like the idea of this series, because it _again_ doesn't tell us > the truth about the hardware. This typicall ends up with bigger problems honestly...thats all the info i have about the vpu hardware that it restricts non pixel to DMA from the 0-600MB range. The same i have been trying for a year now https://lore.kernel.org/all/[email protected]/ > 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. > >> >> resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>; >> reset-names = "bus"; >> >> -- >> 2.34.1 >> >