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

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