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

From: "Michel Dänzer" <michel@daenzer.net>
To: "Christian König" <deathsimple@vodafone.de>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 2/3] drm/radeon: Reinstate radeon_gart_restore for GART table in VRAM
Date: Thu, 22 Jan 2015 18:52:23 +0900	[thread overview]
Message-ID: <54C0C857.2000301@daenzer.net> (raw)
In-Reply-To: <54C0C2C8.80605@daenzer.net>

On 22.01.2015 18:28, Michel Dänzer wrote:
> 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@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@vger.kernel.org
>>>>> Signed-off-by: Michel Dänzer <michel.daenzer@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?

Actually, I think I already tested it a couple of years ago, when I
tried un-pinning the fbdev BO while it's not being scanned out. I could
see fbcon scribbling over other BOs in VRAM when there was console
output. :)

-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel