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

[Bryan O'Donoghue]

On 12/10/2025 23:47, Dmitry Baryshkov wrote:
> On Sun, Oct 12, 2025 at 09:44:43PM +0100, Bryan O'Donoghue wrote:
> > On 10/10/2025 20:53, Charan Teja Kalla wrote:
> > > 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? */
> > >      iommu-map = <0 smmu sid3 mask3>,
> > > 	       <0 smmu sid4 mask4>;
> > > };
> >
> >
> > This whole iommu-map thing is a wrong direction, its a workaround.
> >
> > It stems from here:
> >
> > 1. Vikash posted a series adding a platform device
> > https://lore.kernel.org/linux-media/20250627-video_cb-v3-0-51e18c0ffbce@xxxxxxxxxxx/
> >
> >     The two objectives of this are
> >
> >     a. Allow Linux, the APPS as qcom calls it,@ EL1 or EL2
> >        to setup iommu entries for function_ids that are
> >        not the APPS @ EL1/EL2.
>
> No.
>
> Up to now we were talking only about the non-pixel bitstreams and secure
> en-/decoding data.  None of that is related to anything except Linux
> running in EL1/EL2. Only Linux consumes / provides normal non-pixel
> data. Only Linux handles decoded secure buffers. Only Linux sets up the
> video decoding of secure data and then blending of that data inside DPU.

As I understand some of these >>        For example the APPS running in 
TEE or one of the
> >        various co-processors - like say the Compute DSP cDSP.
>
> How did CDSP or TEE get into the picture?

Hypothetical examples of the non-HLOS VMID. Call these AC_VM_CP_BITSREAM 
or AC_VM_CP_NON_PIXEL to use values from the documentation.

> >     b. Allowing for each device to have a full IOVA range.
> >
> > 2. Krzysztof queried about changing _existing_ entries e.g.
> > https://lore.kernel.org/linux-media/6fd3fa34-69e1-484f-ad6f-8caa852f1a6c@xxxxxxxxxx/
> >
> >     The point about ABI breakage.
> >
> > 3. This proposal to introduce iommu-map as a workaround
> >     Gets the FUNCTION_ID APPS v cDSP v TZ into the DT
>
> It's neither CDSP nor TZ. The source or the consumer of the data might
> be crypto core or just Linux process. For non-secured non-pixel data it
> _is_ Linux process.
>
> >     So it solves 1/a I'm not sure it solves 1/b
> >
> >     However if you were designing from scratch you wouldn't
> >     have a motivation to assign this additional property.
> >
> >     The motivation is to not break the ABI I think.
> >
> > 4. Robin said
> >
> >     "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"
>
> Correct. But it doesn't require separate OF device nodes. See
> host1x_memory_context_list_init().

Fine could be platform code too.


> > 5. If you think about this, its actually the right long term solution
> >
> >     - Individual devices means something like:
> >
> >       video-codec@aa00000 {
> >           /* Any SID mapping to S1_VIDEO_HLOS belongs here */
> >           compatible = "qcom,sm8550-iris";
> >           iommus = <&apps_smmu 0x1947 0x0000>;
> >       };
> >
> >       video-codec-non-pixel {
> >           /* Any SID mapping to S1_VIDEO_HLOS_P belongs here */
> >           compatible = "qcom,sm8550-iris-non-pixel";
> >           iommus = <&apps_smmu 0x1940 0x0000>;
> >       };
>
> Which piece of hardware is described by this node? Why is it separate
> from the main video-codec? The IOMMU stream doesn't have any specifics,
> it's just a part of the video codec core.

You could conceivably start associating /dev/video entries with a device 
that maps to AC_VM_CP_PIXEL - the protected video stream.

There may be data other than SID/FUNCTION_ID that we would want to 
associate with those devices, I'll stipulate to further discussion there.
> >     - Or do something like that above again in platform code.
> >
> > 6. We should on introduction of a new SoC
> >
> >     - Fix the iommus = <> for "qcom,newsoc-iris" to contain
> >       only what is pertinent to S1_VIDEO_HLOS
> >
> >     - Make new devices in the DT for each FUNCTION_ID
> >
> >     - Then look at how - if - that fix can be brought back to Lemans
> >
> > My problem with introducing the iommu-map is that it bakes into the video
> > codec definitions a fixup which then gets carried forward.
> >
> > But the right thing to do is individual devices so, let's do that and worry
> > about how to back-port that fix to older SoCs once done.

So really whether we end up representing these devices in DT or platform 
code, separate devices are the answer - both for the FUNCTION_ID mapping 
and the IOVA range.

You just need to carefully think about what ends up being a device if 
the IOVA range is a concern.

Its unfortunate that sm8550 has an addtional iommu entry that wants to 
live in a different device - but, that's a problem for sm8550.

Perhaps something we can backport to Lanai, Lemans and friends once we 
get the new submissions right..

---
bod