Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices

[Konrad Dybcio]

On 6/18/26 5:17 PM, Jason Gunthorpe wrote:
> On Thu, Jun 18, 2026 at 01:57:40PM +0200, Krzysztof Kozlowski wrote:

[...]

> So, if we are going to do a hack in DT to accomodate Linux, I argue to
> choose explicit child devices so VPU does not need to create a special
> bus, call of_dma_configue, or hack in new DMA API things that only it
> will ever use.

Bit late to the party, but I'll chime in with some more "amazing news"..

All of the multimedia HW on QC platforms (camera, display, GPU, video
and their specialized variations) has at least part of the same problems:

* Multiple SID groups that need to be accommodated for different purposes
  (normal vs secure buffers provided by the same device, different
  "logical functions" generally speaking) apply to all of them

* Different IOVA limitations per SID group seems to also concern at
 least the camera uC ("ICP") (but not all of camera hw)

* Remoteprocs (and therefore also the audio stack) expose a number of
  subfunctions, some of which we currently model as subnodes (although
  many arguably only exist as such because someone decided it was
  convenient to express them this way). This, for example led to the
  representation of each SID group associated with the remoteproc
  (fastrpc/"run compute on rproc") as a separate node:

-- qcom/hamoa.dtsi
remoteproc_adsp: remoteproc@6800000 {
	[...]

	// no iommus OR iommus used for another purpose (fw loading)

	fastrpc {
		// no iommus

		compute-cb@3 {
			compatible = "qcom,fastrpc-compute-cb";
			reg = <3>;
			iommus = <&apps_smmu 0x1003 0x80>,
				 <&apps_smmu 0x1063 0x0>;
			dma-coherent;
		};

		compute-cb@4 {
			compatible = "qcom,fastrpc-compute-cb";
			reg = <4>;
			iommus = <&apps_smmu 0x1004 0x80>,
				 <&apps_smmu 0x1064 0x0>;
			dma-coherent;
		};

		[...] (there's a lot of them)
	};
};

There may be more hiding in plain sight, but those are the ones I'm
aware of.


I was kinda hoping there would be more buy-in to follow what PCIe
does, but to my understanding you're opposed to it because "vpu_bus"
is not dynamically discoverable. PCIe generally obviously is, but
we already have prior art regarding hardwired/onboard devices - many
qcom DTs carry per-board iommu-map overrides to please the allocator
with known-in-advance BDF values (because the HW has only so many
SIDs):

-- qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
iommu-map = <0x0 &apps_smmu 0x1c00 0x1>,
            <0x100 &apps_smmu 0x1c01 0x1>,
            <0x208 &apps_smmu 0x1c04 0x1>,
            <0x210 &apps_smmu 0x1c05 0x1>,
            <0x218 &apps_smmu 0x1c06 0x1>,
            <0x300 &apps_smmu 0x1c07 0x1>,
            <0x400 &apps_smmu 0x1c08 0x1>,
            <0x500 &apps_smmu 0x1c09 0x1>,
            <0x501 &apps_smmu 0x1c10 0x1>;

Although it seems to me that it's more of a hack than anything else..


With that in mind, do you still prefer that this is handled through
separate nodes, presumably for all of the aforementioned cases?

Konrad