On Mon, 2011-09-05 at 12:47 +0800, Chen Jie wrote: > > Guess it may be related -- we got similar corruption when standby(ACPI S1). > A further debugging shows it is related with invocation of > radeon_bo_evict_vram in function radeon_suspend_kms: > ... > /* evict vram memory */ > radeon_bo_evict_vram(rdev); > /* wait for gpu to finish processing current batch */ > radeon_fence_wait_last(rdev); > > radeon_save_bios_scratch_regs(rdev); > > radeon_pm_suspend(rdev); > radeon_suspend(rdev); > radeon_hpd_fini(rdev); > /* evict remaining vram memory */ > radeon_bo_evict_vram(rdev); > ... > Comment out two invocations of radeon_bo_evict_vram above, no corruption > happen.
... so long as you're lucky and VRAM doesn't lose its contents between suspend and resume, I guess. :) What if you only comment out one of the invocations? Do you get corruption in one case but not the other one? > BTW, some questions: > 1. What does radeon_bo_evict_vram do? Evict bo from VRAM to GTT domain? Yes. > 2. Why invoke radeon_bo_evict_vram twice? My guess would be that during the first invocation, some BOs are still pinned in VRAM, so they can't be evicted. Those are taken care of by the second invocation. > 3. In resume stage, need it restore evicted BOs? Or evicted BOs will > be restored on demand? Mostly the latter, though at least some of the BOs above are probably explicitly pinned to VRAM again on resume. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
