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

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

2013-08-18T17:37:41+00:00

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 
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter

drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a

2013-07-09T14:31:49+00:00

It's not a good idea to also run the pipe_control cleanup.

This regression has been introduced whith the original cs tlb w/a in

commit b45305fce5bb1abec263fcff9d81ebecd6306ede
Author: Daniel Vetter 
Date:   Mon Dec 17 16:21:27 2012 +0100

    drm/i915: Implement workaround for broken CS tlb on i830/845

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64610
Cc: Chris Wilson 
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter

drm/i915: reinit status page registers after gpu reset

2013-07-04T09:36:36+00:00

This fixes gpu reset on my gm45 - without this patch the bsd thing is
forever stuck since the seqno updates never reach the status page.

Tbh I have no idea how this ever worked without rewriting the hws
registers after a gpu reset.

To satisfy my OCD also give the functions a bit more consistent names:
- Use status_page everywhere, also for the physical addressed one.
- Use init for the allocation part and setup for the register setup
  part consistently.

Long term I'd really like to share the hw init parts completely
between gpu reset, resume and driver load, i.e. to call
i915_gem_init_hw instead of the individual pieces we might need.

v2: Add the missing paragraph to the commit message about what bug
exactly this patch here fixes.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65495
Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
Tested-by: lu hua 
Signed-off-by: Daniel Vetter

drm/i915: change i915_add_request to macro

2013-06-13T15:42:15+00:00

Only execbuffer needed all the parameters on i915_add_request().
By putting __i915_add_request behind macro, all current callsites
become cleaner. Following patch will introduce a new parameter
for __i915_add_request. With this patch, only the relevant callsite
will reflect the change making commit smaller and easier to understand.

v2: _i915_add_request as function name (Chris Wilson)

v3: change name __i915_add_request and fix ordering of params (Ben Widawsky)

Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
Acked-by: Ben Widawsky 
Signed-off-by: Daniel Vetter

drm/i915: Initialize ring->hangcheck upon ring init

2013-06-11T09:40:58+00:00

When we reset and restart a ring, we also want to clear any existing
hangcheck.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
Signed-off-by: Daniel Vetter

drm/i915: WA: FBC Render Nuke.

2013-06-07T15:56:55+00:00

WaFbcNukeOn3DBlt for IVB, HSW.

According BSPec: "Workaround: Do not enable Render Command Streamer tracking for FBC.
Instead insert a LRI to address 0x50380 with data 0x00000004 after the PIPE_CONTROL that
follows each render submission."

v2: Chris noticed that flush_domains check was missing here and also suggested to do
    LRI only when fbc is enabled. To avoid do a I915_READ on every flush lets use the
    module parameter check.

v3: Adding Wa name as Damien suggested.

v4: Ville noticed VLV doesn't support fbc at all and comment came wrong from spec.

v5: Ville noticed than on blt a Cache Clean LRI should be used instead the Nuke one.

v6: Check for flush domain on blt (by Ville).
    Check for scanout dirty (by Chris).

v7: Apply proper fbc_dirty implemented by Chris.

v8: remove unused variables.

Cc: Ville Syrjälä 
Cc: Chris Wilson 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Vetter

drm/i915: Enable vebox interrupts

2013-05-31T18:54:20+00:00

Similar to a patch originally written by:

v2: Reversed the meanings of masked and enabled (Haihao)
Made non-destructive writes in case enable/disabler rps runs first
(Haihao)

v3: Reword error message (Damien)
Modify postinstall to do the right thing based on previous fixup. (Ben)

CC: Xiang, Haihao 
Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
Signed-off-by: Daniel Vetter

drm/i915: vebox interrupt get/put

2013-05-31T18:54:19+00:00

v2: Use the correct lock to protect PM interrupt regs, this was
accidentally lost from earlier (Haihao)
Fix return types (Ben)

Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
Signed-off-by: Daniel Vetter

drm/i915: consolidate interrupt naming scheme

2013-05-31T18:54:18+00:00

The motivation here is we're going to add some new interrupt definitions
and handling outside of the GT interrupts which is all we've managed so
far (with some RPS exceptions). By consolidating the names in the future
we can make thing a bit cleaner as we don't need to define register
names twice, and we can leverage pretty decent overlap in HW registers
since ILK.

To explain briefly what is in the comments: there are two sets of
interrupt masking/enabling registers. At least so far, the definitions
of the two sets overlap. The old code setup distinct names for
interrupts in each set, ie. one for global, and one for ring. This made
things confusing when using the wrong defines in the wrong places.

rebase: Modified VLV bits

v2: Renamed GT_RENDER_MASTER to GT_RENDER_CS_MASTER (Damien)

Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
Signed-off-by: Daniel Vetter

drm/i915: Convert irq_refounct to struct

2013-05-31T18:54:18+00:00

It's overkill on older gens, but it's useful for newer gens.

Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
Signed-off-by: Daniel Vetter