We really need a macro to test whether a given connector has a panel
attached rather than sprinkling HAS_PCH_SPLIT/IS_eDP/has_edp_encoder
etc all over. In the meantime, fix the bug...
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: tidy up the duplicity in the conditionals]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Make them match the others and add BPP definitions.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Our usage of kmap() cannot return NULL here, so remove the unnecessary
error handling.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The GPU records whether it is currently waiting for a completion of a
WAIT_FOR_EVENT in the RB_WAIT bit in the ringbuffer control registers.
On third generation chipsets and later, a write of 1 to this bit breaks
the hang and returns the GPU to arbitration, i.e. the GPU should
continue executing the reminder of the batchbuffer and return to normal
operations.

By adding this to hangcheck we can avoid a full GPU reset under these
conditions.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If we disable the pipe and the GPU is currently waiting on a scanline
WAIT_FOR_EVENT, the GPU will hang. Fortunately, there is a magic bit
which we can write on i915+ to break this wait after disabling the
pipe.

References:

  Bug 29252 - [Arrandale] Hung WAIT_FOR_EVENT when running rss-glx-skyrocket
  https://bugs.freedesktop.org/show_bug.cgi?id=29252

  Bug 28964 - [i965gm] GPU infinite MI_WAIT_FOR_EVENT while watching video in Totem
  https://bugs.freedesktop.org/show_bug.cgi?id=28964

and many others.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>

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

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

Hopefully this is a contributing factor to the spurious TV detection
repoted by Ivan Bulatovic and others.

References:

  Bug 16871 - "TV1 connected" with no tv
  https://bugzilla.kernel.org/show_bug.cgi?id=16871Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-by: NIvan Bulatovic <combuster@gmx.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>

There were two instances of code to control the panel backlight and
neither handled the complete set of device variations.

Fixes:

  Bug 29716 - [GM965] Regression: Backlight resets to minimum when changing resolution
  https://bugs.freedesktop.org/show_bug.cgi?id=29716

And a bug on one of my PineView boxes which overflowed the backlight
value.

Incorporates part of a similar patch by Matthew Garrett that exposes a
native Intel backlight controller.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We do it whilst configuring dev->mode_config, so remove the out-of-place
earlier initialisation.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

This spinlock only served debugging purposes in a time when we could not
be sure of the mutex ever being released upon a GPU hang. As we now
should be able rely on hangcheck to do the job for us (and that error
reporting should not itself require the struct mutex) we can kill the
incomplete attempt at protection.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We have no idea why we request a SyncFlush via INSTPM at that point in
time -- we certainly never check for its completion...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Alexander reported that the compilation of intel_overlay.c was failing
due to an inclusion that was only valid with CONFIG_DEBUG_FS. As the
whole error reporting is only useful with debugfs enabled, remove all
the redundant error state collection code when compiling without
CONFIG_DEBUG_FS.
Reported-by: NAlexander Lam <lambchop468@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Slightly easier to follow than the state machine and now possible as the
control structure is opaque and hw_wedged is no longer interferred with.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

During DPMS we currently do not want the overlay code to be
interruptible, so pass that information down and only take the
uninterrruptible paths.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On i830, there exists a bug where an overlay on pipe B requires the mode
clock on pipe A in order to activate. So workaround this by activating
pipe A when trying to enable the overlay on pipe B.

References:

  [Bug 29007] GPU hang on video playback with overlay
  https://bugs.freedesktop.org/show_bug.cgi?id=29007Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

By allocating the request prior to writing to the ringbuffer, we can
abort the operation without leaving the GPU in an inconsistent state.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Inline the call to wait_flip() and simplify the resulting code.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can program the h/w to first wait on the flip and then switch off
without relying on s/w intervention. This removes the need for a double
step switch off, bringing much rejoicing.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The scoping of the validity of the mapping is thus clarified.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

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

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

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

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

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

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

The only time where an atomic mapping is required is during
error-capture and there we cannot use the default slot, but need to
specifically use one of the IRQ slots. So separate out the two
conditions and use the atomic mapping only when appropriate.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

Just makes sure that writes are not being aliased by the CPU cache and
do make it out to main memory.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=24977
Cc: stable@kernel.org

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

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

... take advantage of the new implicit request issuing of
i915_wait_request.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

One caller (for the pageflip support) wants a purely pipelined flush.
Distinguish this case by a new parameter. This will also be useful
later on for pipelined fencing.

v2: Simplify the code by depending upon the implicit request emitting
of i915_wait_request.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
[ickle: And drop the non-interruptible support in the process.]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

By moving one i915_add_request we can solely depend on the new
auto-seqno-numbering behaviour.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

i915_gem_object_move_to_active can handle zero seqno for us now.
And not emitting a request is not fatal here - we'll try to emit
a new one if we have to wait for some rendering to complete.

In case this assumption ever gets accidentally broken, there's already
a BUG_ON to catch it in i915_do_wait_request.

So just silently ignore ENOMEM here instead of screwing up the whole
drm.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... instead of threading flush_domains through the execbuf code to
i915_add_request.

With this change 2 small cleanups are possible (likewise the majority
of the patch):

- The flush_domains parameter of i915_add_request is always 0. Drop it
  and the corresponding logic.
- Ditto for the seqno param of i915_gem_process_flushing_list.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>