- 11 Nov, 2019 19 commits
-
-
Chris Wilson authored
As the memory regions are setup early, we can rely on its existence as we takeover the HW settings from BIOS. 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/20191111182143.23479-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Pass around the intended intel_uncore for mmio access during stolen setup, and avoid relying on the implicit magic I915_READ() macros. Signed-off-by:
-
Chris Wilson authored
Some basic information that is useful to know, such as how many cycles is a MI_NOOP. v2: Keep volatile pages pinned at all times! (Matthew) Signed-off-by:
-
Chris Wilson authored
The gem_ctx_persistence/smoketest was detecting an odd coherency issue inside the LRC context image; that the address of the ring buffer did not match our associated struct intel_ring. As we set the address into the context image when we pin the ring buffer into place before the context is active, that leaves the question of where did it get overwritten. Either the HW context save occurred after our pin which would imply that our idle barriers are broken, or we overwrote the context image ourselves. It is only in reset_active() where we dabble inside the context image outside of a serialised path from schedule-out; but we could equally perform the operation inside schedule-in which is then fully serialised with the context pin -- and remains serialised by the engine pulse with kill_context(). (The only downside, aside from doing more work inside the engine->active.lock, was the plan to merge all the reset paths into doing their context scrubbing on schedule-out needs more thought.) Fixes: d12acee8 ("drm/i915/execlists: Cancel banned contexts on schedule-out") Testcase: igt/gem_ctx_persistence/smoketest Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
Enable gup to retry and fault the pages outside of the mmap_sem lock in our worker. As we are inside our worker, outside of any critical path, we can allow the mmap_sem lock to be dropped in order to service a page fault; this in turn allows the mm to populate the page using a slow fault handler. References: 5b56d49f ("mm: add locked parameter to get_user_pages_remote()") Testcase: igt/gem_userptr/userfault Signed-off-by:
-
Chris Wilson authored
set_page_dirty says: For pages with a mapping this should be done under the page lock for the benefit of asynchronous memory errors who prefer a consistent dirty state. This rule can be broken in some special cases, but should be better not to. Under those rules, it is only safe for us to use the plain set_page_dirty calls for shmemfs/anonymous memory. Userptr may be used with real mappings and so needs to use the locked version (set_page_dirty_lock). However, following a try_to_unmap() we may want to remove the userptr and so call put_pages(). However, try_to_unmap() acquires the page lock and so we must avoid recursively locking the pages ourselves -- which means that we cannot safely acquire the lock around set_page_dirty(). Since we can't be sure of the lock, we have to risk skip dirtying the page, or else risk calling set_page_dirty() without a lock and so risk fs corruption. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203317 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112012 Fixes: 5cc9ed4b ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl") References: cb6d7c7d ("drm/i915/userptr: Acquire the page lock around set_page_dirty()") References: 505a8ec7 ("Revert "drm/i915/userptr: Acquire the page lock around set_page_dirty()"") References: 6dcc693b ("ext4: warn when page is dirtied without buffers") Signed-off-by:
-
Gwan-gyeong Mun authored
The setting of MSA is done by the DDI .pre_enable() hook. And when we are using MST, the MSA is only set to first mst stream by calling of DDI .pre_eanble() hook. It raies issues to non-first mst streams. Wrong MSA or missed MSA packets might show scrambled screen or wrong screen. This splits a setting of MSA to MST and SST cases. And In the MST case it will call a setting of MSA after an allocating of Virtual Channel from MST encoder pre_enable callback. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112212 Fixes: 0c06fa15 ("drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA") Fixes: d4a415dc ("drm/i915: Fix MST oops due to MSA changes") Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191106212636.502471-1-gwan-gyeong.mun@intel.comReviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> [vsyrjala: nuke spurious newline] Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Chris Wilson authored
Having been forced to reduce Braswell back to using the aliasing ppgtt, the coherency issue we previously observed cannot impact us. Reduce the performance penalty imposed on all platforms from using the mfence to a mere sfence. References: cf66b8a0 ("drm/i915/execlists: Apply a full mb before execution for Braswell") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191110185806.17413-10-chris@chris-wilson.co.uk
-
Chris Wilson authored
As the ftrace buffer is single shot, once dumped it will not update. As such, it only provides information for the first bug and all subsequent bugs are noise. The goal of CI is to have zero bugs, so taint the kernel causing CI to reboot the machine; fix the bug and move on. Signed-off-by:
-
Chris Wilson authored
To test mmap_offset_exhaustion, we first have to fill the entire vma manager leaving a single page. Don't assume that the vma manager is not already fragment, and fill all the holes. Signed-off-by:
-
Chris Wilson authored
Make sure that our code is robust enough to handle multiple threads trying to clear objects for a single client context. This brings the joy of a shared GGTT to all! References: https://bugs.freedesktop.org/show_bug.cgi?id=112176Signed-off-by:
-
Chris Wilson authored
We report "frequencies" (actual-frequency, requested-frequency) as the number of accumulated cycles so that the average frequency over that period may be determined by the user. This means the units we report to the user are Mcycles (or just M), not MHz. Signed-off-by:
-
Chris Wilson authored
If we detect a hang in a closed context, just flush all of its requests and cancel any remaining execution along the context. Note that after closing the context, the last reference to the context may be dropped, leaving it only valid under RCU. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191111114323.5833-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
We mention that we are resetting the GPU, and dump the device state for post mortem debugging. However, while that dump contains the active processes and the one flagged as causing the error, we do not always include that information in dmesg. Include the name of the guilty process in dmesg for reference. Signed-off-by:
-
Chris Wilson authored
Update the context.name on closing so that the persistent requests are clear in debug prints. Signed-off-by:
-
Chris Wilson authored
Use a small char buffer inside the i915_gem_context to store the user friendly name so that ctx->name has the same lifetime as the RCU protected GEM context. That is, e.g. when using print_request() that prints the timeline name (ctx->name), the name will not be prematurely freed upon the context being closed and the last reference dropped. Signed-off-by:
-
Chris Wilson authored
Inside print_request(), we query the context/timeline name. Nothing immediately protects the context from being freed if the request is complete -- we rely on serialisation by the caller to keep the name valid until they finish using it. Inside intel_engine_dump(), we generally only print the requests in the execution queue protected by the engine->active.lock, but we also show the pending execlists ports which are not protected and so require a rcu_read_lock to keep the pointer valid. [ 1695.700883] BUG: KASAN: use-after-free in i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.700981] Read of size 8 at addr ffff8887344f4d50 by task gem_ctx_persist/2968 [ 1695.701068] [ 1695.701156] CPU: 1 PID: 2968 Comm: gem_ctx_persist Tainted: G U 5.4.0-rc6+ #331 [ 1695.701246] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 1695.701334] Call Trace: [ 1695.701424] dump_stack+0x5b/0x90 [ 1695.701870] ? i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.701964] print_address_description.constprop.7+0x36/0x50 [ 1695.702408] ? i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.702856] ? i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.702947] __kasan_report.cold.10+0x1a/0x3a [ 1695.703390] ? i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.703836] i915_fence_get_timeline_name+0x53/0x90 [i915] [ 1695.704241] print_request+0x82/0x2e0 [i915] [ 1695.704638] ? fwtable_read32+0x133/0x360 [i915] [ 1695.705042] ? write_timestamp+0x110/0x110 [i915] [ 1695.705133] ? _raw_spin_lock_irqsave+0x79/0xc0 [ 1695.705221] ? refcount_inc_not_zero_checked+0x91/0x110 [ 1695.705306] ? refcount_dec_and_mutex_lock+0x50/0x50 [ 1695.705709] ? intel_engine_find_active_request+0x202/0x230 [i915] [ 1695.706115] intel_engine_dump+0x2c9/0x900 [i915] Fixes: c36eebd9 ("drm/i915/gt: execlists->active is serialised by the tasklet") Signed-off-by:
-
Chris Wilson authored
After doing some measuring, Icelake behaves on a par with Broadwell, and without having to compromise for low power cores with long latencies, we can reduce the powergating hysteresis so that the powersaving is enabled faster. No impact observed on client side throughput measures (so negligible increase in extra switching), and inspection from high frequency polling using igt/gem_exec_nop/sequential, provided an estimate for the upper bound before we can measure a substantial impact on latency. Signed-off-by:
-
Lionel Landwerlin authored
The ordering of the checks in the existing code can lead to holding preemption not being considered as privileged op. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 9cd20ef7 ("drm/i915/perf: allow holding preemption on filtered ctx") Reviewed-by:
-
- 08 Nov, 2019 7 commits
-
-
Ville Syrjälä authored
Make sure we have a crtc before probing its primary plane's max stride. Initially I thought we can't get this far without crtcs, but looks like we can via the dumb_create ioctl. Not sure if we shouldn't disable dumb buffer support entirely when we have no crtcs, but that would require some amount of work as the only thing currently being checked is dev->driver->dumb_create which we'd have to convert to some device specific dynamic thing. Cc: stable@vger.kernel.org Reported-by:
-
Chris Wilson authored
On gen7, we have to avoid concurrent access to the same mmio cacheline, and so coordinate all mmio access with the uncore->lock. However, for pmu, we want to avoid perturbing the system and disabling interrupts unnecessarily, so restrict the w/a to gen7 where it is requied to prevent machine hangs. Signed-off-by:
-
Chris Wilson authored
We want to avoid taking forcewake when querying the performance stats, as we wish to avoid perturbing the system under observation. (And with the forcewake being kept alive for 1ms after use, sampling the frequency from a 200Hz timer keeps forcewake 40% active.) Signed-off-by:
-
Chris Wilson authored
In the selftests, where we are accessing a private ctx from within the confines of a single test, we know that the ctx->vm pointer is static and bounded by the lifetime of the test. We can use a simple helper to provide the RCU annotations to keep sparse happy. Signed-off-by:
-
Chris Wilson authored
Since drm provided us with a real struct file we can use for our anonymous internal clients (mock_file), complete our transition to using that as the primary interface (and not the mocked up struct drm_file we previous were using). Signed-off-by:
-
Masahiro Yamada authored
The headers in the gem/selftests/, gt/selftests, gvt/, selftests/ directories have never been compile-tested, but it would be possible to make them self-contained. This commit only addresses missing <linux/types.h> and forward struct declarations. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by:
-
Masahiro Yamada authored
Since this function is defined in a header file, it should be 'static inline' instead of 'static'. Signed-off-by:
-
- 07 Nov, 2019 14 commits
-
-
Matt Roper authored
Rather than just specifying the bullet numbers from the bspec (e.g., "4.b") actually include the description of what the bspec wants us to do. Steps can be renumbered or moved so including the description will help us match the code up to the spec. Plus if we add support for new platforms, some of the steps may be added/removed so more descriptive comments will be useful for ensuring all of the bspec requirements are met. 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> Link: https://patchwork.freedesktop.org/patch/msgid/20191107174527.11165-1-matthew.d.roper@intel.comReviewed-by:
José Roberto de Souza <jose.souza@intel.com>
-
Chris Wilson authored
Whenever, we unbind (or change fence registers) on an object, we must revoke any and all mmap_gtt using the previous bindings. Those user PTEs point at the GGTT which know points into a new object, the wrong object. Ergo, those PTEs must be cleared so that any user access provokes a new page fault. Signed-off-by:
Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191107180601.30815-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
Provide a utility function to create a vma corresponding to an mmap() of our device. And use it to exercise the equivalent of userspace performing a GTT mmap of our objects. Signed-off-by:
-
Chris Wilson authored
As drm now exports a method to create an anonymous struct file around a drm_device for internal use, make use of it to avoid our horrible hacks. Danial suggested that the mock_file_put() wrapper was suitable for drm-core, along with the mock_drm_getfile() [and that the vestigal mock_drm_file() in this patch should perhaps be the drm interface itself]. However, the eventual goal is to remove the mock_drm_file() and use the struct file and fput() directly, in this patch we take a simple transition in that direction. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191107180601.30815-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
Sometimes we need to create a struct file to wrap a drm_device, as it the user were to have opened /dev/dri/card0 but to do so anonymously (i.e. for internal use). Provide a utility method to create a struct file with the drm_device->driver.fops, that wrap the drm_device. v2: Restrict usage to selftests Signed-off-by:
-
Chris Wilson authored
Currently, we only export symbols for drm-selftests which are either compiled as modules or into the main drm builtin. However, if we want to export symbols from drm.ko for the drivers' selftests, we require a means of controlling that export separately. So we add a new Kconfig to determine whether or not the EXPORT_SYMBOL_FOR_TESTS_ONLY() takes effect. Signed-off-by:
-
Chris Wilson authored
As we read the ctx->vm unlocked before cloning/exporting, we should validate our reference is correct before returning it. We already do for clone_vm() but were not so strict around get_ppgtt(). Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191106091312.12921-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Only add the engine to the available set of uabi engines once it has been fully initialised and we know we want it in the public set. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Reviewed-by:
-
Ville Syrjälä authored
The LUTs are single buffered so in order to program them without tearing we'd have to do it during vblank (actually to be 100% effective it has to happen between start of vblank and frame start). We have no proper mechanism for that at the moment so we just defer loading them after the vblank waits have happened. That is not quite sufficient (especially when committing multiple pipes whose vblanks don't line up) so the LUT load will often leak into the following frame causing tearing. However in case the hardware wasn't previously using the LUT we can preload it before setting the enable bit (which is double buffered so won't tear). Let's determine if we can do such preloading and make it happen. Slight variation between the hardware requires some platforms specifics in the checks. Hans is seeing ugly colored flash on VLV/CHV macchines (GPD win and Asus T100HA) when the gamma LUT gets loaded for the first time as the BIOS has left some junk in the LUT memory. v2: Deal with uapi vs. hw crtc state split s/GCM/CGM/ typo fix Cc: Hans de Goede <hdegoede@redhat.com> Fixes: 051a6d8d ("drm/i915: Move LUT programming to happen after vblank waits") Signed-off-by:Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Ramalingam C authored
If Local memory is supported by hardware, we want framebuffer backing gem objects from local memory. if the backing obj is not from LMEM, pin_to_display is failed. v2: memory regions are correctly assigned to obj->memory_regions [tvrtko] migration failure is reported as debug log [Tvrtko] v3: Migration is dropped. only error is reported [Daniel] mem region check is move to pin_to_display [Chris] v4: s/dev_priv/i915 [chris] v5: i915_gem_object_is_lmem is used for detecting the obj mem type. [Matt] cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
-
Chris Wilson authored
The hidden aliasing-ppgtt's size is never revealed, as we only inspect the front GTT when engaged. However, we were "fixing" the hidden ppgtt to match, with the net result that we ended up leaking the unused portion on Braswell were we preallocated the entire set of top level PDP, see gen8_preallocate_top_level_pdp(). [ 26.025364] DMA-API: pci 0000:00:02.0: device driver has pending DMA allocations while released from device [count=2] [ 26.025364] One of leaked entries details: [device address=0x0000000230778000] [size=4096 bytes] [mapped with DMA_BIDIRECTIONAL] [mapped as single] [ 26.025683] WARNING: CPU: 0 PID: 415 at kernel/dma/debug.c:894 dma_debug_device_change+0x1a4/0x1f0 [ 26.025905] Modules linked in: i915(E-) intel_powerclamp(E) nls_ascii(E) nls_cp437(E) crct10dif_pclmul(E) crc32_pclmul(E) vfat(E) crc32c_intel(E) fat(E) ghash_clmulni_intel(E) prime_numbers(E) intel_gtt(E) i2c_algo_bit(E) efi_pstore(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) evdev(E) drm(E) aesni_intel(E) glue_helper(E) crypto_simd(E) cryptd(E) intel_cstate(E) sg(E) efivars(E) pcspkr(E) video(E) button(E) efivarfs(E) ip_tables(E) x_tables(E) autofs4(E) sd_mod(E) lpc_ich(E) ahci(E) mfd_core(E) i2c_i801(E) libahci(E) i2c_designware_pci(E) i2c_designware_core(E) [ 26.026613] CPU: 0 PID: 415 Comm: rmmod Tainted: G E 5.4.0-rc6+ #25 [ 26.026837] Hardware name: /, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 26.027080] RIP: 0010:dma_debug_device_change+0x1a4/0x1f0 [ 26.027319] Code: 89 54 24 08 e8 ad 60 62 00 48 8b 54 24 08 48 89 c6 41 57 4d 89 e9 49 89 d8 44 89 f1 41 54 48 c7 c7 e0 61 06 82 e8 c1 aa f5 ff <0f> 0b 5a 59 48 83 3c 24 00 0f 85 97 26 00 00 8b 05 77 47 92 01 85 [ 26.027600] RSP: 0018:ffff888228d2fcc8 EFLAGS: 00010282 [ 26.027831] RAX: 0000000000000000 RBX: 0000000230778000 RCX: 0000000000000000 [ 26.028053] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffed10451a5f8f [ 26.028279] RBP: ffff88823480c0b0 R08: 0000000000000001 R09: ffffed1046e83eb1 [ 26.028500] R10: ffffed1046e83eb0 R11: ffff88823741f587 R12: ffffffff82067340 [ 26.028725] R13: 0000000000001000 R14: 0000000000000002 R15: ffffffff82067480 [ 26.028952] FS: 00007fdf3ed174c0(0000) GS:ffff888237400000(0000) knlGS:0000000000000000 [ 26.029185] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 26.029405] CR2: 000055e211109030 CR3: 0000000230139000 CR4: 00000000001006f0 [ 26.029622] Call Trace: [ 26.029846] notifier_call_chain+0x67/0xa0 [ 26.030076] blocking_notifier_call_chain+0x5a/0x80 [ 26.030305] device_release_driver_internal+0x20d/0x260 [ 26.030535] driver_detach+0x7b/0xe1 [ 26.030761] bus_remove_driver+0x8c/0x153 [ 26.030993] pci_unregister_driver+0x2d/0xf0 [ 26.032603] i915_exit+0x16/0x1c [i915] Reported-by:
-
Jani Nikula authored
The intel_dp_link_training.h include has no need or place in intel_display.h. Include it in intel_display.c instead. Cc: Manasi Navare <manasi.d.navare@intel.com> Fixes: eadf6f91 ("drm/i915/display/icl: Enable master-slaves in trans port sync") 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/20191029103947.7535-1-jani.nikula@intel.com
-
Daniel Vetter authored
So strictly speaking the existing annotation is also ok, because we have a chain of obj->mm.lock#I915_MM_GET_PAGES -> fs_reclaim -> obj->mm.lock (the shrinker cannot get at an object while we're in get_pages, hence this is safe). But it's confusing, so try to take the right subclass of the lock. This does a bit reduce our lockdep based checking, but then it's also less fragile, in case we ever change the nesting around. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Will Deacon <will@kernel.org> Cc: linux-kernel@vger.kernel.org Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191104173720.2696-3-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Necessary to annotate functions where we might acquire a mutex_lock_nested() or similar. Needed by i915. Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
-
