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

[Robin Murphy]

On 2025-09-28 6:17 pm, Charan Teja Kalla wrote:
> This series introduces a new iommu property called iommu-map-masked(may
> be there is a better name), which is used to represent the IOMMU
> specifier pairs for each function of a __multi-functional platform
> device__, where each function can emit unique master id(s) that can be
> associated with individual translation context.
>
> Currently, the iommu configuration - at least for arm architecture-
> requires all the functions of a platform device will be represented
> under single dt node thus endup in using only a single translation
> context.
>
> A simple solution to associate individual translation context for each
> function of a device can be through creating per function child nodes in
> the device tree, but dt is only to just represent the soc layout to
> linux kernel.
>
> Supporting such cases requires a new iommu property called,
> iommu-map-masked(taking cue from iommu-map for pci devices) and syntax
> is:
>     iommu-map-masked = <FUNCTION_ID1 &iommu ID1 MASK1>,
> 		      <FUNCTION_ID2 &iommu ID2 MASK2>;
> NOTE: As an RFC, it is considered that this property always expects 4
> cells.
>
> During the probe phase of the driver for a multi-functional device
> behind an IOMMU, a child device is instantiated for each FUNCTION_ID.
> The call to of_dma_configure_id() on each child sets up the IOMMU
> configuration, ensuring that each function of the device is associated
> with a distinct translation context.
>
> This property can also be used in association with 'iommus=' when dt
> bindings requires the presence of 'iommus=', example[2]. For these
> cases, representation will be(on arm64):
>     iommus = <&iommu sid mask>; //for default function.
>     iommu-map-masked = <FUNCTION_ID &iommu sid mask>;//additional
> function.
>
> 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

or:

b) Use standard "iommu-map" which already supports mapping a masked 
input ID to an arbitrary IOMMU specifier

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.
>
> For this case, it can be considered as iommus= property can be
> associated with pixel functionality and iommu-map-masked= is with
> non-pixel or viceversa.
>
> [1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@xxxxxxxxxxx/
>
> Charan Teja Kalla (3):
>    dtbindings: add binding for iommu-map-masked property
>    of: create a wrapper for of_map_id()
>    of: implment the 'iommu-map-masked' to represent multi-functional
>      devices
>
>   .../bindings/media/qcom,sm8550-iris.yaml      | 31 ++++++++++-
>   drivers/iommu/of_iommu.c                      | 44 +++++++++++++++
>   drivers/of/base.c                             | 55 ++++++++++++++++---
>   include/linux/of.h                            | 15 +++++
>   4 files changed, 133 insertions(+), 12 deletions(-)