[PATCH] drm/radeon: fix TOPDOWN handling for bo_create

[Michel Dänzer]

On 12.03.2015 06:14, Alex Deucher wrote:
> On Wed, Mar 11, 2015 at 4:51 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
>> On Wed, Mar 11, 2015 at 2:21 PM, Christian König
>> <deathsimple at vodafone.de> wrote:
>>> On 11.03.2015 16:44, Alex Deucher wrote:
>>>>
>>>> radeon_bo_create() calls radeon_ttm_placement_from_domain()
>>>> before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
>>>> uses the ttm bo size to determine when to select top down
>>>> allocation but since the ttm bo is not initialized yet the
>>>> check is always false.
>>>>
>>>> Noticed-by: Oded Gabbay <oded.gabbay at amd.com>
>>>> Signed-off-by: Alex Deucher <alexander.deucher at amd.com>
>>>> Cc: stable at vger.kernel.org
>>>
>>>
>>> And I was already wondering why the heck the BOs always made this ping/pong
>>> in memory after creation.
>>>
>>> Patch is Reviewed-by: Christian König <christian.koenig at amd.com>
>>
>> And fixing that promptly broke VCE due to vram location requirements.
>> Updated patch attached.  Thoughts?
> 
> And one more take to make things a bit more explicit for static kernel
> driver allocations.

struct ttm_place::lpfn is honoured even with TTM_PL_FLAG_TOPDOWN, so
latter should work with RADEON_GEM_CPU_ACCESS. It sounds like the
problem is really that some BOs are expected to be within a certain
range from the beginning of VRAM, but lpfn isn't set accordingly. It
would be better to fix that by setting lpfn directly than indirectly via
RADEON_GEM_CPU_ACCESS.


Anyway, since this isn't the first bug which prevents
TTM_PL_FLAG_TOPDOWN from working as intended in the radeon driver, I
wonder if its performance impact should be re-evaluated. Lauri?


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer