| Message ID | 20230602090227.7264-3-yong.wu@mediatek.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | MT8188 IOMMU SUPPORT | expand |
On 02/06/2023 11:02, Yong Wu wrote: > Prepare for mt8188 to fix a two IOMMU HWs share pagetable issue. > > We have two MM IOMMU HWs in mt8188, one is VPP-IOMMU, the other is > VDO-IOMMU. The 2 MM IOMMU HWs share pagetable don't work in this case: > a) VPP-IOMMU probe firstly. > b) VDO-IOMMU probe. > c) The master for VDO-IOMMU probe (means frstdata is vpp-iommu). > d) The master in another domain probe. No matter it is vdo or vpp. > Then it still create a new pagetable in step d). The problem is > "frstdata->bank[0]->m4u_dom" was not initialized. Then when d) enter, it > still create a new one. > > In this patch, we create a new variable "share_dom" for this share > pgtable case, it should be helpful for readable. and put all the share > pgtable logic in the mtk_iommu_domain_finalise. > > In mt8195, the master of VPP-IOMMU probes before than VDO-IOMMU > from its dtsi node sequence, we don't see this issue in it. Prepare for > mt8188. Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
Hello, This patch is causing fluster tests to fail on MT8192, IOMMU read and write faults are reported in the log. Here's an extract is from the VP9 tests: mtk-iommu 1401d000.m4u: fault type=0x280 iova=0x1ff7c0000 pa=0x0 master=0x5000480(larb=5 port=0) layer=0 read mtk-iommu 1401d000.m4u: fault type=0x280 iova=0x1fe3ee000 pa=0x0 master=0x5000492(larb=5 port=4) layer=0 write Tests are failing for H264, VP8 and VP9 decoding on next-20230817 with fluster in the same way, complete logs can be found here: - H264: https://storage.kernelci.org/next/master/next-20230817/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/v4l2-decoder-conformance-h264-mt8192-asurada-spherion-r0.html - VP8: https://storage.kernelci.org/next/master/next-20230817/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/v4l2-decoder-conformance-vp8-mt8192-asurada-spherion-r0.html - VP9: https://storage.kernelci.org/next/master/next-20230817/arm64/defconfig+arm64-chromebook+videodec/gcc-10/lab-collabora/v4l2-decoder-conformance-vp9-mt8192-asurada-spherion-r0.html Reverting this patch fixes the issue. From my understanding, on MT8192 the 16GB iova space is partitioned between display, vcodec and camera. The iommu domain configuration for vcodec was loaded from frstdata->bank[0]->m4u_dom (vcodec is preassigned to a specific iova range), while after this patch a new pagetable is created instead. Do you have any insight on how to fix this while keeping compatibility with MT8188 and MT8195? Best, Laura
Hi Laura, Thanks very much for your testing. On Fri, 2023-08-18 at 17:41 +0200, Laura Nao wrote: > Hello, > > This patch is causing fluster tests to fail on MT8192, IOMMU read and > write faults are reported in the log. Here's an extract is from the > VP9 tests: > > mtk-iommu 1401d000.m4u: fault type=0x280 iova=0x1ff7c0000 pa=0x0 > master=0x5000480(larb=5 port=0) layer=0 read > mtk-iommu 1401d000.m4u: fault type=0x280 iova=0x1fe3ee000 pa=0x0 > master=0x5000492(larb=5 port=4) layer=0 write > > Tests are failing for H264, VP8 and VP9 decoding on next-20230817 > with fluster in the same way, complete logs can be found here: > - H264: > https://urldefense.com/v3/__https://storage.kernelci.org/next/master/next-20230817/arm64/defconfig*arm64-chromebook*videodec/gcc-10/lab-collabora/v4l2-decoder-conformance-h264-mt8192-asurada-spherion-r0.html__;Kys!!CTRNKA9wMg0ARbw!g5CkV4Tmx8gZ_Ll6AMpoEosTjSgKbdfG2RNwJJFdnpX4g-MW0IdAmt3bXphiIIfSPmGbbPO1tFM4b8wSlrgogw$ > > - VP8: > https://urldefense.com/v3/__https://storage.kernelci.org/next/master/next-20230817/arm64/defconfig*arm64-chromebook*videodec/gcc-10/lab-collabora/v4l2-decoder-conformance-vp8-mt8192-asurada-spherion-r0.html__;Kys!!CTRNKA9wMg0ARbw!g5CkV4Tmx8gZ_Ll6AMpoEosTjSgKbdfG2RNwJJFdnpX4g-MW0IdAmt3bXphiIIfSPmGbbPO1tFM4b8wa_83EZw$ > > - VP9: > https://urldefense.com/v3/__https://storage.kernelci.org/next/master/next-20230817/arm64/defconfig*arm64-chromebook*videodec/gcc-10/lab-collabora/v4l2-decoder-conformance-vp9-mt8192-asurada-spherion-r0.html__;Kys!!CTRNKA9wMg0ARbw!g5CkV4Tmx8gZ_Ll6AMpoEosTjSgKbdfG2RNwJJFdnpX4g-MW0IdAmt3bXphiIIfSPmGbbPO1tFM4b8xaOT2SLw$ > > > Reverting this patch fixes the issue. > > From my understanding, on MT8192 the 16GB iova space is partitioned > between display, vcodec and camera. The iommu domain configuration > for vcodec was loaded from frstdata->bank[0]->m4u_dom (vcodec is > preassigned to a specific iova range), while after this patch a new > pagetable is created instead. Exactly Right. It creates a new pagetable for this case. I sent a patch for this. Could you also help confirm? Thanks. https://lore.kernel.org/linux-mediatek/20230819081443.8333-1-yong.wu@mediatek.com/ > > Do you have any insight on how to fix this while keeping > compatibility with MT8188 and MT8195? > > Best, > > Laura
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c index aecc7d154f28..7287be67bd1f 100644 --- a/drivers/iommu/mtk_iommu.c +++ b/drivers/iommu/mtk_iommu.c @@ -258,6 +258,8 @@ struct mtk_iommu_data { struct device *smicomm_dev; struct mtk_iommu_bank_data *bank; + struct mtk_iommu_domain *share_dom; /* For 2 HWs share pgtable */ + struct regmap *pericfg; struct mutex mutex; /* Protect m4u_group/m4u_dom above */ @@ -620,15 +622,14 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom, struct mtk_iommu_data *data, unsigned int region_id) { + struct mtk_iommu_domain *share_dom = data->share_dom; const struct mtk_iommu_iova_region *region; - struct mtk_iommu_domain *m4u_dom; - - /* Always use bank0 in sharing pgtable case */ - m4u_dom = data->bank[0].m4u_dom; - if (m4u_dom) { - dom->iop = m4u_dom->iop; - dom->cfg = m4u_dom->cfg; - dom->domain.pgsize_bitmap = m4u_dom->cfg.pgsize_bitmap; + + /* Always use share domain in sharing pgtable case */ + if (MTK_IOMMU_HAS_FLAG(data->plat_data, SHARE_PGTABLE) && share_dom) { + dom->iop = share_dom->iop; + dom->cfg = share_dom->cfg; + dom->domain.pgsize_bitmap = share_dom->cfg.pgsize_bitmap; goto update_iova_region; } @@ -658,6 +659,9 @@ static int mtk_iommu_domain_finalise(struct mtk_iommu_domain *dom, /* Update our support page sizes bitmap */ dom->domain.pgsize_bitmap = dom->cfg.pgsize_bitmap; + if (MTK_IOMMU_HAS_FLAG(data->plat_data, SHARE_PGTABLE)) + data->share_dom = dom; + update_iova_region: /* Update the iova region for this domain */ region = data->plat_data->iova_region + region_id; @@ -708,7 +712,9 @@ static int mtk_iommu_attach_device(struct iommu_domain *domain, /* Data is in the frstdata in sharing pgtable case. */ frstdata = mtk_iommu_get_frst_data(hw_list); + mutex_lock(&frstdata->mutex); ret = mtk_iommu_domain_finalise(dom, frstdata, region_id); + mutex_unlock(&frstdata->mutex); if (ret) { mutex_unlock(&dom->mutex); return ret;