On Wed, Feb 13, 2013 at 10:55:24PM +0200, Imre Deak wrote:
> 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 +
>
> drm/i915: Allocate fbcon f
On Wed, Feb 13, 2013 at 08:39:58PM +, 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 fi
On Wed, 2013-02-13 at 20:39 +, 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 b
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 t
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 obj
