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

drm/i915: Write RING_TAIL once per-request

2013-09-10T13:35:58+00:00

Ignoring the legacy DRI1 code, and a couple of special cases (to be discussed later), all access to the ring is mediated through requests. The first write to a ring will grab a seqno and mark the ring as having an outstanding_lazy_request. Either through explicitly adding a request after an execbuffer or through an implicit wait (either by the CPU or by a semaphore), that sequence of writes will be terminated with a request. So we can ellide all the intervening writes to the tail register and send the entire command stream to the GPU at once. This will reduce the number of *serialising* writes to the tail register by a factor or 3-5 times (depending upon architecture and number of workarounds, context switches, etc involved). This becomes even more noticeable when the register write is overloaded with a number of debugging tools. The astute reader will wonder if it is then possible to overflow the ring with a single command. It is not. When we start a command sequence to the ring, we check for available space and issue a wait in case we have not. The ring wait will in this case be forced to flush the outstanding register write and then poll the ACTHD for sufficient space to continue. The exception to the rule where everything is inside a request are a few initialisation cases where we may want to write GPU commands via the CS before userspace wakes up and page flips. Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter

drm/i915: include hangcheck action and score in error_state

2013-09-06T15:56:17+00:00

Score and action reveals what all the rings were doing and why hang was declared. Add idle state so that we can distinguish between waiting and idle ring. v2: - add idle as a hangcheck action - consensed hangcheck status to single line (Chris) - mark active explicitly when we are making progress (Chris) Reviewed-by: Chris Wilson Signed-off-by: Mika Kuoppala Signed-off-by: Daniel Vetter

drm/i915; Preallocate the lazy request

2013-09-05T10:03:53+00:00

It is possible for us to be forced to perform an allocation for the lazy request whilst running the shrinker. This allocation may fail, leaving us unable to reclaim any memory leading to premature OOM. A neat solution to the problem is to preallocate the request at the same time as acquiring the seqno for the ring transaction. This means that we can report ENOMEM prior to touching the rings. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala Signed-off-by: Daniel Vetter

drm/i915: Rename ring->outstanding_lazy_request

2013-09-05T10:03:12+00:00

Prior to preallocating an request for lazy emission, rename the existing field to make way (and differentiate the seqno from the request struct). Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala Signed-off-by: Daniel Vetter

drm/i915: Embed the ring->private within the struct intel_ring_buffer

2013-09-03T17:17:55+00:00

We now have more devices using ring->private than not, and they all want the same structure. Worse, I would like to use a scratch page from outside of intel_ringbuffer.c and so for convenience would like to reuse ring->private. Embed the object into the struct intel_ringbuffer so that we can keep the code clean. Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter

drm/i915: Remove I915_READ_{NOPID, SYNC_0, SYNC_1})()

2013-08-23T12:52:24+00:00

The code directly uses the registers and ring->mmio_base. Signed-off-by: Damien Lespiau Signed-off-by: Daniel Vetter

drm/i915: give more distinctive names to ring hangcheck action enums

2013-08-22T11:31:37+00:00

The short lowercase names are bound to collide. The default warnings don't even warn about shadowing. Signed-off-by: Jani Nikula Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter

drm/i915: unify ring irq refcounts (again)

2013-07-11T12:36:49+00:00

With the simplified locking there's no reason any more to keep the refcounts seperate. v2: Readd the lost comment that ring->irq_refcount is protected by dev_priv->irq_lock. Reviewed-by: Ben Widawsky Signed-off-by: Daniel Vetter

drm/i915: kill dev_priv->rps.lock

2013-07-11T12:36:43+00:00

Now that the rps interrupt locking isn't clearly separated (at elast conceptually) from all the other interrupt locking having a different lock stopped making sense: It protects much more than just the rps workqueue it started out with. But with the addition of VECS the separation started to blurr and resulted in some more complex locking for the ring interrupt refcount. With this we can (again) unifiy the ringbuffer irq refcounts without causing a massive confusion, but that's for the next patch. v2: Explain better why the rps.lock once made sense and why no longer, requested by Ben. Reviewed-by: Ben Widawsky Signed-off-by: Daniel Vetter

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