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
