diff options
| author | Imre Deak <imre.deak@intel.com> | 2013-02-13 21:56:05 +0200 |
|---|---|---|
| committer | Daniel Vetter <daniel.vetter@ffwll.ch> | 2013-02-20 00:21:43 +0100 |
| commit | 769ce4643b775496166d09c227b070cc38f9e205 (patch) | |
| tree | 4169bb20e669a36af5c51f80168551aa8da7d669 /drivers/gpu/drm/i915/i915_gem.c | |
| parent | 10d8373064762b21e16e73bc7dfde49d68f4e31f (diff) | |
| download | op-kernel-dev-769ce4643b775496166d09c227b070cc38f9e205.zip op-kernel-dev-769ce4643b775496166d09c227b070cc38f9e205.tar.gz | |
drm/i915: don't clflush gem objects in stolen memory
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>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu/drm/i915/i915_gem.c')
| -rw-r--r-- | drivers/gpu/drm/i915/i915_gem.c | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index d8618f3..a367801 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3021,6 +3021,13 @@ i915_gem_clflush_object(struct drm_i915_gem_object *obj) if (obj->pages == NULL) return; + /* + * Stolen memory is always coherent with the GPU as it is explicitly + * marked as wc by the system, or the system is cache-coherent. + */ + if (obj->stolen) + return; + /* If the GPU is snooping the contents of the CPU cache, * we do not need to manually clear the CPU cache lines. However, * the caches are only snooped when the render cache is |
