Message-Id: <20250928171718.436440-1-charan.kalla@oss.qualcomm.com>
Date: Sun, 28 Sep 2025 22:47:15 +0530
From: Charan Teja Kalla <charan.kalla@....qualcomm.com>
To: joro@...tes.org, will@...nel.org, robin.murphy@....com,
        saravanak@...gle.com, conor+dt@...nel.org, robh@...nel.org,
        mchehab@...nel.org, bod@...nel.org, krzk+dt@...nel.org,
        abhinav.kumar@...ux.dev, vikash.garodia@....qualcomm.com,
        dikshita.agarwal@....qualcomm.com
Cc: linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        iommu@...ts.linux.dev,
        Charan Teja Kalla <charan.kalla@....qualcomm.com>
Subject: [RFC PATCH 0/3] Introduce iommu-map-masked for platform devices

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

Powered by blists - more mailing lists