Re: [PATCH v2 1/9] dt-bindings: dma: nvidia,tegra186-gpc-dma: Add iommu-map property

[Akhil R <akhilrajeev@nvidia.com>]

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