From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH] drm/i915: don't clflush gem objects in
 stolen memory
Date: Wed, 13 Feb 2013 22:11:49 +0100
Message-ID: <20130213211148.GR5813@phenom.ffwll.local>
References: <1360785365-5628-1-git-send-email-imre.deak@intel.com>
	<20130213203958.GA32075@cantiga.alporthouse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com
	[209.85.215.178])
	by gabe.freedesktop.org (Postfix) with ESMTP id 9D91EE5EBB
	for <intel-gfx@lists.freedesktop.org>;
	Wed, 13 Feb 2013 13:09:34 -0800 (PST)
Received: by mail-ea0-f178.google.com with SMTP id a14so714638eaa.37
	for <intel-gfx@lists.freedesktop.org>;
	Wed, 13 Feb 2013 13:09:33 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <20130213203958.GA32075@cantiga.alporthouse.com>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Chris Wilson <chris@chris-wilson.co.uk>, Imre Deak <imre.deak@intel.com>, intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Wed, Feb 13, 2013 at 08:39:58PM +0000, Chris Wilson wrote:
> On Wed, Feb 13, 2013 at 09:56:05PM +0200, Imre Deak wrote:
> > As explained by Chris Wilson gem objects in stolen memory are always
> > coherent with the GPU so we don't need to ever flush the CPU caches for
> > these.
> > 
> > This fixes a breakage - at least with the compact sg patches applied -
> > during the resume/restore gtt mappings path, when we tried to clflush an
> > FB object in stolen memory, but since stolen objects don't have backing
> > pages we passed an invalid page pointer to drm_clflush_page().
> > 
> > Signed-off-by: Imre Deak <imre.deak@intel.com>
> 
> To the best of my knowledge, this is correct:
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> Though the stolen framework landed in 3.8, tough call as to whether this
> should be in 3.8 as well given the backported clflush fix... I guess we
> are simply too late, so drm-intel-next +
> Cc: stable@vger.kernel.org
> 
> Imre do you mind digging up the sha of both the introduction of stolen
> and the clflush of unbounded upon resume?

Stolen allocations seem to be only in 3.9-next, so no cc: stable. Queued
up, thanks for the patch an review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch