Message-Id: <cover.1762235099.git.charan.kalla@oss.qualcomm.com>
Date: Tue,  4 Nov 2025 14:20:59 +0530
From: Charan Teja Kalla <charan.kalla@....qualcomm.com>
To: robin.murphy@....com, will@...nel.org, joro@...tes.org, robh@...nel.org,
        dmitry.baryshkov@....qualcomm.com, konrad.dybcio@....qualcomm.com,
        bjorn.andersson@....qualcomm.com, bod@...nel.org, conor+dt@...nel.org,
        krzk+dt@...nel.org, saravanak@...gle.com,
        prakash.gupta@....qualcomm.com, vikash.garodia@....qualcomm.com
Cc: iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org,
        Charan Teja Kalla <charan.kalla@....qualcomm.com>
Subject: [PATCH 0/6] of: iommu-map parsing for multi-cell IOMMU

The iommu-map property has been defined for the PCIe usecase and has
been hardcoded to assume single cell for IOMMU specification, ignoring
the #iommu-cells completely. Since the initial definition the iommu-maps
property has been reused for other usecases and we can no longer assume
that the single IOMMU cell properly describes the necessary IOMMU
streams. Expand the iommu-map to take #iommu-cells into account, while
keeping the compatibility with the existing DTs, which assume single
argument. 

Unlike single iommu-cell, it is complex to establish a linear relation
between input 'id' and output specifier for multi iommu-cells. To handle
such cases, rely on arch-specific drivers called through
of_iommu_xlate() from of_iommu layer, aswell it is expected the 'len'
passed is always 1. In the of_iommu layer, the below relation is
established before calling into vendor specific driver: 

a) For platform devices, 'rid' defined in the iommu-map tuple indicates
a function, through a bit position, which is compared against passed
input 'id' that represents a bitmap of functions represented by the
device.

b) For others, 'rid' is compared against the input 'id' as an integer
value.

Thus the final representation when #iommu-cells=n is going to be,
iommu-map = <rid/functionid IOMMU_phandle cell0 .. celln len>;, where
len = 1.

The RFC for this patch set is found at [2].

The other motivation for this patchset is the below usecase.
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 logical 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, each functionality is represented in the firmware(device
tree) by the 'rid' field of the iommu-map property and the video driver
creates sub platform devices for each of this functionality and call
into IOMMU configuration. Each rid(function id) in the dt property
indicates the bit that can be associated by the driver passed input id.

Example: 
iommu {
	#iommu-cells = 2;
};

video-codec@...bar {
	compatible = "qcom,video";
	iommus = <&apps_smmu 0x1234 0xca>;
	iommu-map= <0x1 &iommu 0x1940 0x0 0x1>,
               <0x1 &iommu 0x1941 0x0 0x1>,
               <0x2 &iommu 0x1942 0x0 0x1>,
               <0x4 &iommu 0x1943 0x0 0x1>,
               <0x4 &iommu 0x1944 0x0 0x1>;
};

video-driver:
#define PIXEL_FUNC	   (1)
#define NON_PIXEL_FUNC	   (2)
#define SECURE_FUNC	   (4)

case1: All these functionalities requires individual contexts.
Create 3 subdevices for each of this function and call
of_dma_configure_id(..,id), id = 0x1, 0x2, 0x4.

Case2: Secure and non-secure functionalities require individual
contexts. Create 2 subdevices and call of_dma_configure_id(..,id), id =
0x3(bitmap of pixel and non-pixel), 0x4 (secure).

Credits: to Dmitry for thorough discussions on the RFC patch and major
help in getting the consenus on this approach, to Konrad & Bjorn for
offline discussions and reviews, to Robin for his inputs on IOMMU front,
to Bod, Rob and Krzysztof for all valuable inputs.

[1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/
[2] https://lore.kernel.org/all/20250928171718.436440-1-charan.kalla@oss.qualcomm.com/#r

Charan Teja Kalla (6):
  of: create a wrapper for of_map_id()
  of: introduce wrapper function to query the cell count
  of: parse #<name>-cells property to get the cell count
  of: detect and handle legacy iommu-map parsing
  of: add infra to parse iommu-map per IOMMU cell count
  of: use correct iommu-map parsing logic from of_iommu layer

 drivers/iommu/of_iommu.c |  59 +++++++--
 drivers/of/base.c        | 269 +++++++++++++++++++++++++++++++++++----
 include/linux/of.h       |  19 +++
 3 files changed, 314 insertions(+), 33 deletions(-)

-- 
2.34.1

Powered by blists - more mailing lists