Re: [PATCH 04/22] arm64: dts: qcom: hamoa: Reserve low IOVA range for Iris
Bryan O'Donoghue <[email protected]>
| Newsgroups | org.kernel.vger.stable,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media |
|---|---|
| Message-ID | <[email protected]> |
On 10/08/2026 14:47, Rob Herring wrote: >>> 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. > > Rob Back from the eclipse, sorry for the delayed response. Ah I get you. Yes. I take your point. This is a property of the node itself; the IOVA < 600MB only matters _if_ the venus or iris nodes are enabled - otherwise an IOVA < 600MB is perfectly fine. So it follows its a property specific to this node not specific to the overall system. Yep, I agree - its a device/node property, not a top-level property. --- bod