On 22.01.2015 18:08, Christian König wrote: > Am 22.01.2015 um 08:31 schrieb Michel Dänzer: >> On 21.01.2015 18:22, Christian König wrote: >>> Am 21.01.2015 um 09:36 schrieb Michel Dänzer: >>>> From: Michel Dänzer <michel.daenzer@xxxxxxx> >>>> >>>> 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. >>>> >>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85204 >>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86267 >>>> Cc: stable@xxxxxxxxxxxxxxx >>>> Signed-off-by: Michel Dänzer <michel.daenzer@xxxxxxx> >>> Can we make that directly part of radeon_gart_table_vram_pin? Doesn't >>> seem to make sense to always need to call both functions. >> Good point, fixed in v2. >> >> >>> Additional to that couldn't we just stop mapping/unmapping the BO in >>> radeon_gart_table_vram_pin? As far as I know CPU mapped BOs can still >>> move around. >> You're probably thinking of userspace mappings. I think the kernel >> mapping would continue pointing to the same area of VRAM even while the >> BO is evicted from VRAM or pinned back to another area of VRAM. > > > Oh really? I was always under the impression that we only need to wait > for moves to complete and the kernel page tables would point to the new > location after that automatically. > > If that's not the case we might have a problem in the UVD code as well. AFAIK it's not the case. If you can't confirm it either way from looking at the TTM code, maybe you can hack up a test to verify it? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel