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

On 8/7/2026 3:30 PM, Dmitry Baryshkov wrote:
> On Fri, Aug 07, 2026 at 02:56:27PM +0530, Vikash Garodia wrote:
>>
>> 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
> 
> You are not honest here. You also know that there are secure streams,
> which have to use their own IOMMU SIDs. And some of them, as far as I
> remember, also have memory range restrictions.

please read the commit description again, the answer is there.

> 
> So, if we land these patches, how do extend it later to account for all
> of that?
> 

forward looking design would be subnode, which we can land ontop of this 
series.

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