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

On 12/08/2026 17:44, Vikash Garodia wrote:
> 
> On 8/10/2026 7:17 PM, Rob Herring wrote:
>> On Sat, Aug 8, 2026 at 4:55 AM Bryan O'Donoghue <[email protected]> wrote:
>>>
>>> On 08/08/2026 05:37, Vishnu Reddy wrote:
>>>>
>>>> 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:
>>>>>>> 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
>>>>>> 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.
>>>>> I think this is an abuse of /reserved-memory. reserved-memory is
>>>>> 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
>>> I think that is an entirely reasonable reading of the text
>>>
>>> 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.
>>
>> But if "iommu-addresses" is the only property of the reserved memory,
>> why put this property in reserved-memory rather than directly in the
>> device's node? I'm only questioning where is the right place to
>> describe a reserved IOVA.
>>
> 
> a single property node vs multi-property node should not be the reason 
> to decide the place i believe, rather having them all under 
> reserve-memory keeps all reservation at one place instead of scattering 
> it all over.
> 

It is not about the amount of properties, but the intention of
reserved-nodes. Their intention is for reserved memory, which you do not
have here really.

Best regards,
Krzysztof