kernel/linux.git/drivers/gpu/drm/i915/intel_ringbuffer.c, branch v3.4.38

drm/i915: Add wait_for in init_ring_common

2013-01-17T16:51:07+00:00

commit f01db988ef6f6c70a6cc36ee71e4a98a68901229 upstream. I have seen a number of "blt ring initialization failed" messages where the ctl or start registers are not the correct value. Upon further inspection, if the code just waited a little bit, it would read the correct value. Adding the wait_for to these reads should eliminate the issue. Signed-off-by: Sean Paul Reviewed-by: Ben Widawsky Signed-off-by: Daniel Vetter Signed-off-by: Julien Cristau Signed-off-by: Greg Kroah-Hartman

drm/i915: hold forcewake around ring hw init

2013-01-17T16:51:07+00:00

commit b7884eb45ec98c0d34c7f49005ae9d4b4b4e38f6 upstream. Empirical evidence suggests that we need to: On at least one ivb machine when running the hangman i-g-t test, the rings don't properly initialize properly - the RING_START registers seems to be stuck at all zeros. Holding forcewake around this register init sequences makes chip reset reliable again. Note that this is not the first such issue: commit f01db988ef6f6c70a6cc36ee71e4a98a68901229 Author: Sean Paul Date: Fri Mar 16 12:43:22 2012 -0400 drm/i915: Add wait_for in init_ring_common added delay loops to make RING_START and RING_CTL initialization reliable on the blt ring at boot-up. So I guess it won't hurt if we do this unconditionally for all force_wake needing gpus. To avoid copy&pasting of the HAS_FORCE_WAKE check I've added a new intel_info bit for that. v2: Fixup missing commas in static struct and properly handling the error case in init_ring_common, both noticed by Jani Nikula. Reported-and-tested-by: Yang Guang Reviewed-by: Eugeni Dodonov Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 Signed-Off-by: Daniel Vetter [bwh: Backported to 3.2: - drop changes to Haswell device information - NEEDS_FORCE_WAKE didn't refer to Valley View anyway] Signed-off-by: Ben Hutchings [jcristau: further context adjustments for 3.4] Signed-off-by: Julien Cristau Signed-off-by: Greg Kroah-Hartman

Revert: drm/i915: correctly order the ring init sequence

2012-10-02T17:30:49+00:00

This reverts commit 57ecc93ce680b1ace1f9e79d588dabe32353202c which really is commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream as it has been reported to cause problems in the 3.4.y kernel series. Reported-by: Herton Ronaldo Krzesinski Cc: Andreas Sturmlechner Cc: Jani Nikula Cc: Yang Guang Cc: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: correctly order the ring init sequence

2012-08-26T22:00:40+00:00

commit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream. We may only start to set up the new register values after having confirmed that the ring is truely off. Otherwise the hw might lose the newly written register values. This is caught later on in the init sequence, when we check whether the register writes have stuck. Reviewed-by: Jani Nikula Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522 Tested-by: Yang Guang Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Mark the ringbuffers as being in the GTT domain

2012-06-17T18:21:29+00:00

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 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41092 Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Reset last_retired_head when resetting ring

2012-06-17T18:21:22+00:00

commit c3b20037926e607b6cdaecbf9d3103e2ca63bc31 upstream. When we reset the ring control registers, including the HEAD and TAIL of the ring, we also need to reset associated state. In this instance, we were failing to reset the cached value of ring->last_retired_head and so upon the first request for more space following a resume would potentially (depending on a narrow race window) believe that the HEAD had advanced much further than reality. This is a regression from: commit a71d8d94525e8fd855c0466fb586ae1cb008f3a2 Author: Chris Wilson Date: Wed Feb 15 11:25:36 2012 +0000 drm/i915: Record the tail at each request and use it to estimate the head Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Do no set Stencil Cache eviction LRA w/a on gen7+

2012-05-07T08:37:56+00:00

I've flagged this while reviewing the first version and Ken Graunke fixed it up in v2, but unfortunately Dave Airlie picked up the wrong version. Cc: Dave Airlie Cc: Kenneth Graunke Cc: stable@kernel.org Signed-Off-by: Daniel Vetter

drm/i915: Set the Stencil Cache eviction policy to non-LRA mode.

2012-04-28T07:05:15+00:00

Clearing bit 5 of CACHE_MODE_0 is necessary to prevent GPU hangs in OpenGL programs such as Google MapsGL, Google Earth, and gzdoom when using separate stencil buffers. Without it, the GPU tries to use the LRA eviction policy, which isn't supported. This was supposed to be off by default, but seems to be on for many machines. This cannot be done in gen6_init_clock_gating with most of the other workaround bits; the render ring needs to exist. Otherwise, the register write gets dropped on the floor (one printk will show it changed, but a second printk immediately following shows the value reverts to the old one). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47535 Cc: stable@vger.kernel.org Cc: Rob Castle Cc: Eric Appleman Cc: aaron667@gmx.net Cc: Keith Packard Signed-off-by: Kenneth Graunke Reviewed-by: Daniel Vetter Acked-by: Daniel Vetter Signed-off-by: Dave Airlie

drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g

2012-04-11T10:14:24+00:00

The 845g shares the errata with i830 whereby executing a command within 2 cachelines of the end of the ringbuffer may cause a GPU hang. Signed-off-by: Chris Wilson Cc: stable@kernel.org Signed-off-by: Daniel Vetter

drm/i915: apply CS reg readback trick against missed IRQ on snb

2012-04-01T10:30:24+00:00

Ben Widawsky reported missed IRQ issues and this patch here helps. We have one other missed IRQ report still left on snb, reported by QA: https://bugs.freedesktop.org/show_bug.cgi?id=46145 This is _not_ a regression due to the forcewake voodoo though, it started showing up before that was applied and has been on-and-off for the past few weeks. According to QA this patch does not help. But the missed IRQ is always from the blt ring (despite running piglit, so also render activity expected), so I'm hopefully that this is an issue with the blt ring itself. Tested-by: Ben Widawsky Signed-Off-by: Daniel Vetter