Re: [PATCH RFC 0/4] iommu/arm-smmu-v3: Support shared Stream IDs

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Sep 17, 2026 at 09:33:55AM +0800, Peng Fan wrote:
> Hi Jason,
> 
> On Wed, Sep 16, 2026 at 01:10:18PM -0300, Jason Gunthorpe wrote:
> >On Wed, Sep 16, 2026 at 11:12:33PM +0800, Peng Fan (OSS) wrote:
> >> Some SoCs have a limited number of IOMMU Stream IDs (SIDs) and
> >> hardware that inherently shares them. For example, the NXP i.MX95
> >> eDMA controller has 64 channels where each TX/RX pair is assigned
> >> a single SID by the hardware - the two channel devices are distinct
> >> from Linux's perspective but present the same SID to the SMMU.
> >
> >Is that a reflection of poor DT modelling though?
> >
> >Why must a TX/RX *PAIR* have two platform_devices nodes?
> >
> >Fix it there and you don't need any of this? Or is there more?
> 
> I think there may be a misunderstanding about the device topology here.
> 
> There is only one platform device node for the eDMA controller
> (dma-controller@42000000). There are no separate platform device nodes per
> channel pair.
> 
> What happens instead:
> The fsl-edma driver probes the single platform device. During
> dmaenginem_async_device_register(), the dmaengine core calls

Yes, and if your DT is correct then that platform device should have a
single iommus = [] listing all the SIDs for that logical device.

Using iommu-map to describe synthetic dma_chan_dev devices that the
kernel creates is the same kind of DT abuse from over here:

https://lore.kernel.org/linux-iommu/20260618151745.GD231643@ziepe.ca/

So the problem is self created, by using iommu-map instead of iommus
and using DT to describe linux SW expectations you end up in this
strange place of asking for aliases.

> The iommu-map property sits on the eDMA controller's DT node. At channel
> allocation time (xlate), the driver calls of_dma_configure_id(chan_dev,
> edma_np, true, &chan_id) to look up the channel index in the eDMA node's
> iommu-map and attach an IOMMU domain to that specific channel device. The
> dmaengine framework's dmaengine_get_dma_device() API
> (which checks chan->dev->chan_dma_dev) then returns the per-channel device
> instead of the parent platform device, so DMA clients map buffers through
> the correct IOMMU context.

So go back to the basics, why did this platform use iommu-map instead
of iommus? The only real difference is you get a DMA translation per
queue. Is that required? Are you short IOVA? Some other reason?

You can read what I wrote about this general problem before:

https://lore.kernel.org/linux-iommu/20260818130724.GA5482@ziepe.ca/

It would be really nice if you all could work together to figure out a
better way to handle this than through DT abuses.

If you really need unique translations per sub-compoment of a logical
device from some pool of SIDs that feels like a weird version of PASID
to me, it may be an interesting to explore.

Jason