Matthew Brost [Sat, 7 Dec 2019 01:00:33 +0000 (17:00 -0800)]
drm/i915/guc: Update uncore access path in flush_ggtt_writes
The preferred way to access the uncore is through the GT structure.
Update the GuC function, flush_ggtt_writes, to use this path.
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <john.c.harrison@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191207010033.24667-1-John.C.Harrison@Intel.com
Chris Wilson [Fri, 6 Dec 2019 10:55:26 +0000 (10:55 +0000)]
drm/i915/gem: Pin gen6_ppgtt prior to constructing the request
All pinning must be done prior to i915_request_create, to avoid
timeline->mutex inversions.
Here we slightly abuse the context_barrier_task stages to utilise the
'skip' decision as an opportunity to acquire the pin on the new ppgtt.
Consider it s/skip/prepare/. At the moment, we only have on user of
context_barrier_task, so it might be worth breaking it down for the
specific task of set-vm and refactor it later if we find a second
purpose.
<4> [402.377487] WARNING: possible circular locking dependency detected
<4> [402.377493] 5.4.0-rc8-CI-CI_DRM_7491+ #1 Tainted: G U
<4> [402.377497] ------------------------------------------------------
<4> [402.377502] gem_exec_parall/2506 is trying to acquire lock:
<4> [402.377507]
ffff888403cdac70 (&kernel#2){+.+.}, at: i915_request_create+0x16/0x1c0 [i915]
<4> [402.377593]
but task is already holding lock:
<4> [402.377597]
ffff88835efad550 (&ppgtt->pin_mutex){+.+.}, at: gen6_ppgtt_pin+0x4d/0x110 [i915]
<4> [402.377660]
which lock already depends on the new lock.
<4> [402.377664]
the existing dependency chain (in reverse order) is:
<4> [402.377668]
-> #1 (&ppgtt->pin_mutex){+.+.}:
<4> [402.377674] __mutex_lock+0x9a/0x9d0
<4> [402.377713] gen6_ppgtt_pin+0x4d/0x110 [i915]
<4> [402.377756] emit_ppgtt_update+0x1dc/0x370 [i915]
<4> [402.377801] context_barrier_task+0x176/0x310 [i915]
<4> [402.377844] ctx_setparam+0x400/0xb10 [i915]
<4> [402.377886] i915_gem_context_setparam_ioctl+0xc8/0x160 [i915]
<4> [402.377891] drm_ioctl_kernel+0xa7/0xf0
<4> [402.377895] drm_ioctl+0x2e1/0x390
<4> [402.377899] do_vfs_ioctl+0xa0/0x6f0
<4> [402.377903] ksys_ioctl+0x35/0x60
<4> [402.377906] __x64_sys_ioctl+0x11/0x20
<4> [402.377910] do_syscall_64+0x4f/0x210
<4> [402.377914] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [402.377917]
-> #0 (&kernel#2){+.+.}:
<4> [402.377923] __lock_acquire+0x1328/0x15d0
<4> [402.377926] lock_acquire+0xa7/0x1c0
<4> [402.377930] __mutex_lock+0x9a/0x9d0
<4> [402.377977] i915_request_create+0x16/0x1c0 [i915]
<4> [402.378013] intel_engine_flush_barriers+0x4c/0x100 [i915]
<4> [402.378062] i915_ggtt_pin+0x7d/0x130 [i915]
<4> [402.378108] gen6_ppgtt_pin+0x9c/0x110 [i915]
<4> [402.378148] ring_context_pin+0x2e/0xc0 [i915]
<4> [402.378183] __intel_context_do_pin+0x6b/0x190 [i915]
<4> [402.378226] i915_gem_do_execbuffer+0x180c/0x26b0 [i915]
<4> [402.378268] i915_gem_execbuffer2_ioctl+0x11b/0x460 [i915]
<4> [402.378272] drm_ioctl_kernel+0xa7/0xf0
<4> [402.378275] drm_ioctl+0x2e1/0x390
<4> [402.378279] do_vfs_ioctl+0xa0/0x6f0
<4> [402.378282] ksys_ioctl+0x35/0x60
<4> [402.378286] __x64_sys_ioctl+0x11/0x20
<4> [402.378289] do_syscall_64+0x4f/0x210
<4> [402.378292] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [402.378295]
other info that might help us debug this:
<4> [402.378299] Possible unsafe locking scenario:
<4> [402.378302] CPU0 CPU1
<4> [402.378305] ---- ----
<4> [402.378307] lock(&ppgtt->pin_mutex);
<4> [402.378310] lock(&kernel#2);
<4> [402.378314] lock(&ppgtt->pin_mutex);
<4> [402.378317] lock(&kernel#2);
<4> [402.378320]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206105527.1130413-4-chris@chris-wilson.co.uk
Andi Shyti [Fri, 6 Dec 2019 21:24:17 +0000 (23:24 +0200)]
drm/i915/gt: Replace I915_WRITE with its uncore counterpart
Get rid of the last remaining I915_WRITEs and replace them with
intel_uncore_write().
Signed-off-by: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206212417.20178-1-andi@etezian.org
José Roberto de Souza [Thu, 5 Dec 2019 21:03:50 +0000 (13:03 -0800)]
drm/i915/display: Refactor intel_commit_modeset_disables()
Commit
9c722e17c1b9 ("drm/i915: Disable pipes in reverse order")
reverted the order that pipes gets disabled because of TGL
master/slave relationship between transcoders in MST mode.
But as stated in a comment in skl_commit_modeset_enables() the
enabling order is not always crescent, possibly causing previously
selected slave transcoder being enabled before master so another
approach will be needed to select a transcoder to master in MST mode.
It will be similar to the approach taken in port sync.
But instead of implement something like
intel_trans_port_sync_modeset_disables() to MST lets simply it and
iterate over all pipes 2 times, the first one disabling any slave and
then disabling everything else.
The MST bits will be added in another patch.
v2:
Not using crtc->active as it is deprecated
v3:
Removing is_trans_port_sync_mode() check, just check for
is_trans_port_sync_master() is enough
v4:
Adding and using is_trans_port_sync_slave(), otherwise non-port sync
pipes will be disabled in the first loop, what is not wrong but is
not what patch description promises
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2)
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205210350.96795-3-jose.souza@intel.com
José Roberto de Souza [Thu, 5 Dec 2019 21:03:49 +0000 (13:03 -0800)]
drm/i915/display/tgl: Fix the order of the step to turn transcoder clock off
For TGL the step to turn off the transcoder clock was moved to after
the complete shutdown of DDI. Only the MST slave transcoders should
disable the clock before that.
v2:
- Adding last_mst_stream to intel_mst_post_disable_dp, make code more
easy to read and is similar to first_mst_stream in
intel_mst_pre_enable_dp()(Ville's idea)
- Calling intel_ddi_disable_pipe_clock() for GEN12+ right
intel_disable_ddi_buf() as stated in BSpec(Ville)
BSpec: 49190
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205210350.96795-2-jose.souza@intel.com
José Roberto de Souza [Thu, 5 Dec 2019 21:03:48 +0000 (13:03 -0800)]
drm/i915/display: Do not check for the ddb allocations of turned off pipes
It should not care about DDB allocations of pipes going through
a fullmodeset, as at this point those pipes are disabled.
The comment in the code also points to that but that was not what
was being executed.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205210350.96795-1-jose.souza@intel.com
José Roberto de Souza [Tue, 3 Dec 2019 21:13:08 +0000 (13:13 -0800)]
drm/i915: Add new EHL/JSL PCI ids
Adding the recently added EHL/JSL PCI ids.
BSpec: 29153
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203211308.109703-1-jose.souza@intel.com
Chris Wilson [Fri, 6 Dec 2019 16:04:28 +0000 (16:04 +0000)]
drm/i915: Propagate errors on awaiting already signaled dma-fences
If we see an already signaled dma-fence that we want to await on, we skip
adding to the i915_sw_fence. However, we should pay attention to whether
there was an error on that fence and if so propagate it for our future
request.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206160428.1503343-3-chris@chris-wilson.co.uk
Chris Wilson [Fri, 6 Dec 2019 16:04:27 +0000 (16:04 +0000)]
drm/i915: Propagate errors on awaiting already signaled fences
If we see an already signaled fence that we want to await on, we skip
adding to the i915_sw_fence. However, we should pay attention to whether
there was an error on that fence and if so propagate it for our future
request.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206160428.1503343-2-chris@chris-wilson.co.uk
Chris Wilson [Fri, 6 Dec 2019 16:04:26 +0000 (16:04 +0000)]
drm/i915: Check for error before calling cmpxchg()
Only do the locked compare of the existing fence->error if we actually
need to set an error. As we tend to call i915_sw_fence_set_error_once()
unconditionally, it saves on typing to put the common has-error check
into the inline.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206160428.1503343-1-chris@chris-wilson.co.uk
Tvrtko Ursulin [Fri, 29 Nov 2019 10:54:36 +0000 (10:54 +0000)]
drm/i915/pmu: Report frequency as zero while GPU is sleeping
We used to report the minimum possible frequency as both requested and
active while GPU was in sleep state. This was a consequence of sampling
the value from the "current frequency" field in our software tracking.
This was strictly speaking wrong, but given that until recently the
current frequency in sleeping state used to be equal to minimum, it did
not stand out sufficiently to be noticed as such.
After some recent changes have made the current frequency be reported
as last active before GPU went to sleep, meaning both requested and active
frequencies could end up being reported at their maximum values for the
duration of the GPU idle state, it became much more obvious that this does
not make sense.
To fix this we will now sample the frequency counters only when the GPU is
awake. As a consequence reported frequencies could be reported as below
the GPU reported minimum but that should be much less confusing that the
current situation.
v2:
* Split out early exit conditions for readability. (Chris)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Closes: https://gitlab.freedesktop.org/drm/intel/issues/675
Link: https://patchwork.freedesktop.org/patch/msgid/20191129105436.20100-1-tvrtko.ursulin@linux.intel.com
Chris Wilson [Fri, 6 Dec 2019 10:55:23 +0000 (10:55 +0000)]
drm/i915/gem: Flush the pwrite through the chipset before signaling
Before we signal the fence to indicate completion, ensure the pwrite
through the indirect GGTT is coherent (as best as we know) in memory.
Any listeners to the fence may start immediately and sample from the
backing store prior to the writes being posted, thus seeing stale data.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191206105527.1130413-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 5 Dec 2019 21:58:42 +0000 (21:58 +0000)]
drm/i915/gt: Acquire a GT wakeref for the breadcrumb interrupt
Take a wakeref on the intel_gt specifically for the enabled breadcrumb
interrupt so that we can safely process the mmio. If the intel_gt is
already asleep by the time we try and setup the breadcrumb interrupt, by
a process of elimination we know the request must have been completed
and we can skip its enablement!
<4> [1518.350005] Unclaimed write to register 0x220a8
<4> [1518.350323] WARNING: CPU: 2 PID: 3685 at drivers/gpu/drm/i915/intel_uncore.c:1163 __unclaimed_reg_debug+0x40/0x50 [i915]
<4> [1518.350393] Modules linked in: vgem snd_hda_codec_hdmi x86_pkg_temp_thermal i915 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core btusb cdc_ether btrtl usbnet btbcm btintel r8152 snd_pcm mii bluetooth ecdh_generic ecc i2c_hid pinctrl_sunrisepoint pinctrl_intel intel_lpss_pci prime_numbers [last unloaded: vgem]
<4> [1518.350646] CPU: 2 PID: 3685 Comm: gem_exec_parse_ Tainted: G U 5.4.0-rc8-CI-CI_DRM_7490+ #1
<4> [1518.350708] Hardware name: Google Caroline/Caroline, BIOS MrChromebox 08/27/2018
<4> [1518.350946] RIP: 0010:__unclaimed_reg_debug+0x40/0x50 [i915]
<4> [1518.350992] Code: 74 05 5b 5d 41 5c c3 45 84 e4 48 c7 c0 95 8d 47 a0 48 c7 c6 8b 8d 47 a0 48 0f 44 f0 89 ea 48 c7 c7 9e 8d 47 a0 e8 40 45 e3 e0 <0f> 0b 83 2d 27 4f 2a 00 01 5b 5d 41 5c c3 66 90 41 55 41 54 55 53
<4> [1518.351100] RSP: 0018:
ffffc900007f39c8 EFLAGS:
00010086
<4> [1518.351140] RAX:
0000000000000000 RBX:
0000000000000000 RCX:
0000000000000006
<4> [1518.351202] RDX:
0000000080000006 RSI:
0000000000000000 RDI:
00000000ffffffff
<4> [1518.351249] RBP:
00000000000220a8 R08:
0000000000000000 R09:
0000000000000000
<4> [1518.351296] R10:
ffffc900007f3990 R11:
ffffc900007f3868 R12:
0000000000000000
<4> [1518.351342] R13:
00000000fefeffff R14:
0000000000000092 R15:
ffff888155fea000
<4> [1518.351391] FS:
00007fc255abfe40(0000) GS:
ffff88817ab00000(0000) knlGS:
0000000000000000
<4> [1518.351445] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
<4> [1518.351485] CR2:
00007fc2554882d0 CR3:
0000000168ca2005 CR4:
00000000003606e0
<4> [1518.351529] Call Trace:
<4> [1518.351746] fwtable_write32+0x114/0x1d0 [i915]
<4> [1518.351795] ? sync_file_alloc+0x80/0x80
<4> [1518.352039] gen8_logical_ring_enable_irq+0x30/0x50 [i915]
<4> [1518.352295] irq_enable.part.10+0x23/0x40 [i915]
<4> [1518.352523] i915_request_enable_breadcrumb+0xb5/0x330 [i915]
<4> [1518.352575] ? sync_file_alloc+0x80/0x80
<4> [1518.352612] __dma_fence_enable_signaling+0x60/0x160
<4> [1518.352653] ? sync_file_alloc+0x80/0x80
<4> [1518.352685] dma_fence_add_callback+0x44/0xd0
<4> [1518.352726] sync_file_poll+0x95/0xc0
<4> [1518.352767] do_sys_poll+0x24d/0x570
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205215842.862750-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 5 Dec 2019 21:41:59 +0000 (21:41 +0000)]
drm/i915: Claim vma while under closed_lock in i915_vma_parked()
Remove the vma we wish to destroy from the gt->closed_list to avoid
having two i915_vma_parked() try and free it.
Fixes: aa5e4453dc05 ("drm/i915/gem: Try to flush pending unbind events")
References:
2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205214159.829727-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 5 Dec 2019 23:40:59 +0000 (23:40 +0000)]
drm/i915/gt: Trim gen6 ppgtt updates to PD cachelines
It appears now that we have the ring TLB invalidation in place, we need
only update the page directory cachelines that we have altered. A great
reduction from rewriting the whole 2MiB ppgtt on every update.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205234059.1010030-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 5 Dec 2019 18:33:32 +0000 (18:33 +0000)]
drm/i915: Serialise i915_active_acquire() with __active_retire()
As __active_retire() does it's final atomic_dec() under the
ref->tree_lock spinlock, in order to prevent ourselves from reusing the
ref->cache and ref->tree as they are being destroyed, we need to
serialise with the retirement during i915_active_acquire().
[ +0.000005] kernel BUG at drivers/gpu/drm/i915/i915_active.c:157!
[ +0.000011] invalid opcode: 0000 [#1] SMP
[ +0.000004] CPU: 7 PID: 188 Comm: kworker/u16:4 Not tainted
5.4.0-rc8-03070-gac5e57322614 #89
[ +0.000002] Hardware name: Razer Razer Blade Stealth 13 Late 2019/LY320, BIOS 1.02 09/10/2019
[ +0.000082] Workqueue: events_unbound active_work [i915]
[ +0.000059] RIP: 0010:__active_retire+0x115/0x120 [i915]
[ +0.000003] Code: 75 28 48 8b 3d 8c 6e 1a 00 48 89 ee e8 e4 5f a5 c0 48 8b 44 24 10 65 48 33 04 25 28 00 00 00 75 0f 48 83 c4 18 5b 5d 41 5c c3 <0f> 0b 0f 0b 0f 0b e8 a0 90 87 c0 0f 1f 44 00 00 48 8b 3d 54 6e 1a
[ +0.000002] RSP: 0018:
ffffb833003f7e48 EFLAGS:
00010286
[ +0.000003] RAX:
ffff8d6e8d726d00 RBX:
ffff8d6f9db4e840 RCX:
0000000000000000
[ +0.000001] RDX:
ffffffff82605930 RSI:
ffff8d6f9adc4908 RDI:
ffff8d6e96cefe28
[ +0.000002] RBP:
ffff8d6e96cefe00 R08:
0000000000000000 R09:
ffff8d6f9ffe9a50
[ +0.000002] R10:
0000000000000048 R11:
0000000000000018 R12:
ffff8d6f9adc4930
[ +0.000001] R13:
ffff8d6f9e04fb00 R14:
0000000000000000 R15:
ffff8d6f9adc4988
[ +0.000002] FS:
0000000000000000(0000) GS:
ffff8d6f9ffc0000(0000) knlGS:
0000000000000000
[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ +0.000002] CR2:
000055eb5a34cf10 CR3:
000000018d609002 CR4:
0000000000760ee0
[ +0.000002] PKRU:
55555554
[ +0.000001] Call Trace:
[ +0.000010] process_one_work+0x1aa/0x350
[ +0.000004] worker_thread+0x4d/0x3a0
[ +0.000004] kthread+0xfb/0x130
[ +0.000004] ? process_one_work+0x350/0x350
[ +0.000003] ? kthread_park+0x90/0x90
[ +0.000005] ret_from_fork+0x1f/0x40
Reported-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes: c9ad602feabe ("drm/i915: Split i915_active.mutex into an irq-safe spinlock for the rbtree")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Matthew Auld <matthew.auld@intel.com>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205183332.801237-1-chris@chris-wilson.co.uk
Andi Shyti [Thu, 5 Dec 2019 16:44:22 +0000 (16:44 +0000)]
drm/i915/gt: Replace I915_READ with intel_uncore_read
Get rid of the last remaining I915_READ in gt/ and make gt-land
the first I915_READ-free happy island.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205164422.727968-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 5 Dec 2019 14:59:34 +0000 (14:59 +0000)]
drm/i915/gt: Save irqstate around virtual_context_destroy
As virtual_context_destroy() may be called from a request signal, it may
be called from inside an irq-off section, and so we need to do a full
save/restore of the irq state rather than blindly re-enable irqs upon
unlocking.
<4> [110.024262] WARNING: inconsistent lock state
<4> [110.024277] 5.4.0-rc8-CI-CI_DRM_7489+ #1 Tainted: G U
<4> [110.024292] --------------------------------
<4> [110.024305] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
<4> [110.024323] kworker/0:0/5 [HC0[0]:SC0[0]:HE1:SE1] takes:
<4> [110.024338]
ffff88826a0c7a18 (&(&rq->lock)->rlock){?.-.}, at: i915_request_retire+0x221/0x930 [i915]
<4> [110.024592] {IN-HARDIRQ-W} state was registered at:
<4> [110.024612] lock_acquire+0xa7/0x1c0
<4> [110.024627] _raw_spin_lock_irqsave+0x33/0x50
<4> [110.024788] intel_engine_breadcrumbs_irq+0x38c/0x600 [i915]
<4> [110.024808] irq_work_run_list+0x49/0x70
<4> [110.024824] irq_work_run+0x26/0x50
<4> [110.024839] smp_irq_work_interrupt+0x44/0x1e0
<4> [110.024855] irq_work_interrupt+0xf/0x20
<4> [110.024871] __do_softirq+0xb7/0x47f
<4> [110.024885] irq_exit+0xba/0xc0
<4> [110.024898] do_IRQ+0x83/0x160
<4> [110.024910] ret_from_intr+0x0/0x1d
<4> [110.024922] irq event stamp: 172864
<4> [110.024938] hardirqs last enabled at (172863): [<
ffffffff819ea214>] _raw_spin_unlock_irq+0x24/0x50
<4> [110.024963] hardirqs last disabled at (172864): [<
ffffffff819e9fba>] _raw_spin_lock_irq+0xa/0x40
<4> [110.024988] softirqs last enabled at (172812): [<
ffffffff81c00385>] __do_softirq+0x385/0x47f
<4> [110.025012] softirqs last disabled at (172797): [<
ffffffff810b829a>] irq_exit+0xba/0xc0
<4> [110.025031]
other info that might help us debug this:
<4> [110.025049] Possible unsafe locking scenario:
<4> [110.025065] CPU0
<4> [110.025075] ----
<4> [110.025084] lock(&(&rq->lock)->rlock);
<4> [110.025099] <Interrupt>
<4> [110.025109] lock(&(&rq->lock)->rlock);
<4> [110.025124]
*** DEADLOCK ***
<4> [110.025144] 4 locks held by kworker/0:0/5:
<4> [110.025156] #0:
ffff88827588f528 ((wq_completion)events){+.+.}, at: process_one_work+0x1de/0x620
<4> [110.025187] #1:
ffffc9000006fe78 ((work_completion)(&engine->retire_work)){+.+.}, at: process_one_work+0x1de/0x620
<4> [110.025219] #2:
ffff88825605e270 (&kernel#2){+.+.}, at: engine_retire+0x57/0xe0 [i915]
<4> [110.025405] #3:
ffff88826a0c7a18 (&(&rq->lock)->rlock){?.-.}, at: i915_request_retire+0x221/0x930 [i915]
<4> [110.025634]
stack backtrace:
<4> [110.025653] CPU: 0 PID: 5 Comm: kworker/0:0 Tainted: G U 5.4.0-rc8-CI-CI_DRM_7489+ #1
<4> [110.025675] Hardware name: /NUC7i5BNB, BIOS BNKBL357.86A.0054.2017.1025.1822 10/25/2017
<4> [110.025856] Workqueue: events engine_retire [i915]
<4> [110.025872] Call Trace:
<4> [110.025891] dump_stack+0x71/0x9b
<4> [110.025907] mark_lock+0x49a/0x500
<4> [110.025926] ? print_shortest_lock_dependencies+0x200/0x200
<4> [110.025946] mark_held_locks+0x49/0x70
<4> [110.025962] ? _raw_spin_unlock_irq+0x24/0x50
<4> [110.025978] lockdep_hardirqs_on+0xa2/0x1c0
<4> [110.025995] _raw_spin_unlock_irq+0x24/0x50
<4> [110.026171] virtual_context_destroy+0xc5/0x2e0 [i915]
<4> [110.026376] __active_retire+0xb4/0x290 [i915]
<4> [110.026396] dma_fence_signal_locked+0x9e/0x1b0
<4> [110.026613] i915_request_retire+0x451/0x930 [i915]
<4> [110.026766] retire_requests+0x4d/0x60 [i915]
<4> [110.026919] engine_retire+0x63/0xe0 [i915]
Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex")
Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205145934.663183-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 5 Dec 2019 13:29:12 +0000 (13:29 +0000)]
drm/i915/gem: Reinitialise the local list before repeating
As we may start the loop again, we require our local list of i915_vma
we've processed to be reinitialised.
Fixes: aa5e4453dc05 ("drm/i915/gem: Try to flush pending unbind events")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/731
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205132912.606868-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 5 Dec 2019 11:37:26 +0000 (11:37 +0000)]
drm/i915/gt: Bump the PP_DIR invalidation for Baytrail
Invalidate the ring TLB and increase the delay required for Baytrail.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205113726.413351-3-chris@chris-wilson.co.uk
Chris Wilson [Thu, 5 Dec 2019 11:37:25 +0000 (11:37 +0000)]
drm/i915: Try hard to bind the context
It is not acceptable for context pinning to fail with -ENOSPC as we
should always be able to make space in the GGTT. The only reason we may
fail is that other "temporary" context pins are reserving their space
and we need to wait for an available slot.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/676
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205113726.413351-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 5 Dec 2019 11:37:24 +0000 (11:37 +0000)]
drm/i915: Ignore most failures during evict-vm
Removing all vma from the VM is best effort -- we only remove all those
ready to be removed, so forgive and VMA that becomes pinned. While
forgiving those that become pinned, also take a second look for any that
became unpinned as we waited.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191205113726.413351-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 4 Dec 2019 23:26:16 +0000 (23:26 +0000)]
drm/i915: Remove vestigal i915_gem_context locals from cmdparser
The use GEM context itself was removed in commit
cd30a5031704
("drm/i915/gem: Excise the per-batch whitelist from the context"), but
the locals were left in place as an oversight. Remove the parameters and
clean up.
References:
cd30a5031704 ("drm/i915/gem: Excise the per-batch whitelist from the context")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204232616.94397-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 4 Dec 2019 18:06:28 +0000 (18:06 +0000)]
drm/i915/gem: Hook user-extensions upto MMAP_OFFSET_IOCTL
Call i915_user_extensions() to validate the arg->extensions pointer, and
so return consistent error numbers for the future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204162803.3841140-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 4 Dec 2019 16:45:27 +0000 (16:45 +0000)]
drm/i915/gem: Hold the obj->vma.lock while walking the vma.list
Remember to take the lock before walking the obj->vma.list so that the
nodes do not change beneath us! E.g.,
i915_gem_object_bump_inactive_ggtt:387 GEM_BUG_ON(vma->vm != &i915->ggtt.vm)
Closes: https://gitlab.freedesktop.org/drm/intel/issues/691
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204164527.3872783-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 4 Dec 2019 12:35:56 +0000 (12:35 +0000)]
drm/i915/gem: Try to flush pending unbind events
If we cannot handle a vma within the unbind loop, try to flush the
pending events (i915_vma_parked, i915_vm_release) and try again. This
avoids a round trip to userspace that is not guaranteed to make forward
progress, as the events we wait upon require being idle.
References:
cb6c3d45f948 ("drm/i915/gem: Avoid parking the vma as we unbind")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204123556.3740002-1-chris@chris-wilson.co.uk
Abdiel Janulgue [Wed, 4 Dec 2019 12:00:32 +0000 (12:00 +0000)]
drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET
This is really just an alias of mmap_gtt. The 'mmap offset' nomenclature
comes from the value returned by this ioctl which is the offset into the
device fd which userpace uses with mmap(2).
mmap_gtt was our initial mmap_offset implementation, this extends
our CPU mmap support to allow additional fault handlers that depends on
the object's backing pages.
Note that we multiplex mmap_gtt and mmap_offset through the same ioctl,
and use the zero extending behaviour of drm to differentiate between
them, when we inspect the flags.
To support multiple mmap types on an object we need to support multiple
mmap_offsets for an object (each offset in the global device address
space corresponding to a unique instance of the object for a file + mmap
type). As we drop the simplified drm core idea of a single mmap_offset,
we need to provide replacement hooks for the dumb mmap interface as
well.
Link: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1675
Testcase: igt/gem_mmap_offset
Signed-off-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204120032.3682839-1-chris@chris-wilson.co.uk
Mao Wenan [Wed, 4 Dec 2019 01:01:54 +0000 (09:01 +0800)]
drm/i915/perf: drop pointless static qualifier in i915_perf_add_config_ioctl()
There is no need to have the 'T *v' variable static
since new value always be assigned before use it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204010154.152396-1-maowenan@huawei.com
Ville Syrjälä [Wed, 27 Nov 2019 19:05:56 +0000 (21:05 +0200)]
drm/i915: Make intel_crtc_arm_fifo_underrun() functional on gen2
Assuming intel_crtc_arm_fifo_underrun() only gets called when
there's no pending plane updates we can utilize it on gen2 by
checking the active_planes bitmask so that we only re-enable
underrun reporting if some planes are active.
i915_fifo_underrun_reset_write() seems to have the necessary
hw_done/flip_done waits in place.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-8-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 27 Nov 2019 19:05:55 +0000 (21:05 +0200)]
drm/i915: Nuke intel_pre_disable_primary_noatomic()
Let's just inline intel_pre_disable_primary_noatomic() into
intel_plane_disable_noatomic(). The CxSR disable we can do
regardless of which plane we're disabling, and while at it we can
make the gen2 underrun w/a accurate by consulting the active_planes
bitmask.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-7-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 27 Nov 2019 19:05:54 +0000 (21:05 +0200)]
drm/i915: Clean up the gen2 "no planes -> underrun" workaround
We have the active_planes bitmask now so use it to properly
determine when some planes are visible for the gen2 underrun
workaround.
This let's us almost eliminate intel_post_enable_primary().
The manual underrun checks we can simply move into
intel_atomic_commit_tail() since they loop over all the pipes
already. No point in repeating the checks multiple times when
there are multiple pipes in the commit.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-6-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 27 Nov 2019 19:05:53 +0000 (21:05 +0200)]
drm/i915: Clean up intel_{pre,post}_plane_update()
Change the calling convention to just pass the state+crtc and
switch to intel_ types throughout.
We'll also do a quick s/if (old_primary_state)/if (new_primary_state)/
so that we'll be able to eliminate old_primary_state later. This
is fine since we always have either both old and new state or neither.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-5-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 27 Nov 2019 19:05:52 +0000 (21:05 +0200)]
drm/i915: s/pipe_config/new_crtc_state/ intel_{pre,post}_plane_update()
Replace the old world 'pipe_config' variable name with the new thing.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-4-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 27 Nov 2019 19:05:51 +0000 (21:05 +0200)]
drm/i915: Pass dev_priv to ilk_disable_lp_wm()
Get rid of another 'dev' usage by passing dev_priv instead.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-3-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 27 Nov 2019 19:05:50 +0000 (21:05 +0200)]
drm/i915: Clean up arguments to nv12/scaler w/a funcs
Don't pass the redundant dev_priv to needs_nv12_wa() and
needs_scalerclk_wa().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127190556.1574-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Chris Wilson [Tue, 3 Dec 2019 21:16:31 +0000 (21:16 +0000)]
drm/i915/gt: Set the PD again for Haswell
And Haswell still occasionally forgets it is meant to be using a new
page directory, so repeat ourselves a little louder.
<7> [509.919864] heartbeat rcs0 heartbeat {prio:-
2147483645} not ticking
<7> [509.919895] heartbeat Awake? 8
<7> [509.919903] heartbeat Barriers?: no
<7> [509.919912] heartbeat Heartbeat: 3008 ms ago
<7> [509.919930] heartbeat Reset count: 0 (global 0)
<7> [509.919937] heartbeat Requests:
<7> [509.921008] heartbeat active a7eb:56e1* @ 5847ms:
<7> [509.921157] heartbeat ring->start: 0x00001000
<7> [509.921164] heartbeat ring->head: 0x00001610
<7> [509.921170] heartbeat ring->tail: 0x000023d8
<7> [509.921176] heartbeat ring->emit: 0x000023d8
<7> [509.921182] heartbeat ring->space: 0x00002570
<7> [509.921189] heartbeat ring->hwsp: 0x7fffe100
<7> [509.921197] heartbeat [head 1628, postfix 1738, tail 1750, batch 0xffffffff_ffffffff]:
<7> [509.921289] heartbeat [0000]
7a000002 00100002 00000000 00000000 7a000002 01154c1e 7ffff080 00000000
<7> [509.921299] heartbeat [0020]
11000001 00002220 ffffffff 12400001 00002220 7ffff000 00000000 11000001
<7> [509.921308] heartbeat [0040]
00002228 6e900000 7a000002 00100002 00000000 00000000 7a000002 01154c1e
<7> [509.921317] heartbeat [0060]
7ffff080 00000000 12400001 00002228 7ffff000 00000000 7a000002 00100002
<7> [509.921326] heartbeat [0080]
00000000 00000000 7a000002 01154c1e 7ffff080 00000000 7a000002 001010a1
<7> [509.921335] heartbeat [00a0]
7ffff080 00000000 04000000 11000005 00022050 00010001 00012050 00010001
<7> [509.921345] heartbeat [00c0]
0001a050 00010001 00000000 0c000000 459a110c 00000000 11000005 00022050
<7> [509.921354] heartbeat [00e0]
00010000 00012050 00010000 0001a050 00010000 12400001 0001a050 7ffff000
<7> [509.921363] heartbeat [0100]
00000000 04000001 18802100 00000000 7a000002 011050a1 7fffe100 000056e1
<7> [509.921370] heartbeat [0120]
01000000 00000000
<7> [509.921538] heartbeat MMIO base: 0x00002000
<7> [509.921682] heartbeat CCID: 0x3fa0110d
<7> [509.922342] heartbeat RING_START: 0x00001000
<7> [509.922353] heartbeat RING_HEAD: 0x00001628
<7> [509.922366] heartbeat RING_TAIL: 0x000023d8
<7> [509.922381] heartbeat RING_CTL: 0x00003001
<7> [509.922396] heartbeat RING_MODE: 0x00004000
<7> [509.922408] heartbeat RING_IMR:
ffffffde
<7> [509.922421] heartbeat ACTHD: 0x00000000_30e01628
<7> [509.922434] heartbeat BBADDR: 0x00000000_00004004
<7> [509.922446] heartbeat DMA_FADDR: 0x00000000_00002800
<7> [509.922458] heartbeat IPEIR: 0x00000000
<7> [509.922470] heartbeat IPEHR: 0x780c0000
<7> [509.922642] heartbeat PP_DIR_BASE: 0x6e700000
<7> [509.922652] heartbeat PP_DIR_BASE_READ: 0x00000000
<7> [509.922662] heartbeat PP_DIR_DCLV: 0xffffffff
<7> [509.922678] heartbeat E a7eb:56e1* @ 5849ms:
<7> [509.922689] heartbeat E a7eb:56e2- @ 5849ms:
<7> [509.922698] heartbeat E a7eb:56e3 @ 5848ms:
<7> [509.922707] heartbeat E a7eb:56e4 @ 5848ms:
<7> [509.922715] heartbeat E a7eb:56e5 @ 5847ms:
<7> [509.922724] heartbeat E a7eb:56e6 @ 5846ms:
<7> [509.922735] heartbeat E a7eb:56e7 @ 5846ms:
<7> [509.922744] heartbeat ...skipping 4 executing requests...
<7> [509.922754] heartbeat E a7eb:56ec @ 3010ms:
<7> [509.922796] heartbeat HWSP:
<7> [509.922807] heartbeat [0000]
00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922817] heartbeat [0020]
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922826] heartbeat *
<7> [509.922836] heartbeat [0100]
000056e0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922845] heartbeat [0120]
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922851] heartbeat *
<7> [509.922870] heartbeat Idle? no
<7> [509.922878] heartbeat Signals:
<7> [509.923000] heartbeat [a7eb:56e2] @ 5850ms
Here, we have a failed context restore after the PD switch, but note
that the PP_DIR_BASE register does not match the LRI in the ring.
Bump it to 8^W 4 loops, and with that Baytrail starts passing the sanity
checks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203211631.3167430-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 3 Dec 2019 15:50:32 +0000 (15:50 +0000)]
drm/i915/gem: Avoid parking the vma as we unbind
In order to avoid keeping a reference on the i915_vma (which is long
overdue!) we have to coordinate all the possible lifetimes and only use
the vma while we know it is alive. In this episode, we are reminded that
while idle, the closed vma are destroyed. So if the GT idles while we are
working with the vma, the vma itself becomes invalid.
First class i915_vma here we come, but in the meantime keep piling on
the straw.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203155032.3137263-1-chris@chris-wilson.co.uk
José Roberto de Souza [Mon, 2 Dec 2019 22:25:13 +0000 (14:25 -0800)]
drm/i915/display/mst: Move DPMS_OFF call to post_disable
Moving just to simplify handling as there is no change in behavior.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202222513.337777-3-jose.souza@intel.com
José Roberto de Souza [Mon, 2 Dec 2019 22:25:12 +0000 (14:25 -0800)]
drm/i915/dp: Power down sink before disable pipe/transcoder clock
Disabling pipe/transcoder clock before power down sink could cause
sink lost signal, causing it to trigger a hotplug to notify source
that link signal was lost.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202222513.337777-2-jose.souza@intel.com
José Roberto de Souza [Mon, 2 Dec 2019 22:25:11 +0000 (14:25 -0800)]
drm/i915/display: Check the old state to find port sync slave
If the CRTC is going from enabled to disabled and it is a port sync
slave, it needs to check to the old state to be disabled before the
port sync master.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202222513.337777-1-jose.souza@intel.com
Matt Roper [Mon, 2 Dec 2019 17:16:08 +0000 (09:16 -0800)]
drm/i915/irq: Refactor gen11 display interrupt handling
Let's move handling and reset for gen11 display IRQs to their own
functions, similar to how we deal with GT interrupts. This will make
the top-level functions a bit easier to read and potentially make things
easier to deal with in the future if new platforms wind up needing
different display handling logic.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202171608.3361125-1-matthew.d.roper@intel.com
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Chris Wilson [Tue, 3 Dec 2019 12:41:55 +0000 (12:41 +0000)]
drm/i915/gt: Track the context validity explicitly
Rather than assume if and only if the engine->default_state is not set
that the context is invalid, instead track when we know the context has
valid state -- either because we have copied the default_state or we
have completed a context switch to save the HW state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203124155.3019926-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 3 Dec 2019 15:26:31 +0000 (15:26 +0000)]
drm/i915/execlists: Skip nested spinlock for validating pending
Only along the submission path can we guarantee that the locked request
is indeed from a foreign engine, and so the nesting of engine/rq is
permissible. On the submission tasklet (process_csb()), we may find
ourselves competing with the normal nesting of rq/engine, invalidating
our nesting. As we only use the spinlock for debug purposes, skip the
debug if we cannot acquire the spinlock for safe validation - catching
99% of the bugs is better than causing a hard lockup.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: c95d31c3df1b ("drm/i915/execlists: Lock the request while validating it during promotion")
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203152631.3107653-2-chris@chris-wilson.co.uk
Chris Wilson [Tue, 3 Dec 2019 15:26:30 +0000 (15:26 +0000)]
drm/i915/execlists: Add a couple more validity checks to assert_pending()
Check the pending request submission is valid: that it at least has a
reference for the submission and that the request is on the active list.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203152631.3107653-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 2 Dec 2019 20:43:14 +0000 (20:43 +0000)]
drm/i915: Lift i915_vma_pin() out of intel_renderstate_emit()
Once inside a request, inside the timeline->mutex, pinning is verboten.
<4> [896.032829] ======================================================
<4> [896.032831] WARNING: possible circular locking dependency detected
<4> [896.032835] 5.4.0-rc8-CI-Patchwork_15533+ #1 Tainted: G U
<4> [896.032838] ------------------------------------------------------
<4> [896.032841] gem_exec_parall/3720 is trying to acquire lock:
<4> [896.032844]
ffff888401863270 (&kernel#2){+.+.}, at: i915_request_create+0x16/0x1c0 [i915]
<4> [896.032915]
but task is already holding lock:
<4> [896.032917]
ffff8883ec1c93c0 (&vm->mutex){+.+.}, at: i915_vma_pin+0xf3/0x11c0 [i915]
<4> [896.032952]
which lock already depends on the new lock.
<4> [896.032954]
the existing dependency chain (in reverse order) is:
<4> [896.032956]
-> #1 (&vm->mutex){+.+.}:
<4> [896.032961] __mutex_lock+0x9a/0x9d0
<4> [896.032995] i915_vma_pin+0xf3/0x11c0 [i915]
<4> [896.033033] intel_renderstate_emit+0xb9/0x9e0 [i915]
<4> [896.033081] i915_gem_init+0x5a9/0xa50 [i915]
<4> [896.033112] i915_driver_probe+0xb00/0x15f0 [i915]
<4> [896.033144] i915_pci_probe+0x43/0x1c0 [i915]
<4> [896.033149] pci_device_probe+0x9e/0x120
<4> [896.033154] really_probe+0xea/0x420
<4> [896.033158] driver_probe_device+0x10b/0x120
<4> [896.033161] device_driver_attach+0x4a/0x50
<4> [896.033164] __driver_attach+0x97/0x130
<4> [896.033168] bus_for_each_dev+0x74/0xc0
<4> [896.033171] bus_add_driver+0x142/0x220
<4> [896.033174] driver_register+0x56/0xf0
<4> [896.033178] do_one_initcall+0x58/0x2ff
<4> [896.033183] do_init_module+0x56/0x1f8
<4> [896.033187] load_module+0x243e/0x29f0
<4> [896.033190] __do_sys_finit_module+0xe9/0x110
<4> [896.033194] do_syscall_64+0x4f/0x210
<4> [896.033197] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [896.033200]
-> #0 (&kernel#2){+.+.}:
<4> [896.033206] __lock_acquire+0x1328/0x15d0
<4> [896.033209] lock_acquire+0xa7/0x1c0
<4> [896.033213] __mutex_lock+0x9a/0x9d0
<4> [896.033255] i915_request_create+0x16/0x1c0 [i915]
<4> [896.033287] intel_engine_flush_barriers+0x4c/0x100 [i915]
<4> [896.033327] ggtt_flush+0x37/0x60 [i915]
<4> [896.033366] i915_gem_evict_something+0x46b/0x5a0 [i915]
<4> [896.033407] i915_gem_gtt_insert+0x21d/0x6a0 [i915]
<4> [896.033449] i915_vma_pin+0xb36/0x11c0 [i915]
<4> [896.033488] gen6_ppgtt_pin+0xd5/0x170 [i915]
<4> [896.033523] ring_context_pin+0x2e/0xc0 [i915]
<4> [896.033554] __intel_context_do_pin+0x6b/0x190 [i915]
<4> [896.033591] i915_gem_do_execbuffer+0x1814/0x26c0 [i915]
<4> [896.033627] i915_gem_execbuffer2_ioctl+0x11b/0x460 [i915]
<4> [896.033632] drm_ioctl_kernel+0xa7/0xf0
<4> [896.033635] drm_ioctl+0x2e1/0x390
<4> [896.033638] do_vfs_ioctl+0xa0/0x6f0
<4> [896.033641] ksys_ioctl+0x35/0x60
<4> [896.033644] __x64_sys_ioctl+0x11/0x20
<4> [896.033647] do_syscall_64+0x4f/0x210
<4> [896.033650] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Lift the object allocation and pin prior to the request construction.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202204316.2665847-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 3 Dec 2019 10:13:46 +0000 (10:13 +0000)]
drm/i915/gem: Take runtime-pm wakeref prior to unbinding
Some machines require ACPI for runtime resume, and ACPI is quite kmalloc
happy. We cannot handle kmalloc from inside the vm->mutex, as they are
used by the shrinker, and so we must ensure the global runtime-pm is
awake prior to unbinding to avoid the potential inversion.
<4> [57.121748] ======================================================
<4> [57.121750] WARNING: possible circular locking dependency detected
<4> [57.121753] 5.4.0-rc8-CI-CI_DRM_7466+ #1 Tainted: G U
<4> [57.121754] ------------------------------------------------------
<4> [57.121756] i915_pm_rpm/1105 is trying to acquire lock:
<4> [57.121758]
ffffffff82263a40 (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.117+0x0/0x30
<4> [57.121766]
but task is already holding lock:
<4> [57.121768]
ffff888475a593c0 (&vm->mutex){+.+.}, at: i915_vma_unbind+0x21/0x50 [i915]
<4> [57.121868]
which lock already depends on the new lock.
<4> [57.121869]
the existing dependency chain (in reverse order) is:
<4> [57.121871]
-> #1 (&vm->mutex){+.+.}:
<4> [57.121951] i915_gem_shrinker_taints_mutex+0xa2/0xd0 [i915]
<4> [57.122028] i915_address_space_init+0xa9/0x170 [i915]
<4> [57.122104] i915_ggtt_init_hw+0x47/0x130 [i915]
<4> [57.122150] i915_driver_probe+0xbb4/0x15f0 [i915]
<4> [57.122197] i915_pci_probe+0x43/0x1c0 [i915]
<4> [57.122202] pci_device_probe+0x9e/0x120
<4> [57.122206] really_probe+0xea/0x420
<4> [57.122209] driver_probe_device+0x10b/0x120
<4> [57.122212] device_driver_attach+0x4a/0x50
<4> [57.122214] __driver_attach+0x97/0x130
<4> [57.122217] bus_for_each_dev+0x74/0xc0
<4> [57.122220] bus_add_driver+0x142/0x220
<4> [57.122222] driver_register+0x56/0xf0
<4> [57.122226] do_one_initcall+0x58/0x2ff
<4> [57.122230] do_init_module+0x56/0x1f8
<4> [57.122233] load_module+0x243e/0x29f0
<4> [57.122236] __do_sys_finit_module+0xe9/0x110
<4> [57.122239] do_syscall_64+0x4f/0x210
<4> [57.122242] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [57.122244]
-> #0 (fs_reclaim){+.+.}:
<4> [57.122249] __lock_acquire+0x1328/0x15d0
<4> [57.122251] lock_acquire+0xa7/0x1c0
<4> [57.122254] fs_reclaim_acquire.part.117+0x24/0x30
<4> [57.122257] __kmalloc+0x48/0x320
<4> [57.122261] acpi_ns_internalize_name+0x44/0x9b
<4> [57.122264] acpi_ns_get_node_unlocked+0x6b/0xd3
<4> [57.122267] acpi_ns_get_node+0x3b/0x50
<4> [57.122271] acpi_get_handle+0x8a/0xb4
<4> [57.122274] acpi_has_method+0x1c/0x40
<4> [57.122278] acpi_pci_set_power_state+0x40/0xe0
<4> [57.122281] pci_platform_power_transition+0x3e/0x90
<4> [57.122284] pci_set_power_state+0x83/0xf0
<4> [57.122287] pci_restore_standard_config+0x22/0x40
<4> [57.122289] pci_pm_runtime_resume+0x23/0xc0
<4> [57.122293] __rpm_callback+0xb1/0x110
<4> [57.122296] rpm_callback+0x1a/0x70
<4> [57.122299] rpm_resume+0x50e/0x790
<4> [57.122302] __pm_runtime_resume+0x42/0x80
<4> [57.122357] __intel_runtime_pm_get+0x15/0x60 [i915]
<4> [57.122435] ggtt_unbind_vma+0x24/0x60 [i915]
<4> [57.122514] __i915_vma_unbind.part.39+0xb5/0x500 [i915]
<4> [57.122593] i915_vma_unbind+0x2d/0x50 [i915]
<4> [57.122668] i915_gem_object_unbind+0x11c/0x260 [i915]
<4> [57.122740] i915_gem_object_set_cache_level+0x32/0x90 [i915]
<4> [57.122810] i915_gem_set_caching_ioctl+0x1f7/0x2f0 [i915]
<4> [57.122815] drm_ioctl_kernel+0xa7/0xf0
<4> [57.122818] drm_ioctl+0x2e1/0x390
<4> [57.122822] do_vfs_ioctl+0xa0/0x6f0
<4> [57.122825] ksys_ioctl+0x35/0x60
<4> [57.122828] __x64_sys_ioctl+0x11/0x20
<4> [57.122830] do_syscall_64+0x4f/0x210
<4> [57.122833] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Closes: https://gitlab.freedesktop.org/drm/intel/issues/711
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191203101347.2836057-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 2 Dec 2019 14:01:33 +0000 (14:01 +0000)]
drm/i915: Serialise i915_active_wait() with its retirement
As the i915_active.retire() may be running on another CPU as we detect
that the i915_active is idle, we may not wait for the retirement itself.
Wait for the remote callback by waiting for the retirement worker.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112424
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202140133.2444217-2-chris@chris-wilson.co.uk
Chris Wilson [Mon, 2 Dec 2019 14:01:32 +0000 (14:01 +0000)]
drm/i915: Specialise i915_active.work lock classes
Similar to for i915_active.mutex, we require each class of i915_active
to have distinct lockdep chains as some, but by no means all,
i915_active are used within the shrinker and so have much more severe
usage constraints. By using a lockclass local to i915_active_init() all
i915_active workers have the same lock class, and we may generate false
positives when waiting for the i915_active. If we push the lockclass
into the caller, each class of i915_active will have distinct lockdep
chains.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202140133.2444217-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 2 Dec 2019 17:43:10 +0000 (17:43 +0000)]
drm/i915/gem: Unbind all current vma on changing cache-level
Avoid dangerous race handling of destroyed vma by unbinding all vma
instead. Unfortunately, this stops us from trying to be clever and only
doing the minimal change required, so on first use of scanout we may
encounter an annoying stall as it transitions to a new cache level.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112413
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202174310.2630302-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 2 Dec 2019 11:08:36 +0000 (11:08 +0000)]
drm/i915/gt: Simplify rc6 w/a application
Quite simply we only need to check for prior corruption on enabling rc6
on module load and resume, so by hooking into the common entry points.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202110836.2342685-2-chris@chris-wilson.co.uk
Chris Wilson [Mon, 2 Dec 2019 11:08:35 +0000 (11:08 +0000)]
drm/i915/gt: Use soft-rc6 for w/a protection
Now that we have soft-rc6 in place, we can use that instead of the
forcewake to disable rc6 while active; preferred by a few
microbenchmarks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202110836.2342685-1-chris@chris-wilson.co.uk
Lucas De Marchi [Tue, 26 Nov 2019 22:51:10 +0000 (14:51 -0800)]
drm/i915/bios: assume vbt is 4-byte aligned into oprom
The unaligned ioread32() will make us read byte by byte looking for the
vbt. We could just as well have done a ioread8() + a shift and avoid the
extra confusion on how we are looking for "$VBT".
However when using ACPI it's guaranteed the VBT is 4-byte aligned
per spec, so we can probably assume it here as well.
v2: do not try to simplify the loop by eliminating the auxiliary counter
(Jani and Ville)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-4-lucas.demarchi@intel.com
Lucas De Marchi [Tue, 26 Nov 2019 22:51:09 +0000 (14:51 -0800)]
drm/i915/bios: fold pci rom map/unmap into copy function
We don't need to keep the pci rom mapped during the entire
intel_bios_init() anymore. Move it to the previous copy_vbt() function
and rename it to oprom_get_vbt() since now it's responsible to to all
operations related to get the vbt from the oprom.
v2: fix double __iomem attribute detected by sparse
v3: fix missing unmap on success (Ville)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-3-lucas.demarchi@intel.com
Lucas De Marchi [Tue, 26 Nov 2019 22:51:08 +0000 (14:51 -0800)]
drm/i915/bios: do not discard address space
When we map the VBT through pci_map_rom() we may not be allowed
to simply discard the address space and go on reading the memory.
That doesn't work on my test system, but by dumping the rom via
sysfs I can can get the correct vbt. So change our find_vbt() to do
the same as done by pci_read_rom(), i.e. use memcpy_fromio().
v2: the just the minimal changes by not bothering with the unaligned io
reads: this can be done on top (from Ville and Jani)
v3: drop const in function return since now we are copying the vbt,
rather than just finding it
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126225110.8127-2-lucas.demarchi@intel.com
José Roberto de Souza [Wed, 27 Nov 2019 02:16:09 +0000 (18:16 -0800)]
drm/i915/display: Suspend MST topology manager before destroy fbdev
MST topology needs to be suspended so we don't have any calls to
fbdev after it's finalized. MST will be destroyed later as part of
drm_mode_config_cleanup().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127021609.162700-1-jose.souza@intel.com
José Roberto de Souza [Thu, 28 Nov 2019 01:48:52 +0000 (17:48 -0800)]
drm/i915/vbt: Parse power conservation features block
From VBT 228+ this is block that PSR and other power saving
features configuration should be read from.
v3:
Using DRRS from this new block
v4:
Using BIT()
Fixing DRRS comment in parse_power_conservation_features()
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128014852.214135-5-jose.souza@intel.com
José Roberto de Souza [Thu, 28 Nov 2019 01:48:51 +0000 (17:48 -0800)]
drm/i915/psr: Check if sink PSR capability changed
eDP specification states that sink can have its PSR capability
changed, I have never found any panel doing that but lets add that
for completeness.
For now it is not reading back the PSR capabilities and if possible
re-enabling PSR, this will be added if a panel is found using this
feature.
v4:
Cleaning DP_PSR_CAPS_CHANGE
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128014852.214135-4-jose.souza@intel.com
José Roberto de Souza [Thu, 28 Nov 2019 01:48:50 +0000 (17:48 -0800)]
drm/i915/psr: Enable ALPM lock timeout error interruption
When this error happens sink link is not stable after the required
FW_EXIT_LATENCY period so it will miss the selective update.
As the other PSR errors, for now we are not trying to recover from
it.
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128014852.214135-3-jose.souza@intel.com
José Roberto de Souza [Thu, 28 Nov 2019 01:48:49 +0000 (17:48 -0800)]
drm/i915/psr: Refactor psr short pulse handler
eDP spec states that when sink enconters a problem that prevents it
to keep PSR running it should set PSR status to internal error and
set the reason why it happen to PSR_ERROR_STATUS but it is not how it
was implemented.
But also I don't want to change this behavior, who knows if there is
a panel out there that only set the PSR_ERROR_STATUS.
So here refactoring the code a bit to make more easy to read what was
state above as more checks will be added to this function.
v2:
returning a int instead of a bool in psr_get_status_and_error_status()
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128014852.214135-2-jose.souza@intel.com
José Roberto de Souza [Thu, 28 Nov 2019 01:48:48 +0000 (17:48 -0800)]
drm/i915/psr: Add bits per pixel limitation
PSR2 HW only support a limited number of bits per pixel, if mode has
more than supported PSR2 should not be enabled.
BSpec: 50422
BSpec: 7713
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128014852.214135-1-jose.souza@intel.com
Lucas De Marchi [Wed, 27 Nov 2019 22:11:21 +0000 (14:11 -0800)]
drm/i915/dsb: fix cmd_buf being wrongly set
The "err" label is not really "err", but rather "out" since the return
path is shared between error condition and normal path. This broke when
commit
03cea61076f0 ("drm/i915/dsb: fix extra warning on error path
handling") added a "dsb->cmd_buf = NULL;" there, making DSB to stop
working since now all writes would pass-through via mmio.
Remove the set to NULL since it's actually not needed: we only set it if
all steps are successful. While at it, rename the label so this confusion
doesn't happen again.
Fixes: 03cea61076f0 ("drm/i915/dsb: fix extra warning on error path handling")
Resolves: https://gitlab.freedesktop.org/drm/intel/issues/8
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127221119.384754-1-lucas.demarchi@intel.com
Ville Syrjälä [Fri, 29 Nov 2019 18:54:34 +0000 (20:54 +0200)]
drm/i915: Stop using connector->encoder and encoder->crtc links in i915_display_info
Migrate away from the legacy encoder->crtc and connector->encoder links
in the debugfs display_info code. Other users still remain so can't kill
these off yet.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-10-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Ville Syrjälä [Fri, 29 Nov 2019 18:54:33 +0000 (20:54 +0200)]
drm/i915: Dump both the uapi and hw states for crtcs and planes
Let's make the display info more useful by dumping both
the uapi and hw states for each crtc/plane.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-9-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Ville Syrjälä [Fri, 29 Nov 2019 18:54:32 +0000 (20:54 +0200)]
drm/i915: Use the canonical [CRTC:%d:%s]/etc. format in i915_display_info
Use the canonical "[CRTC:%d:%s]" format for the obj id/name
in the debugfs display_info dump. Everyone should already be
familiar with the format since it's used in the debug logs
extensively.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-8-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Ville Syrjälä [Fri, 29 Nov 2019 18:54:31 +0000 (20:54 +0200)]
drm/i915: Use drm_modeset_lock_all() in debugfs display info
Make out life easier by just grabbing all modeset locks around
the display_info dump.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-7-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Ville Syrjälä [Fri, 29 Nov 2019 18:54:30 +0000 (20:54 +0200)]
drm/i915: Dump the mode for the crtc just the once
No point in repeating the crtc mode for each cloned encoder.
Just print it once, and avoid using multiple lines for it.
And while at let's polish the fixed mode print to fit on
one line as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-6-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Ville Syrjälä [Fri, 29 Nov 2019 18:54:29 +0000 (20:54 +0200)]
drm/i915: Refactor debugfs display info code
Pull the crtc dumping stuff into a nice function so the
loop over the crtcs doesn't look like crap.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-5-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Ville Syrjälä [Fri, 29 Nov 2019 18:54:28 +0000 (20:54 +0200)]
drm/i915: Reorganize plane/fb dump in debugfs
Eliminate the special cases for the primary and cursor planes and just
dump all the information consistently for all the planes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-4-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Ville Syrjälä [Fri, 29 Nov 2019 18:54:27 +0000 (20:54 +0200)]
drm/i915: Switch to intel_ types in debugfs display_info
Switch to using intel_ types in the debugfs display_info code.
Should make it easier to handle bigjoiner etc. in the future.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-3-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Ville Syrjälä [Fri, 29 Nov 2019 18:54:26 +0000 (20:54 +0200)]
drm/i915: Use drm_rect to simplify plane {crtc,src}_{x,y,w,h} printing
Use DRM_RECT_FMT & co. to simpify the code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129185434.25549-2-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Ville Syrjälä [Tue, 5 Nov 2019 17:14:47 +0000 (19:14 +0200)]
drm/i915: Switch intel_crtc_disable_noatomic() to intel_ types
It's hard to see what is going on when the function mixes drm_
and intel_ types. Switch to intel_ types.
v2: Deal with another use of 'intel_crtc' being introduced
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191105171447.22111-2-ville.syrjala@linux.intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Matt Roper [Wed, 27 Nov 2019 22:13:14 +0000 (14:13 -0800)]
drm/i915: Program SHPD_FILTER_CNT on CNP+
The bspec tells us 'Program SHPD_FILTER_CNT with the "500 microseconds
adjusted" value before enabling hotplug detection' on CNP+. We haven't
been touching this register at all thus far, but we should probably
follow the bspec's guidance.
The register also exists on LPT and SPT, but there isn't any specific
guidance I can find on how we should be programming it there so let's
leave it be for now.
Bspec: 4342
Bspec: 31297
Bspec: 8407
Bspec: 49305
Bspec: 50473
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127221314.575575-3-matthew.d.roper@intel.com
Matt Roper [Wed, 27 Nov 2019 22:13:13 +0000 (14:13 -0800)]
drm/i915/ehl: Make icp_digital_port_connected() use phy instead of port
When looking at SDEISR to determine the connection status of combo
outputs, we should use the phy index rather than the port index.
Although they're usually the same thing, EHL's DDI-D (port D) is
attached to PHY-A and SDEISR doesn't even have bits for a "D" output.
It's also possible that future platforms may map DDIs (the internal
display engine programming units) to PHYs (the output handling on the IO
side) in ways where port!=phy, so let's look at the PHY index by
default.
v2: Rename to intel_combo_phy_connected. (Lucas)
Fixes: 719d24002602 ("drm/i915/ehl: Enable DDI-D")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127221314.575575-2-matthew.d.roper@intel.com
Matt Roper [Wed, 27 Nov 2019 22:13:12 +0000 (14:13 -0800)]
drm/i915: Handle SDEISR according to PCH rather than platform
The South Display is part of the PCH so we should technically be basing
our port detection logic off the PCH in use rather than the platform
generation.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127221314.575575-1-matthew.d.roper@intel.com
Ville Syrjälä [Thu, 28 Nov 2019 18:23:58 +0000 (20:23 +0200)]
drm/i915: Use the correct PCH transcoder for LPT/WPT in intel_sanitize_frame_start_delay()
LPT/WPT only have PCH transcoder A. Make sure we poke at its
chicken register instead of some non-existent register when
FDI is being driven by pipe B or C.
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128182358.14477-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Chris Wilson [Sun, 1 Dec 2019 14:09:16 +0000 (14:09 +0000)]
drm/i915: Refactor gen6_flush_pd()
As the gen6 page directory is written on binding and after every update,
the code ended up duplicated. Refactor the code into a single routine to
share the locking and serialisation.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191201140916.2128905-1-chris@chris-wilson.co.uk
Chris Wilson [Sat, 30 Nov 2019 16:23:20 +0000 (16:23 +0000)]
drm/i915: Serialise access to GFX_FLSH_CNTL
Now that many threads may try to use the same mmio to flush the global
buffers after updating the PTE, serialise access to the mmio to prevent
concurrent access on gen7.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191130162320.1683424-1-chris@chris-wilson.co.uk
Chris Wilson [Sat, 30 Nov 2019 12:05:03 +0000 (12:05 +0000)]
drm/i915/gt: Push the flush_pd before the set-context
Move our "wait for the PD load to complete" paranoia before the
MI_SET_CONTEXT just in case the context restore tries to access local
addresses.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191130120503.1609483-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 20:13:28 +0000 (20:13 +0000)]
drm/i915/gen7: Re-enable full-ppgtt for ivb & hsw
After much hair pulling, resort to preallocating the ppGTT entries on
init to circumvent the apparent lack of PD invalidate following the
write to PP_DCLV upon switching mm between contexts (and here the same
context after binding new objects). However, the details of that PP_DCLV
invalidate are still unknown, and it appears we need to reload the mm
twice to cover over a timing issue. Worrying.
Fixes: 3dc007fe9b2b ("drm/i915/gtt: Downgrade gen7 (ivb, byt, hsw) back to aliasing-ppgtt")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129201328.1398583-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 22:27:02 +0000 (22:27 +0000)]
drm/i915/selftests: Keep engine awake during live_coherency
Keep the engine awake and so avoid frequent cycling in and out of
powersaving mode to eliminate the unnecessary overhead and speed up the
testing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129222702.1456292-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 17:25:42 +0000 (17:25 +0000)]
drm/i915/execlists: Ensure the tasklet is decoupled upon shutdown
As we only cancel the timers asynchronously, they may
still be running on another CPU as we shutdown, raising one last
softirq. So be safe and make sure the tasklet is flushed before
destroying the engine's memory.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129172542.1222810-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 15:18:45 +0000 (15:18 +0000)]
drm/i915/gem: Take timeline->mutex to walk list-of-requests
Though the context is closed and so no more requests can be added to the
timeline, retirement can still be removing requests. It can even be
removing the very request we are inspecting and so cause us to wander
into dead links.
Serialise with the retirement by taking the timeline->mutex used for
guarding the timeline->requests list.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112404
Fixes: 4a3174152147 ("drm/i915/gem: Refine occupancy test in kill_context()")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129151845.1092933-1-chris@chris-wilson.co.uk
Ville Syrjälä [Fri, 11 Oct 2019 20:09:45 +0000 (23:09 +0300)]
drm/i915: Don't set undefined bits in dirty_pipes
skl_commit_modeset_enables() straight up compares dirty_pipes
with a bitmask of already committed pipes. If we set bits in
dirty_pipes for non-existent pipes that comparison will never
work right. So let's limit ourselves to bits that exist.
And we'll do the same for the active_pipes_changed bitmask.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011200949.7839-5-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Chris Wilson [Fri, 29 Nov 2019 12:48:46 +0000 (12:48 +0000)]
Revert "drm/i915: use a separate context for gpu relocs"
Since commit
c45e788d95b4 ("drm/i915/tgl: Suspend pre-parser across GTT
invalidations"), we now disable the advanced preparser on Tigerlake for the
invalidation phase at the start of the batch, we no longer need to emit
the GPU relocations from a second context as they are now flushed inlined.
References:
8a9a982767b7 ("drm/i915: use a separate context for gpu relocs")
References:
c45e788d95b4 ("drm/i915/tgl: Suspend pre-parser across GTT invalidations")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129124846.949100-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 10:34:55 +0000 (10:34 +0000)]
drm/i915/selftests: Wait only on the expected barrier
Wait on only the last request on the kernel_context after emitting a
barrier so that we do not wait for everything in general and by doing so
cause an accidental emission of the barrier!
Bugzilla; https://bugs.freedesktop.org/show_bug.cgi?id=112405
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129103455.744389-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Nov 2019 09:56:59 +0000 (09:56 +0000)]
drm/i915/selftests: Always lock the drm_mm around insert/remove
Be paranoid and make sure the drm_mm is locked whenever we insert/remove
our own nodes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191129095659.665381-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 28 Nov 2019 23:29:46 +0000 (23:29 +0000)]
drm/i915/selftests: Use sgt_iter for huge_pages_free
Use the normal sgt_iter to walk the pages scatterlist on free so that we
handle the error path correctly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112225
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128232946.546831-1-chris@chris-wilson.co.uk
Michel Thierry [Thu, 28 Nov 2019 02:10:05 +0000 (07:40 +0530)]
drm/i915/tgl: Implement Wa_1604555607
Implement Wa_1604555607 (set the DS pairing timer to 128 cycles).
FF_MODE2 is part of the register state context, that's why it is
implemented here.
At TGL A0 stepping, FF_MODE2 register read back is broken, hence
disabling the WA verification.
v2: Rebased on top of the WA refactoring (Oscar)
v3: Correctly add to ctx_workarounds_init (Michel)
v4:
uncore read is used [Tvrtko]
Macros as used for MASK definition [Chris]
v5:
Skip the Wa_1604555607 verification [Ram]
i915 ptr retrieved from engine. [Tvrtko]
v6:
Added wa_add as a wrapper for __wa_add [Chris]
wa_add is directly called instead of new wrapper [tvrtko]
BSpec: 19363
HSDES:
1604555607
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Ramalingam C <ramlingam.c@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> [v5]
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128021005.3350-1-ramalingam.c@intel.com
Chris Wilson [Thu, 28 Nov 2019 18:54:01 +0000 (18:54 +0000)]
drm/i915/selftests: Drop local vm reference!
After obtaining a local reference to the vm from the context, remember
to drop it before it goes out of scope!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128185402.110678-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 27 Nov 2019 22:32:50 +0000 (22:32 +0000)]
drm/i915/selftests: Count the number of engines used
Don't rely on the RUNTIME_INFO() when we loop over a particular context
and only run on a filtered set of engines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127223252.3777141-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 28 Nov 2019 10:25:46 +0000 (10:25 +0000)]
drm/i915/selftests: Try to show where the pulse went
We have a case of a mysteriously absent pulse, so dump the engine
details to see if we can find out what happened to it.
References: https://bugs.freedesktop.org/show_bug.cgi?id=112405
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128102546.3857140-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 28 Nov 2019 11:34:24 +0000 (11:34 +0000)]
drm/i915/gem: Excise the per-batch whitelist from the context
One does not lightly add a new hidden struct_mutex dependency deep within
the execbuf bowels! The immediate suspicion in seeing the whitelist
cached on the context, is that it is intended to be preserved between
batches, as the kernel is quite adept at caching small allocations
itself. But no, it's sole purpose is to serialise command submission in
order to save a kmalloc on a slow, slow path!
By removing the whitelist dependency from the context, our freedom to
chop the big struct_mutex is greatly augmented.
v2: s/set_bit/__set_bit/ as the whitelist shall never be accessed
concurrently.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191128113424.3885958-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 27 Nov 2019 11:58:13 +0000 (11:58 +0000)]
drm/i915/gt: Defer breadcrumb processing to after the irq handler
The design of our interrupt handlers is that we ack the receipt of the
interrupt first, inside the critical section where the master interrupt
control is off and other cpus cannot start processing the next
interrupt; and then process the interrupt events afterwards. However,
Icelake introduced a whole new set of banked GT_IIR that are inherently
serialised and slow to retrieve the IIR and must be processed within the
critical section. We can still push our breadcrumbs out of this critical
section by using our irq_worker. On bdw+, this should not make too much
of a difference as we only slightly defer the breadcrumbs, but on icl+
this should make a big difference to our throughput of interrupts from
concurrently executing engines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127115813.3345823-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 27 Nov 2019 13:45:27 +0000 (13:45 +0000)]
drm/i915: Serialise i915_active_fence_set() with itself
The expected downside to commit
58b4c1a07ada ("drm/i915: Reduce nested
prepare_remote_context() to a trylock") was that it would need to return
-EAGAIN to userspace in order to resolve potential mutex inversion. Such
an unsightly round trip is unnecessary if we could atomically insert a
barrier into the i915_active_fence, so make it happen.
Currently, we use the timeline->mutex (or some other named outer lock)
to order insertion into the i915_active_fence (and so individual nodes
of i915_active). Inside __i915_active_fence_set, we only need then
serialise with the interrupt handler in order to claim the timeline for
ourselves.
However, if we remove the outer lock, we need to ensure the order is
intact between not only multiple threads trying to insert themselves
into the timeline, but also with the interrupt handler completing the
previous occupant. We use xchg() on insert so that we have an ordered
sequence of insertions (and each caller knows the previous fence on
which to wait, preserving the chain of all fences in the timeline), but
we then have to cmpxchg() in the interrupt handler to avoid overwriting
the new occupant. The only nasty side-effect is having to temporarily
strip off the RCU-annotations to apply the atomic operations, otherwise
the rules are much more conventional!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112402
Fixes: 58b4c1a07ada ("drm/i915: Reduce nested prepare_remote_context() to a trylock")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127134527.3438410-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 27 Nov 2019 09:56:57 +0000 (09:56 +0000)]
drm/i915/gt: Manual rc6 entry upon parking
Now that we rapidly park the GT when the GPU idles, we often find
ourselves idling faster than the RC6 promotion timer. Thus if we tell
the GPU to enter RC6 manually as we park, we can do so quicker (by
around 50ms, half an EI on average) and marginally increase our
powersaving across all execlists platforms.
v2: Now with a selftest to check we can enter RC6 manually
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Acked-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191127095657.3209854-1-chris@chris-wilson.co.uk
Clint Taylor [Thu, 21 Nov 2019 20:14:55 +0000 (12:14 -0800)]
drm/i915: Disable display interrupts during display IRQ handler
During the Display Interrupt Service routine the Display Interrupt
Enable bit must be disabled, The interrupts handled, then the
Display Interrupt Enable bit must be set to prevent possible missed
interrupts.
Bspec: 49212
V2: Change Title to remove SDE reference.
V3: Fix TAB spacing.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Aditya Swarup <aditya.swarup@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191121201455.2558-1-clinton.a.taylor@intel.com
Kai Vehmanen [Mon, 25 Nov 2019 12:53:12 +0000 (14:53 +0200)]
drm/i915/dp: fix DP audio for PORT_A on gen12+
Starting with gen12, PORT_A can be connected to a transcoder
with audio support. Modify the existing logic that disabled
audio on PORT_A unconditionally.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125125313.17584-1-kai.vehmanen@linux.intel.com
Stanislav Lisovskiy [Mon, 25 Nov 2019 16:08:00 +0000 (18:08 +0200)]
drm/i915: Support more QGV points
According to BSpec 53998, there is a mask of
max 8 SAGV/QGV points we need to support.
Bumping this up to keep the CI happy(currently
preventing tests to run), until all SAGV
changes land.
v2: Fix second plane where QGV points were
hardcoded as well.
v3: Change the naming of I915_NUM_SAGV_POINTS
to be I915_NUM_QGV_POINTS, as more meaningful
(Ville Syrjälä)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112189
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125160800.14740-1-stanislav.lisovskiy@intel.com
[vsyrjala: Add missing braces around else (checkpatch), fix Bugzilla tag]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Chris Wilson [Tue, 26 Nov 2019 06:55:21 +0000 (06:55 +0000)]
drm/i915: Reduce nested prepare_remote_context() to a trylock
On context retiring, we may invoke the kernel_context to unpin this
context. Elsewhere, we may use the kernel_context to modify this
context. This currently leads to an AB-BA lock inversion, so we need to
back-off from the contended lock, and repeat.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111732
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: a9877da2d629 ("drm/i915/oa: Reconfigure contexts on the fly")
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191126065521.2331017-1-chris@chris-wilson.co.uk
Chris Wilson [Mon, 25 Nov 2019 16:27:37 +0000 (16:27 +0000)]
drm/i915: Default to a more lenient forced preemption timeout
Based on a sampling of a number of benchmarks across platforms, by
default opt for a much more lenient timeout so that we should not
adversely affect existing "good" clients.
640ms ought to be enough for anyone.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112169
Fixes: 3a7a92aba8fb ("drm/i915/execlists: Force preemption")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191125162737.2161069-1-chris@chris-wilson.co.uk
projects / openwrt / staging / blogic.git / log