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

[Rob Herring]

On Wed, Oct 15, 2025 at 3:53 AM Bryan O'Donoghue <bod@xxxxxxxxxx> wrote:
>
> On 14/10/2025 23:18, Dmitry Baryshkov wrote:
> > On Tue, Oct 14, 2025 at 09:49:17PM +0100, Bryan O'Donoghue wrote:
> >> On 14/10/2025 19:35, Dmitry Baryshkov wrote:
> >>>> Each function id can be associated with a device and a compat string
> >>>> associated with it.
> >>> So, which part of the hardware is described by the -cb device? What does
> >>> it mean_here_?
> >>
> >> The non-pixel path video encoder, the tz video encoder...
> >>
> >> What's not clear about that ?
> >
> > Where do you have pixel encoders in the fastrpc device node?
> >
> > --
> > With best wishes
> > Dmitry
>
> Haha, no sorry I didn't mean to suggest that at all.
>
> I mean do something _like_ that, for these FUNCION_IDs.
>
> We could replicate that for a new iris add for say Glymur or Kanaapali.
>
> Sub-nodes of the main iris device. They have a real purpose in that the
> 'device' requirement is full range IOVA for the SID and implicit
> identification of the FUNCTION_ID with the compat string
>
> iris-video@0xdeadbeef {
>         video@0 {
>                 reg = <0>;  /* FUNCTION_ID HLOS could also go here */
>                 compat = "qcom,glymur-iris";
>
>                 iommus = <&apps_smmu 0x1940 0x0000>;
>         };
>
>         video@1 {
>                 reg = <1>;
>                 compat = "qcom,glymur-iris-non-pixel";
>                 iommus = <&apps_smmu 0x1947 0x0000>;
>         };
> };
>
> The reg property could also be the function_id
>
> video@FUNC_ID_HLOS {
>         reg = <FUNC_ID_HLOS>;
>         ...
> };
>
> There's no need for a new iommu specific property to help us fixup
> sm8550 iommu definition.
>
> As I say if that error wasn't already in sm8550, we wouldn't be trying
> to solve the problem this way.
>
> So lets solve the problem for Glymur and Kanaapali and then backport
> upstream if we can or downstream if we can't.
>
> What we need are new devices what we will do with the data in
> iommu-map-masked is make new devices. We are mapping data - iommu SID to
> device and implicit FUNCTION_ID to a device.
>
> So we should be declaring devices, instead of burying the data in a new
> property that is not obvious what it does or why it exists.

No, these aren't separate devices. Please stop going down this route.

Rob