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

drm/i915: store ring hangcheck action

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

For guilty batchbuffer analysis later on when rings are reset,
store what state the ring was on when hang was declared.
This helps to weed out the waiting rings from the active ones.

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

drm/i915: Don't count semaphore waits towards a stuck ring

2013-06-11T09:49:28+00:00

If we detect a ring is in a valid wait for another, just let it be.
Eventually it will either begin to progress again, or the entire system
will come grinding to a halt and then hangcheck will fire as soon as the
deadlock is detected.

This error was foretold by Ben in
commit 05407ff889ceebe383aa5907219f86582ef96b72
Author: Mika Kuoppala 
Date:   Thu May 30 09:04:29 2013 +0300

    drm/i915: detect hang using per ring hangcheck_score

"If ring B is waiting on ring A via semaphore, and ring A is making
progress, albeit slowly - the hangcheck will fire. The check will
determine that A is moving, however ring B will appear hung because
the ACTHD doesn't move. I honestly can't say if that's actually a
realistic problem to hit it probably implies the timeout value is too
low."

v2: Make sure we don't even incur the KICK cost whilst waiting.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65394
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Ben Widawsky 
Reviewed-by: Mika Kuoppala 
Signed-off-by: Daniel Vetter

drm/i915: Track when we dirty the scanout with render commands

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

This is required for tracking render damage for use with FBC and will be
used in subsequent patches.

Signed-off-by: Chris Wilson 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Daniel Vetter

drm/i915: detect hang using per ring hangcheck_score

2013-06-03T08:58:21+00:00

Keep track of ring seqno progress and if there are no
progress detected, declare hang. Use actual head (acthd)
to distinguish between ring stuck and batchbuffer looping
situation. Stuck ring will be kicked to trigger progress.

This commit adds a hard limit for batchbuffer completion time.
If batchbuffer completion time is more than 4.5 seconds,
the gpu will be declared hung.

Review comment from Ben which nicely clarifies the semantic change:

"Maybe I'm just stating the functional changes of the patch, but in case
they were unintended here is what I see as potential issues:

1. "If ring B is waiting on ring A via semaphore, and ring A is making
   progress, albeit slowly - the hangcheck will fire. The check will
   determine that A is moving, however ring B will appear hung because
   the ACTHD doesn't move. I honestly can't say if that's actually a
   realistic problem to hit it probably implies the timeout value is too
   low.

2. "There's also another corner case on the kick. If the seqno = 2
   (though not stuck), and on the 3rd hangcheck, the ring is stuck, and
   we try to kick it... we don't actually try to find out if the kick
   helped"

v2: use atchd to detect stuck ring from loop (Ben Widawsky)

v3: Use acthd to check when ring needs kicking.
Declare hang on third time in order to give time for
kick_ring to take effect.

v4: Update commit msg

Signed-off-by: Mika Kuoppala 
Reviewed-by: Ben Widawsky 
[danvet: Paste in Ben's review comment.]
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: 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

drm/i915: Vebox ringbuffer init

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

v2: Add set_seqno which didn't exist before rebase (Haihao)

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

drm/i915: Introduce VECS: the 4th ring

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

The video enhancement command streamer is a new ring on HSW which does
what it sounds like it does. This patch provides the most minimal
inception of the ring.

In order to support a new ring, we need to bump the number. The patch
may look trivial to the untrained eye, but bumping the number of rings
is a bit scary. As such the patch is not terribly useful by itself, but
a pretty nice place to find issues during a bisection.

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

drm/i915: Semaphore MBOX update generalization

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

This replaces the existing MBOX update code with a more generalized
calculation for emitting mbox updates. We also create a sentinel for
doing the updates so we can more abstractly deal with the rings.

When doing MBOX updates the code must be aware of the /other/ rings.
Until now the platforms which supported semaphores had a fixed number of
rings and so it made sense for the code to be very specialized
(hardcoded).

The patch does contain a functional change, but should have no
behavioral changes.

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

drm/i915: Comments for semaphore clarification

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

Semaphores are tied very closely to the rings in the GPU. Trivial patch
adds comments to the existing code so that when we add new rings we can
include comments there as well. It also helps distinguish the ring to
semaphore mailbox interactions by using the ringname in the semaphore
data structures.

This patch should have no functional impact.

v2: The English parts (as opposed to register names) of the comments
were reversed. (Damien)

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