- 15 Feb, 2019 6 commits
-
-
Ville Syrjälä authored
intel_crtc_disable_planes() disables the planes so it should trigger the appropriate tracepoint. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190206204910.13965-3-ville.syrjala@linux.intel.comReviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
Add tracepoints for pipe enable/disable. We'll include the frame/scanline counters for all pipes in these tracepoints to help in diagnosing underruns and whatnot when enabling/disabling pipes in parallel with plane updates/flips on another pipe. Signed-off-by:
-
Ville Syrjälä authored
Add a tracepoint for pipe crc. Makes life much simpler when staring at traces when hunting for fifo underruns and other issues which cause corrupted frames. We'll add the tracepoint before filtering out any potentially bogus crcs during modeset (should actually verify if that filtering is even correct anymore...) v2: s/crcs[5]/*crcs/ in the function argument because something in the macros wants to do sizeof(crcs) and gcc likes to warn us it's not an actual array so the size may not be as expected. The silly bugger even does that for 'crcs[]' causing us to lose any helpful syntactic hint that we are in fact dealing with an array (kbuild test robot) Signed-off-by: -
Chris Wilson authored
Since we no longer need to hold struct_mutex to perform a global device reset, don't do so for igt_reset_wedge(). 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/20190215102732.15520-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we currently do not check on submission whether the context is banned in a timely manner it is possible for some requests to escape cancellation after their parent context is banned. By moving the ban into the request submission under the engine->timeline.lock, we serialise it with the reset and setting of the context ban. References: eb8d0f5a ("drm/i915: Remove GPU reset dependence on struct_mutex") Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
Chris Wilson authored
Currently, we only try to reset a live engine for checking the whitelist retention across a per-engine reset. For safety, it appears we need to prime the system with a hanging spinner before performing a full-device reset. (Figuring out the root cause behind the instability with handling a reset during a no-op request is a challenge for another test, the whitelist test has its own purpose.) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109626Signed-off-by:
-
- 14 Feb, 2019 7 commits
-
-
Chris Wilson authored
Currently we try to stop the engine by programming the ring registers to be disabled before we perform the reset. Sometimes, we see the context image also have invalid ring registers, which one presumes may be actually caused by us doing so. Lets risk not doing programming the ring to zero on the first attempt to avoid preserving that corruption into the context image, leaving the w/a in place for subsequent reset attempts. Signed-off-by:
-
Chris Wilson authored
drm/i915 is tracking all wakeref owners with a cookie in order to identify leaks. To that end, each rpm acquisition ops->get_power is assigned a cookie which should be passed to ops->put_power to signify its release (and removal from the list of wakeref owners). As snd/hda is already using a bool to track current status of display_power extending that to an unsigned long to hold the boolean cookie is a trivial extension, and will quell all doubt that snd/hda is the cause of the device runtime pm leaks. v2: Keep using the power abstraction for local wakeref tracking. v3: BUILD_BUG_ON impedance mismatch Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
The new workaround from the hw team involves leaving WM1 still disabled but programming the blocks value identically to WM0, and we also need to set the "ignore lines watermark" bit for WM1. v2: Fix commit message wording a bit Signed-off-by:
Clint Taylor <Clinton.A.Taylor@intel.com>
-
Ville Syrjälä authored
We'll need to poke at the "ignore lines" bit in the skl+ watermark registers for a w/a. Include that bit in the wm state. Signed-off-by:
-
Ville Syrjälä authored
This reverts commit bf002c10. The hw team has come up with a better workaround. So let's get rid of this one. Signed-off-by:
-
Aditya Swarup authored
Organize MG PHY macro definitions semantically based on dword, lane and port (in this order). Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Aditya Swarup <aditya.swarup@intel.com> Reviewed-by:
Manasi navare <manasi.d.navare@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190128220012.13122-3-aditya.swarup@intel.com
-
Aditya Swarup authored
Organize combo PHY DDI macro definitions semantically based on dword, lane and port (in this order). Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
- 13 Feb, 2019 8 commits
-
-
Ville Syrjälä authored
As there are no upstream drivers for VED or ISP let's just assert that they are power gated. Otherwise they would prevent s0ix entry. For ISP this is only relevant when it is not exposed as a PCI device and instead is a subordinate of the gunit. When exposed as a PCI device it will be handled by the atomisp2_pm driver. On my VLV FFRD8 board the firmware power gates both of these by default. Let's assume that is always the case and just WARN if we ever encounter something different. Cc: Hans de Goede <hdegoede@redhat.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Rename the punit display power register to match the spec. Signed-off-by:
-
Chris Wilson authored
As time goes by, usage of generic ioctls such as drm_syncobj and sync_file are on the increase bypassing i915-specific ioctls like GEM_WAIT. Currently, we only apply waitboosting to our driver ioctls as we track the file/client and account the waitboosting to them. However, since commit 7b92c1bd ("drm/i915: Avoid keeping waitboost active for signaling threads"), we no longer have been applying the client ratelimiting on waitboosts and so that information has only been used for debug tracking. Push the application of waitboosting down to the common i915_request_wait, and apply it to all foreign fence waits as well. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190213092504.25709-1-chris@chris-wilson.co.uk
-
Uma Shankar authored
Add the degamma and gamma lut sizes to gen11 capability structure. Note: Currently this doesn't account for the extended range gamma entries and this will be addressed with new segmented gamma ABI in a future patch. v2: Reorder the patch as per Maarten's suggestion. v3: Rebase v4: Updated commit message with a note as per Matt's suggestion. v5: No Change. Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Uma Shankar authored
GEN11+ onwards an output csc hardware block has been added. This is after the pipe gamma block and is in addition to the legacy pipe CSC block. Primary use case for this block is to convert RGB to YUV in case sink supports YUV. This patch adds supports for the same. v2: This is added after splitting the existing ICL pipe CSC handling. As per Matt's suggestion, made this to co-exist with existing pipe CSC, wherein both can be enabled if a certain usecase arises. v3: Fixed an issue with co-existence of output csc and normal pipe csc, spotted by Matt. Put the csc mode flag enabling to color_check to align with atomic. v4: Fixed macro alignment and checkpatch complaints wrt line over 100 characters limit. Signed-off-by:
-
Uma Shankar authored
Enable ICL pipe csc hardware. CSC block is enabled in CSC_MODE register instead of PLANE_COLOR_CTL. ToDO: Extend the ABI to accept 32 bit coefficient values instead of 16bit for future platforms. v2: Addressed Maarten's review comments. v3: Addressed Matt's review comments. Removed rmw patterns as suggested by Matt. v4: Addressed Matt's review comments. v5: Addressed Ville's review comments. v6: Separated pipe output csc programming from regular csc. v7: Rebase Signed-off-by:
-
Uma Shankar authored
Add support for icl pipe degamma and gamma. v2: Removed a POSTING_READ and corrected the Bit Definition as per Maarten's comments. v3: Addressed Matt's review comments. Removed rmw patterns as suggested by Matt. v4: Fixed Matt's review comments. v5: Corrected macro alignment as per Jani Nikula's comments. Addressed Ville and Matt's review comments. v6: Merged ICL degamma handling with GLK and dropped ICL degamma function as per Ville and Matt's comments. v7: updated gamma_mode state with pre csc gammma and post gamma enabling in intel_color_check to align with atomic. v8: Addressed Maarten's review comments. Signed-off-by:
-
Uma Shankar authored
Fixed the glk degamma lut programming which currently was hard coding a linear lut all the time, making degamma block of glk basically a pass through. Currently degamma lut for glk is assigned as 0 in platform configuration. Updated the same to 33 as per the hardware capability. IGT tests for degamma were getting skipped due to this, spotted by Swati. ToDo: The current gamma/degamm lut ABI has just 16bit for each color component. This is not enough for GLK+, since input precision is increased to 3.16 which will need 19bit entries. v2: Added Matt's RB. v3: Changed uint32_t to u32. v4: Fixed Maarten's review comment Credits-to: Swati Sharma <swati2.sharma@intel.com> Signed-off-by:
-
- 12 Feb, 2019 3 commits
-
-
Chris Wilson authored
Use lockdep to warn before we wait indefinitely in case we may be waiting indefinitely. Suggested-by:
-
Chris Wilson authored
We cannot nest i915_reset_trylock() as the inner may wait for the I915_RESET_BACKOFF which in turn is waiting upon sync_srcu who is waiting for our outermost lock. As we take the reset srcu around the fence update, we have to defer taking it in i915_gem_fault() until after we acquire the pin on the fence to avoid nesting. This is a little ugly, but still works. If a reset occurs between i915_vma_pin_fence() and the second reset lock, the reset will restore the fence register back to the pinned value before the reset lock allows us to proceed (our mmap won't be revoked as we haven't yet marked it as being a userfault as that requires us to hold the reset lock), so the pagefault is still serialised with the revocation in reset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109605 Fixes: 2caffbf1 ("drm/i915: Revoke mmaps and prevent access to fence registers across reset") Signed-off-by:
-
Ville Syrjälä authored
Currently we're only dumping out the ddb allocation changes, let's do the same for the watermarks. This should help with debugging underruns and whatnot. First I tried one line per plane per wm level, but that resulted in an obnoxious amount of lines printed. So as a compromise I settled on a four line format, each line containing a single watermark related value (enable,lines,blocks,min_ddb_alloc) for all 8 levels (+trans wm). It still produces quite a lot of output but I can't really see a way around that because we simply have a lot of data to dump. Let's also pimp the ddb debug to print the size of the allocations too, not just their bounds. Makes it a bit easier to compare against the watermarks. Signed-off-by:
-
- 11 Feb, 2019 7 commits
-
-
Chris Wilson authored
If we drop the engine lock, we may run execlists_dequeue which may free the priolist. Therefore if we ever drop the execution lock on the engine, we have to discard our cache and refetch the priolist to ensure we do not use a stale pointer. [ 506.418935] [IGT] gem_exec_whisper: starting subtest contexts-priority [ 593.240825] general protection fault: 0000 [#1] SMP [ 593.240863] CPU: 1 PID: 494 Comm: gem_exec_whispe Tainted: G U 5.0.0-rc6+ #100 [ 593.240879] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0029.2016.1124.1625 11/24/2016 [ 593.240965] RIP: 0010:__i915_schedule+0x1fe/0x320 [i915] [ 593.240981] Code: 48 8b 0c 24 48 89 c3 49 8b 45 28 49 8b 75 20 4c 89 3c 24 48 89 46 08 48 89 30 48 8b 43 08 48 89 4b 08 49 89 5d 20 49 89 45 28 <48> 89 08 45 39 a7 b8 03 00 00 7d 44 45 89 a7 b8 03 00 00 49 8b 85 [ 593.240999] RSP: 0018:ffffc90000057a60 EFLAGS: 00010046 [ 593.241013] RAX: 6b6b6b6b6b6b6b6b RBX: ffff8882582d7870 RCX: ffff88826baba6f0 [ 593.241026] RDX: 0000000000000000 RSI: ffff8882582d6e70 RDI: ffff888273482194 [ 593.241049] RBP: ffffc90000057a68 R08: ffff8882582d7680 R09: ffff8882582d7840 [ 593.241068] R10: 0000000000000000 R11: ffffea00095ebe08 R12: 0000000000000728 [ 593.241105] R13: ffff88826baba6d0 R14: ffffc90000057a40 R15: ffff888273482158 [ 593.241120] FS: 00007f4613fb3900(0000) GS:ffff888277a80000(0000) knlGS:0000000000000000 [ 593.241133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 593.241146] CR2: 00007f57d3c66a84 CR3: 000000026e2b6000 CR4: 00000000001406e0 [ 593.241158] Call Trace: [ 593.241233] i915_schedule+0x1f/0x30 [i915] [ 593.241326] i915_request_add+0x1a9/0x290 [i915] [ 593.241393] i915_gem_do_execbuffer+0x45f/0x1150 [i915] [ 593.241411] ? init_object+0x49/0x80 [ 593.241425] ? ___slab_alloc.constprop.91+0x4b8/0x4e0 [ 593.241491] ? i915_gem_execbuffer2_ioctl+0x99/0x380 [i915] [ 593.241563] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915] [ 593.241629] i915_gem_execbuffer2_ioctl+0x1bb/0x380 [i915] [ 593.241705] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915] [ 593.241724] drm_ioctl_kernel+0x81/0xd0 [ 593.241738] drm_ioctl+0x1a7/0x310 [ 593.241803] ? i915_gem_execbuffer_ioctl+0x270/0x270 [i915] [ 593.241819] ? __update_load_avg_se+0x1c9/0x240 [ 593.241834] ? pick_next_entity+0x7e/0x120 [ 593.241851] do_vfs_ioctl+0x88/0x5d0 [ 593.241880] ksys_ioctl+0x35/0x70 [ 593.241894] __x64_sys_ioctl+0x11/0x20 [ 593.241907] do_syscall_64+0x44/0xf0 [ 593.241924] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 593.241940] RIP: 0033:0x7f4615ffe757 [ 593.241952] Code: 00 00 90 48 8b 05 39 a7 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 a7 0c 00 f7 d8 64 89 01 48 [ 593.241970] RSP: 002b:00007ffc1030ddf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 593.241984] RAX: ffffffffffffffda RBX: 00007ffc10324420 RCX: 00007f4615ffe757 [ 593.241997] RDX: 00007ffc1030e220 RSI: 0000000040406469 RDI: 0000000000000003 [ 593.242010] RBP: 00007ffc1030e220 R08: 00007f46160c9208 R09: 00007f46160c9240 [ 593.242022] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000040406469 [ 593.242038] R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000 [ 593.242058] Modules linked in: i915 intel_gtt drm_kms_helper prime_numbers v2: Track the local engine cache and explicitly clear it when switching engine locks. Fixes: a02eb975 ("drm/i915/execlists: Cache the priolist when rescheduling") Testcase: igt/gem_exec_whisper/contexts-priority # rare! Signed-off-by:
-
Chris Wilson authored
While this is mainly only useful for ELSP[0], it is definitely useful to know the current timeline seqno wrt to the queued set of requests for that port, as this carries additional information above and beyond the near-defunct global_seqno and global HWSP. Signed-off-by:
-
Chris Wilson authored
We impose upon ourselves a strict timeout for resets (to ensure forward progress by use of a failsafe). Prefer to use the expedited synchronisation function in this case to reduce the likelihood of a spurious delay being treated as a deadlock. Signed-off-by:
-
Chris Wilson authored
We need to flush our srcu protecting resources about to be clobbered by the reset, inside of our timer failsafe but outside of the error->wedge_mutex, so that the failsafe can run in case the synchronize_srcu() takes too long (hits a shrinker deadlock?). Fixes: 72eb16df ("drm/i915: Serialise resets with wedging") References: https://bugs.freedesktop.org/show_bug.cgi?id=109605Signed-off-by:
-
Jani Nikula authored
Starting from opregion version 2.1 (roughly corresponding to ICL+) the RVDA field is relative from the beginning of opregion, not absolute address. Fix the error path while at it. v2: Make relative vs. absolute conditional on the opregion version, bumped for the purpose. Turned out there are machines relying on absolute RVDA in the wild. v3: Fix the version checks Fixes: 04ebaadb ("drm/i915/opregion: handle VBT sizes bigger than 6 KB") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: -
Jani Nikula authored
The u32 version field encodes major, minor, revision and reserved. We've basically been checking for any non-zero version. Add opregion version logging while at it. v2: Fix the fix of the version check Fixes: 04ebaadb ("drm/i915/opregion: handle VBT sizes bigger than 6 KB") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Chris Wilson authored
If we allocate while iterating the rbtree of active nodes, we may hit the shrinker and so retire the i915_active, reaping the rbtree. Modifying the rbtree as we iterate is not good behaviour, so acquire the i915_active first to keep the tree intact whenever we allocate. Fixes: a42375af ("drm/i915: Release the active tracker tree upon idling") Signed-off-by:
-
- 09 Feb, 2019 1 commit
-
-
Chris Wilson authored
In the next patch, we add another user that wants to check whether requests can be merge into a single HW execution, and in the future we want to add more conditions under which requests from the same context cannot be merge. In preparation, extract out can_merge_rq(). v2: Reorder tests to decide if we can continue filling ELSP and bonus comments. Signed-off-by:
-
- 08 Feb, 2019 8 commits
-
-
Chris Wilson authored
If we haven't even begun executing the payload of the stalled request, then we should not claim that its userspace context was guilty of submitting a hanging batch. v2: Check for context corruption before trying to restart. v3: Preserve semaphores on skipping requests (need to keep the timelines intact). Signed-off-by:
-
Chris Wilson authored
Prevent concurrent set-wedge with ongoing resets (and vice versa) by taking the same wedge_mutex around both operations. Signed-off-by:
-
Chris Wilson authored
Since we use the debugfs to recover the device after modifying the i915.reset parameter, we need to be sure that we apply the reset and not piggy-back onto a concurrent one in order for the parameter to take effect. Signed-off-by:
-
Chris Wilson authored
On wedging, we mark all executing requests as complete and all pending requests completed as soon as they are ready. Before unwedging though we wish to flush those pending requests prior to restoring default execution, and so we must wait. Do so uninterruptibly as we do not provide the EINTR gracefully back to userspace in this case but persists in keeping the permanently wedged state without restarting the syscall. Signed-off-by:
-
Chris Wilson authored
When declaring the GPU wedged, we do need to hit the GPU with the reset hammer so that its state matches our presumed state during cleanup. If the reset fails, it fails, and we may be unhappy but wedged. However, if we are testing our wedge/unwedged handling, the desync carries over into the next test and promptly explodes. References: https://bugs.freedesktop.org/show_bug.cgi?id=106702Signed-off-by:
-
Chris Wilson authored
Previously, we were able to rely on the recursive properties of struct_mutex to allow us to serialise revoking mmaps and reacquiring the FENCE registers with them being clobbered over a global device reset. I then proceeded to throw out the baby with the bath water in order to pursue a struct_mutex-less reset. Perusing LWN for alternative strategies, the dilemma on how to serialise access to a global resource on one side was answered by https://lwn.net/Articles/202847/ -- Sleepable RCU: 1 int readside(void) { 2 int idx; 3 rcu_read_lock(); 4 if (nomoresrcu) { 5 rcu_read_unlock(); 6 return -EINVAL; 7 } 8 idx = srcu_read_lock(&ss); 9 rcu_read_unlock(); 10 /* SRCU read-side critical section. */ 11 srcu_read_unlock(&ss, idx); 12 return 0; 13 } 14 15 void cleanup(void) 16 { 17 nomoresrcu = 1; 18 synchronize_rcu(); 19 synchronize_srcu(&ss); 20 cleanup_srcu_struct(&ss); 21 } No more worrying about stop_machine, just an uber-complex mutex, optimised for reads, with the overhead pushed to the rare reset path. However, we do run the risk of a deadlock as we allocate underneath the SRCU read lock, and the allocation may require a GPU reset, causing a dependency cycle via the in-flight requests. We resolve that by declaring the driver wedged and cancelling all in-flight rendering. v2: Use expedited rcu barriers to match our earlier timing characteristics. v3: Try to annotate locking contexts for sparse v4: Reduce selftest lock duration to avoid a reset deadlock with fences v5: s/srcu/reset_backoff_srcu/ v6: Remove more stale comments Testcase: igt/gem_mmap_gtt/hang Fixes: eb8d0f5a ("drm/i915: Remove GPU reset dependence on struct_mutex") Signed-off-by:
-
Chris Wilson authored
Currently, we may simultaneously release the fence register from both fence_update() and i915_gem_restore_fences(). This is dangerous, so defer the bookkeeping entirely to i915_gem_restore_fences() when the device is asleep. Reported-by:
-
Ville Syrjälä authored
On g4x+ we depend on the primary plane DSPCNTR gamma/csc enable bits for the pipe bottom color. To guarantee that those are correct already when enabling the crtc let's do an explicit ->disable_plane() call before enabling the pipe. On skl+ this will be handled by the explicit PIPE_BOTTOM_COLOR register which is already part of the normal color commit we do durign crtc enable. Signed-off-by:
-
