From: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> commit 3eef8918ff440837f6af791942d8dd07e1a268ee upstream By correctly describing the rinbuffers as being in the GTT domain, it appears that we are more careful with the management of the CPU cache upon resume and so prevent some coherency issue when submitting commands to the GPU later. A secondary effect is that the debug logs are then consistent with the actual usage (i.e. they no longer describe the ringbuffers as being in the CPU write domain when we are accessing them through an wc iomapping.) Reported-and-tested-by: Daniel Gnoutcheff <daniel@xxxxxxxxxxxxxxx> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41092 Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Cc: stable@xxxxxxxxxxxxxxx Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> Signed-off-by: Egbert Eich <eich@xxxxxxx> [bwh: Backported to 3.0: adjusted context] --- This upstream commit is required (together with f01db988ef6f6c70a6cc36ee71e4a98a68901229) to fix the issue described in https://bugs.freedesktop.org/show_bug.cgi?id=54575 which on some Intel Gen4 chipsets occurs intermittently or even permanently. These two commits are part of the stable 3.2 and 3.4 branch but are missing from the 3.0 branch. This patch has been adjusted slightly to apply to that branch. drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 38ae0ec..ee21e9c 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -843,6 +843,10 @@ int intel_init_ring_buffer(struct drm_device *dev, if (ret) goto err_unref; + ret = i915_gem_object_set_to_gtt_domain(obj, true); + if (ret) + goto err_unpin; + ring->map.size = ring->size; ring->map.offset = dev->agp->base + obj->gtt_offset; ring->map.type = 0; -- 1.7.6.1 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html