Re: [RFC PATCH 0/3] Introduce iommu-map-masked for platform devices

[Robin Murphy <robin.murphy@arm.com>]

On 2025-10-08 8:10 pm, Charan Teja Kalla wrote:
> 
> On 9/29/2025 3:50 PM, Robin Murphy wrote:
>>> USECASE [1]:
>>> -----------
>>> Video IP, 32bit, have 2 hardware sub blocks(or can be called as
>>> functions) called as pixel and nonpixel blocks, that does decode and
>>> encode of the video stream. These sub blocks are __configured__ to
>>> generate different stream IDs.
>>
>> So please clarify why you can't:
>>
>> a) Describe the sub-blocks as individual child nodes each with their own
>> distinct "iommus" property
>>
> 
> Thanks Robin for your time. Sorry for late reply as I really didn't have
> concrete answer for this question.
> 
> First let me clarify the word "sub blocks" -- This is just the logical
> separation with no separate address space to really able to define them
> as sub devices. Think of it like a single video IP with 2 dma
> engines(used for pixel and non-pixel purpose).
> 
> I should agree that the child-nodes in the device tree is the easy one
> and infact, it is how being used in downstream.
> 
> For upstream -- Since there is no real address space to interact with
> these sub-blocks(or logical blocks), does it really qualify to define as
> child nodes in the device tree? I see there is some push back[1].

Who says you need an address space? Child nodes without "reg" 
properties, referenced by name, compatible or phandle, exist all over 
the place for all manner of reasons. If there are distinct logical 
functions with their own distinct hardware properties, then I would say 
having child nodes to describe and associate those properties with their 
respective functions is entirely natural and appropriate. The first 
example that comes to mind of where this is a well-established practice 
is PMICs - to pick one at random: 
Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml

For bonus irony, you can't take the other approaches without inherently 
*introducing* a notional address space in the form of your logical 
function IDs anyway.

>    > or:
>>
>> b) Use standard "iommu-map" which already supports mapping a masked
>> input ID to an arbitrary IOMMU specifier
>>
> 
> I think clients is also required to program non-zero smr mask, where as
> iommu-map just maps the id to an IOMMU specifier(sid). Please LMK if I
> am unable to catch your thought here.
An IOMMU specifier is whatever the target IOMMU node's #iommu-cells says 
it is. The fact that Linux's parsing code only works properly for 
#iommu-cells = 1 is not really a DT binding problem (other than it 
stemming from a loose assumption stated in the PCI binding's use of the 
property).

However, I still lean toward the first approach, as this definitely 
seems like it wants to be one overall device with a level of internal 
hierarchy, rather than a full-blown bus abstraction.

Thanks,
Robin.

> 
> Do you suggest to extend the iommu-map to give the non-zero SMR mask
> value[2]?
> 
> 
> [1]
> https://lore.kernel.org/all/ogslvjglnz56lz6nria7py6i4ccp6zvcd4ujpiusrq6xutydsm@xb72os5wk67r/#t
> 
> [2]
> https://lore.kernel.org/all/bffc8478-4de9-4a9b-9248-96a936f20096@oss.qualcomm.com/>
> Thanks,
>> Robin.
>>
>>> With the classical approach of representing all sids with iommus= end up
>>> in using a single translation context limited to the 4GB. There are
>>> video usecases which needs larger IOVA space, like higher concurrent
>>> video sessions(eg: 32 session and 192MB per session) where 4GB of IOVA
>>> is not sufficient.