[PATCH] drm/radeon: TTM must be init with cpu-visible VRAM, v2

[Alex Deucher]

On Sat, Mar 1, 2014 at 5:29 AM, Christian König <deathsimple at vodafone.de> wrote:
> Am 01.03.2014 10:15, schrieb Lauri Kasanen:
>
>> On Sat, 1 Mar 2014 06:47:41 +1000
>> Dave Airlie <airlied at gmail.com> wrote:
>>
>>> On Sat, Mar 1, 2014 at 5:56 AM, Christian König <deathsimple at vodafone.de>
>>> wrote:
>>>>
>>>> Am 28.02.2014 19:50, schrieb Lauri Kasanen:
>>>>
>>>>> Without this, a bo may get created in the cpu-inaccessible vram.
>>>>> Before the CP engines get setup, all copies are done via cpu memcpy.
>>>>>
>>>>> This means that the cpu tries to read from inaccessible memory, fails,
>>>>> and the radeon module proceeds to disable acceleration.
>>>>>
>>>>> Doing this has no downsides, as the real VRAM size gets set as soon as
>>>>> the
>>>>> CP engines get init.
>>>>>
>>>>> This is a candidate for 3.14 fixes.
>>>>>
>>>>> v2: Add comment on why the function is used
>>>>
>>>> Reviewed-by: Christian König <christian.koenig at amd.com>
>>>>
>>>> And I suggest to add "Cc: stable at vger.kernel.org" as well.
>>>
>>> Won't this create objects that are stuck in the middle of VRAM with
>>> the new top down approach?
>>>
>>> then when we go to use all the VRAM they'll be pinned in the middle?
>>
>> Yes, the initial pins would act like that with the top-down code. But
>> the top-down logic is 3.15 material and still WIP.
>>
>> Depending on their constraints, I think I'll either add a new flag, or
>> turn them into FIXED allocations - do they need to be at exact position
>> foo or only at the beginning. (Christian?)
>
>
> AFAIK the stolen VGA memory must be at the very beginning.
>
> The UVD firmware memory block needs to be in the first 256MB, allocated and
> initialized before all other blocks are started and after used once can't be
> moved around any more.
>
> I'm not sure about this but we probably have more allocations that assume
> they end up at the beginning of the address space (GART?).
>

Gart (vmid 0) needs to be in the visible area since we use the CPU to update it.

Alex

> Christian.
>
>
>>
>> So sending this fix to stable is safe, as they all use bottom-up.
>>
>> - Lauri
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel