From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lauri Kasanen <cand@gmx.com>
Subject: Re: [PATCH] drm/radeon: TTM must be init with cpu-visible VRAM, v2
Date: Sat, 1 Mar 2014 11:15:00 +0200
Message-ID: <20140301111500.cd313296.cand@gmx.com>
References: <20140228205023.9677a7f9.cand@gmx.com>
	<5310E9EA.8020606@vodafone.de>
	<CAPM=9tw88uH6SY1=PzG23=F222mTTVNbxXJc+TKjWFQSkdze4w@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Return-path: <dri-devel-bounces@lists.freedesktop.org>
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22])
	by gabe.freedesktop.org (Postfix) with ESMTP id 8AE7AFA948
	for <dri-devel@lists.freedesktop.org>;
	Sat,  1 Mar 2014 01:14:05 -0800 (PST)
Received: from Valinor ([84.248.177.169]) by mail.gmx.com (mrgmx002) with
	ESMTPA (Nemesis) id 0M7pI0-1X61Lo03FY-00vRin for
	<dri-devel@lists.freedesktop.org>; Sat, 01 Mar 2014 10:14:04 +0100
In-Reply-To: <CAPM=9tw88uH6SY1=PzG23=F222mTTVNbxXJc+TKjWFQSkdze4w@mail.gmail.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Sender: dri-devel-bounces@lists.freedesktop.org
Errors-To: dri-devel-bounces@lists.freedesktop.org
To: Dave Airlie <airlied@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>
List-Id: dri-devel@lists.freedesktop.org

On Sat, 1 Mar 2014 06:47:41 +1000
Dave Airlie <airlied@gmail.com> wrote:

> On Sat, Mar 1, 2014 at 5:56 AM, Christian K=F6nig <deathsimple@vodafone.d=
e> 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=F6nig <christian.koenig@amd.com>
>>
>> And I suggest to add "Cc: stable@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