- 13 Nov, 2019 2 commits
-
-
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> (cherry picked from commit bd8c9cca) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191113125241.20547-1-ville.syrjala@linux.intel.com
-
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 <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-3-chris@chris-wilson.co.uk (cherry picked from commit 31b61f0e) Signed-off-by:
-
- 12 Nov, 2019 4 commits
-
-
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:
-
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
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:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191111114323.5833-1-chris@chris-wilson.co.uk (cherry picked from commit fecffa46) 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:
-
- 11 Nov, 2019 6 commits
-
-
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:
-
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
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 (cherry picked from commit 3c954c41) Signed-off-by:
-
Chris Wilson authored
When inside the lock, remember to unlock even if you want to leave early. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: a4e7ccda ("drm/i915: Move context management under GEM") Signed-off-by:
-
Chris Wilson authored
Mika spotted that only using cancel_delayed_work() could mean that we attempted to clear the heartbeat.systole while the worker was still running. Rectify the situation by only touching the systole from outside the worker if we suceeded in cancelling the worker before it could run. The worker is expected to clean up by itself upon idling. Reported-by:
-
- 05 Nov, 2019 7 commits
-
-
Chris Wilson authored
Call suspend_prepare first so that we don't leave GuC so confused. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191101174405.7389-1-chris@chris-wilson.co.uk (cherry picked from commit 833e979d) Signed-off-by:
-
Chris Wilson authored
The counter is removed from the pm wakeref count, but it remains intact so that we can restore it upon resume. Ergo inside suspend, it may have a value. Signed-off-by:
-
Chris Wilson authored
Currently we shutdown rc6 during i915_gem_resume() but this is called during the preparation phase (i915_drm_prepare) for all suspend paths, but we only want to shutdown rc6 for S3+. Move the actual shutdown to i915_gem_suspend_late(). We then need to differentiate between suspend targets, to distinguish S0 (s2idle) where the device is kept awake but needs to be in a low power mode (the same as runtime suspend) from the device suspend levels where we lose control of HW and so must disable any HW access to dangling memory. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111909 Fixes: c1132367 ("drm/i915: Extract GT render sleep (rc6) management") Testcase: igt/gem_exec_suspend/power-S0 Signed-off-by:
-
Chris Wilson authored
We already track the debugfs user_forcewake on the GT, so it is natural to pull the suspend/resume handling under gt/ as well. Signed-off-by:
-
Chris Wilson authored
As we already do reload the kernel context in intel_gt_resume, repeating that action inside i915_gem_resume() as well is redundant. Signed-off-by:
-
Chris Wilson authored
Assume all responsibility for operating on the HW to sanitize the GT state upon load/resume in intel_gt_sanitize() itself. Signed-off-by:
-
Chris Wilson authored
Since the execlists_active() is no longer protected by the engine->active.lock, we need to protect the request pointer with RCU to prevent it being freed as we evaluate whether or not we need to preempt. Fixes: df403069 ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Fixes: 13ed13a4 ("drm/i915: Don't set queue_priority_hint if we don't kick the submission") Signed-off-by:
-
- 04 Nov, 2019 1 commit
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
drm-next-5.5-2019-11-01: amdgpu: - Add EEPROM support for Arcturus - Enable VCN encode support for Arcturus - Misc PSP fixes - Misc DC fixes - swSMU cleanup amdkfd: - Misc cleanups - Fix typo in cu bitmap parsing Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191101190607.3763-1-alexander.deucher@amd.com
-
- 03 Nov, 2019 3 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-2019-11-01-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next UAPI Changes: - Make context persistence optional Allow userspace to tie the context lifetime to FD lifetime, effectively allowing Ctrl-C killing of a process to also clean up the hardware immediately. Compute changes: https://github.com/intel/compute-runtime/pull/228 The compute driver is shipping in Ubuntu. uAPI acked by Mesa folks. - Put future HW and their uAPIs under STAGING & BROKEN Introduces DRM_I915_UNSTABLE Kconfig menu for working on the new uAPI for future HW in upstream. We already disable driver loading by default the platform is deemed ready. This is a second level of protection based on compile time switch (STAGING & BROKEN). - Under DRM_I915_UNSTABLE: Add the fake lmem region on iGFX Fake local memory region on integrated GPU through cmdline: memmap=2G$16G i915.fake_lmem_start=0x400000000 Currently allows testing non-mappable GGTT behavior and running kernel selftest for local memory. Driver Changes: - Fix Bugzilla #112084: VGA external monitor not working (Ville) - Add support for half float framebuffers (Ville) - Add perf support on TGL (Lionel) - Replace hangcheck by heartbeats (Chris) - Allow SPT PCH on all AML devices (James) - Add new CNL PCH for CML platform (Imre) - Allow 100 ms (Kconfig) for workloads to exit before reset (Chris, Jon, Joonas) - Forcibly pre-empt a context after 100 ms (Kconfig) of delay (Chris) - Make timeslice duration Kconfig configurable (Chris) - Whitelist PS_(DEPTH|INVOCATION)_COUNT for Tigerlake (Tapani) - Support creating LMEM objects in kernel (Matt A) - Adjust the location of RING_MI_MODE in the context image for TGL (Chris) - Handle AUX interrupts for TC ports (Matt R) - Add support for devices without mappable GGTT aperture (Daniele) - Rename "inject_load_failure" module parameter to "inject_probe_failure" (Janusz) - Handle fused off HDCP, FBC, DMC and DSC (Jose) - Add support to one DP-MST stream on Tigerlake (Lucas) - Add HuC firmware (and GuC) for TGL (Daniele) - Allow ICL+ DSI on any pipe (Ville) - Check some transcoder timing minimum limits (Ville) - Don't set queue_priority_hint if we don't kick the submission (Chris) - Introduce barrier pulses along engines to flush idle/in-flight requests (Chris) - Drop assertion that ce->pin_mutex guards state updates (Chris) - Cancel banned contexts on schedule-out (Chris) - Cancel contexts when hangchecking is disabled (Chris) - Catch GTT fault errors for gen11+ planes (Matt R) - Print in debugfs if PSR is not enabled because of sink (Jose) - Do not set MOCS control values on dgfx (Lucas) - Setup io-mapping for LMEM (Abdiel) - Support kernel mapping of LMEM objects (Abdiel) - Add LMEM selftests (Matt A) - Initialise PMU spinlock before registering (Chris) - Clear DKL_TX_PMD_LANE_SUS before program TC voltage swing (Jose) - Flip interpretation of ips fmin/fmax to max rps (Chris) - Add VBT compression parameter block definition (Jani) - Limit the blitter sizes to ensure low preemption latency (Chris) - Fixup block_size rounding on BLT (Matt A) - Don't try to place HWS in non-existing mappable region (Michal Wa) - Don't allocate the ring in stolen if we lack aperture (Matt A) - Add AUX B & C to DC_OFF_POWER_DOMAINS for Tigerlake (Matt R) - Avoid HPD poll detect triggering a new detect cycle (Imre) - Document the userspace fail with possible_crtcs (Ville) - Drop lrc header page now unused by GuC (Daniele) - Do not switch aux to TBT mode for non-TC ports (Jose) - Restructure code to avoid depending on i915 but smaller structs (Chris, Tvrtko, Andi) - Remove pm park/unpark notifications (Chris) - Avoid lockdep cross-contamination between object types (Chris) - Restructure DSC code (Jani) - Fix dead locking in early workload shadow (Zhenyu) - Split the legacy submission backend from the common CS ring buffer (Chris) - Move intel_engine_context_in/out into intel_lrc.c (Tvrtko) - Describe perf/wakeref structure members in documentation (Anna) - Update renamed header files names in documentation (Anna) - Add debugs to distingiush a cd2x update from a full cdclk pll update (Ville) - Rework atomic global state locking (Ville) - Allow planes to declare their minimum acceptable cdclk (Ville) - Eliminate skl_check_pipe_max_pixel_rate() and simplify skl_max_scale() (Ville) - Making loglevel of PSR2/SU logs same (Ap) - Capture aux page table error register (Lionel) - Add is_dgfx to device info (Jose) - Split gen11_irq_handler to make it shareable (Lucas) - Encapsulate kconfig constant values inside boolean predicates (Chris) - Split memory_region initialisation into its own file (Chris) - Use _PICK() for CHICKEN_TRANS() and add CHICKEN_TRANS_D (Ville) - Add perf helper macros for comparing with whitelisted registers (Umesh) - Fix i915_inject_load_error() name to read *_probe_* (Janusz) - Drop unused AUX register offsets (Matt R) - Provide more information on DP AUX failures (Matt R) - Add GAM/SFC instdone to error state (Mika) - Always track callers to intel_rps_mark_interactive() (Chris) - Nuke 'mode' argument to intel_get_load_detect_pipe() (Ville) - Simplify LVDS crtc_mask and pipe_mask setup (Ville) - Stop frobbing crtc->base.mode (Ville) - Do s/crtc_mask/pipe_mask/ (Ville) - Split detaching and removing the vma (Chris) - Selftest improvements (Chris, Tvrtko, Mika, Matt A, Lionel) - GuC code improvements (Rob, Andi, Daniele) - Check against i915_selftest only under CONFIG_SELFTEST (Chris) - Refine occupancy test in kill_context() (Chris) - Start kthreads before stopping (Chris) Signed-off-by:
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
drm/tegra: Changes for v5.5-rc1 The bulk of these changes is the addition of DisplayPort support for Tegra210, Tegra186 and Tegra194. I've been running versions of this for about three years now, so I'd consider these changes to be pretty mature. These changes also unify the existing eDP support with the DP support since the programming is very similar, except for a few steps that can be easily parameterized. The rest are a couple of fixes all over the place for minor issues, as well as some work to support the IOMMU-backed DMA API, which in the end turned out to also clean up a number of cases where the DMA API was not being used correctly. Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.5: UAPI Changes: -dma-buf: Introduce and revert dma-buf heap (Andrew/John/Sean) Cross-subsystem Changes: - None Core Changes: -dma-buf: add dynamic mapping to allow exporters to choose dma_resv lock state on mmap/munmap (Christian) -vram: add prepare/cleanup fb helpers to vram helpers (Thomas) -ttm: always keep bo's on the lru + ttm cleanups (Christian) -sched: allow a free_job routine to sleep (Steven) -fb_helper: remove unused drm_fb_helper_defio_init() (Thomas) Driver Changes: -bochs/hibmc/vboxvideo: Use new vram helpers for prepare/cleanup fb (Thomas) -amdgpu: Implement dma-buf import/export without drm helpers (Christian) -panfrost: Simplify devfreq integration in driver (Steven) Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Steven Price <steven.price@arm.com> Cc: Andrew F. Davis <afd@ti.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
- 01 Nov, 2019 7 commits
-
-
Joonas Lahtinen authored
Signed-off-by: -
Chris Wilson authored
An interesting observation made with our parallel selftests was that on our small/single cpu systems we would call kthread_stop() before the kthreads were spawned. If this happens, the kthread is never run at all; completely bypassing the test. A simple yield() from the parent will ensure that all children have the opportunity to start before we reap them. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191101084940.31838-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
The i915_selftest module parameters only exist when CONFIG_DRM_I915_SELFTEST is set. Signed-off-by:
-
Thierry Reding authored
Currently configurations can be generated where IOMMU_SUPPORT is disabled but IOMMU_IOVA is built as a module and DRM_TEGRA as built-in. In such a case, the symbols guarded by IOMMU_IOVA will not be available when linking the Tegra DRM driver and cause a linking failure. Simplify this by unconditionally selecting IOMMU_IOVA, which makes sure that it will be forced to =y if DRM_TEGRA=y. Technically we can now get IOMMU_IOVA code built-in even if we don't use it (Tegra DRM only uses it when IOMMU_SUPPORT is also enabled), but such configuration are of a mostly academic nature. In all practical configurations we want IOMMU support anyway. Signed-off-by:Thierry Reding <treding@nvidia.com>
-
Thierry Reding authored
Currently configurations can be generated where IOMMU_SUPPORT is disabled but IOMMU_IOVA is built as a module and HOST1X as built-in. In such a case, the symbols guarded by IOMMU_IOVA will not be available when linking the host1x driver and cause a linking failure. Simplify this by unconditionally selecting IOMMU_IOVA, which makes sure that it will be forced to =y if HOST1X=y. Technically we can now get IOMMU_IOVA code built-in even if we don't use it (host1x only uses it when IOMMU_SUPPORT is also enabled), but such configuration are of a mostly academic nature. In all practical configurations we want IOMMU support anyway. Signed-off-by: -
Chris Wilson authored
Don't just look at the very last request in a queue when deciding if we need to evict the context from the GPU, as that request may still be in the submission queue while the rest of the context is running! Instead, walk back along the queued requests looking for the active request and checking that. Fixes: 2e0986a5 ("drm/i915/gem: Cancel contexts when hangchecking is disabled") Testcase: igt/gem_ctx_persistence/queued Signed-off-by:
-
Joonas Lahtinen authored
Signed-off-by:
-
- 31 Oct, 2019 10 commits
-
-
Matthew Auld authored
Intended for upstream testing so that we can still exercise the LMEM plumbing and !i915_ggtt_has_aperture paths. Smoke tested on Skull Canyon device. This works by allocating an intel_memory_region for a reserved portion of system memory, which we treat like LMEM. For the LMEMBAR we steal the aperture and 1:1 it map to the stolen region. To enable simply set the i915 modparam fake_lmem_start= on the kernel cmdline with the start of reserved region(see memmap=). The size of the region we can use is determined by the size of the mappable aperture, so the size of reserved region should be >= mappable_end. For now we only enable for the selftests. Depends on CONFIG_DRM_I915_UNSTABLE being enabled. eg. memmap=2G$16G i915.fake_lmem_start=0x400000000 v2: make fake_lmem_start an i915 modparam Signed-off-by:
-
José Roberto de Souza authored
Non-TC ports always have tc_mode == TC_PORT_TBT_ALT so it was switching aux to TBT mode for all combo-phy ports, happily this did not caused any issue but is better follow BSpec. Also this is reserved bit before ICL. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Fixes: e9b7e142 ("drm/i915: Sanitize the terminology used for TypeC port modes") Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191029011014.286885-1-jose.souza@intel.com
-
Daniele Ceraolo Spurio authored
Recent GuC doesn't require the shared area. We still have one user in i915 (engine reset via guc) because we haven't updated the command to match the current guc submission flow [1]. Since the flow in guc is about to change again, just disable the command for now and add a note that we'll implement it as part of the new flow. [1] https://patchwork.freedesktop.org/patch/295038/Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Fernando Pacheco <fernando.pacheco@intel.com> Acked-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
Recent GuC binaries (including all the ones we're currently using) don't require this shared area anymore, having moved the relevant entries into the stage pool instead. i915 itself doesn't write anything into it either, so we can safely drop it. Signed-off-by:
-
Chris Wilson authored
In order to keep the assert_bind_count() valid, we need to hold the vma page reference until after we drop the bind count. However, we must also keep the drm_mm_remove_node() as the last action of i915_vma_unbind() so that it serialises with the unlocked check inside i915_vma_destroy(). So we need to split up i915_vma_remove() so that we order the detach, drop pages and remove as required during unbind. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112067Signed-off-by:
-
Chris Wilson authored
If the idle_pulse fails to flush the i915_active, dump the tree to see if that has any clues. Signed-off-by:
-
Chris Wilson authored
When checking the heartbeat pulse, we expect it to have been sent by the time we have slept. We can verify this by checking the engine serial number to see if that matches the predicted pulse serial. It will always be true if, and only if, the pulse was sent by itself (as designed by the test). Signed-off-by:
-
Ville Syrjälä authored
To avoid accidentally breaking things in the future add a comment explaining why we misconfigure the pipe_mask. Also toss in a TODO for investigating a single encoder approach as opposed to the encoder-per-pipe approach. v2: Drop a bogus TODO comment Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
Just set pipe_mask=~0 for the non-special cases where any pipe will do. intel_encoder_possible_crtcs() will anyway drop out anything that doesn't exist. Signed-off-by:
-
Ville Syrjälä authored
There are no longer any pipe<->DSI port limitations on icl+. Populate the pipe_mask accordingly. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
