[go: nahoru, domu]

History log of /drivers/gpu/drm/i915/i915_gpu_error.c
Revision Date Author Comments
0a4cd7c8c89a15938d67bdc7be8314d85b9ef4da 22-Aug-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Differentiate between LLC or snooped for the user

Rather than describing an object as either "snooped or LLC", we can do
better as we should know what machine we are running on!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
9075e52face677b87c6bf08d8ea1a960d48d085c 24-Jul-2014 Oscar Mateo <oscar.mateo@intel.com> drm/i915/bdw: Make sure error capture keeps working with Execlists

Since the ringbuffer does not belong per engine anymore, we have to
make sure that we are always recording the correct ringbuffer.

TODO: This is only a small fix to keep basic error capture working, but
we need to add more information for it to be useful (e.g. dump the
context being executed).

v2: Reorder how the ringbuffer is chosen to clarify the change and
rename the variable, both changes suggested by Chris Wilson. Also,
add the TODO comment to the code, as suggested by Daniel.

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
87a01e822db6e8b6a2898ddc7f116698247c7a4d 12-Aug-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Suppress a WARN on reading an object back for a GPU hang

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
8ae62dc62b340edd0f6a5a2522f284234e82c0ec 12-Aug-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Remove num_pages parameter to i915_error_object_create()

For cleanliness, i915_error_object_create() was written to handle the
NULL pointer in a central location. The macro that wrapped it and passed
it a num_pages to use, was not safe. As we now never limit the num_pages
to use (we did so at one point to only capture the first page of the
context), we can remove the redundant macro and be NULL safe again.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
b3c3f5e69e25583703383d674e73d0ce26e731c3 12-Aug-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Do not access stolen memory directly by the CPU, even for error capture

For stolen pages, since it is verboten to access them directly on many
architectures, we have to read them through the GTT aperture. If they
are not accessible through the aperture, then we have to abort.

This was complicated by

commit 8b6124a633d8095b0c8364f585edff9c59568a96
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jan 30 14:38:16 2014 +0000

drm/i915: Don't access snooped pages through the GTT (even for error capture)

and the desire to use stolen memory for ringbuffers, contexts and
batches in the future.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
3a448734902359113b0c7c3454ce4cd56dc1e61f 12-Aug-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Print captured bo for all VM in error state

The current error state harks back to the era of just a single VM. For
full-ppgtt, we capture every bo on every VM. It behoves us to then print
every bo for every VM, which we currently fail to do and so miss vital
information in the error state.

v2: Use the vma address rather than -1!

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ae6c4806927b8b0781ecc187aa16b10c820fc430 06-Aug-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Only track real ppgtt for a context

There's a bit a confusion since we track the global gtt,
the aliasing and real ppgtt in the ctx->vm pointer. And not
all callers really bother to check for the different cases and just
presume that it points to a real ppgtt.

Now looking closely we don't actually need ->vm to always point at an
address space - the only place that cares actually has fixup code
already to decide whether to look at the per-proces or the global
address space.

So switch to just tracking the ppgtt directly and ditch all the
extraneous code.

v2: Fixup the ppgtt debugfs file to not oops on a NULL ctx->ppgtt.
Also drop the early exit - without aliasing ppgtt we want to dump all
the ppgtts of the contexts if we have full ppgtt.

v3: Actually git add the compile fix.

Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Cc: "Thierry, Michel" <michel.thierry@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
OTC-Jira: VIZ-3724
[danvet: Resolve conflicts with execlist patches while applying.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
885ea5a8132224cf1ae12b8413352e8b893c8842 05-Aug-2014 Rodrigo Vivi <rodrigo.vivi@intel.com> drm/i915: Fix DEIER and GTIER collecting for BDW.

BDW has many other Display Engine interrupts and GT interrupts registers.
Collecting it properly on gpu_error_state.

On debugfs all was properly listed already but besides we were also listing old
DEIER and GTIER that doesn't exist on BDW anymore. This was causing
unclaimed register messages

v2: Fix small issues of first version and don't read DEIER regs when pipe's
power well is disabled
v3: bikeshed accepted: use enum pipe pipe instead of int i for pipe interection
v4: Ben notice previous version was checking for display_power_enabled without
using propper locks. Using _unlocked version isn't reliable and we cannot
get this registers when power well is off. So let's avoid getting all DE_IER
per pipe for now. If someone think this is an useful information it can be
added later.
v5: Ben: put back debugfs stuff that might be coverred by pm_get and use
gen >= 8 trying to predict future.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81701
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: (v3) Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
f260fe7b2f8c32e2fb02a36d3b76ef64b61dbdc5 05-Aug-2014 Mika Kuoppala <mika.kuoppala@linux.intel.com> drm/i915: Don't accumulate hangcheck score on forward progress

If the actual head has progressed forward inside a batch (request),
don't accumulate hangcheck score.

As the hangcheck score in increased only by acthd jumping backwards,
the result is that we only declare an active batch as stuck if it is
trapped inside a loop. Or that the looping will dominate the batch
progression so that it overcomes the bonus that forward progress gives.

v2: Improved commit message (Chris Wilson)

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: s/active_loop/active (loop)/ as requested by Chris.]
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
843db716a9c3d3089a3a1f1b9b7af9a33943ab85 01-Aug-2014 Rodrigo Vivi <rodrigo.vivi@intel.com> drm/i915: Collect gtier properly on HSW.

