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

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

[Vishnu Reddy]

Drivers can create child devices dynamically. These child devices often
inherit parent device tree node, including its reserved iommu-address
ranges. While device tree can declare the multiple iommu-address ranges,
they still apply uniformly to any child inheriting the parent OF node.

This creates a limitation when child requires a different iommu-address
range than its parent, as device tree cannot express the reservation per
child.

Example layout and use case:
----------------------------
A multimedia subsystem with multiple child devices and distinct ranges:

    +-----------------------------------------------------------+
    | Device A reserved region (256 MB)                         |
    | 0x00000000 - 0x10000000                                   |
    +-----------------------------------------------------------+
    | Device B reserved region (512 MB)                         |
    | 0x00000000 - 0x20000000                                   |
    +-----------------------------------------------------------+
    | Device C reserved region (600 MB)                         |
    | 0x00000000 - 0x25800000                                   |
    +-----------------------------------------------------------+
    | Other reserved regions                                    |
    +-----------------------------------------------------------+

If we add Device C's reserved range (0x0 to 0x025800000) into iommu
address range into device tree and assign that OF node to Device B
and C, it wastes memory:
- Device A wastes ~344 MB
- Device B wastes ~88 MB

To avoid this, drivers can use the introduced API to set their device
specific IOVA region at runtime, ensuring the DMA mapping without
unnecessary address space reservation.

Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20251220023555.3017456-1-busanna.reddy@oss.qualcomm.com/
---
 drivers/iommu/dma-iommu.c   | 44 +++++++++++++++++++++++++++++++++++++
 include/linux/dma-mapping.h |  7 ++++++
 2 files changed, 51 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index aeaf8fad985c3..baee119e1c277 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1743,6 +1743,50 @@ size_t iommu_dma_max_mapping_size(struct device *dev)
 	return SIZE_MAX;
 }
 
