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

[Bryan O'Donoghue <bod@kernel.org>]

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@quicinc.com/
>>
>>     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@kernel.org/
>>
>>     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