GTIER and DEIER doesn't have same interface on HSW so this "or" operation
makes the information provided useless.

v2: since we have gtier variable already let's split for everybody
and avoid the strange | op.
Also avoid overriding the value that was set for vlv. In this case I
believe that we should reorganize the whole function, but I'll respect
the comment that ask to not touch the order and let this organization
work to be done later.
v3: moving VLV check to the right place.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
864c61811c7c3d877e8fb3162eeb8616f2c8e9b8 01-Aug-2014 Rodrigo Vivi <rodrigo.vivi@intel.com> drm/i915: Fix error state collecting

Fix signal_offset when recording semaphore state on BDW.

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
b4558b46d58e872114e96647cbd6a75ff7280f86 18-Jul-2014 Rodrigo Vivi <rodrigo.vivi@intel.com> drm/i915: Fix possible overflow when recording semaphore states.

semaphore _sync_seqno, _seqno and _mbox are smaller than number of rings.
This optimization is to remove the ring itself from the list and the logic to do that
is at intel_ring_sync_index as below:

/*
* rcs -> 0 = vcs, 1 = bcs, 2 = vecs, 3 = vcs2;
* vcs -> 0 = bcs, 1 = vecs, 2 = vcs2, 3 = rcs;
* bcs -> 0 = vecs, 1 = vcs2. 2 = rcs, 3 = vcs;
* vecs -> 0 = vcs2, 1 = rcs, 2 = vcs, 3 = bcs;
* vcs2 -> 0 = rcs, 1 = vcs, 2 = bcs, 3 = vecs;
*/

v2: Skip when from == to (Damien).
v3: avoid computing idx when from == to (Damien).
use ring == to instead of ring->id == to->id (Damien).
use continue instead of return (Rodrigo).
v4: avoid all unecessary computation (Damien).
reduce idx to loop scope (Damien).

Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
36362ad3b64acd5e4d438db480bdb80a4ff75eb2 01-Jul-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915/error: Check the potential ctx obj's vm

The bound list is global (all objects which back the VMAs are stored
here). Recently the BUG() in the offset lookup was demoted to a WARN,
but the fault actually lies in the caller, here.

This bug has existed since the initial introduction of PPGTT (however,
it was fixed in unmerged patches to fix up the error state).

Note: The reason for the BUG_ON to WARN_ON demotion was _not_ to
duct-tape over this bug here but another but triggerable without
ppgtt. See the commit for details:

commit f25748ea7342bcc44866befcbf0222cd1d89d851
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jun 17 22:34:38 2014 +0200

drm/i915: Don't BUG_ON in i915_gem_obj_offset

A WARN_ON is perfectly fine.

The BUG in here seems to be the cause behind hard-hangs when I cat the
i915_gem_pageflip debugfs file (which calls this from an irq
spinlock). But only while running a full igt run after a while. I
still need to root cause the underlying issue.

I'll also start reject patches which add new BUG_ON but don't come
with a really good justification for it. The general rule really
should be to just WARN and hope the driver survives for long enough.

v2: Make the WARN a bit more useful per Chris' suggestion.

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

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Clarfy that the WARN_ON (former BUG_ON) in ggtt_offset caught
more than just this bug fixed in this patch here.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
0ca36d78391dc97b7d3e3d26e4518e30f3e88c16 30-Jun-2014 Ben Widawsky <ben@bwidawsk.net> drm/i915/bdw: collect semaphore error state

Since the semaphore information is in an object, just dump it, and let
the user parse it later.

NOTE: The page being used for the semaphores are incoherent with the
CPU. No matter what I do, I cannot figure out a way to read anything but
0s. Note that the semaphore waits are indeed working.

v2: Don't print signal, and wait (they should be the same). Instead,
print sync_seqno (Chris)

v3: Free the semaphore error object (Chris)

v4: Fix semaphore offset calculation during error state collection
(Ville)

v5: VCS2 rebase
Make semaphore object error capture coding style consistent (Ville)
Do the proper math for the signal offset (Ville)

v6: Fix small conflicts on rebase and s/ring_buffer/engine_cs (Rodrigo)

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
87f85ebc8dd089842e9efafd811486e5997b2265 30-Jun-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Extract semaphore error collection

v2: s/ring_buffer/engine_cs (Rodrigo)

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
eee73b46261325eb140d899b5371f49b02d88f63 10-Jun-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i95: Initialize active ring->pid to -1

Otherwise we print out spurious processes on unused rings in the error
state.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
ee1b1e5ef38d22e2447b48b8456a2b2bcf438e65 22-May-2014 Oscar Mateo <oscar.mateo@intel.com> drm/i915: Split the ringbuffers from the rings (2/3)

This refactoring has been performed using the following Coccinelle
semantic script:

@@
struct intel_engine_cs r;
@@
(
- (r).obj
+ r.buffer->obj
|
- (r).virtual_start
+ r.buffer->virtual_start
|
- (r).head
+ r.buffer->head
|
- (r).tail
+ r.buffer->tail
|
- (r).space
+ r.buffer->space
|
- (r).size
+ r.buffer->size
|
- (r).effective_size
+ r.buffer->effective_size
|
- (r).last_retired_head
+ r.buffer->last_retired_head
)

