[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aec0f40a-8346-4194-8b18-1022fe3366bb@arm.com>
Date: Mon, 29 Sep 2025 11:20:34 +0100
From: Robin Murphy <robin.murphy@....com>
To: Charan Teja Kalla <charan.kalla@....qualcomm.com>, joro@...tes.org,
will@...nel.org, 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
Subject: Re: [RFC PATCH 0/3] Introduce iommu-map-masked for platform devices
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(-)
>
Powered by blists - more mailing lists