Re: [PATCH v2 1/9] dt-bindings: dma: nvidia,tegra186-gpc-dma: Add iommu-map property
From: Jon Hunter
Date: Wed Mar 04 2026 - 06:18:00 EST
On 04/03/2026 10:37, Akhil R wrote:
On Tue, 3 Mar 2026 17:34:00 +0000, Jon Hunter wrote:
On 03/03/2026 17:14, Akhil R wrote:
On Tue, 3 Mar 2026 13:09:00 +0000, Jon Hunter wrote:available for a VM, but not the stream ID 0x80f.
On 03/03/2026 08:40, Akhil R wrote:
...
Why is this flexible? If it is, means usually items are distinctive, so
I would expect defining/listing them. If they are not distinctive,
commit msg is incorrect. If the list is as simple as 1-to-1 channel
mapping, just add it in the description how they are ordered.
Yes, it is a 1-to-1 channel mapping to an IOMMU ID. The intent of making
it flexible is to allow non-consecutive IOMMU ID assignments as well.
This is particularly needed in virtualised environments where the
hypervisor may reserve certain stream IDs, and the guest VM can map only
the permitted ones. Shall I add a description here mentioning this
use-case?
Isn't this already handled by the 'dma-channel-mask' property? The
driver will skip over any channels that are not in specified by the mask.
dma-channel-mask would not help if a channel is exposed, and the
corresponding IOMMU ID is not exposed. For instance say channel 15 is
Is that a valid configuration? Above we said it is a 1-to-1 mapping
which would imply the mapping is always constant. Ie. same channels maps
to name SID. Is that not the case?
I think the hypervisor configuration can determinte which stream IDs
are assigned to each VM, so the mapping can vary across platforms.
By 1-to-1, I meant that each channel maps to one IOMMU ID, but the
specific IDs themselves may not be fixed. If we prefer a constant
mapping instead, we could document that only IDs in the range 0x801 to
0x81f should be allocated to a Linux VM. Happy to go either way. Let me
know your thoughts.
I guess I don't know what flexibility we need here. But the more flexible, the more complex the binding and so if we need that flexibility then you will need to look at how Qualcomm solved this for their 'iris video codec' as Krzysztof mentioned.
Jon
--
nvpublic