@@
struct intel_engine_cs *r;
@@
(
- (r)->obj
+ r->buffer->obj
|
- (r)->virtual_start
+ r->buffer->virtual_start
|
- (r)->head
+ r->buffer->head
|
- (r)->tail
+ r->buffer->tail
|
- (r)->space
+ r->buffer->space
|
- (r)->size
+ r->buffer->size
|
- (r)->effective_size
+ r->buffer->effective_size
|
- (r)->last_retired_head
+ r->buffer->last_retired_head
)

@@
expression E;
@@
(
- LP_RING(E)->obj
+ LP_RING(E)->buffer->obj
|
- LP_RING(E)->virtual_start
+ LP_RING(E)->buffer->virtual_start
|
- LP_RING(E)->head
+ LP_RING(E)->buffer->head
|
- LP_RING(E)->tail
+ LP_RING(E)->buffer->tail
|
- LP_RING(E)->space
+ LP_RING(E)->buffer->space
|
- LP_RING(E)->size
+ LP_RING(E)->buffer->size
|
- LP_RING(E)->effective_size
+ LP_RING(E)->buffer->effective_size
|
- LP_RING(E)->last_retired_head
+ LP_RING(E)->buffer->last_retired_head
)

Note: On top of this this patch also removes the now unused ringbuffer
fields in intel_engine_cs.

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
[danvet: Add note about fixup patch included here.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
a4872ba6d01454dfeb251d96f623ab5d1b0666a4 22-May-2014 Oscar Mateo <oscar.mateo@intel.com> drm/i915: s/intel_ring_buffer/intel_engine_cs

In the upcoming patches we plan to break the correlation between
engine command streamers (a.k.a. rings) and ringbuffers, so it
makes sense to refactor the code and make the change obvious.

No functional changes.

Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
5cc9ed4b9a7ac579362ccebac67f7a4cdb36de06 16-May-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl

By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, with zero-copy downloads to the GPU and efficient
readback making the intermixed streaming of CPU and GPU operations
fairly efficient. This ability has many widespread implications from
faster rendering of client-side software rasterisers (chromium),
mitigation of stalls due to read back (firefox) and to faster pipelining
of texture data (such as pixel buffer objects in GL or data blobs in CL).

v2: Compile with CONFIG_MMU_NOTIFIER
v3: We can sleep while performing invalidate-range, which we can utilise
to drop our page references prior to the kernel manipulating the vma
(for either discard or cloning) and so protect normal users.
v4: Only run the invalidate notifier if the range intercepts the bo.
v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
v6: Recheck after reacquire mutex for lost mmu.
v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
v8: Fix rebasing error after forwarding porting the back port.
v9: Limit the userptr to page aligned entries. We now expect userspace
to handle all the offset-in-page adjustments itself.
v10: Prevent vma from being copied across fork to avoid issues with cow.
v11: Drop vma behaviour changes -- locking is nigh on impossible.
Use a worker to load user pages to avoid lock inversions.
v12: Use get_task_mm()/mmput() for correct refcounting of mm.
v13: Use a worker to release the mmu_notifier to avoid lock inversion
v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
with its own locking and tree of objects for each mm/mmu_notifier.
v15: Prevent overlapping userptr objects, and invalidate all objects
within the mmu_notifier range
v16: Fix a typo for iterating over multiple objects in the range and
rearrange error path to destroy the mmu_notifier locklessly.
Also close a race between invalidate_range and the get_pages_worker.
v17: Close a race between get_pages_worker/invalidate_range and fresh
allocations of the same userptr range - and notice that
struct_mutex was presumed to be held when during creation it wasn't.
v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
for the struct sg_table and to clear it before reporting an error.
v19: Always error out on read-only userptr requests as we don't have the
hardware infrastructure to support them at the moment.
v20: Refuse to implement read-only support until we have the required
infrastructure - but reserve the bit in flags for future use.
v21: use_mm() is not required for get_user_pages(). It is only meant to
be used to fix up the kernel thread's current->mm for use with
copy_user().
v22: Use sg_alloc_table_from_pages for that chunky feeling
v23: Export a function for sanity checking dma-buf rather than encode
userptr details elsewhere, and clean up comments based on
suggestions by Bradley.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Akash Goel <akash.goel@intel.com>
Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
[danvet: Frob ioctl allocation to pick the next one - will cause a bit
of fuss with create2 apparently, but such are the rules.]
[danvet2: oops, forgot to git add after manual patch application]
[danvet3: Appease sparse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ebc348b2ad59ed5c9b22269f422d12095b640ff5 29-Apr-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Move semaphore specific ring members to struct

This will be helpful in abstracting some of the code in preparation for
gen8 semaphores.

v2: Move mbox stuff to a separate struct

v3: Rebased over VCS2 work

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
f301b1e116396804c6fcd4a33eb4477a24e0a3b8 18-Apr-2014 Imre Deak <imre.deak@intel.com> drm/i915: add missing error capturing of the PIPESTAT reg

While checking the error capture path I noticed that we lacked the
power domain-on check for PIPESTAT so fix this by moving that to where
the rest of pipe registers are captured.

The move also revealed that we actually don't include this register in
the error report, so fix that too.

v2:
- patch introduced in v2 of the patchset
v3:
- add back !HAS_PCH_SPLIT check (Ville)
[ Ignore my previous comment about the gen<=5 || vlv check, I realized
that it's the same as !HAS_PCH_SPLIT. ]

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
51660e0eb6e7130fb1ba511cc1918cbe505be0af 14-Apr-2014 Imre Deak <imre.deak@intel.com> drm/i915: gen2: move error capture of IER to its correct place

While checking the error capture path I noticed that this register is
read twice for GEN2, so fix this and also move the read where it's done
for other platforms.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
845f74a701541662bf7d4880a0f4d492b28f2d18 17-Apr-2014 Zhao Yakui <yakui.zhao@intel.com> drm/i915:Initialize the second BSD ring on BDW GT3 machine

Based on the hardware spec, the BDW GT3 machine has two independent
BSD ring that can be used to dispatch the video commands.
So just initialize it.

V3->V4: Follow Imre's comment to do some minor updates. For example:
more comments are added to describe the semaphore between ring.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
[danvet: Fix up checkpatch error.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
17d36749a559905f7d9a640239a9fc74fc3bb445 05-Apr-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Dump the whole context object.

As we've learned over time, the HW context is just a series of GPU
commands that we're able to decode without any changes in
intel_error_decode. Since many bugs recently have been implicated in
the HW context state, it makes sense to dump the whole context object
in a form which can be parsed.

Sample:
render ring --- HW Context = 0x042db000
ringbuffer (render ring) at 0x0160c000; HEAD points to: 0x0160c000
0x0160c000: 0x00000000: MI_NOOP
0x0160c004: 0x00000000: MI_NOOP
0x0160c008: 0x00000000: MI_NOOP
0x0160c00c: 0x00000000: MI_NOOP
0x0160c010: 0x00000000: MI_NOOP
0x0160c014: 0x00000000: MI_NOOP
0x0160c018: 0x00000000: MI_NOOP
0x0160c01c: 0x00000000: MI_NOOP

Unfortunately, our decoder isn't quite smart enough to deal with the
variable length LRIs - but that is a tools problem.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Clarify commit message a bit, seems to have lost a few
crucial words.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
13ffadd1f9fa2e19ecb054b063887dcd62dde2be 02-Apr-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915/bdw: Expand FADD to 64bit

For error state, like the recent modification to ACTHD, FADD also gets
an upper dword. This is useful for debug to make sure the fetch address
and head are similar.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
50227e1cae118562b8b6230e31bca84870cad27e 31-Mar-2014 Jani Nikula <jani.nikula@intel.com> drm/i915: prefer struct drm_i915_private to drm_i915_private_t

Remove the rest of the references to drm_i915_private_t. No functional
changes.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Drop hunk in i915_cmd_parser.c]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
e3243d16726798c451f1d0c356a177117fa75c2e 21-Mar-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Split 64bit hexadecimal addresses to make them easier to read

Broadwell introduces large address spaces, greater than 32bits in width.
These require that we then store and print 64bit values. If we were to
zero pad them out to 16 hexadecimal places, we have to carefully count
the leading zeroes - which is easy to make a mistake. Conversely, if we
do not zero pad out to 16, but keep it padding to 8 hexadecimal places,
it is very easy to miss an address that is actually larger than 4GiB. A
suggested compromise is to insert a space between the upper and lower
dwords of the address so that we can continue with our accustom 32bit
parser. (Alternatively, we could do the equivalent in our userspace
decoder.)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
508774452d657e8d307e1c52682ffcdf743e992d 21-Mar-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Broadwell expands ACTHD to 64bit

As Broadwell has an increased virtual address size, it requires more
than 32 bits to store offsets into its address space. This includes the
debug registers to track the current HEAD of the individual rings, which
may be anywhere within the per-process address spaces. In order to find
the full location, we need to read the high bits from a second register.
We then also need to expand our storage to keep track of the larger
address.

v2: Carefully read the two registers to catch wraparound between
the reads.
v3: Use a WARN_ON rather than loop indefinitely on an unstable
register read.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Drop spurious hunk which conflicted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ae89f44d13a36192cc19c1de04aa41ab0b3624cc 15-Mar-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Actually capture PP_DIR_BASE on error

I have been seeing this for a long time, but ignored it because it's
typically not terribly important. Recently, I really needed this info,
and it was garbage. Proof that I should have fixed it sooner. Originally
wrong from:

commit 6c7a01ec3743a5a6ce9e53a69d7a6c2d8c715eb1
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Thu Jan 30 00:19:40 2014 -0800

drm/i915: Capture PPGTT info on error capture

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
62d5d69b49b6fea9905e36e67cc6c4fc5a17d75f 25-Feb-2014 Mika Kuoppala <mika.kuoppala@linux.intel.com> drm/i915: Add suspend count to error state

For example if we get bug reports with similar error states and
suspend count is always 1, that might lead the Sherlocks to
right general direction.

Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
48b031e30d46b11fdf7a8075f02f5f9eef728f4d 25-Feb-2014 Mika Kuoppala <mika.kuoppala@linux.intel.com> drm/i915: Add reset count to error state

By default we keep only the error state from first hang. However
some sneaky user might have cleared the first error state and we
assume mistakenly that it is from first hang. As sometimes this
matters, it is better to explicitly store the reset count.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
581744626d89930a03f307558182896a4f51173c 25-Feb-2014 Mika Kuoppala <mika.kuoppala@linux.intel.com> drm/i915: Add reason for capture in error state

We capture error state not only when the GPU hangs but also on
other situations as in interrupt errors and in situations where
we can kick things forward without GPU reset. There will be log
entry on most of these cases. But as error state capture might be
only thing we have, if dmesg was not captured. Or as in GEN4 case,
interrupt error can trigger error state capture without log entry,
the exact reason why capture was made is hard to decipher.

v2: Split out the the error code stuff to separate patch (Ben)

References: https://bugs.freedesktop.org/show_bug.cgi?id=74193
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
cb38300215dc24886347bfc6400ccfed806dac21 25-Feb-2014 Mika Kuoppala <mika.kuoppala@linux.intel.com> drm/i915: Add error code into error state

commit 011cf577b2531dfbd2254bd9ec147ad71471abaf
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Tue Feb 4 12:18:55 2014 +0000

drm/i915: Generate a hang error code

added error code debug into dmesg. Store this also
with error state to make matching dmesg logs and error
states easier.

As we need to have full ring state for error code generation,
do full capture always, print hang message into log and then
decide if we need to keep the error state.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ab0e7ff9f2d0bfe139a2ed5bb6a36f8cbd4e0886 25-Feb-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Record pid/comm of hanging task

After finding the guilty batch and request, we can use it to find the
process that submitted the batch and then add the culprit into the error
state.

This is a slightly different approach from Ben's in that instead of
adding the extra information into the struct i915_hw_context, we use the
information already captured in struct drm_file which is then referenced
from the request.

v2: Also capture the workaround buffer for gen2, so that we can compare
its contents against the intended batch for the active request.

v3: Rebase (Mika)
v4: Check for null context (Chris)
checkpatch warnings fixed

Link: http://lists.freedesktop.org/archives/intel-gfx/2013-August/032280.html
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v4)
Acked-by: Ben Widawsky <ben@bwidawsk.net>
Cc: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
8d9fc7fd2de6edc3b9c3f828a701bfa6891987e7 25-Feb-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Rely on accurate request tracking for finding hung batches

In the past, it was possible to have multiple batches per request due to
a stray signal or ENOMEM. As a result we had to scan each active object
(filtered by those having the COMMAND domain) for the one that contained
the ACTHD pointer. This was then made more complicated by the
introduction of ppgtt, whereby ACTHD then pointed into the address space
of the context and so also needed to be taken into account.

This is a fairly robust approach (though the implementation is a little
fragile and depends upon the per-generation setup, registers and
parameters). However, due to the requirements for hangstats, we needed a
robust method for associating batches with a particular request and
having that we can rely upon it for finding the associated batch object
for error capture.

If the batch buffer tracking is not robust enough, that should become
apparent quite quickly through an erroneous error capture. That should
also help to make sure that the runtime reporting to userspace is
robust. It also means that we then report the oldest incomplete batch on
each ring, which can be useful for determining the state of userspace at
the time of a hang.

v2: Use i915_gem_find_active_request (Mika)

v3: remove check for ring->get_seqno, split long lines (Ben)

v4: check that context is available (Chris)
checkpatch warnings fixed

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v3)
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v3)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
1d2cb9a54abc6e1d239f28f07661366d5662a94a 07-Feb-2014 Mika Kuoppala <mika.kuoppala@linux.intel.com> drm/i915: Pair va_copy with va_end in i915_error_vprintf

Each invocation of va_copy() must be matched by a corresponding
invocation of va_end() in the same function.

This regression has been introduced in

commit e29bb4ebbf000ff9ac081d29784a3331618f012e
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Sep 20 10:20:59 2013 +0100

drm/i915: Use a temporary va_list for two-pass string handling

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
011cf577b2531dfbd2254bd9ec147ad71471abaf 04-Feb-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Generate a hang error code

We get a large number of bugs which have a, "hey I have that too"
because they see a GPU hang in dmesg. While two machines of the same
model having a GPU hang is indeed a coincidence, it is far from enough
evidence to suggest they are the same.

In order to reduce this effect, and hopefully get people to file new bug
reports, clearly the error message itself has been insufficient (see ref
at the bottom for a new bug report with this characteristic).

The algorithm is purposely pretty naive. I don't think we need much in
order to avoid the problem I am trying to solve, and keeping it naive
gives us some ability to make a decent test case.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=73276
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
8b6124a633d8095b0c8364f585edff9c59568a96 30-Jan-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Don't access snooped pages through the GTT (even for error capture)

We want to use the GTT for reading back objects upon an error so that we
have exactly the information that the GPU saw. However, it is verboten
to access snoopable pages through the GTT and causes my PineView GPU to
throw a page fault instead.

This has not been a problem in the past as we only dumped ringbuffers
and batchbuffers, both of which must be not snooped. However, the
introduction of HWS page dumping leads to a read of a snooped object
through the GTT. This was introduced by

commit f3ce3821393e31a3f1a8ca6c24eb2d735a428445
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Jan 23 22:40:36 2014 +0000

drm/i915: Include HW status page in error capture

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet:s/uncached/not snooped/ for one case in the commit message as
requested by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
53a4c6b26ddef1f2969f8bc17178bcda4782d18d 30-Jan-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Only print information for filing bug reports once

Repeating the same information multiple times is just annoying.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
6c7a01ec3743a5a6ce9e53a69d7a6c2d8c715eb1 30-Jan-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Capture PPGTT info on error capture

v2: Rebased upon cleaned up error state
v3: Make sure hangcheck info remains last (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
91ec5d11ab6fea7eafd0364b77cd39baf60cd8e3 30-Jan-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Add some more registers to error state

Chris:
Do we also want to capture?
GAC_ECO_BITS /* gen6,7 */
GAM_ECOCHK /* gen6,7 */
GAB_CTL /* gen6 */
GFX_MODE /* gen6 */

Requested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
362b8af7ad1d91266aa4931e62be45c1e5cf753b 30-Jan-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Move per ring error state to ring_error

v2: Moved num_requests up (Chris)
Rebased on new hws page capture which required a rename since it made
two members named, 'hws' in the per ring error state. (Ben)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
654c90c67853c4f2677af36b154304b7d560aef8 30-Jan-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Logically reorder error register capture

Create logical sections in an attempt to clean up, and continue to keep
future additions clean.

v2: Reworded the comments. Added section headers (Chris)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
1d762aad7bcc93ae739008e98a9dc8e5cbce565e 30-Jan-2014 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Extract register state error capture

The code has become quite hairy. By relocating all the generic registers
it will become more obvious where future ones should go. There is still
admittedly a bit of confusion left for things like per ring registers.

A subsequent patch will clean this function up.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
f3ce3821393e31a3f1a8ca6c24eb2d735a428445 23-Jan-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Include HW status page in error capture

Many times in the past we have concluded that the cause of the GPU hang
has been that the hw status page was stale, usually because the GPU and
CPU disagreed over the address of the page. Having stumbled across yet
another issue that seems to be related to the HWSP, it is time to
include that information in the GPU error dump.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
372fbb8e3927fc76b0f842d8eb8a798a71d8960f 27-Jan-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Decouple GPU error reporting from ring initialisation

Currently we report through our error state only the rings that have
been initialised (as detected by ring->obj). This check is done after
the GPU reset and ring re-initialisation, which means that the software
state may not be the same as when we captured the hardware error and we
may not print out any of the vital information for debugging the hang.

This (and the implied object leak) is a regression from

commit 3d57e5bd1284f44e325f3a52d966259ed42f9e05
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Mon Oct 14 10:01:36 2013 -0700

drm/i915: Do a fuller init after reset

Note that we are already starting to get bug reports with incomplete
error states from 3.13, which also hampers debugging userspace driver
issues.

v2: Prevent a NULL dereference on 830gm/845g after a GPU reset where
the scratch obj may be NULL.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=74094
Cc: stable@vger.kernel.org # please don't delay since it's a
vital support/debug feature for the intel gfx stack in general
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add a bit of fluff to make it clear we need this expedited in
stable.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
7e0d96bc03c140cb8183955ad6f0290caa731e64 06-Dec-2013 Ben Widawsky <ben@bwidawsk.net> drm/i915: Use multiple VMs -- the point of no return

As with processes which run on the CPU, the goal of multiple VMs is to
provide process isolation. Specific to GEN, there is also the ability to
map more objects per process (2GB each instead of 2Gb-2k total).

For the most part, all the pipes have been laid, and all we need to do
is remove asserts and actually start changing address spaces with the
context switch. Since prior to this we've converted the setting of the
page tables to a streamed version, this is quite easy.

One important thing to point out (since it'd been hotly contested) is
that with this patch, every context created will have it's own address
space (provided the HW can do it).

v2: Disable BDW on rebase

NOTE: I tried to make this commit as small as possible. I needed one
place where I could "turn everything on" and that is here. It could be
split into finer commits, but I didn't really see much point.

Cc: Eric Anholt <eric@anholt.net>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
d7f46fc4e7323887494db13f063a8e59861fefb0 06-Dec-2013 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Make pin count per VMA

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
685987c6915222730f45141a89f1cd87fb092e9a 06-Dec-2013 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Identify active VM for batchbuffer capture

Using the current state of the page directory registers, we can
determine which of our address spaces was active when the hang occurred.
This allows us to scan through all the address spaces to identify the
"active" one during error capture.

v2: Rebased for BDW error detection. BDW error detection is similar
except instead of PP_DIR_BASE, we can use the PDP registers.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add FIXME about global gtt misuse.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
496bfcb9f174f68802439b15b8f0bad17ebe0558 06-Dec-2013 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Don't use gtt mapping for !gtt error objects

The existing check was insufficient to determine whether we can use the
GTT mapping to read out the object during error capture.

The previous condition was, if the object has a GGTT mapping, and the
reloc is in the GTT range... the can happen with opjects mapped into
multiple vms (one of which being the GTT).

There are two solutions to this problem:
1. This patch, which avoid reading the io mapping
2. Use the GGTT offset with the io mapping.

Since error capture is about recording the most accurate possible error
state, and the error was caused by the object not in the GGTT - I opted
for the former.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
a7b910789f77afa40ae0816d22339e9d25723c6e 06-Dec-2013 Ben Widawsky <ben@bwidawsk.net> drm/i915: Add vm to error BO capture

formerly: drm/i915: Create VMAs (part 6) - finish error plumbing

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
3dda20a974e013a4985560904c0e491a70a25251 10-Dec-2013 Ville Syrjälä <ville.syrjala@linux.intel.com> drm/i915: Record BB_ADDR for every ring

Every ring seems to have a BB_ADDR registers, so include them all in the
error state.

v2: Also include the _UDW on BDW

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
0476190e107f398cfe0b50101bee4f8bd8e0fe30 10-Dec-2013 Ville Syrjälä <ville.syrjala@linux.intel.com> drm/i915: Use 32bit read for BB_ADDR

The BB_ADDR register is documented to be 32bits at least since SNB.
Prior to that the high 32bits were listed as MBZ, so using a 64bit read
doesn't seem worth anything. Also the simulator doesn't like the 64bit
read. So just switch to using a 32bit read instead.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
d0582ed2ff119eae26c74a5ec85c08fbd6ae0e18 03-Nov-2013 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915/bdw: Update relevant error state

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
5ab31333ac94f808e2249a0955a2a79b2b1c32a1 03-Nov-2013 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915/bdw: Fences on gen8 look just like gen7

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
94e39e282ecd299b095f37cd0f521d83bd799b14 30-Oct-2013 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Capture batchbuffer state upon GPU hang

The bbstate contains useful bits of debugging information such as
whether the batch is being read from GTT or PPGTT, or whether it is
allowed to execute privileged instructions.

v2: Only record BB_STATE for gen4+

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
f468980171fa6293917a8b59bfec71c6616e06c9 09-Oct-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Educate users in dmesg about reporting gpu hangs

Untangling me-too reports that actually aren't is really messy. And we
need to make sure the blame is put where it should be right from the
start ;-)

v2: Improve the wording from Ben's suggestions.

Cc: Ben Widawsky <ben@bwidawsk.net>
Acked-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Frob the message as suggested by Paulo on irc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ffbab09bf939975b62ec233c426bf7df0dd4cea8 04-Oct-2013 Ville Syrjälä <ville.syrjala@linux.intel.com> drm: Remove pci_vendor and pci_device from struct drm_device

We can get the PCI vendor and device IDs via dev->pdev. So we can drop
the duplicated information.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
094f9a54e35500739da185cdb78f2e92fc379458 25-Sep-2013 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Fix __wait_seqno to use true infinite timeouts

When we switched to always using a timeout in conjunction with
wait_seqno, we lost the ability to detect missed interrupts. Since, we
have had issues with interrupts on a number of generations, and they are
required to be delivered in a timely fashion for a smooth UX, it is
important that we do log errors found in the wild and prevent the
display stalling for upwards of 1s every time the seqno interrupt is
missed.

Rather than continue to fix up the timeouts to work around the interface
impedence in wait_event_*(), open code the combination of
wait_event[_interruptible][_timeout], and use the exposed timer to
poll for seqno should we detect a lost interrupt.

v2: In order to satisfy the debug requirement of logging missed
interrupts with the real world requirments of making machines work even
if interrupts are hosed, we revert to polling after detecting a missed
interrupt.

v3: Throw in a debugfs interface to simulate broken hw not reporting
interrupts.

v4: s/EGAIN/EAGAIN/ (Imre)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Don't use the struct typedef in new code.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
f56383cb9fc8d7165bd7d2136b4c4af98c41177c 25-Sep-2013 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Show WT caching in debugfs

Add the missing cache-level to the describe_obj() function for debug and
error reporting.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
a1e2265332e9344f913811ac6d2b84a506195bd8 21-Sep-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Use kcalloc more

No buffer overflows here, but better safe than sorry.

v2:
- Fixup the sizeof conversion, I've missed the pointer deref (Jani).
- Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani).
- Use kmalloc_array for the execbuf fastpath to avoid the memset
(Chris). I've opted to leave all other conversions as-is since they
aren't in a fastpath and dealing with cleared memory instead of
random garbage is just generally nicer.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Drop the contentious kmalloc_array hunk in execbuf.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
e29bb4ebbf000ff9ac081d29784a3331618f012e 20-Sep-2013 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Use a temporary va_list for two-pass string handling

