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

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

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.
       For example the APPS running in TEE or one of the
       various co-processors - like say the Compute DSP cDSP.

    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

    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"

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>;
      };

    - 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.

---
bod