Add iommu-map property to specify separate stream IDs for each DMA
channel. This enables each channel to be in its own IOMMU domain,
keeping memory isolated from other devices sharing the same DMA
controller.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
.../devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
index 0dabe9bbb219..1e7b5ddd4658 100644
--- a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml
@@ -14,6 +14,7 @@ description: |
maintainers:
- Jon Hunter <jonathanh@nvidia.com>
- Rajesh Gumasta <rgumasta@nvidia.com>
+ - Akhil R <akhilrajeev@nvidia.com>
allOf:
- $ref: dma-controller.yaml#
@@ -51,6 +52,10 @@ properties:
iommus:
maxItems: 1
+ iommu-map:
+ minItems: 1
+ maxItems: 32
+
dma-coherent: true
dma-channel-mask:
--
2.50.1On Mon, Mar 02, 2026 at 06:02:31PM +0530, Akhil R wrote: > Add iommu-map property to specify separate stream IDs for each DMA > channel. This enables each channel to be in its own IOMMU domain, > keeping memory isolated from other devices sharing the same DMA > controller. > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com> > --- > .../devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml > index 0dabe9bbb219..1e7b5ddd4658 100644 > --- a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml > +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml > @@ -14,6 +14,7 @@ description: | > maintainers: > - Jon Hunter <jonathanh@nvidia.com> > - Rajesh Gumasta <rgumasta@nvidia.com> > + - Akhil R <akhilrajeev@nvidia.com> > > allOf: > - $ref: dma-controller.yaml# > @@ -51,6 +52,10 @@ properties: > iommus: > maxItems: 1 > > + iommu-map: > + minItems: 1 > + maxItems: 32 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. > + > dma-coherent: true > > dma-channel-mask: > -- > 2.50.1 >
On Tue, 3 Mar 2026 07:39:58 +0100 Krzysztof Kozlowski wrote: > On Mon, Mar 02, 2026 at 06:02:31PM +0530, Akhil R wrote: >> Add iommu-map property to specify separate stream IDs for each DMA >> channel. This enables each channel to be in its own IOMMU domain, >> keeping memory isolated from other devices sharing the same DMA >> controller. >> >> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> >> --- >> .../devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml >> index 0dabe9bbb219..1e7b5ddd4658 100644 >> --- a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml >> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml >> @@ -14,6 +14,7 @@ description: | >> maintainers: >> - Jon Hunter <jonathanh@nvidia.com> >> - Rajesh Gumasta <rgumasta@nvidia.com> >> + - Akhil R <akhilrajeev@nvidia.com> >> >> allOf: >> - $ref: dma-controller.yaml# >> @@ -51,6 +52,10 @@ properties: >> iommus: >> maxItems: 1 >> >> + iommu-map: >> + minItems: 1 >> + maxItems: 32 > > 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? > >> + >> dma-coherent: true >> >> dma-channel-mask: >> -- >> 2.50.1 >
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. Jon -- nvpublic
On Tue, 3 Mar 2026 13:09:00 +0000, Jon Hunter wrote: > 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 available for a VM, but not the stream ID 0x80f. Regards, Akhil
On 03/03/2026 17:14, Akhil R wrote: > On Tue, 3 Mar 2026 13:09:00 +0000, Jon Hunter wrote: >> 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 > available for a VM, but not the stream ID 0x80f. 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? Jon -- nvpublic
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: >>> 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 > available for a VM, but not the stream ID 0x80f. > > 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. Regards, Akhil
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: >>>> 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 >> available for a VM, but not the stream ID 0x80f. >> >> 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
Hi Krzysztof and Jon, On Wed, 4 Mar 2026 11:10:55 +0000, Jon Hunter wrote: > 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: >>>>> 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 >>> available for a VM, but not the stream ID 0x80f. >>> >>> 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. Looking at the qcom,sm8750-camss.yaml, each iommus entry is describing a functionally distinct hardware block like IPE, JPEG, etc. Here for GPCDMA the channels and the stream IDs are identical in hardware and there is nothing functionally unique about any individual channel to describe. If the channels and stream IDs are consecutive, as Frank mentioned in the previous version, we would need only one iommu-map entry for all the channels. In a virtualized system the hypervisor may assign non-consecutive stream IDs, or a scattered channel mask. That would require multiple entries. I will document this in the description. Please let me know if it sounds good or if you have any suggestions. Regards, Akhil
On 10/03/2026 04:44, Akhil R wrote: ... > Looking at the qcom,sm8750-camss.yaml, each iommus entry is describing a > functionally distinct hardware block like IPE, JPEG, etc. Here for > GPCDMA the channels and the stream IDs are identical in hardware and there > is nothing functionally unique about any individual channel to describe. > > If the channels and stream IDs are consecutive, as Frank mentioned in > the previous version, we would need only one iommu-map entry for all > the channels. In a virtualized system the hypervisor may assign > non-consecutive stream IDs, or a scattered channel mask. That would > require multiple entries. > > I will document this in the description. Please let me know if it sounds > good or if you have any suggestions. Even in the non-virtualised case we can set dma-channel-mask property and only enable specific channels. Given that the hardware allows this flexibility and we could potentially have various different permutations. So I think that we need to have a flexible number of items for iommu-map. And yes, let's describe that clearer in the commit message. Jon -- nvpublic
On 03/03/2026 09:40, Akhil R wrote: > On Tue, 3 Mar 2026 07:39:58 +0100 Krzysztof Kozlowski wrote: >> On Mon, Mar 02, 2026 at 06:02:31PM +0530, Akhil R wrote: >>> Add iommu-map property to specify separate stream IDs for each DMA >>> channel. This enables each channel to be in its own IOMMU domain, >>> keeping memory isolated from other devices sharing the same DMA >>> controller. >>> >>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com> >>> --- >>> .../devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml | 5 +++++ >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml >>> index 0dabe9bbb219..1e7b5ddd4658 100644 >>> --- a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml >>> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml >>> @@ -14,6 +14,7 @@ description: | >>> maintainers: >>> - Jon Hunter <jonathanh@nvidia.com> >>> - Rajesh Gumasta <rgumasta@nvidia.com> >>> + - Akhil R <akhilrajeev@nvidia.com> >>> >>> allOf: >>> - $ref: dma-controller.yaml# >>> @@ -51,6 +52,10 @@ properties: >>> iommus: >>> maxItems: 1 >>> >>> + iommu-map: >>> + minItems: 1 >>> + maxItems: 32 >> >> 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. You cannot skip items if these have such meaning of mapping per channel. The list order is the ABI - index of the list is the channel here. > 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? You can also look at recent works for iris video codec from Qualcomm solving something similar. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.