In

commit edc3d8848dc9fe2a470316363dab8ef211d77e01
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Thu May 23 13:55:35 2013 +0300

drm/i915: avoid big kmallocs on reading error state

we introduce a two-pass mechanism for splitting long strings being
formatted into the error-state. The first pass finds the length, and the
second pass emits the right portion of the string into the accumulation
buffer. Unfortunately we use the same va_list for both passes, resulting
in the second pass reading garbage off the end of the argument list. As
the two passes are only used for boundaries between read() calls, the
corruption is only rarely seen.

This fixes the root cause behind

commit baf27f9b17bf2f369f3865e38c41d2163e8d815d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Sat Jun 29 23:26:50 2013 +0100

drm/i915: Break up the large vsnprintf() in print_error_buffers()

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
da66146425c3136943452988afd3d64cd551da58 06-Sep-2013 Mika Kuoppala <mika.kuoppala@linux.intel.com> drm/i915: include hangcheck action and score in error_state

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 <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
0d1aacac36530fce058d7a0db3da7befd5765417 26-Aug-2013 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Embed the ring->private within the struct intel_ring_buffer

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 <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
4e5aabfd3106cfd68694db416e271996aadf114a 13-Aug-2013 Ben Widawsky <benjamin.widawsky@intel.com> drm/i915: Get VECS semaphore info on error

