From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/i915: don't clflush gem objects in stolen memory Date: Wed, 13 Feb 2013 20:39:58 +0000 Message-ID: <20130213203958.GA32075@cantiga.alporthouse.com> References: <1360785365-5628-1-git-send-email-imre.deak@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by gabe.freedesktop.org (Postfix) with ESMTP id 08B45E5C56 for ; Wed, 13 Feb 2013 12:40:05 -0800 (PST) Content-Disposition: inline In-Reply-To: <1360785365-5628-1-git-send-email-imre.deak@intel.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: Imre Deak Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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? -Chris -- Chris Wilson, Intel Open Source Technology Centre