On Mon, Sep 12, 2016 at 2:26 PM, Christian König <deathsimple@xxxxxxxxxxx> wrote: > Am 12.09.2016 um 18:44 schrieb Alex Deucher: >> >> From: "monk.liu" <monk.liu@xxxxxxx> >> >> original we use ttm_dma path to allocate GTT bo, which is too much >> slower than the path of ttm_pool, in most cases. >> >> The swiotlb checks don't seem to work and we always end up in the >> slow path even when an IOMMU is available. > > > While the check is clearly not correct. Simply always using the direct > mapping and not checking the fallback path can break as well. > > So this patch is clearly not a good idea and needs to be fixed before it is > pushed. Jerome looked into it when Monk first debugged this, but I don't think anything ever came of it: https://patchwork.kernel.org/patch/7079521/ Alex > > Christian. > > >> Signed-off-by: monk.liu <Monk.Liu@xxxxxxx> >> Reviewed-by: Jammy Zhou <jammy.zhou@xxxxxxx> >> Signed-off-by: Alex Deucher <alexander.deucher@xxxxxxx> >> --- >> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 13 ------------- >> 1 file changed, 13 deletions(-) >> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >> index 3beb10b..e2fcd39 100644 >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c >> @@ -783,12 +783,6 @@ static int amdgpu_ttm_tt_populate(struct ttm_tt *ttm) >> adev = amdgpu_get_adev(ttm->bdev); >> -#ifdef CONFIG_SWIOTLB >> - if (swiotlb_nr_tbl()) { >> - return ttm_dma_populate(>t->ttm, adev->dev); >> - } >> -#endif >> - >> r = ttm_pool_populate(ttm); >> if (r) { >> return r; >> @@ -829,13 +823,6 @@ static void amdgpu_ttm_tt_unpopulate(struct ttm_tt >> *ttm) >> adev = amdgpu_get_adev(ttm->bdev); >> -#ifdef CONFIG_SWIOTLB >> - if (swiotlb_nr_tbl()) { >> - ttm_dma_unpopulate(>t->ttm, adev->dev); >> - return; >> - } >> -#endif >> - >> for (i = 0; i < ttm->num_pages; i++) { >> if (gtt->ttm.dma_address[i]) { >> pci_unmap_page(adev->pdev, >> gtt->ttm.dma_address[i], > > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel