Re: [PATCH 1/2] dt-bindings: dma: fsl,edma: add iommu-map property

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

Hi Rob, Frank,

On Thu, Sep 24, 2026 at 04:56:26PM -0500, Rob Herring (Arm) wrote:
>
>On Wed, 16 Sep 2026 23:55:25 +0800, Peng Fan (OSS) wrote:
>> From: Peng Fan <peng.fan@nxp.com>
>> 
>> Add the iommu-map property to the fsl,edma binding to allow per-channel
>> IOMMU stream ID mapping. This enables IOMMU translation for individual
>> eDMA channels, where paired channels can share the same stream ID and
>> channels without an entry operate in bypass mode.
>> 
>> Also add a new example using fsl,imx95-edma5 that demonstrates the
>> iommu-map usage with per-channel mappings.
>> 
>> Assisted-by: Claude:claude-opus-4-6
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> ---
>>  .../devicetree/bindings/dma/fsl,edma.yaml          | 89 ++++++++++++++++++++++
>>  1 file changed, 89 insertions(+)
>> 
>
>Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Thanks for reviewing this patchset. I think I need to drop this patchset
and use the other method.

in https://lore.kernel.org/all/20260917144804.GI3196566@ziepe.ca/,
Jason Gunthorpe does not agree to use iommu-map for eDMA channels.

"The DT modeling for devices that have multiple stream-IDs is to list
them all in iommus list."

More comments about QCOM VPU in
https://lore.kernel.org/linux-iommu/20260618151745.GD231643@ziepe.ca/
"
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.
"

Thanks
Peng
>
>