[PATCH 2/3] drm/radeon: Reinstate radeon_gart_restore for GART table in VRAM

Christian König deathsimple at vodafone.de
Thu Jan 22 01:08:13 PST 2015


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 at amd.com>
>>>
>>> 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 at vger.kernel.org
>>> Signed-off-by: Michel Dänzer <michel.daenzer at amd.com>
>> 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.

Regards,
Christian.


More information about the dri-devel mailing list