kernel.git/drivers/gpu/drm/i915/intel_ringbuffer.c, branch linux-3.2.y

drm/i915: Add intel_ring_cachline_align()

2014-04-01T23:58:51Z

commit 753b1ad4a281b0663329409d410243e91825c323 upstream. intel_ring_cachline_align() emits MI_NOOPs until the ring tail is aligned to a cacheline boundary. Cc: Bjoern C Cc: Alexandru DAMIAN Cc: Enrico Tagliavini Suggested-by: Chris Wilson Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

drm/i915: Invalidate TLBs for the rings after a reset

2013-09-10T00:57:25Z

commit 884020bf3d2a3787a1cc6df902e98e0eec60330b upstream. After any "soft gfx reset" we must manually invalidate the TLBs associated with each ring. Empirically, it seems that a suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is that the hardware would fail to note the new address for its status page, and so it would continue to write the shadow registers and breadcrumbs into the old physical address (now used by something completely different, scary). Whereas the driver would read the new status page and never see any progress, it would appear that the GPU hung immediately upon resume. Based on a patch by naresh kumar kachhi Reported-by: Thiago Macieira Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64725 Signed-off-by: Chris Wilson Tested-by: Thiago Macieira Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: add definition of RING_INSTPM() from commit c1cd90ed7957 'drm/i915: collect more per ring error state'] Signed-off-by: Ben Hutchings

Revert "drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits"

2013-06-29T03:06:33Z

This reverts commit 393143615d9f2f581d87387268dc11b95adc339c, which was commit f05bb0c7b624252a5e768287e340e8e45df96e42 upstream. This has been found to cause GPU hangs when backported to 3.2, though not in mainline. References: http://bugs.launchpad.net/bugs/1140716 Cc: Steve Conklin Cc: Stefan Bader Cc: Bradd Figg Cc: Luis Henriques Signed-off-by: Ben Hutchings

drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits

2013-02-06T04:33:46Z

commit f05bb0c7b624252a5e768287e340e8e45df96e42 upstream. On SNB, if bit 13 of GFX_MODE, Flush TLB Invalidate Mode, is not set to 1, the hardware can not program the scanline values. Those scanline values then control when the signal is sent from the display engine to the render ring for MI_WAIT_FOR_EVENTs. Note setting this bit means that TLB invalidations must be performed explicitly through the appropriate bits being set in PIPE_CONTROL. References: https://bugzilla.kernel.org/show_bug.cgi?id=52311 Signed-off-by: Chris Wilson Reviewed-by: Ben Widawsky Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: s/_MASKED_BIT/GFX_MODE/] Signed-off-by: Ben Hutchings

drm/i915: Disable AsyncFlip performance optimisations

2013-02-06T04:33:45Z

commit 1c8c38c588ea91f8deeae21284840459d1bb58e3 upstream. This is a required workarounds for all products, especially on gen6+ where it causes the command streamer to fail to parse instructions following a WAIT_FOR_EVENT. We use WAIT_FOR_EVENT for synchronising between the GPU and the display engines, and so this bit being unset may cause hangs. References: https://bugzilla.kernel.org/show_bug.cgi?id=52311 Signed-off-by: Chris Wilson Reviewed-by: Imre Deak Signed-off-by: Daniel Vetter [bwh: Backported to 3.2: - Adjust context - s/_MASKED_BIT/GFX_MODE/] Signed-off-by: Ben Hutchings

drm/i915: Remove the MI_FLUSH_ENABLE setting.

2013-02-06T04:33:45Z

commit 8d79c3490aecfe6e51f0ba6f9780746fb1434954 upstream. We have always been using the wrong bit -- it's bit 12. However, the bit also doesn't do anything -- hardware has always accepted the MI_FLUSH command even when it was specced not to. Given that there is only one MI_FLUSH emitted in all of the driver stack on gen6+ (in i965_video.c of the 2d driver, and it should be using other code to do its flush instead), just remove the MI_FLUSH enable instead of trying to fix it. Signed-off-by: Eric Anholt Reviewed-by: Kenneth Graunke Reviewed-by: Ben Widawsky Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings

