- 21 Nov, 2016 2 commits
-
-
Chris Wilson authored
For user actions, such as the context ioctls, we prefer to use DRM_DEBUG rather than DRM_DEBUG_DRIVER as currently used. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20161121113109.1976-1-chris@chris-wilson.co.ukReviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Daniel Vetter authored
Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 Nov, 2016 9 commits
-
-
Chris Wilson authored
If the LLC is coherent with the object, we do not need to worry about whether main memory and cache mismatch when we hand the object back to the system. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161118211747.25197-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Currently we only clflush the scanout if it is in the CPU domain. Also flush if we have a pending CPU clflush. We also want to treat the dirtyfb path similar, and flush any pending writes there as well. v2: Only send the fb flush message if flushing the dirt on flip v3: Make flush-for-flip and dirtyfb look more alike since they serve similar roles as end-of-frame marker. Signed-off-by:
-
Chris Wilson authored
On the DMA mapping error path, sg may be NULL (it has already been marked as the last scatterlist entry), and we should avoid dereferencing it again. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: e2273302 ("drm/i915: avoid leaking DMA mappings") Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
Chris Wilson authored
Trying to chase an impossible bug (ivb): [ 207.765411] [drm:i915_reset_and_wakeup [i915]] resetting chip [ 207.765734] [drm:i915_gem_reset [i915]] resetting render ring to restart from tail of request 0x4ee834 [ 207.765791] [drm:intel_print_rc6_info [i915]] Enabling RC6 states: RC6 on RC6p on RC6pp off [ 207.767213] [drm:intel_guc_setup [i915]] GuC fw status: path (null), fetch NONE, load NONE [ 207.767515] kernel BUG at drivers/gpu/drm/i915/i915_gem_request.c:203! [ 207.767551] invalid opcode: 0000 [#1] PREEMPT SMP [ 207.767576] Modules linked in: snd_hda_intel i915 cdc_ncm usbnet mii x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel lpc_ich snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core mei_me mei snd_pcm sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915] [ 207.767808] CPU: 3 PID: 8855 Comm: gem_ringfill Tainted: G U 4.9.0-rc5-CI-Patchwork_3052+ #1 [ 207.767854] Hardware name: LENOVO 2356GCG/2356GCG, BIOS G7ET31WW (1.13 ) 07/02/2012 [ 207.767894] task: ffff88012c82a740 task.stack: ffffc9000383c000 [ 207.767927] RIP: 0010:[<ffffffffa00a0a3a>] [<ffffffffa00a0a3a>] i915_gem_request_retire+0x2a/0x4b0 [i915] [ 207.767999] RSP: 0018:ffffc9000383fb20 EFLAGS: 00010293 [ 207.768027] RAX: 00000000004ee83c RBX: ffff880135dcb480 RCX: 00000000004ee83a [ 207.768062] RDX: ffff88012fea42a8 RSI: 0000000000000001 RDI: ffff88012c82af68 [ 207.768095] RBP: ffffc9000383fb48 R08: 0000000000000000 R09: 0000000000000000 [ 207.768129] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880135dcb480 [ 207.768163] R13: ffff88012fea42a8 R14: 0000000000000000 R15: 00000000000001d8 [ 207.768200] FS: 00007f955f658740(0000) GS:ffff88013e2c0000(0000) knlGS:0000000000000000 [ 207.768239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 207.768258] CR2: 0000555899725930 CR3: 00000001316f6000 CR4: 00000000001406e0 [ 207.768286] Stack: [ 207.768299] ffff880135dcb480 ffff880135dcbe00 ffff88012fea42a8 0000000000000000 [ 207.768350] 00000000000001d8 ffffc9000383fb70 ffffffffa00a1339 0000000000000000 [ 207.768402] ffff88012f296c88 00000000000003f0 ffffc9000383fbb0 ffffffffa00b582d [ 207.768453] Call Trace: [ 207.768493] [<ffffffffa00a1339>] i915_gem_request_retire_upto+0x49/0x90 [i915] [ 207.768553] [<ffffffffa00b582d>] intel_ring_begin+0x15d/0x2d0 [i915] [ 207.768608] [<ffffffffa00b59cb>] intel_ring_alloc_request_extras+0x2b/0x40 [i915] [ 207.768667] [<ffffffffa00a2fd9>] i915_gem_request_alloc+0x359/0x440 [i915] [ 207.768723] [<ffffffffa008bd03>] i915_gem_do_execbuffer.isra.15+0x783/0x1a10 [i915] [ 207.768766] [<ffffffff811a6a2e>] ? __might_fault+0x3e/0x90 [ 207.768816] [<ffffffffa008d380>] i915_gem_execbuffer2+0xc0/0x250 [i915] [ 207.768854] [<ffffffff815532a6>] drm_ioctl+0x1f6/0x480 [ 207.768900] [<ffffffffa008d2c0>] ? i915_gem_execbuffer+0x330/0x330 [i915] [ 207.768939] [<ffffffff81202f6e>] do_vfs_ioctl+0x8e/0x690 [ 207.768972] [<ffffffff818193ac>] ? retint_kernel+0x2d/0x2d [ 207.769004] [<ffffffff810d6ef2>] ? trace_hardirqs_on_caller+0x122/0x1b0 [ 207.769039] [<ffffffff812035ac>] SyS_ioctl+0x3c/0x70 [ 207.769068] [<ffffffff818189ae>] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 207.769103] Code: 90 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fc 53 8b 35 fa 7b e1 e1 85 f6 0f 85 55 03 00 00 41 8b 84 24 80 02 00 00 85 c0 75 02 <0f> 0b 49 8b 94 24 a8 00 00 00 48 8b 8a e0 01 00 00 8b 89 c0 00 [ 207.769400] RIP [<ffffffffa00a0a3a>] i915_gem_request_retire+0x2a/0x4b0 [i915] [ 207.769463] RSP <ffffc9000383fb20> Let's add a couple more BUG_ONs before this to ascertain that the request did make it to hardware. The impossible part of this stacktrace is that request must have been considered completed by the i915_request_wait() before we tried to retire it. Signed-off-by:
-
Matthew Auld authored
When gathering the pages from our backing storage we expect get_pages() to either give us our sg_table or an err ptr. However when gathering our fake pages for stolen memory we may return NULL in the event of a failure. To prevent any funny business we should therefore return the proper err ptr value. Fixes: 03ac84f1 ("drm/i915: Pass around sg_table to get_pages/put_pages backend") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1478609742-13603-12-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #irc
-
Chris Wilson authored
Since we can retire requests from multiple paths, we cannot assume that i915_gem_retire_requests() is the sole path on which we can transition to gt.active_requests == 0. A consequence of this is that we would skip the function if we had already retired all the requests and not scheduled the idle worker. This is fallout from changing the routine from considering active_engines (for which it was the only consumer) to active_requests. v2: Move kicking the idle working to i915_gem_request_retire() otherwise we could postpone the idle callback everytime we called retire_requests even though we did no work. v3: We only need to move the idle work kicking! v4: Drop the BUG_ON(!awake) as we may be called from the shrinker in the middle of constructing a request before we have marked the device awake. v5: Add a BUG_ON() for active_requests underflow upon retirement (Joonas) Fixes: 28176ef4 ("drm/i915: Reserve space in the global seqno during request allocation") Signed-off-by:
-
Chris Wilson authored
I tried to avoid having to track the write for every VMA by only tracking writes to the ggtt. However, for the purposes of frontbuffer tracking this is insufficient as we need to invalidate around writes not just to the the ggtt but all aliased ppgtt views of the framebuffer. By moving the critical section to the object and only doing so for framebuffer writes we can reduce the tracking even further by only watching framebuffers and not vma. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Otherwise it is just an useless empty line. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by:
-
- 17 Nov, 2016 29 commits
-
-
Matthew Auld authored
We need to clean up the global_timeline in i915_gem_load_cleanup. v2: don't forget about the struct_mutex, and also WARN_ON if we have any remaining timelines before purging the global_timeline. v3: it might be a good idea to first remove the global_timeline...duh! Fixes: 73cb9701 ("drm/i915: Combine seqno + tracking into a global timeline struct") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Matthew Auld authored
We already have an i915_address_space_init, so for symmetry we should also have a _fini, plus we already open code it twice. This then also fixes a bug where we leak the timeline for the ggtt vm. v2: don't forget about the struct_mutex for the ggtt path. Fixes: 80b204bc ("drm/i915: Enable multiple timelines") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
We should never be called via obj->ops->release() on anything other than a fully formed stolen object, so raise that to an assert. In the process tidy up a comment and variable no longer used outside of a conditional BUG. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
We have to make sure there are no holes in the table in Gen9. Signed-off-by:
-
Tvrtko Ursulin authored
Similar to existing yesno and onoff and use it throughout the code. Signed-off-by:
-
Tvrtko Ursulin authored
Signed-off-by: -
Tvrtko Ursulin authored
Signed-off-by: -
Tvrtko Ursulin authored
Signed-off-by: -
Tvrtko Ursulin authored
Kernel pointer does not sound like an useful thing to log and pipe name is already contained in the crtc name. Signed-off-by: -
Tvrtko Ursulin authored
Signed-off-by: -
Tvrtko Ursulin authored
And also only dump DP config for crtcs with DP encoders. Signed-off-by: -
Chris Wilson authored
We don't spam the debug when we create a normal object, nor when we allocate their pages. Yet we do for stolen objects, and since these are quite frequently used (at least once per context), the resulting spam floods the dmesg in CI. Signed-off-by:
-
Chris Wilson authored
We use DRM_DEBUG() when reporting on user actions, to try and keep intentional errors out of the CI dmesg. Demote the debug from i915_gem_open() similarly so that it is only apparent with drm.debug & 1 like its brethren. Signed-off-by:
-
Tvrtko Ursulin authored
It looks to me skl_update_scaler will already log interesting debug messages when the state transitions or there is an error. In this case it feels we can remove the two unconditional debug messages which happen immediately before calling skl_update_scaler. This way we get rid of the sole debug message when switching virtual terminals for example. Signed-off-by:
-
Tvrtko Ursulin authored
And at the same time introduce a static inline helper for more type safety. Signed-off-by:
-
Tvrtko Ursulin authored
Macro takes dev_priv and not dev. Signed-off-by:
-
Tvrtko Ursulin authored
v2: Rebase. Signed-off-by:
-
Tvrtko Ursulin authored
Plus a trickle of function prototype changes. Signed-off-by:
-
Tvrtko Ursulin authored
And as usual a little bit of cascaded function prototype changes. Signed-off-by:
-
Tvrtko Ursulin authored
A bunch of source files with just a few instances of the incorrect INTEL_INFO use. Signed-off-by:
-
Tvrtko Ursulin authored
And a little bit of function prototype changes. Signed-off-by:
-
Tvrtko Ursulin authored
And a little bit of function prototype changes. Signed-off-by:
-
Tvrtko Ursulin authored
And a little bit of cascaded function prototype changes. Signed-off-by:
-
Tvrtko Ursulin authored
And a little bit of cascaded function prototype changes. Signed-off-by:
-
Tvrtko Ursulin authored
And a little bit of cascaded function prototype changes. Signed-off-by:
-
Tvrtko Ursulin authored
Started with removing INTEL_INFO(dev) and cascaded into a quite big trickle of function prototype changes. Still, I think it is for the better. Signed-off-by:
-
Tvrtko Ursulin authored
Plus a small cascade of function prototype changes. Signed-off-by:
-
Tvrtko Ursulin authored
Signed-off-by:
-
Tvrtko Ursulin authored
Signed-off-by:
-
