- 19 Feb, 2019 4 commits
-
-
Chris Wilson authored
Currently, we accumulate each time a context hangs the GPU, offset against the number of requests it submits, and if that score exceeds a certain threshold, we ban that context from submitting any more requests (cancelling any work in flight). In contrast, we use a simple timer on the file, that if we see more than a 9 hangs faster than 60s apart in total across all of its contexts, we will ban the client from creating any more contexts. This leads to a confusing situation where the file may be banned before the context, so lets use a simple timer scheme for each. If the context submits 3 hanging requests within a 120s period, declare it forbidden to ever send more requests. This has the advantage of not being easy to repair by simply sending empty requests, but has the disadvantage that if the context is idle then it is forgiven. However, if the context is idle, it is not disrupting the system, but a hog can evade the request counting and cause much more severe disruption to the system. Updating ban_score from request retirement is dubious as the retirement is purposely not in sync with request submission (i.e. we try and batch retirement to reduce overhead and avoid latency on submission), which leads to surprising situations where we can forgive a hang immediately due to a backlog of requests from before the hang being retired afterwards. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
CI still reports the occasional multi-second delay for resets, in particular along the wedge+recovery paths. As the likely, and unbounded, delay here is from sync_rcu, use the expedited variant instead. Testcase: igt/gem_eio/unwedge-stress Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-7-chris@chris-wilson.co.uk
-
Chris Wilson authored
The stack usage exceeded 1024 bytes prompting warnings on conservative setups, so move the temporary allocation for HW readback onto the heap. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
We don't want to pre-reserve any holes in our uAPI for that is a sign of nefarious and hidden activity. Add a reminder about our uAPI expectations to encourage good practice when adding new defines/enums. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190218094628.13522-1-chris@chris-wilson.co.uk
-
- 18 Feb, 2019 3 commits
-
-
Chris Wilson authored
At least on i965g and i965gm, performing a device reset clobbers the IER resulting in loss of interrupts thereafter. So, run the irq_postinstall hook to restore them. v2: Ville pointed out that he already attempted to solve this problem by reinstalling the interrupts in intel_reset_finish() (part of the display handling around reset). However, reinstalling the irq clobbers the i915->irq_mask which we need for handling MI_USER_INTERRUPTS, and does so too late to handle any interrupts generated from resuming the rings. The simple solution to both is to pull the interrupt reenabling from afterwards to around the device reset. Signed-off-by:
-
Chris Wilson authored
igt_ctx_sseu was caught using bannable contexts, and in the course of resetting rapidly to run its test, was banned. Don't let ourselves ban the test! Signed-off-by:
-
Chris Wilson authored
Some clients, such as mesa, may only emit minimal incremental batches that rely on the logical context state from previous batches. They know that recovery is impossible after a hang as their required GPU state is lost, and that each in flight and subsequent batch will hang (resetting the context image back to default perpetuating the problem). To avoid getting into the state in the first place, we can allow clients to opt out of automatic recovery and elect to ban any guilty context following a hang. This prevents the continual stream of hangs and allows the client to recreate their context and rebuild the state from scratch. v2: Prefer calling it recoverable rather than unrecoverable. References: https://lists.freedesktop.org/archives/mesa-dev/2019-February/215431.htmlSigned-off-by:
-
- 17 Feb, 2019 1 commit
-
-
Chris Wilson authored
This struct appears quite large and pushes our stack frame over 1024 bytes -- too high for conservative setups. So move the mock_ggtt struct to the heap. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190217202518.24730-1-chris@chris-wilson.co.uk
-
- 16 Feb, 2019 2 commits
-
-
Chris Wilson authored
Prepare a nice little onion unwind to ensure that we always free the spinner if we __sseu_prepare fails. Fixes: c06ee6ff ("drm/i915/selftests: Context SSEU reconfiguration tests") Reported-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
Chris Wilson authored
If we skipped all the connectors that were not part of a tile, we would leave conn_seq=0 and conn_configured=0, convincing ourselves that we had stagnated in our configuration attempts. Avoid this situation by starting conn_seq=ALL_CONNECTORS, and repeating until we find no more connectors to configure. Fixes: 754a7659 ("drm/i915/fbdev: Stop repeating tile configuration on stagnation") Reported-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
- 15 Feb, 2019 7 commits
-
-
Ville Syrjälä authored
Wrap the .update_plane()/.update_slave()/.disable_plane() vfunc calls into helpers which also take care to emit the appropriate tracepoint. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Ville Syrjälä authored
intel_crtc_disable_planes() disables the planes so it should trigger the appropriate tracepoint. Signed-off-by:
-
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 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:
-
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:
-
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 5 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:
-