drm/i915: correctly order the ring init sequence

2012-08-19T17:15:34Z

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: Ben Hutchings

drm/i915: Add wait_for in init_ring_common

2012-08-19T17:15:34Z

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: Ben Hutchings

drm/i915: fixup seqno allocation logic for lazy_request

2012-08-19T17:15:27Z

commit 53d227f282eb9fa4c7cdbfd691fa372b7ca8c4c3 upstream. Currently we reserve seqnos only when we emit the request to the ring (by bumping dev_priv->next_seqno), but start using it much earlier for ring->oustanding_lazy_request. When 2 threads compete for the gpu and run on two different rings (e.g. ddx on blitter vs. compositor) hilarity ensued, especially when we get constantly interrupted while reserving buffers. Breakage seems to have been introduced in commit 6f392d548658a17600da7faaf8a5df25ee5f01f6 Author: Chris Wilson Date: Sat Aug 7 11:01:22 2010 +0100 drm/i915: Use a common seqno for all rings. This patch fixes up the seqno reservation logic by moving it into i915_gem_next_request_seqno. The ring->add_request functions now superflously still return the new seqno through a pointer, that will be refactored in the next patch. Note that with this change we now unconditionally allocate a seqno, even when ->add_request might fail because the rings are full and the gpu died. But this does not open up a new can of worms because we can already leave behind an outstanding_request_seqno if e.g. the caller gets interrupted with a signal while stalling for the gpu in the eviciton paths. And with the bugfix we only ever have one seqno allocated per ring (and only that ring), so there are no ordering issues with multiple outstanding seqnos on the same ring. v2: Keep i915_gem_get_seqno (but move it to i915_gem.c) to make it clear that we only have one seqno counter for all rings. Suggested by Chris Wilson. v3: As suggested by Chris Wilson use i915_gem_next_request_seqno instead of ring->oustanding_lazy_request to make the follow-up refactoring more clearly correct. Also improve the commit message with issues discussed on irc. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45181 Tested-by: Nicolas Kalkhof nkalkhof()at()web.de Reviewed-by: Chris Wilson Signed-Off-by: Daniel Vetter Signed-off-by: Ben Hutchings

drm/i915: Remove use of the autoreported ringbuffer HEAD position

2012-07-04T04:44:11Z

This is a revert of 6aa56062eaba67adfb247cded244fd877329588d. This was originally introduced to workaround reads of the ringbuffer registers returning 0 on SandyBridge causing hangs due to ringbuffer overflow. The root cause here was reads through the GT powerwell require the forcewake dance, something we only learnt of later. Now it appears that reading the reported head position from the HWS is returning garbage, leading once again to hangs. For example, on q35 the autoreported head reports: [ 217.975608] head now 00010000, actual 00010000 [ 436.725613] head now 00200000, actual 00200000 [ 462.956033] head now 00210000, actual 00210010 [ 485.501409] head now 00400000, actual 00400020 [ 508.064280] head now 00410000, actual 00410000 [ 530.576078] head now 00600000, actual 00600020 [ 553.273489] head now 00610000, actual 00610018 which appears reasonably sane. In contrast, if we look at snb: [ 141.970680] head now 00e10000, actual 00008238 [ 141.974062] head now 02734000, actual 000083c8 [ 141.974425] head now 00e10000, actual 00008488 [ 141.980374] head now 032b5000, actual 000088b8 [ 141.980885] head now 03271000, actual 00008950 [ 142.040628] head now 02101000, actual 00008b40 [ 142.180173] head now 02734000, actual 00009050 [ 142.181090] head now 00000000, actual 00000ae0 [ 142.183737] head now 02734000, actual 00009050 In addition, the automatic reporting of the head position is scheduled to be defeatured in the future. It has no more utility, remove it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45492 Reviewed-by: Daniel Vetter Tested-by: Eric Anholt Signed-off-by: Chris Wilson Signed-off-by: Jesse Barnes (cherry picked from commit 5d031e5b633d910f35e6e0abce94d9d842390006) Signed-off-by: Timo Aaltonen Signed-off-by: Ben Hutchings