Ideally we could use for_each_ring with the ring flags as I've done a
couple times
(http://lists.freedesktop.org/archives/intel-gfx/2013-June/029450.html).
Until Daniel merges that patch though, we can just use this.

Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
95f5301dd880da2dea2c9a9c29750064536d426a 01-Aug-2013 Ben Widawsky <ben@bwidawsk.net> drm/i915: Update error capture for VMs

formerly: "drm/i915: Create VMAs (part 4) - Error capture"

Since the active/inactive lists are per VM, we need to modify the error
capture code to be aware of this, and also extend it to capture the
buffers from all the VMs. For now all the code assumes only 1 VM, but it
will become more generic over the next few patches.

NOTE: If the number of VMs in a real world system grows significantly
we'll have to focus on only capturing the guilty VM, or else it's likely
there won't be enough space for error capture.

v2: Squashed in the "part 6" which had dependencies on the mm_list
change. Since I've moved the mm_list change to an earlier point in the
series, we were able to accomplish it here and now.

v3: Rebased over new error capture

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ca191b1313e733e47a9fb37c26b44aa6cdd9b1b1 01-Aug-2013 Ben Widawsky <ben@bwidawsk.net> drm/i915: mm_list is per VMA

formerly: "drm/i915: Create VMAs (part 5) - move mm_list"

The mm_list is used for the active/inactive LRUs. Since those LRUs are
per address space, the link should be per VMx .

Because we'll only ever have 1 VMA before this point, it's not incorrect
to defer this change until this point in the patch series, and doing it
here makes the change much easier to understand.

Shamelessly manipulated out of Daniel:
"active/inactive stuff is used by eviction when we run out of address
space, so needs to be per-vma and per-address space. Bound/unbound otoh
is used by the shrinker which only cares about the amount of memory used
and not one bit about in which address space this memory is all used in.
Of course to actual kick out an object we need to unbind it from every
address space, but for that we have the per-object list of vmas."

v2: only bump GGTT LRU in i915_gem_object_set_to_gtt_domain (Chris)

v3: Moved earlier in the series

v4: Add dropped message from v3

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Frob patch to apply and use vma->node.size directly as
discused with Ben. Also drop a needles BUG_ON before move_to_inactive,
the function itself has the same check.]
[danvet 2nd: Rebase on top of the lost "drm/i915: Cleanup more of VMA
in destroy", specifically unlink the vma from the mm_list in
vma_unbind (to keep it symmetric with bind_to_vm) instead of
vma_destroy.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
350ec881d966453bdcf1d3299071e90da4e507b4 06-Aug-2013 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Rename I915_CACHE_MLC_LLC to L3_LLC for Ivybridge

MLC_LLC was never validated for Sandybridge and was superseded by a new
level of cacheing for the GPU in Ivybridge. Update our names to be
consistent with usage, and in the process stop setting the unwanted bit
on Sandybridge.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: s/BUG/WARN_ON(1) bikeshed.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
5cef07e1628300aeda9ac9dae95a2b406175b3ff 17-Jul-2013 Ben Widawsky <ben@bwidawsk.net> drm/i915: Move active/inactive lists to new mm

Shamelessly manipulated out of Daniel :-)
"When moving the lists around explain that the active/inactive stuff is
used by eviction when we run out of address space, so needs to be
per-vma and per-address space. Bound/unbound otoh is used by the
shrinker which only cares about the amount of memory used and not one
bit about in which address space this memory is all used in. Of course
to actual kick out an object we need to unbind it from every address
space, but for that we have the per-object list of vmas."

v2: Leave the bound list as a global one. (Chris, indirectly)

v3: Rebased with no i915_gtt_vm. In most places I added a new *vm local,
since it will eventually be replaces by a vm argument.
Put comment back inline, since it no longer makes sense to do otherwise.

v4: Rebased on hangcheck/error state movement

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
84734a049d0ef2f6f5fb0a1fe060cd51480dd855 12-Jul-2013 Mika Kuoppala <mika.kuoppala@linux.intel.com> drm/i915: move error state to own compilation unit

Move error state generation and stringification to it's
own compilation unit. Sysfs also uses this so it can't be
under CONFIG_DEBUG_FS

This fixes a regression introduced in

commit ef86ddced720fddc3835558447a7f594d3609c73
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Thu Jun 6 17:38:54 2013 +0300

drm/i915: add error_state sysfs entry

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66814
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>