+/**
+ * dma_iova_set_resv_region - Set a reserved region in the IOVA space
+ * @dev: Device to set the reserved region for
+ * @start: Start of the reserved region
+ * @length: Length of the reserved region
+ *
+ * This function enables drivers to set device specific reservations at
+ * runtime, which is particularly useful for dynamically created child
+ * devices that requires distinct IOVA ranges than parent.
+ *
+ * Returns:
+ *  0        - Success
+ *  -ENODEV  - No valid IOMMU DMA domain for the device
+ *  -EINVAL  - Invalid domain or cookie type for this operation
+ *  -ENOMEM  - Failed to reserve the requested range
+ */
+int dma_iova_set_resv_region(struct device *dev, unsigned long start,
+			     unsigned long length)
+{
+	struct iommu_dma_cookie *cookie;
+	struct iommu_domain *domain;
+	struct iova_domain *iovad;
+	unsigned long lo, hi;
+
+	domain = iommu_get_dma_domain(dev);
+	if (!domain || domain->type != IOMMU_DOMAIN_DMA)
+		return -ENODEV;
+
+	cookie = domain->iova_cookie;
+	if (!cookie || domain->cookie_type != IOMMU_COOKIE_DMA_IOVA)
+		return -EINVAL;
+
+	iovad = &cookie->iovad;
+
+	lo = iova_pfn(iovad, start);
+	hi = iova_pfn(iovad, start + length - 1);
+
+	if (!reserve_iova(iovad, lo, hi))
+		return -ENOMEM;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(dma_iova_set_resv_region);
+
 /**
  * dma_iova_try_alloc - Try to allocate an IOVA space
  * @dev: Device to allocate the IOVA space for
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 29973baa05816..75b65160a37f3 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -347,6 +347,8 @@ static inline bool dma_use_iova(struct dma_iova_state *state)
 	return state->__size != 0;
 }
 
+int dma_iova_set_resv_region(struct device *dev, unsigned long start,
+			     unsigned long length);
 bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state,
 		phys_addr_t phys, size_t size);
 void dma_iova_free(struct device *dev, struct dma_iova_state *state);
@@ -366,6 +368,11 @@ static inline bool dma_use_iova(struct dma_iova_state *state)
 {
 	return false;
 }
+static inline int dma_iova_set_resv_region(struct device *dev, unsigned long start,
+					   unsigned long length)
+{
+	return -ENODEV;
+}
 static inline bool dma_iova_try_alloc(struct device *dev,
 		struct dma_iova_state *state, phys_addr_t phys, size_t size)
 {
-- 
2.34.1

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

[Christoph Hellwig]

This still seems to lack an actual user.

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

[Robin Murphy]

On 19/01/2026 5:49 am, Vishnu Reddy wrote:
> Drivers can create child devices dynamically. These child devices often
> inherit parent device tree node, including its reserved iommu-address
> ranges.

Which frankly sounds entirely wrong. If there are distinct devices with 
distinct hardware properties, then they should be properly described as 
such, and handled by a proper bus driver. And if different devices have 
different DMA restrictions, that should be described by "dma-ranges", 
not by abusing reserved regions.

Thanks,
Robin.

> While device tree can declare the multiple iommu-address ranges,
> they still apply uniformly to any child inheriting the parent OF node.
> 
> This creates a limitation when child requires a different iommu-address
> range than its parent, as device tree cannot express the reservation per
> child.
> 
> Example layout and use case:
> ----------------------------
> A multimedia subsystem with multiple child devices and distinct ranges:
> 
>      +-----------------------------------------------------------+
>      | Device A reserved region (256 MB)                         |
>      | 0x00000000 - 0x10000000                                   |
>      +-----------------------------------------------------------+
>      | Device B reserved region (512 MB)                         |
>      | 0x00000000 - 0x20000000                                   |
>      +-----------------------------------------------------------+
>      | Device C reserved region (600 MB)                         |
>      | 0x00000000 - 0x25800000                                   |
>      +-----------------------------------------------------------+
>      | Other reserved regions                                    |
>      +-----------------------------------------------------------+
> 
> If we add Device C's reserved range (0x0 to 0x025800000) into iommu
> address range into device tree and assign that OF node to Device B
> and C, it wastes memory:
> - Device A wastes ~344 MB
> - Device B wastes ~88 MB
> 
> To avoid this, drivers can use the introduced API to set their device
> specific IOVA region at runtime, ensuring the DMA mapping without
> unnecessary address space reservation.
> 
> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
> Link: https://lore.kernel.org/all/20251220023555.3017456-1-busanna.reddy@oss.qualcomm.com/
> ---
>   drivers/iommu/dma-iommu.c   | 44 +++++++++++++++++++++++++++++++++++++
>   include/linux/dma-mapping.h |  7 ++++++
>   2 files changed, 51 insertions(+)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index aeaf8fad985c3..baee119e1c277 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -1743,6 +1743,50 @@ size_t iommu_dma_max_mapping_size(struct device *dev)
>   	return SIZE_MAX;
>   }
>   
> +/**
> + * dma_iova_set_resv_region - Set a reserved region in the IOVA space
> + * @dev: Device to set the reserved region for
> + * @start: Start of the reserved region
> + * @length: Length of the reserved region
> + *
> + * This function enables drivers to set device specific reservations at
> + * runtime, which is particularly useful for dynamically created child
> + * devices that requires distinct IOVA ranges than parent.
> + *
> + * Returns:
> + *  0        - Success
> + *  -ENODEV  - No valid IOMMU DMA domain for the device
> + *  -EINVAL  - Invalid domain or cookie type for this operation
> + *  -ENOMEM  - Failed to reserve the requested range
> + */
> +int dma_iova_set_resv_region(struct device *dev, unsigned long start,
> +			     unsigned long length)
> +{
> +	struct iommu_dma_cookie *cookie;
> +	struct iommu_domain *domain;
> +	struct iova_domain *iovad;
> +	unsigned long lo, hi;
> +
> +	domain = iommu_get_dma_domain(dev);
> +	if (!domain || domain->type != IOMMU_DOMAIN_DMA)
> +		return -ENODEV;
> +
> +	cookie = domain->iova_cookie;
> +	if (!cookie || domain->cookie_type != IOMMU_COOKIE_DMA_IOVA)
> +		return -EINVAL;
> +
> +	iovad = &cookie->iovad;
> +
> +	lo = iova_pfn(iovad, start);
> +	hi = iova_pfn(iovad, start + length - 1);
> +
> +	if (!reserve_iova(iovad, lo, hi))
> +		return -ENOMEM;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(dma_iova_set_resv_region);
> +
>   /**
>    * dma_iova_try_alloc - Try to allocate an IOVA space
>    * @dev: Device to allocate the IOVA space for
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 29973baa05816..75b65160a37f3 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -347,6 +347,8 @@ static inline bool dma_use_iova(struct dma_iova_state *state)
>   	return state->__size != 0;
>   }
>   
> +int dma_iova_set_resv_region(struct device *dev, unsigned long start,
> +			     unsigned long length);
>   bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state,
>   		phys_addr_t phys, size_t size);
>   void dma_iova_free(struct device *dev, struct dma_iova_state *state);
> @@ -366,6 +368,11 @@ static inline bool dma_use_iova(struct dma_iova_state *state)
>   {
>   	return false;
>   }
> +static inline int dma_iova_set_resv_region(struct device *dev, unsigned long start,
> +					   unsigned long length)
> +{
> +	return -ENODEV;
> +}
>   static inline bool dma_iova_try_alloc(struct device *dev,
>   		struct dma_iova_state *state, phys_addr_t phys, size_t size)
>   {

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

[Vishnu Reddy]

On 1/19/2026 7:43 PM, Robin Murphy wrote:
> On 19/01/2026 5:49 am, Vishnu Reddy wrote:
>> Drivers can create child devices dynamically. These child devices often
>> inherit parent device tree node, including its reserved iommu-address
>> ranges.
>
> Which frankly sounds entirely wrong. If there are distinct devices with
> distinct hardware properties, then they should be properly described as such,
> and handled by a proper bus driver. And if different devices have different
> DMA restrictions, that should be described by "dma-ranges", not by abusing
> reserved regions.
>

Hi Robin,

The VPU is a single hardware unit, but internally it consists of
multiple functional blocks. Each block has its own distinct Stream ID
(SID) and operates with a different IOVA range requirement:

  +--------------------------------------------------+
  |                  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.

The upper boundary can be enforced via dma_set_mask_and_coherent. However,
enforcing the lower boundary (e.g., blocking 0 to 600MB for Block 0,
and 0 to 16MB for Block 2) requires explicit IOVA reservation,
which is what dma_iova_set_resv_region() provides in this patch.

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.

A crash was observed on one of the platforms due to the absence of
reserved regions. This API would help avoid such crashes by allowing
drivers to explicitly reserve the restricted IOVA range.
https://gitlab.freedesktop.org/drm/msm/-/work_items/100

Thanks,
Vishnu Reddy.

> Thanks,
> Robin.
>
>> While device tree can declare the multiple iommu-address ranges,
>> they still apply uniformly to any child inheriting the parent OF node.
>>
>> This creates a limitation when child requires a different iommu-address
>> range than its parent, as device tree cannot express the reservation per
>> child.
>>
>> Example layout and use case:
>> ----------------------------
>> A multimedia subsystem with multiple child devices and distinct ranges:
>>
>>      +-----------------------------------------------------------+
>>      | Device A reserved region (256 MB)                         |
>>      | 0x00000000 - 0x10000000                                   |
>>      +-----------------------------------------------------------+
>>      | Device B reserved region (512 MB)                         |
>>      | 0x00000000 - 0x20000000                                   |
>>      +-----------------------------------------------------------+
>>      | Device C reserved region (600 MB)                         |
>>      | 0x00000000 - 0x25800000                                   |
>>      +-----------------------------------------------------------+
>>      | Other reserved regions                                    |
>>      +-----------------------------------------------------------+
>>
>> If we add Device C's reserved range (0x0 to 0x025800000) into iommu
>> address range into device tree and assign that OF node to Device B
>> and C, it wastes memory:
>> - Device A wastes ~344 MB
>> - Device B wastes ~88 MB
>>
>> To avoid this, drivers can use the introduced API to set their device
>> specific IOVA region at runtime, ensuring the DMA mapping without
>> unnecessary address space reservation.
>>
>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
>> Link:
>> https://lore.kernel.org/all/20251220023555.3017456-1-busanna.reddy@oss.qualcomm.com/
>> ---
>>   drivers/iommu/dma-iommu.c   | 44 +++++++++++++++++++++++++++++++++++++
>>   include/linux/dma-mapping.h |  7 ++++++
>>   2 files changed, 51 insertions(+)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index aeaf8fad985c3..baee119e1c277 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -1743,6 +1743,50 @@ size_t iommu_dma_max_mapping_size(struct device *dev)
>>       return SIZE_MAX;
>>   }
>>   +/**
>> + * dma_iova_set_resv_region - Set a reserved region in the IOVA space
>> + * @dev: Device to set the reserved region for
>> + * @start: Start of the reserved region
>> + * @length: Length of the reserved region
>> + *
>> + * This function enables drivers to set device specific reservations at
>> + * runtime, which is particularly useful for dynamically created child
>> + * devices that requires distinct IOVA ranges than parent.
>> + *
>> + * Returns:
>> + *  0        - Success
>> + *  -ENODEV  - No valid IOMMU DMA domain for the device
>> + *  -EINVAL  - Invalid domain or cookie type for this operation
>> + *  -ENOMEM  - Failed to reserve the requested range
>> + */
>> +int dma_iova_set_resv_region(struct device *dev, unsigned long start,
>> +                 unsigned long length)
>> +{
>> +    struct iommu_dma_cookie *cookie;
>> +    struct iommu_domain *domain;
>> +    struct iova_domain *iovad;
>> +    unsigned long lo, hi;
>> +
>> +    domain = iommu_get_dma_domain(dev);
>> +    if (!domain || domain->type != IOMMU_DOMAIN_DMA)
>> +        return -ENODEV;
>> +
>> +    cookie = domain->iova_cookie;
>> +    if (!cookie || domain->cookie_type != IOMMU_COOKIE_DMA_IOVA)
>> +        return -EINVAL;
>> +
>> +    iovad = &cookie->iovad;
>> +
>> +    lo = iova_pfn(iovad, start);
>> +    hi = iova_pfn(iovad, start + length - 1);
>> +
>> +    if (!reserve_iova(iovad, lo, hi))
>> +        return -ENOMEM;
>> +
>> +    return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(dma_iova_set_resv_region);
>> +
>>   /**
>>    * dma_iova_try_alloc - Try to allocate an IOVA space
>>    * @dev: Device to allocate the IOVA space for
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index 29973baa05816..75b65160a37f3 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -347,6 +347,8 @@ static inline bool dma_use_iova(struct dma_iova_state
>> *state)
>>       return state->__size != 0;
>>   }
>>   +int dma_iova_set_resv_region(struct device *dev, unsigned long start,
>> +                 unsigned long length);
>>   bool dma_iova_try_alloc(struct device *dev, struct dma_iova_state *state,
>>           phys_addr_t phys, size_t size);
>>   void dma_iova_free(struct device *dev, struct dma_iova_state *state);
>> @@ -366,6 +368,11 @@ static inline bool dma_use_iova(struct dma_iova_state
>> *state)
>>   {
>>       return false;
>>   }
>> +static inline int dma_iova_set_resv_region(struct device *dev, unsigned long
>> start,
>> +                       unsigned long length)
>> +{
>> +    return -ENODEV;
>> +}
>>   static inline bool dma_iova_try_alloc(struct device *dev,
>>           struct dma_iova_state *state, phys_addr_t phys, size_t size)
>>   {
>

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

[Jason Gunthorpe]

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.

> 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 :)

Jason

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@oss.qualcomm.com/

> 
>> 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

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

[Jason Gunthorpe]

On Mon, Jun 15, 2026 at 12:26:25PM +0530, Vikash Garodia wrote:

> 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@oss.qualcomm.com/

Well, I'm not enthused by this:

+static int iris_vpu_bus_dma_configure(struct device *dev)
+{
+       struct iris_context_bank *cb = dev_get_drvdata(dev);
+
+       if (!cb)
+               return -ENODEV;
+
+       return of_dma_configure_id(dev, dev->parent->of_node, true, &cb->f_id);
+}

A custom bus and then calling configure_id on the parent which would
have already called of_dma_configure on that same of_node seems very
hacky to me.

Jason

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

[Vishnu Reddy]

On 6/15/2026 6:22 PM, Jason Gunthorpe wrote:
> On Mon, Jun 15, 2026 at 12:26:25PM +0530, Vikash Garodia wrote:
>
>> 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@oss.qualcomm.com/
> Well, I'm not enthused by this:
>
> +static int iris_vpu_bus_dma_configure(struct device *dev)
> +{
> +       struct iris_context_bank *cb = dev_get_drvdata(dev);
> +
> +       if (!cb)
> +               return -ENODEV;
> +
> +       return of_dma_configure_id(dev, dev->parent->of_node, true, &cb->f_id);
> +}
>
> A custom bus and then calling configure_id on the parent which would
> have already called of_dma_configure on that same of_node seems very
> hacky to me.

Hi Jason,

Here, the parent node does not have an iommus property — it only has iommu-map,
like example below:

iommu-map = <0x0 &apps_smmu 0x1940 0x0 0x1>,  /* function_id 0 → SID 0x1940 */
            <0x1 &apps_smmu 0x1943 0x0 0x1>,  /* function_id 1 → SID 0x1943 */
            <0x2 &apps_smmu 0x1944 0x0 0x1>;  /* function_id 2 → SID 0x1944 */

When the parent device is probed, of_dma_configure() is called, which
internally invokes of_dma_configure_id() with NULL as the function ID. Since
there is no iommus entry, no stream ID gets mapped to the parent device.

The child devices are created at runtime and have no of_node of their own. The
only place the iommu-map property exists is on the parent's of_node. So when
configuring a child device, we pass the parent's of_node along with the child's
specific function_id — this is how of_dma_configure_id() finds and maps the
correct stream ID to the child device only.

So to be clear — the parent of_node is not being configured again. It is just
being used as a lookup source for the iommu-map property, since the child has
no of_node of its own.

Thanks,
Vishnu Reddy.

> Jason

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

[Jason Gunthorpe]

On Mon, Jun 15, 2026 at 11:21:45PM +0530, Vishnu Reddy wrote:
> Hi Jason,
> 
> Here, the parent node does not have an iommus property — it only has iommu-map,
> like example below:
> 
> iommu-map = <0x0 &apps_smmu 0x1940 0x0 0x1>,  /* function_id 0 → SID 0x1940 */
>             <0x1 &apps_smmu 0x1943 0x0 0x1>,  /* function_id 1 → SID 0x1943 */
>             <0x2 &apps_smmu 0x1944 0x0 0x1>;  /* function_id 2 → SID 0x1944 */
> 
> When the parent device is probed, of_dma_configure() is called, which
> internally invokes of_dma_configure_id() with NULL as the function ID. Since
> there is no iommus entry, no stream ID gets mapped to the parent device.

Sure, but it still did of_dma_configure on the parent..

> The child devices are created at runtime and have no of_node of their own. The
> only place the iommu-map property exists is on the parent's of_node. So when
> configuring a child device, we pass the parent's of_node along with the child's
> specific function_id — this is how of_dma_configure_id() finds and maps the
> correct stream ID to the child device only.

The whole thing seems like the wrong way to use DT to me. Having an
iommu-map in the dt that no iommus property ever uses strikes me as
abusive.

Then hard coding the ID table and manually creating the missing
struct devices in C code is a throw back to board files :(

Of course it doesn't fully work, it was never intended to be used like
this.

Why the resistance to doing DT properly with actual iommus and dma
ranges for each and every stream your device needs?

Jason

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

[Krzysztof Kozlowski]

On 17/06/2026 21:40, Jason Gunthorpe wrote:
> On Mon, Jun 15, 2026 at 11:21:45PM +0530, Vishnu Reddy wrote:
>> Hi Jason,
>>
>> Here, the parent node does not have an iommus property — it only has iommu-map,
>> like example below:
>>
>> iommu-map = <0x0 &apps_smmu 0x1940 0x0 0x1>,  /* function_id 0 → SID 0x1940 */
>>             <0x1 &apps_smmu 0x1943 0x0 0x1>,  /* function_id 1 → SID 0x1943 */
>>             <0x2 &apps_smmu 0x1944 0x0 0x1>;  /* function_id 2 → SID 0x1944 */
>>
>> When the parent device is probed, of_dma_configure() is called, which
>> internally invokes of_dma_configure_id() with NULL as the function ID. Since
>> there is no iommus entry, no stream ID gets mapped to the parent device.
> 
> Sure, but it still did of_dma_configure on the parent..
> 
>> The child devices are created at runtime and have no of_node of their own. The
>> only place the iommu-map property exists is on the parent's of_node. So when
>> configuring a child device, we pass the parent's of_node along with the child's
>> specific function_id — this is how of_dma_configure_id() finds and maps the
>> correct stream ID to the child device only.
> 
> The whole thing seems like the wrong way to use DT to me. Having an
> iommu-map in the dt that no iommus property ever uses strikes me as
> abusive.

Same with interrupt-map.

There are PCIe controller nodes which have interrupt-map and no
interrupts property ever uses them.

https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/freescale/imx8mm.dtsi?h=v7.1#n1340

There might be DT children but they still won't have interrupts at all.

> 
> Then hard coding the ID table and manually creating the missing
> struct devices in C code is a throw back to board files :(

There are no distinctive, specific child devices here. Devices in terms
of hardware. There are no resources of children, they are not real
hardware devices.

You mentioned earlier that DT description is incomplete or not proper. I
disagree. Adding any child here just to configure IOMMU differently is
abuse of DT - creating fake device nodes to overcome somehow Linux
limitations.

> 
> Of course it doesn't fully work, it was never intended to be used like
> this.
> 
> Why the resistance to doing DT properly with actual iommus and dma
> ranges for each and every stream your device needs?

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.

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.


Best regards,
Krzysztof

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

[Jason Gunthorpe]

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.

> 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..

Jason