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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 18/06/2026 17:17, Jason Gunthorpe wrote:
> On Thu, Jun 18, 2026 at 01:57:40PM +0200, Krzysztof Kozlowski wrote:
> 
>> Same with interrupt-map.
> 
>> There are PCIe controller nodes which have interrupt-map and no
>> interrupts property ever uses them.
> 
> PCIe is quite a different situation because we expect Linux to
> dynamically create the child nodes based on PCIe discovery, and the
> various maps are all searched based on the PCI BDF based on HW
> properties of real discovered child devices.
> 
> Here they created "vpu_bus" and create a bunch of devices for some
> reason, but they are all hard coded in the driver. It is not a dynamic
> discovery, and it is not creating "real" child devices.

Yes, true.

> 
>> Because DT person - me - told that creating child device nodes just to
>> configure iommus is abuse of DT. There are no child devices in terms of
>> hardware or firmware. The iommu ranges here are no real hardware.
> 
> That doesn't seem to be what Vishnu is saying. Review the earlier two
> emails explaining what the HW issue is here:
> 
> https://lore.kernel.org/all/bb59f07e-ca7e-f012-6a4b-0a148350b69c@oss.qualcomm.com/
> https://lore.kernel.org/all/cb37e7cc-4fb0-4c24-8f89-f6f9eb08a107@oss.qualcomm.com/
> 
> The VPU HW diagram with different IOVA requirements for different
> stream IDs seems to be an entirely HW based thing: "each context bank
> enforces a different IOVA range"
> 
> The original patches just created a 0 based IOVA space per stream and
> justified that by increasing the IOVA address space (make sense). The
> email above now says some of the streams only function with a limited
> range of IOVA because the HW uses the IOVA itself to select the
> streams (insane!)
> 
> IOW this entire device is completely mis-designed if it is going to
> easially support the Linux DMA API :( That's all HW mess, which is
> motivating hacks to try to make the Linux DMA API do something usable
> by this device.
> 
> Anyhow..
> 
> In Linux if you use DT iommus the SW sets things up so every stream
> shares the same translation. If your driver/device doesn't like that
> there is no SW way to opt out of sharing. I think that is the first
> core issue that VPU was struggling with.
> 
> If you have one "device" then I would argue the DT should describe all
> its streams using iommus in the normal way. The introduction of
> iommu-map for VPU is only being done because that is a convenient hack
> to allow Linux to unbundle the streams. It would be much harder to
> unbunble the streams directly from the DT iommus property, but that
> would probably be the cleanest, software agnostic, DT modeling.
> 
> 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. Then the explicit children can properly describe how
> the HW decodes IOVA into each streams in the DT (which sounds very
> much like a HW property to me) so that Linux produces IOVA that the HW
> mangling properly routes to the expected stream.
> 
> Then the VPU driver just has to assemble itself from many struct
> devices, which I admit is also a troublesome task.
> 
>> However, said all this, since I pushed folks to come with the iommu-map
>> approach, I will revoke my disagreement to child device nodes in DT, if
>> you really believe that is the approach. IOW, I will agree to device
>> nodes in DT representing fake hardware-children, just for the sake of
>> Linux driver model limitations.
> 
> I would wait for Robin, he knows this better, but I belive this was
> broadly his point in the original email..

Thanks Jason for context and detailed arguments. Robin did not chime in
yet, but from what I understood the DT-child-node approach will be the
way we should go here.

I accept above point of view and I am fine with this, thus Vishnu and
Vikash - please go ahead with DT-child-node solution we had some time ago.

Best regards,
Krzysztof