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

Michel Dänzer michel at daenzer.net
Thu Jan 22 01:28:40 PST 2015


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 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.

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


More information about the dri-devel mailing list