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.

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@quicinc.com/

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(-)

-- 
2.34.1

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@quicinc.com/
> 
> 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(-)
>

On Sun, Sep 28, 2025 at 12:17 PM Charan Teja Kalla
<charan.kalla@oss.qualcomm.com> 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.

Where does the FUNCTION_ID value come from?

Why can't you just have multiple "iommus" entries where the index
defines the default and any FUNCTION_ID entries? What's in each index
is specific to the device.

Rob