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

[Vikash Garodia]

On 6/12/2026 10:56 PM, Jason Gunthorpe wrote:
> On Wed, Jun 10, 2026 at 07:57:50PM +0530, Vishnu Reddy wrote:
>
> >    +--------------------------------------------------+
> >    |                  VPU Hardware                    |
> >    |                                                  |
> >    |  +------------+   SID-0   IOVA: 600MB - 3500MB   |
> >    |  |  Block 0   |                                  |
> >    |  +------------+                                  |
> >    |                                                  |
> >    |  +------------+   SID-1   IOVA: 0MB  - 3500MB    |
> >    |  |  Block 1   |                                  |
> >    |  +------------+                                  |
> >    |                                                  |
> >    |  +------------+   SID-2   IOVA: 16MB - 600MB     |
> >    |  |  Block 2   |                                  |
> >    |  +------------+                                  |
> >    +--------------------------------------------------+
> >
> > Each Stream ID maps to a distinct IOMMU context bank, and each context
> > bank enforces a different IOVA range.
>
> I think Robin is saying you have to describe your HW properly in
> device tree. In Linux a single struct device should not own multiple
> *different* IOMMU contexts.
>
> So your DT should describe all those blocks as unique DT nodes with
> the proper dma ranges and related data so they can do DMA
> correctly. Then the parent device has to assemble itself from that
> collection of struct devices.

For VPUs, these devices(or blocks) shares everything with the parent 
except the IOVA aspects associated with the stream-IDs from these block, 
something like

Iris {
  reg = <>;
  interrupts = <>;

  block1 {
    iommus = <>
    iommu-addresses = <>;
  }

  block2 {
    iommus = <>
    iommu-addresses = <>;
  }
.....
....
  blockN {
    iommus = <>
    iommu-addresses = <>;
  }

}

To handle such case, we create the device dynamically and associated the 
distinct IOVA range to them,via the api introduced in this patch.
This was prototyped in recent SOC here [1]

[1] 
https://lore.kernel.org/linux-media/20260313-kaanapali-iris-v3-1-9c0d1a67af4b@xxxxxxxxxxxxxxxx/

> > These are synthetic child devices created at runtime and do not have their
> > own of_node. Inheriting the parent of_node might not be the correct way.
>
> Why would you create child devices at runtime? Linux doesn't really
> have a good way to create a fully DMA capable struct device at runtime
> without a DT backing description. The fact you immediately hit API
> problems like this is a big clue :)

Other than this API to associate the iova, i think we did not hit any 
other problem so far.

Regards,
Vikash

> Jason