Re: [RFC PATCH 0/3] Introduce iommu-map-masked for platform devices

[Rob Herring <robh@kernel.org>]

On Fri, Oct 10, 2025 at 2:53 PM Charan Teja Kalla
<charan.kalla@oss.qualcomm.com> wrote:
>
>
>
> On 10/9/2025 11:55 PM, Dmitry Baryshkov wrote:
> >>> I really don't like the idea of extending the #iommu-cells. The ARM SMMU
> >>> has only one cell, which is correct even for our platforms. The fact
> >>> that we need to identify different IOMMU SIDs (and handle them in a
> >>> differnt ways) is internal to the video device (and several other
> >>> devices). There is nothing to be handled on the ARM SMMU side.
> >> Huh? So if you prefer not to change anything, are you suggesting this series
> >> doesn't need to exist at all? Now I'm thoroughly confused...
> > Hmm. We need changes, but I don't feel like adding the FUNCTION_ID to
> > #iommu-cells is the best idea.
> >
> >> If you want to use SMR masks, then you absolutely need #iommu-cells = 2,
> >> because that is the SMMU binding for using SMR masks. It would definitely
> > I'm sorry. Yes, we have #iommu-cells = <2>.
> >
> >> not be OK to have some magic property trying to smuggle
> >> IOMMU-driver-specific data contrary to what the IOMMU node itself says. As
> >> for iommu-map, I don't see what would be objectionable about improving the
> >> parsing to respect a real #iommu-cells value rather than hard-coding an
> >> assumption. Yes, we'd probably need to forbid entries with length > 1
> >> targeting IOMMUs with #iommu-cells > 1, since the notion of a linear
> > This will break e.g. PCIe on Qualcomm platforms:
> >
> >                         iommu-map = <0x0   &apps_smmu 0x1400 0x1>,
> >                                     <0x100 &apps_smmu 0x1401 0x1>;
> >
> >
> > But this seems unlogical anyway wrt. apps_smmu having #iommu-cells =
> > <2>. It depends on ARM SMMU ignoring the second cell when it's not
> > present.
> >
> >> relationship between the input ID and the output specifier falls apart when
> >> the specifier is complex, but that seems simple enough to implement and
> >> document (even if it's too fiddly to describe in the schema itself), and
> >> still certainly no worse than having another property that *is* just
> >> iommu-map with implicit length = 1.
> >>
> >> And if you want individual StreamIDs for logical functions to be attachable
> >> to distinct contexts then those functions absolutely must be visible to the
> >> IOMMU layer and the SMMU driver as independent devices with their own unique
> >> properties, which means either they come that way from the DT as of_platform
> >> devices in the first place, or you implement a full bus_type abstraction
>
> I don't want to dilute what Dmitry is saying here, but the below is what
> i can make out of Robin comments, please CMIW:
>
> iommu {
>         #iommu-cells = <2>;
> }
>
> video {
>    iommu = <iommu sid1 mask1>, <iommu sid2 mask2>;
>    #iommu-map-cells = 2; /* does it look weird to define here, even if
> it is SMMU property? */

No, not weird. interrupt-map similarly requires #interrupt-cells. So
it would be just #iommu-cells here.

>    iommu-map = <0 smmu sid3 mask3>,
>                <0 smmu sid4 mask4>;

But you only have 1 cell, not 2 here. The #iommu-cells in this node
would define the number of cells before 'smmu'. The #iommu-cells in
the &smmu node is the number of cells after the &smmu phandle.

Rob