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:28:40 +0900	[thread overview]
Message-ID: <54C0C2C8.80605@daenzer.net> (raw)
In-Reply-To: <54C0BDFD.2020302@vodafone.de>

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?

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