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

Lauri Kasanen cand at gmx.com
Sat Mar 1 01:15:00 PST 2014


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

So sending this fix to stable is safe, as they all use bottom-up.

- Lauri


More information about the dri-devel mailing list