Re: [PATCH 3/7] of/iommu: add multi-map support

[Vikash Garodia <vikash.garodia@oss.qualcomm.com>]

On 1/27/2026 7:50 PM, Robin Murphy wrote:
> On 2026-01-27 11:45 am, Dmitry Baryshkov wrote:
>> On Mon, Jan 26, 2026 at 05:55:46PM +0530, Vikash Garodia wrote:
>>> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>>>
>>> When multiple mappings are present for an input id, linux matches just
>>> the first one. There is a usecase[1] where all the mappings are to be
>>> maintained in parallel for an iommu-map entry of a same input id.
>>
>> This contradicts the IOMMU idealogy (at least as far as I understood it
>> fom the maintainers): the device (driver) doesn't control which IOMMUs
>> are getting used. Instead _all_ defined entries should get used. For
>> iommu-map it means that if the map defines several entries for a single
>> function, then all entries should always get mapped.
> 
> Indeed there is no concept of "multi-map" - if a single input ID 
> represents more than one thing then that notion of "input ID" is 
> fundamentally wrong. A single *device* may have multiple IDs, as in the 
> case of PCI bridge aliasing, but in that case there are multiple things 
> to map.

Let me take examples of kaanapali and sm8550 and describe the vpu stream 
id generation part,

kaanapali:
iommu-map = <0x100 &apps_smmu 0x1940 0x0 0x1>,
             <0x100 &apps_smmu 0x1a20 0x0 0x1>,
             ....

sm8550:
iommus = <&apps_smmu 0x1940 0>,
	 <&apps_smmu 0x1947 0>;

In kaanapali, 0x1940 and 0x1a20 are the *resultant* stream-IDs. The 
resultant stream-id is generated based on
c-SID --> generated by vpu hardware, controlled by video firmware 
programming.
Topo ID --> port id, port at which vpu is connected to NOC, decided by 
vpu hardware.
TBU - smmu translation buffer unit, decided at soc design time.

Now if we take 0x1940 and 0x1a20, c-SID is same i.e 0. Within VPU, we 
have video engine (vcodec) and processor, both have different TOPO ID in 
kaanapali, whereas in sm8550, both have same TOPO ID. So vcodec and 
processor may (sm8550) or may not (kaanapali) have same stream-id.

There are some buffers, like internal buffers, are accessed by both, 
which then need both the stream-ids to be mapped into single context bank.

If you see sm8550, the requirement for both those hardware to access 
internal buffer is still there, since they have same c-SID, same topo id 
and tbu id, they have same stream id (0x1940)

Regards,
Vikash
> 
> Thanks,
> Robin.