Commit d483628b80156d80bf001fa8b55c95b828183fe4

Authored by Michel Dänzer
Committed by Greg Kroah-Hartman
1 parent 588039c336

drm/radeon: Restore GART table contents after pinning it in VRAM v3

commit 5636d2f842c7bd7800002868ead3d6b809d385a0 upstream.

The GART table BO has to be moved out of VRAM for suspend/resume. Any
updates to the GART table during that time were silently dropped without
this change. This caused GPU lockups on resume in some cases, see the bug
reports referenced below.

This might also make GPU reset more robust in some cases, as we no longer
rely on the GART table in VRAM being preserved across the GPU
lockup/reset.

v2: Add logic to radeon_gart_table_vram_pin directly instead of
    reinstating radeon_gart_restore
v3: Move code after assignment of rdev->gart.table_addr so that the GART
    TLB flush can work as intended, add code comment explaining why we're
    doing this

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Showing 1 changed file with 13 additions and 0 deletions Side-by-side Diff

drivers/gpu/drm/radeon/radeon_gart.c
... ... @@ -165,6 +165,19 @@
165 165 radeon_bo_unpin(rdev->gart.robj);
166 166 radeon_bo_unreserve(rdev->gart.robj);
167 167 rdev->gart.table_addr = gpu_addr;
  168 +
  169 + if (!r) {
  170 + int i;
  171 +
  172 + /* We might have dropped some GART table updates while it wasn't
  173 + * mapped, restore all entries
  174 + */
  175 + for (i = 0; i < rdev->gart.num_gpu_pages; i++)
  176 + radeon_gart_set_page(rdev, i, rdev->gart.pages_entry[i]);
  177 + mb();
  178 + radeon_gart_tlb_flush(rdev);
  179 + }
  180 +
168 181 return r;
169 182 }
170 183