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 at intel.com> > > To the best of my knowledge, this is correct: > Reviewed-by: Chris Wilson <chris at 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 at 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
