- 14 Nov, 2019 1 commit
-
-
Lionel Landwerlin authored
I'm observing incoherence metric values, changing from run to run. It appears the patches introducing noa wait & reconfiguration from command stream switched places in the series multiple times during the review. This lead to the dependency of one onto the order to go missing... Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 15d0ace1 ("drm/i915/perf: execute OA configuration from command stream") Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 13 Nov, 2019 12 commits
-
-
Radhakrishna Sripada authored
Extend disabling SAMPLER_STATE prefetch workaround to gen12. v2: Limit the WA to TGL A0 and update the WA no(Chris) BSpec: 52890 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
-
Bruce Chang authored
io_mapping_map_atomic/kmap_atomic are occasionally taken in error capture (if there is no aperture preallocated for the use of error capture), but the error capture and compression routines are now run in normal context: <3> [113.316247] BUG: sleeping function called from invalid context at mm/page_alloc.c:4653 <3> [113.318190] in_atomic(): 1, irqs_disabled(): 0, pid: 678, name: debugfs_test <4> [113.319900] no locks held by debugfs_test/678. <3> [113.321002] Preemption disabled at: <4> [113.321130] [<ffffffffa02506d4>] i915_error_object_create+0x494/0x610 [i915] <4> [113.327259] Call Trace: <4> [113.327871] dump_stack+0x67/0x9b <4> [113.328683] ___might_sleep+0x167/0x250 <4> [113.329618] __alloc_pages_nodemask+0x26b/0x1110 <4> [113.334614] pool_alloc.constprop.19+0x14/0x60 [i915] <4> [113.335951] compress_page+0x7c/0x100 [i915] <4> [113.337110] i915_error_object_create+0x4bd/0x610 [i915] <4> [113.338515] i915_capture_gpu_state+0x384/0x1680 [i915] However, it is not a good idea to run the slow compression inside atomic context, so we choose not to. Fixes: 895d8ebe ("drm/i915: error capture with no ggtt slot") Signed-off-by:
Bruce Chang <yu.bruce.chang@intel.com> Reviewed-by:
Brian Welty <brian.welty@intel.com> Reviewed-by:
-
Lucas De Marchi authored
Tiger Lake supports HDMI on port A. For other platforms we ignore what the VBT says regarding HDMI to workaround broken VBTs, see commit 2ba7d7e0 ("drm/i915/bios: ignore HDMI on port A"). Make this apply gen12+ so they inherit the TGL behavior. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191113021935.41547-1-lucas.demarchi@intel.com
-
José Roberto de Souza authored
This register was being enabled after enable TRANS_DDI_FUNC_CTL and PIPECONF/TRANS_CONF while BSpec states that it should be set when enabling TRANS_DDI_FUNC_CTL. BSpec: 49190 BSpec: 22243 Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191107214559.77087-3-jose.souza@intel.com
-
José Roberto de Souza authored
Adding pipe D support to DSI transcoder. Not adding it for EDP transcoder code paths as only TGL has 4 pipes and it do not have a EDP transcoder. Reviewed-by:
-
José Roberto de Souza authored
TRANS_DDI_MST_TRANSPORT_SELECT is 2 bits wide not 3, it was taking one bit from EDP/DSI Input Select. Fixes: b3545e08 ("drm/i915/tgl: add support to one DP-MST stream") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Lucas De Marchi authored
When we call intel_bios_is_valid_vbt(), size may not actually be the size of the VBT, but rather the size of the blob the VBT is contained in. For example, when mapping the PCI oprom, size will be the entire oprom size. We don't want to read beyond what is reported to be the VBT. So make sure we vbt->vbt_size makes sense and use that for the latter checks. v2: check for vbt_size after checking for vbt signature and give it a more meaningful error message (from Jani) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191108003602.33526-3-lucas.demarchi@intel.com
-
Lucas De Marchi authored
oprom is actually a better name to use when using pci_map_rom(). "bios" is way too generic and confusing. Signed-off-by:
-
Chris Wilson authored
Still the saga of the hsw live_blt incoherency continues. While it did seem that the invalidate before the breadcrumb had improved the mtbf, nevertheless live_blt still failed. Mika's next idea was to pull the invalidate-stall into the breadcrumb write itself. References: 860afa08 ("drm/i915/gt: Flush gen7 even harder") References: https://bugs.freedesktop.org/show_bug.cgi?id=112147 Testcase: igt/i915_selftest/live_blt Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191113151956.32242-1-chris@chris-wilson.co.uk
-
Matt Roper authored
The bspec was just updated with a minor correction to entry 61 (it shouldn't have had the SCF bit set). v2: - Add a MOCS_ENTRY_UNUSED() and use it to declare the explicitly-reserved MOCS entries. (Lucas) - Move the warning suppression from the Makefile to a #pragma that only affects the TGL table. (Lucas) v3: - Entries 16 and 17 are identical to ICL now, so no need to explicitly adjust them (or mess with compiler warning overrides). Bspec: 45101 Fixes: 2ddf9921 ("drm/i915/tgl: Define MOCS entries for Tigerlake") Cc: Tomasz Lis <tomasz.lis@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Francisco Jerez <francisco.jerez.plata@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Reviewed-by:
Tomasz Lis <tomasz.lis@intel.com>
-
Matt Roper authored
This reverts commit f4071997. These extra EHL entries won't behave as expected without a bit more work on the kernel side so let's drop them until that kernel work has had a chance to land. Userspace trying to use these new entries won't get the advantage of the new functionality these entries are meant to provide, but at least it won't misbehave. When we do add these back in the future, we'll probably want to explicitly use separate tables for ICL and EHL so that userspace software that mistakenly uses these entries (which are undefined on ICL) sees the same behavior it sees with all the other undefined entries. Cc: Francisco Jerez <francisco.jerez.plata@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v5.3+ Fixes: f4071997 ("drm/i915/ehl: Update MOCS table for EHL") Signed-off-by:
-
Imre Deak authored
According to internal documents I found for CMP PCHs the PCI ID 0xA3C1 belongs to a CMP-V chipset. Based on the same docs the programming of the PCH is compatible with that of KBP. Fix up my previous wrong assumption accordingly using the SPT programming which in turn is the basis for KBP. The original bug reporter verified that this is the correct PCH identification (the only way we'll program valid DDC pin-pair values to the GMBUS register) and the Windows team uses the same identification (that is using the KBP programming model for this PCH). I filed the necessary Bspec update requests (BSpec/33734). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051 Fixes: 37c92dc3 ("drm/i915: Add new CNL PCH ID seen on a CML platform") Reported-and-tested-by:
Cyrus <cyrus.lien@canonical.com> Cc: Cyrus <cyrus.lien@canonical.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
- 12 Nov, 2019 9 commits
-
-
Lucas De Marchi authored
The warning should be just a warning. Where it is currently is wrong since we already registered the connector on drm, meaning it dies later on a NULL pointer deref if the VBT-overriding we have is removed. Move the warning up. Signed-off-by:
-
Chris Wilson authored
live_blt is still failing on hsw, showing the hallmark of incoherency. Since we are fairly certain that the interrupt is after the seqno is visible, the other possibility is that the seqno is before the writes to memory are flushed. Throw in an TLB invalidate before the breadcrumb as we are reasonably confident that forces a CS stall. References: f9228f76 ("drm/i915/gt: Try an extra flush on the Haswell blitter") References: https://bugs.freedesktop.org/show_bug.cgi?id=112147 Testcase: igt/i915_selftest/live_blt Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c:453 igt_threaded_blt() error: uninitialized symbol 'file'. Fixes: 34485832 ("drm/i915/selftests: Exercise parallel blit operations on a single ctx") Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191112163643.3527-1-chris@chris-wilson.co.uk
-
Vandita Kulkarni authored
Adding all the register definitions needed for mipi dsi command mode. Signed-off-by:
Madhav Chauhan <madhav.chauhan@intel.com> Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
Chris Wilson authored
Throw in a flush_work() to specifically flush the context cleanup work before the module is unloaded. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112248 Fixes: a4e7ccda ("drm/i915: Move context management under GEM") Signed-off-by:
-
Jani Nikula authored
Using the array is getting clumsy. Make things a bit more dynamic. Remove early returns on not having child devices when the end result after "iterating" the empty list would be the same. v3: - use list_add_tail to not reverse the child device list (Ville) v2: - stick to previous naming of child devices (Ville) - use kzalloc, handle failure - initialize list head earlier to keep intel_bios_driver_remove() safe Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
The pre-initialized magic value is a bit silly, switch to a flag instead. v2: Reduce paranoia to a single sanity check (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
On gen7, including Haswell, the MI_FLUSH_DW command is not synchronous with the command streamer nor is there an option to make it so. To hide this we add a large delay on the CS so that the breadcrumb should always be visible before the interrupt. However, that does not seem to be enough to ensure the memory is actually coherent with the read of the breadcrumb. The breadcrumb update is a post-sync op... Throw in a preliminary MI_FLUSH_DW before the breadcrumb update in the hope that helps. References: https://bugs.freedesktop.org/show_bug.cgi?id=112147 Testcase: igt/i915_selftest/live_blt Signed-off-by:
-
Chris Wilson authored
Since we removed the pm hookup from the GT, the hook in drm_i915_private.gem is unused. Remove it. References: 18f3b272 ("drm/i915: Remove pm park/unpark notifications") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191112113434.31088-1-chris@chris-wilson.co.uk
-
- 11 Nov, 2019 18 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 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:
-
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:
-
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:
-
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:
-
