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

[Dmitry Baryshkov]

On Mon, Aug 10, 2026 at 08:47:45AM -0500, Rob Herring wrote:
> On Sat, Aug 8, 2026 at 4:55 AM Bryan O'Donoghue <bod@xxxxxxxxxx> 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 <daniel@xxxxxxxxx>
> > >>>>
> > >>>> 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>;
> > >>> 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.

Per the reserved-memory.yaml:
   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.

I think this defines exactly this usecase. Would you still prefer if
Vikash moves iommu-addresses to the device node?


-- 
With best wishes
Dmitry