[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ead7cf8b-fbc4-4242-a9da-b313dded1abc@arm.com>
Date: Thu, 9 Oct 2025 11:46:55 +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,
Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
bjorn.andersson@....qualcomm.com,
Dmitry Baryshkov <dmitry.baryshkov@....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-10-08 8:10 pm, Charan Teja Kalla wrote:
>
> On 9/29/2025 3:50 PM, Robin Murphy wrote:
>>> 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
>>
>
> Thanks Robin for your time. Sorry for late reply as I really didn't have
> concrete answer for this question.
>
> First let me clarify the word "sub blocks" -- This is just the logical
> separation with no separate address space to really able to define them
> as sub devices. Think of it like a single video IP with 2 dma
> engines(used for pixel and non-pixel purpose).
>
> I should agree that the child-nodes in the device tree is the easy one
> and infact, it is how being used in downstream.
>
> For upstream -- Since there is no real address space to interact with
> these sub-blocks(or logical blocks), does it really qualify to define as
> child nodes in the device tree? I see there is some push back[1].
Who says you need an address space? Child nodes without "reg"
properties, referenced by name, compatible or phandle, exist all over
the place for all manner of reasons. If there are distinct logical
functions with their own distinct hardware properties, then I would say
having child nodes to describe and associate those properties with their
respective functions is entirely natural and appropriate. The first
example that comes to mind of where this is a well-established practice
is PMICs - to pick one at random:
Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml
For bonus irony, you can't take the other approaches without inherently
*introducing* a notional address space in the form of your logical
function IDs anyway.
> > or:
>>
>> b) Use standard "iommu-map" which already supports mapping a masked
>> input ID to an arbitrary IOMMU specifier
>>
>
> I think clients is also required to program non-zero smr mask, where as
> iommu-map just maps the id to an IOMMU specifier(sid). Please LMK if I
> am unable to catch your thought here.
An IOMMU specifier is whatever the target IOMMU node's #iommu-cells says
it is. The fact that Linux's parsing code only works properly for
#iommu-cells = 1 is not really a DT binding problem (other than it
stemming from a loose assumption stated in the PCI binding's use of the
property).
However, I still lean toward the first approach, as this definitely
seems like it wants to be one overall device with a level of internal
hierarchy, rather than a full-blown bus abstraction.
Thanks,
Robin.
>
> Do you suggest to extend the iommu-map to give the non-zero SMR mask
> value[2]?
>
>
> [1]
> https://lore.kernel.org/all/ogslvjglnz56lz6nria7py6i4ccp6zvcd4ujpiusrq6xutydsm@xb72os5wk67r/#t
>
> [2]
> https://lore.kernel.org/all/bffc8478-4de9-4a9b-9248-96a936f20096@oss.qualcomm.com/>
> 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.
Powered by blists - more mailing lists