From mboxrd@z Thu Jan 1 00:00:00 1970 From: Imre Deak Subject: Re: [PATCH] drm/i915: don't clflush gem objects in stolen memory Date: Wed, 13 Feb 2013 22:55:24 +0200 Message-ID: <1360788924.4200.1.camel@ideak-mobl> 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: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id 94295E5C56 for ; Wed, 13 Feb 2013 12:55:27 -0800 (PST) In-Reply-To: <20130213203958.GA32075@cantiga.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Wed, 2013-02-13 at 20:39 +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 > > To the best of my knowledge, this is correct: > Reviewed-by: Chris Wilson > > 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? Since afaics this problem relates only to _FBs_ in stolen memory the first one is: commit 0ffb0ff283cca16f72caf29c44496d83b0c291fb Author: Chris Wilson Date: Thu Nov 15 11:32:27 2012 +0000 drm/i915: Allocate fbcon from stolen memory and the second: commit a8e93126a6f10d0a14ba8407ec112b1b3a5e2e97 Author: Chris Wilson Date: Wed Dec 8 14:28:54 2010 +0000 drm/i915/gtt: Clear the cachelines upon resume Required for my pineview system to not barf after resuming. Signed-off-by: Chris Wilson --Imre