Message-ID: <0319bdf5-0a46-40fc-93f8-30d74cf6475a@arm.com>
Date: Wed, 5 Nov 2025 17:28:51 +0000
From: Robin Murphy <robin.murphy@....com>
To: Charan Teja Kalla <charan.kalla@....qualcomm.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
Subject: Re: [PATCH 0/6] of: iommu-map parsing for multi-cell IOMMU

On 2025-11-04 8:50 am, Charan Teja Kalla wrote:
> 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(-)

Hmm, I did actually have a quick go at this the other week too, and 
while I though it was a bit clunky, it was still significantly simpler 
than this seems to be...

FWIW: https://gitlab.arm.com/linux-arm/linux-rm/-/commits/iommu-map - I 
can give it some polish and testing to post properly if you like.

Thanks,
Robin.

Powered by blists - more mailing lists