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

[Peng Fan <peng.fan@oss.nxp.com>]

Hi Jason,

On Thu, Sep 17, 2026 at 11:48:04AM -0300, Jason Gunthorpe wrote:
>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.

Agreed - the DMA controller should use iommus, not iommu-map. I'll
rework the DT side. The iommu-map approach has not landed upstream,
so nothing is set in stone yet.

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

Thanks for sharing the links.

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

Per reading this thread, seems need to describe VPU sub-blocks
blocks using device tree node.


For NXP i.MX95, we just use one device tree node for the DMA controller.
https://elixir.bootlin.com/linux/v7.2.5/source/arch/arm64/boot/dts/freescale/imx95.dtsi#L634

>
>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 DT property is not landed in upstream, it is still
under reviewing.

https://lore.kernel.org/dmaengine/20260916-edma-iommu-v1-1-e1731968081e@nxp.com/

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

No, per-queue translation is not required. A single iommus entry (or
a list of all SIDs the controller uses) on the platform device would
work. I'll take this direction.

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

Understood. I'll follow up on the links you shared and work with the
dmaengine folks to sort out the DT modelling.

However, the DMA channel case was just one example - the shared-SID
need exists independently of it. Our SoC (i.MX95) has only 64 SIDs
total, serving MMC, SD, NET, PCI, DMA, NPU, DSP, DISPLAY and more.
Some of these are genuinely separate platform devices (distinct DT
nodes, distinct drivers) that share a SID by hardware design because
the SID space is exhausted.

That cross-IP case cannot be solved by DT restructuring - the devices
really are separate. Would you be open to reviewing the shared-SID
SMMU support (patches 1-4) on that basis, independent of the DMA
channel question?

Thanks,
Peng

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