kernel/drivers/gpu/drm/i915/i915_gpu_error.c, branch linux-4.1.y

drm/i915: Add fault address to error state for gen8 and gen9

2015-03-25T17:23:44Z

The faulting virtual address is >32bits and has been moved to different registers. Add to error state and output upper register first, in the same line for easy reconstruction of the fault address. v2: correct gen masking (Michel) v3: s/TBL/TLB (Ville) Signed-off-by: Mika Kuoppala Reviewed-by: Michel Thierry Signed-off-by: Daniel Vetter

drm/i915: Do not leak objects after capturing error state

2015-03-20T14:46:46Z

While running kmemleak chasing a different memleak, I saw that the capture_error_state function was leaking some objects, for example: unreferenced object 0xffff8800a9b72148 (size 8192): comm "kworker/u16:0", pid 1499, jiffies 4295201243 (age 990.096s) hex dump (first 32 bytes): 00 00 04 00 00 00 00 00 5d f4 ff ff 00 00 00 00 ........]....... 00 30 b0 01 00 00 00 00 37 00 00 00 00 00 00 00 .0......7....... backtrace: [] create_object+0x104/0x2c0 [] kmemleak_alloc+0x7a/0xc0 [] __kmalloc+0xeb/0x220 [] kcalloc.constprop.12+0x2d/0x2f [i915] [] i915_capture_error_state+0x3f4/0x1660 [i915] [] i915_handle_error+0x7f/0x660 [i915] [] i915_hangcheck_elapsed+0x2e7/0x470 [i915] [] process_one_work+0x144/0x490 [] worker_thread+0x11d/0x530 [] kthread+0xc9/0xe0 [] ret_from_fork+0x58/0x90 [] 0xffffffffffffffff The following objects are allocated in i915_gem_capture_buffers, but not released in i915_error_state_free: - error->active_bo_count - error->pinned_bo - error->pinned_bo_count - error->active_bo[vm_count] (allocated in i915_gem_capture_vm). The leaks were introduced by commit 95f5301dd880da2dea2c9a9c29750064536d426a Author: Ben Widawsky Date: Wed Jul 31 17:00:15 2013 -0700 drm/i915: Update error capture for VMs v2: Reuse iterator and add culprit commit details (Chris) Cc: Chris Wilson Signed-off-by: Michel Thierry Signed-off-by: Daniel Vetter

drm/i915: Add process identifier to requests

2015-02-13T22:28:37Z

We use the pid of the process which opened our device when we track which was the culprit of the gpu hang. But as that file descriptor might get inherited, we might blame the wrong process when we record the error state. Track process identifiers in requests to always find the correct offender. v2: Track only user processes (Chris) Cc: Kenneth Graunke Cc: Chris Wilson Signed-off-by: Mika Kuoppala [danvet: drop NULL check before put_pid as suggested by Chris.] Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter

drm/i915: Removed duplicate members from submit_request

2015-01-27T08:50:52Z

Where there were duplicate variables for the tail, context and ring (engine) in the gem request and the execlist queue item, use the one from the request and remove the duplicate from the execlist queue item. Issue: VIZ-4274 v1: Rebase v2: Fixed build issues. Keep separate postfix & tail pointers as these are used in different ways. Reinserted missing full tail pointer update. Signed-off-by: Nick Hoath Reviewed-by: Thomas Daniel Signed-off-by: Daniel Vetter

drm/i915: Organize INSTDONE report for future.

2014-12-17T17:18:43Z

drm/i915: Organize PDP regs report for future.

2014-12-17T17:18:34Z

drm/i915: Organize Fence registers for future enablement.

2014-12-17T17:17:54Z

Let's be optimistic that for future platforms this will remain the same and reorg a bit. This reorg in if blocks instead of switch make life easier for future platform support addition. v2: Jani pointed out I was missing reg_830 for some gen3 platforms. So let's make this platforms subcases of Gen checks. Cc: Jani Nikula Cc: Damien Lespiau Signed-off-by: Rodrigo Vivi Reviewed-by: Paulo Zanoni Signed-off-by: Daniel Vetter

drm/i915: Infrastructure for supporting different GGTT views per object

2014-12-15T10:25:04Z

Things like reliable GGTT mappings and mirrored 2d-on-3d display will need to map objects into the same address space multiple times. Added a GGTT view concept and linked it with the VMA to distinguish between multiple instances per address space. New objects and GEM functions which do not take this new view as a parameter assume the default of zero (I915_GGTT_VIEW_NORMAL) which preserves the previous behaviour. This now means that objects can have multiple VMA entries so the code which assumed there will only be one also had to be modified. Alternative GGTT views are supposed to borrow DMA addresses from obj->pages which is DMA mapped on first VMA instantiation and unmapped on the last one going away. v2: * Removed per view special casing in i915_gem_ggtt_prepare / finish_object in favour of creating and destroying DMA mappings on first VMA instantiation and last VMA destruction. (Daniel Vetter) * Simplified i915_vma_unbind which does not need to count the GGTT views. (Daniel Vetter) * Also moved obj->map_and_fenceable reset under the same check. * Checkpatch cleanups. v3: * Only retire objects once the last VMA is unbound. v4: * Keep scatter-gather table for alternative views persistent for the lifetime of the VMA. * Propagate binding errors to callers and handle appropriately. v5: * Explicitly look for normal GGTT view in i915_gem_obj_bound to align usage in i915_gem_object_ggtt_unpin. (Michel Thierry) * Change to single if statement in i915_gem_obj_to_ggtt. (Michel Thierry) * Removed stray semi-colon in i915_gem_object_set_cache_level. For: VIZ-4544 Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter Reviewed-by: Michel Thierry [danvet: Drop hunk from i915_gem_shrink since it's just prettification but upsets a __must_check warning.] Signed-off-by: Daniel Vetter

drm/i915: Remove the now redundant 'obj->ring'

2014-12-03T08:35:23Z

The ring member of the object structure was always updated with the last_read_seqno member. Thus with the conversion to last_read_req, obj->ring is now a direct copy of obj->last_read_req->ring. This makes it somewhat redundant and potentially misleading (especially as there was no comment to explain its purpose). This checkin removes the redundant field. Many uses were simply testing for non-null to see if the object is active on the GPU. Some of these have been converted to check 'obj->active' instead. Others (where the last_read_req is about to be used anyway) have been changed to check obj->last_read_req. The rest simply pull the ring out from the request structure and proceed as before. For: VIZ-4377 Signed-off-by: John Harrison Reviewed-by: Thomas Daniel Signed-off-by: Daniel Vetter

drm/i915: Replace last_[rwf]_seqno with last_[rwf]_req

2014-12-03T08:35:14Z

The object structure contains the last read, write and fenced seqno values for use in syncrhonisation operations. These have now been replaced with their request structure counterparts. Note that to ensure that objects do not end up with dangling pointers, the assignments of last_*_req include reference count updates. Thus a request cannot be freed if an object is still hanging on to it for any reason. v2: Corrected 'last_rendering_' to 'last_read_' in a number of comments that did not get updated when 'last_rendering_seqno' became 'last_read|write_seqno' several millenia ago. For: VIZ-4377 Signed-off-by: John Harrison Reviewed-by: Thomas Daniel Signed-off-by: Daniel Vetter