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
