Re: [PATCH v12 5/7] iommu/mediatek: Add MT8188 IOMMU Support

["Yong Wu (吴勇)" <Yong.Wu@mediatek.com>]

On Fri, 2023-08-11 at 11:30 +0800, Chen-Yu Tsai wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On Thu, Aug 10, 2023 at 8:23 PM Yong Wu (吴勇) <Yong.Wu@mediatek.com>
> wrote:
> >
> > On Tue, 2023-08-08 at 17:53 +0800, Chen-Yu Tsai wrote:
> > >
> > > External email : Please do not click links or open attachments
> until
> > > you have verified the sender or the content.
> > >  On Fri, Jun 2, 2023 at 5:04 PM Yong Wu <yong.wu@mediatek.com>
> wrote:
> > > >
> > > > From: "Chengci.Xu" <chengci.xu@mediatek.com>
> > > >
> > > > MT8188 has 3 IOMMU, containing 2 MM IOMMUs, one is for vdo, the
> > > other
> > > > is for vpp. and 1 INFRA IOMMU.
> > > >
> > > > Signed-off-by: Chengci.Xu <chengci.xu@mediatek.com>
> > > > Signed-off-by: Yong Wu <yong.wu@mediatek.com>
> > > > Reviewed-by: AngeloGioacchino Del Regno <
> > > angelogioacchino.delregno@collabora.com>
> > > > ---
> > > >  drivers/iommu/mtk_iommu.c | 49
> > > +++++++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 49 insertions(+)
> > > >
> > > > diff --git a/drivers/iommu/mtk_iommu.c
> b/drivers/iommu/mtk_iommu.c
> > > > index 9c89cf894a4d..5c66af0c45a8 100644
> > > > --- a/drivers/iommu/mtk_iommu.c
> > > > +++ b/drivers/iommu/mtk_iommu.c
> > > > @@ -170,6 +170,7 @@ enum mtk_iommu_plat {
> > > >         M4U_MT8173,
> > > >         M4U_MT8183,
> > > >         M4U_MT8186,
> > > > +       M4U_MT8188,
> > > >         M4U_MT8192,
> > > >         M4U_MT8195,
> > > >         M4U_MT8365,
> > > > @@ -1593,6 +1594,51 @@ static const struct mtk_iommu_plat_data
> > > mt8186_data_mm = {
> > > >         .iova_region_larb_msk = mt8186_larb_region_msk,
> > > >  };
> > > >
> > > > +static const struct mtk_iommu_plat_data mt8188_data_infra = {
> > > > +       .m4u_plat         = M4U_MT8188,
> > > > +       .flags            = WR_THROT_EN | DCM_DISABLE |
> > > STD_AXI_MODE | PM_CLK_AO |
> > > > +                           MTK_IOMMU_TYPE_INFRA |
> > > IFA_IOMMU_PCIE_SUPPORT |
> > > > +                           PGTABLE_PA_35_EN |
> > > CFG_IFA_MASTER_IN_ATF,
> > >
> > > FWIW, CFG_IFA_MASTER_IN_ATF should not be tied to the compatible
> > > string,
> > > but set via a DT property. The IOMMU controls are secured by
> > > firmware.
> > > It is not a property intrinsically tied to the hardware.
> >
> > The flag CFG_IFA_MASTER_IN_ATF means the registers which
> enable/disable
> > iommu are in the secure world. If the master like pcie want to
> enable
> > iommu, we have to enter secure world to configure it. It should be
> HW
> > intrinsical, right?
> 
> If I understand correctly, this is forced by setting some registers.
> The registers are set by the firmware at boot time.

The register will be set before the masters that have the "iommus="
property probe. If the master doesn't have "iommus=" property in its
dtsi node, this register won't be set, then its iommu will be disabled
and it has to access continuous buffer.

> 
> So if a different firmware that doesn't set the registers is used,
> then the IOMMU is available to non-secure kernel, correct?

No. The meaning of this register is whether to enable iommu. If the
register are not set, the IOMMU for that master is disabled.

> 
> That's why I said that it should not be tied to a particular hardware
> platform, but set using a boolean device tree property.
> 
> > >
> > > If on some other project there is no such security requirement
> and
> > > the
> > > IOMMU is opened up to non-secure world, and ATF not even having
> > > support
> > > for the SMC call, this becomes unusable and hard to rectify
> without
> > > introducing a new compatible string.
> > >
> > > ChenYu
> > >