[Help][RS780E][mipsel]Screen corruption sometimes

Michel Dänzer michel at daenzer.net
Tue Sep 6 09:57:21 PDT 2011

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?


> 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

More information about the xorg-driver-ati mailing list