This makes the various rings more consistent by removing the anomalous
handing of the rendering ring execbuffer dispatch.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The pipe control object is allocated by the device for the sole use of the
render ringbuffer. Move this detail from the general code to the render
ring buffer initialisation.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

A glorified s/obj_priv/obj/ with a net reduction of over a 100 lines and
many characters!
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This reverts commit 629e8941.

Before reading ring register, set FORCE_WAKE bit to prevent GT core
power down to low power state, otherwise we may read stale values.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
[ickle: added a udelay which seemed to do the trick on my SNB]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

My Sandybridge only reports 0 for the ring buffer registers, causing it
to hang as soon as we exhaust the available ring. As a workaround, take
advantage of our huge ring buffers and use the auto-reporting mechanism
to update the status page with the HEAD location every 64 KiB.

Cherry-picked from 6aa56062.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31404Tested-by: NZhao Jian <jian.j.zhao@intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The ring buffer registers return 0 whilst idle (for some values of idle)
on early Sandybridge hw. Persevere even when all appears hopeless...
Fortunately the head auto-reporting prevents most hangs.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31370Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

a00b10c3 "Only enforce fence limits inside the GTT" also
added a fenceable/mappable disdinction when binding/pinning buffers.
This only complicates the code with no pratical gain:

- In execbuffer this matters on for g33/pineview, as this is the only
  chip that needs fences and has an unmappable gtt area. But fences
  are only possible in the mappable part of the gtt, so need_fence
  implies need_mappable. And need_mappable is only set independantly
  with relocations which implies (for sane userspace) that the buffer
  is untiled.

- The overlay code is only really used on i8xx, which doesn't have
  unmappable gtt. And it doesn't support tiled buffers, currently.

- For all other buffers it's a bug to pass in a tiled bo.

In short, this disdinction doesn't have any practical gain.

I've also reverted mapping the overlay and context pages as possibly
unmappable. It's not worth being overtly clever here, all the big
gains from unmappable are for execbuf bos.

Also add a comment for a clever optimization that confused me
while reading the original patch by Chris Wilson.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

I presumed that we would be writing to the batch through the GTT having
bound it, so I converted it to use iomem. Even later as I spotted that
we didn't even move the batch to the GTT (now an issue since we default
to uncached memory on SNB) I still didn't realise that using iomem for
kmapped memory was incorrect. Fix it.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

On some stepping of SNB cpu, the first command to be parsed in BLT
command streamer should be MI_BATCHBUFFER_START otherwise the GPU
may hang.

(cherry picked from commit 8d19215b)

Conflicts:

	drivers/gpu/drm/i915/intel_ringbuffer.c
	drivers/gpu/drm/i915/intel_ringbuffer.h
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

On some stepping of SNB cpu, the first command to be parsed in BLT
command streamer should be MI_BATCHBUFFER_START otherwise the GPU
may hang.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
[ickle: rebased for -next]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

My Sandybridge only reports 0 for the ring buffer registers, causing it
to hang as soon as we exhaust the available ring. As a workaround, take
advantage of our huge ring buffers and use the auto-reporting mechanism
to update the status page with the HEAD location every 64 KiB.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

It should be idle on cleanup anyway...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

So long as we adhere to the fence registers rules for alignment and no
overlaps (including with unfenced accesses to linear memory) and account
for the tiled access in our size allocation, we do not have to allocate
the full fenced region for the object. This allows us to fight the bloat
tiling imposed on pre-i965 chipsets and frees up RAM for real use. [Inside
the GTT we still suffer the additional alignment constraints, so it doesn't
magic allow us to render larger scenes without stalls -- we need the
expanded GTT and fence pipelining to overcome those...]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Like before add a parameter mappable (also to gem_object_pin) and
set it depending upon the context. Only bos that are brought into
the gtt due to an execbuffer call can be put into the unmappable
part of the gtt, everything else (especially pinned objects) need
to be put into the mappable part of the gtt.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Preparing the ringbuffer for adding new commands can fail (a timeout
whilst waiting for the GPU to catch up and free some space). So check
for any potential error before overwriting HEAD with new commands, and
propagate that error back to the user where possible.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The ringbuffer keeps a pointer to the parent device, so we can use that
instead of passing around the pointer on the stack.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... to prevent flush processing of an idle (or even absent) ring.

This fixes a regression during suspend from 87acb0a5.
Reported-and-tested-by: NAlexey Fisher <bug-track@fisher-privat.net>
Tested-by: NPeter Clifton <pcjc2@cam.ac.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This should fix the error along the reset path were we tried to clear the
tail register by setting it to 0, but were in fact setting it to the
current value and complaining when it did not reset to 0.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

So remove the redundant bit in the capabilities block and
s/IS_IRONLAKE/IS_GEN5/.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Based on an original patch by Zhenyu Wang, this initializes the BLT ring for
SandyBridge and enables support for user execbuffers.

Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... before someone tries to use it. The code both calls
intel_ring_begin/advance() and open-codes the bookkeeping performed by
those two functions.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In commit 8187a2b7, the number of dwords used in the ringbuffer for
executing the batch buffer was erroneously changed from 2 to 4.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If userspace is submitting so many long running batches that the ring
becomes full, throttle by sleeping for a 1ms before checking for free
space. Simply yielding was causing excessive scheduler overhead whilst
making no progress.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... and check more regularly.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

It's the same code, essentially, so kill all copies safe one unified
version.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

All functions are extremely similar, so fold them into one generic
implementation.

This function isn't used anyway, because there's not yet a bsd ring
error state dumper.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Two macros that use a base address for HWS_PGA were missing, add them.
Also switch the remaining users of *_ACTHD to the ring-base one.
Kill the other ring-specific macros because they're now unused.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[ickle: And silence checkpatch whilst in the vicinity]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This was mixed up in the following patch:

commit a6c45cf0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Sep 17 00:32:17 2010 +0100

    drm/i915: INTEL_INFO->gen supercedes i8xx, i9xx, i965g
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Avoid cause latencies in other clients by not taking the global struct
mutex and moving the per-client request manipulation a local per-client
mutex. For example, this allows a compositor to schedule a page-flip
(through X) whilst an OpenGL application is monopolising the GPU.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Always PAGE_SIZE and only complicates the code.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The compiler happily does that for us.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>