- 10 Oct, 2019 10 commits
-
-
Maarten Lankhorst authored
We have a src and dect rectangle, use it instead of relying on the core drm properties. Because the core by default clips the src/dst properties, after the drm_atomic_helper_check_plane_state() we manually set the unclipped src/dst rectangles. We still need the call for visibility checks, but this way we are able to use the src/dst rects in the check/commit code. This removes the special case in the watermark code for cursor w/h. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191004113514.17064-5-maarten.lankhorst@linux.intel.comReviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [mlankhorst: Clarify commit message to state we use unclipped src/dst
-
Maarten Lankhorst authored
This can all be done from the intel_update_crtc function. Split out the pipe update into a separate function, just like is done for the planes. Pull in all the changes done during fastset as well. It makes no sense for it to still exist as a separate function. Changes since v1: - Inline intel_update_pipe_config() Changes since v2: - Add comments suggested by matt. - Reorder commit_pipe_config() to remove all nesting. (Ville, Matt) - Use intel_set_pipe_src_size((). (Matt) Changes since v3: - Move atomic_update_watermarks closer to the plane calls. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> [mlankhorst: Replace 8 spaces with tabs in comment]
-
Maarten Lankhorst authored
We need to look at the hw fb in the plane split, so replace all the places that use drm_plane_state with intel_plane_state. Signed-off-by:
-
Maarten Lankhorst authored
Instead of looking at drm_plane_state, look at intel_plane_state directly. This will allow us to make the watermarks bigjoiner aware, when we make it work for bigjoiner slave pipes as well. Signed-off-by:
-
Maarten Lankhorst authored
Using for_each_intel_plane_mask() fails because of an extra bracket, remove the bracket so we can use it in the next commit. Signed-off-by:
-
Chris Wilson authored
Make sure that we copy across the registers from one engine to the next, as we hop around a virtual engine. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010110252.17289-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Move the BUG_ON around slightly and add some explanations for each to try and capture the expected state more carefully. We want to compare the expected active state of our bookkeeping as compared to the tracked HW state. References: https://bugs.freedesktop.org/show_bug.cgi?id=111937Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191010083242.1387-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we have a wedged GPU that we need to recover, but fail, add a taint for CI to pickup and schedule a reboot. Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002160034.5121-1-chris@chris-wilson.co.uk
-
Daniele Ceraolo Spurio authored
There are small differences between the blitter and the video engines in the xcs context image (e.g. registers 0x200 and 0x204 only exist on the blitter). Since we never explicitly set a value for those register and given that we don't need to update the offsets in the lrc image when we change engine within the class for virtual engine because the HW can handle that, instead of having a separate define for the BCS we can just restrict the programming to the part we're interested in, which is common across the engines. Bspec: 45584 Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
The specs don't mention any specific HW limitation on the blitter and manual inspection shows that the HW does set the relative MMIO bit in the LRI of the blitter context image, so we can remove our limitations. Signed-off-by:
-
- 09 Oct, 2019 7 commits
-
-
Chris Wilson authored
The active/pending execlists is no longer protected by the engine->active.lock, but is serialised by the tasklet instead. Update the locking around the debug and stats to follow suit. v2: local_bh_disable() to prevent recursing into the tasklet in case we trigger a softirq (Tvrtko) Fixes: df403069 ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Signed-off-by:
-
Chris Wilson authored
Now that we dropped the engine->active.lock serialisation from around process_csb(), direct submission can run concurrently to the interrupt handler. As such execlists->active may be advanced as we dequeue, dropping the reference to the request. We need to employ our RCU request protection to ensure that the request is not freed too early. Fixes: df403069 ("drm/i915/execlists: Lift process_csb() out of the irq-off spinlock") Signed-off-by:
-
Matt Roper authored
This slightly simplifies the EHL DPLL4 handling and also gives us more flexibility in the future in case we need to skip the use of specific PLL's (e.g., due to hardware workarounds and such). v2: - Replace GENMASK() with or'd BIT()'s to make the specific DPLLs more explicit. (Ville) - s/unsigned/unsigned long/. (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Swati Sharma authored
Moved common code to check gamma_enable to specific funcs per platform in bit_precision func. icl doesn't support that and chv has separate enable knob for CGM LUT. v2: -Simplified chv_gamma_precision() [Ville] Signed-off-by:
Swati Sharma <swati2.sharma@intel.com> Signed-off-by:
-
Swati Sharma authored
Premature gamma lut prepration and loading which was getting reflected in first modeset causing different colors on screen during boot. Issue: In BIOS, gamma is disabled by default. However, legacy read_luts() was setting crtc_state->base.gamma_lut and gamma_lut was programmed with junk values which led to visual artifacts (different colored screens instead of usual black during boot). Fix: Calling read_luts() only when gamma is enabled which will happen after first modeset. This fix is independent from the revert 1b858874 ("Revert "drm/i915/color: Extract icl_read_luts()"") and should fix different colors on screen in legacy platforms too. v2: -Added gamma_enable checks inside read_luts() [Ville/Jani N] -Corrected gamma enable check for CHV [Ville] v3: -Added check in ilk_read_luts() [Ville] -Simplified gamma enable check for CHV [Ville] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111809 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111885Tested-by:
Jani Saarinen <jani.saarinen@intel.com> Signed-off-by:
-
Colin Ian King authored
In the case where data fails to be allocated the error exit path is via label 'out' where data is dereferenced in a for-loop. Fix this by exiting via the label 'out_file' instead to avoid the null pointer dereference. Addresses-Coverity: ("Dereference after null check") Fixes: 50d16d44 ("drm/i915/selftests: Exercise context switching in parallel") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Chris Wilson authored
Take a reference on the request before submitting it to the HW and then waiting on it for selftest_workarounds. Once submitted, the request may be freed by a background worker, unless we take an extra reference for ourselves. References: https://bugs.freedesktop.org/show_bug.cgi?id=111926Signed-off-by:
-
- 08 Oct, 2019 18 commits
-
-
Chris Wilson authored
Assign a separate lockclass to the perma-pinned timelines of the kernel_context, such that we can use them from within the user timelines should we ever need to inject GPU operations to fixup faults during request construction. Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008185941.15228-1-chris@chris-wilson.co.uk
-
Matthew Auld authored
Volatile objects are marked as DONTNEED while pinned, therefore once unpinned the backing store can be discarded. This is limited to kernel internal objects. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
CQ Tang <cq.tang@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Reviewed-by:
-
Matthew Auld authored
Some kernel internal objects may need to be allocated as a contiguous block, also thinking ahead the various kernel io_mapping interfaces seem to expect it, although this is purely a limitation in the kernel API...so perhaps something to be improved. Signed-off-by:
-
Matthew Auld authored
Support memory regions, as defined by a given (start, end), and allow creating GEM objects which are backed by said region. The immediate goal here is to have something to represent our device memory, but later on we also want to represent every memory domain with a region, so stolen, shmem, and of course device. At some point we are probably going to want use a common struct here, such that we are better aligned with say TTM. Signed-off-by:
Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
A common bane of ours is arbitrary delays in ksoftirqd processing our submission tasklet. Give the submission tasklet a kick before we wait to avoid those delays eating into a tight timeout. Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008105655.13256-1-chris@chris-wilson.co.uk
-
Lionel Landwerlin authored
At some point in time there was the idea that we could have multiple stream from the same piece of HW but that never materialized and given the hard time we already have making everything work with the submission side, there is no real point having this list of 1 element around. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Chris Wilson authored
Couple up our mock_uncore to know about the fake global device and its runtime powermanagement. Signed-off-by:
-
Chris Wilson authored
Set up the engine->uncore shortcut on mock_engine creation. Signed-off-by:
-
Chris Wilson authored
Copy across the engine->uncore shortcut to the virtual_engine from its first physical engine, similar to the handling of the engine->gt backpointer. Signed-off-by:
-
Anshuman Gupta authored
Adding DC3CO counter in i915_dmc_info debugfs will be useful for DC3CO validation. DMC firmware uses DMC_DEBUG3 register as DC3CO counter register on TGL, as per B.Specs DMC_DEBUG3 is general purpose register. v1: comment modification for DMC_DBUG3. using GEN >= 12 check instead of IS_TIGERLAKE() to print DMC_DEBUG3 counter value. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by:Imre Deak <imre.deak@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
Anshuman Gupta authored
DC3CO is useful power state, when DMC detects PSR2 idle frame while an active video playback, playing 30fps video on 60hz panel is the classic example of this use case. B.Specs:49196 has a restriction to enable DC3CO only for Video Playback. It will be worthy to enable DC3CO after completion of each pageflip and switch back to DC5 when display is idle because driver doesn't differentiate between video playback and a normal pageflip. We will use Frontbuffer flush call tgl_dc3co_flush() to enable DC3CO state only for ORIGIN_FLIP flush call, because DC3CO state has primarily targeted for VPB use case. We are not interested here for frontbuffer invalidates calls because that triggers PSR2 exit, which will explicitly disable DC3CO. DC5 and DC6 saves more power, but can't be entered during video playback because there are not enough idle frames in a row to meet most PSR2 panel deep sleep entry requirement typically 4 frames. As PSR2 existing implementation is using minimum 6 idle frames for deep sleep, it is safer to enable DC5/6 after 6 idle frames (By scheduling a delayed work of 6 idle frames, once DC3CO has been enabled after a pageflip). After manually waiting for 6 idle frames DC5/6 will be enabled and PSR2 deep sleep idle frames will be restored to 6 idle frames, at this point DMC will triggers DC5/6 once PSR2 enters to deep sleep after 6 idle frames. In future when we will enable S/W PSR2 tracking, we can change the PSR2 required deep sleep idle frames to 1 so DMC can trigger the DC5/6 immediately after S/W manual waiting of 6 idle frames get complete. v2: calculated s/w state to switch over dc3co when there is an update. [Imre] Used cancel_delayed_work_sync() in order to avoid any race with already scheduled delayed work. [Imre] v3: Cancel_delayed_work_sync() may blocked the commit work. hence dropping it, dc5_idle_thread() checks the valid wakeref before putting the reference count, which avoids any chances of dropping a zero wakeref. [Imre (IRC)] v4: Used frontbuffer flush mechanism. [Imre] v5: Used psr.pipe to extract frontbuffer busy bits. [Imre] Used cancel_delayed_work_sync() in encoder disable path. [Imre] Used mod_delayed_work() instead of cancelling and scheduling a delayed work. [Imre] Used psr.lock in tgl_dc5_idle_thread() to enable psr2 deep sleep. [Imre] Removed DC5_REQ_IDLE_FRAMES macro. [Imre] v6: Used dc3co_exitline check instead of TGL and dc3co allowed_dc_mask checks, used delayed_work_pending with the psr lock and removed the psr2_deep_slp_disabled flag. [Imre] v7: Code refactoring, moved most of functional code to inte_psr.c [Imre] Using frontbuffer_bits on psr.pipe check instead of busy_frontbuffer_bits. [Imre] Calculating dc3co_exit_delay in intel_psr_enable_locked. [Imre] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: -
Anshuman Gupta authored
DC3CO enabling B.Specs sequence requires to enable end configure exit scanlines to TRANS_EXITLINE register, programming this register has to be part of modeset sequence as this can't be change when transcoder or port is enabled. When system boots with only eDP panel there may not be real modeset as BIOS has already programmed the necessary registers, therefore it needs to force a modeset to enable and configure DC3CO exitline. v1: Computing dc3co_exitline crtc state from a DP encoder compute config. [Imre] Enabling and disabling DC3CO PSR2 transcoder exitline from encoder pre_enable and post_disable hooks. [Imre] Computing dc3co_exitline instead of has_dc3co_exitline bool. [Imre] v2: Code refactoring for symmetry and to avoid exported function. [Imre] Removing IS_TIGERLAKE check from compute_config, adding PIPE_A restriction and clearing dc3co_exitline state if crtc is not active or it is not PSR2 capable in dc3co exitline compute_config. [Imre] Using GEN >= 12 check in dc3co exitline get_config. [Imre] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: -
Anshuman Gupta authored
Add target_dc_state and used by set_target_dc_state API in order to enable DC3CO state with existing DC states. target_dc_state will enable/disable the desired DC state in DC_STATE_EN reg when "DC Off" power well gets disable/enable. v2: commit log improvement. v3: Used intel_wait_for_register to wait for DC3CO exit. [Imre] Used gen9_set_dc_state() to allow/disallow DC3CO. [Imre] Moved transcoder psr2 exit line enablement from tgl_allow_dc3co() to a appropriate place haswell_crtc_enable(). [Imre] Changed the DC3CO power well enabled call back logic as recommended in review comments. [Imre] v4: Used wait_for_us() instead of intel_wait_for_reg(). [Imre (IRC)] v5: using udelay() instead of waiting for DC3CO exit status. v6: Fixed minor unwanted change. v7: Removed DC3CO powerwell and POWER_DOMAIN_VIDEO. v8: Uniform checks by using only target_dc_state instead of allowed_dc_mask in "DC off" power well callback. [Imre] Adding "DC off" power well id to older platforms. [Imre] Removed psr2_deep_sleep flag from tgl_set_target_dc_state. [Imre] v9: Used switch case for target DC state in gen9_dc_off_power_well_disable(), checking DC3CO state against allowed DC mask, using WARN_ON() in tgl_set_target_dc_state(). [Imre] v10: Code refactoring and using sanitize_target_dc_state(). [Imre] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: -
Anshuman Gupta authored
Enable dc3co state in enable_dc module param and add dc3co enable mask to allowed_dc_mask and gen9_dc_mask. v1: Adding enable_dc=3,4 options to enable DC3CO with DC5 and DC6 independently. [Animesh] v2: Using a switch statement for cleaner code. [Animesh] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by:Animesh Manna <animesh.manna@intel.com> Reviewed-by:
-
Anshuman Gupta authored
Adding following definition to i915_reg.h 1. DC_STATE_EN register DC3CO bit fields and masks. DC3CO enable bit will be used by driver to make DC3CO ready for DMC f/w and status bit will be used as DC3CO entry status. 2. Transcoder EXITLINE register and its bit fields and mask. Transcoder EXITLINE enable bit represents PSR2 idle frame reset should be applied at exit line and exitlines mask represent required number of scanlines at which DC3CO exit happens. B.Specs:49196 v1: Use of REG_BIT and using extra space for EXITLINE_ macro definition. [Animesh] v2: Grouping EXITLINE reg bits with EXITLINE(trans) define, no functional change. [Ville] Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: -
Chris Wilson authored
The BKL struct_mutex is no more, the only serialisation we required for setting the exclusive stream is already managed by ce->pin_mutex in gen8_configure_all_contexts(). As such, we can manipulate i915_perf.exclusive_stream underneath our own (already held) perf->lock. Signed-off-by:
-
Chris Wilson authored
Use the local uncore accessors for the GT rather than using the [not-so] magic global dev_priv mmio routines. In the process, we also teach the perf stream to use backpointers to the i915_perf rather than digging it out of dev_priv. v2: Rebase onto i915_perf_types.h Signed-off-by:
-
Krzysztof Kozlowski authored
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by:Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007173346.9379-1-krzk@kernel.org
-
- 07 Oct, 2019 5 commits
-
-
Chris Wilson authored
If we cannot claim the timeline->mutex while preparing for a wait on it, we have to skip the timeline. In doing so, treat it as active so that under a intel_gt_wait_for_idle() loop, we repeat the wait after scheduling away. Signed-off-by:
-
Chris Wilson authored
Disable irqs around updating the context image to keep lockdep happy: <4>[ 673.483340] WARNING: possible irq lock inversion dependency detected <4>[ 673.483342] 5.4.0-rc1-CI-Trybot_5118+ #1 Tainted: G U <4>[ 673.483342] -------------------------------------------------------- <4>[ 673.483343] swapper/2/0 just changed the state of lock: <4>[ 673.483344] ffff88845db885a0 (&i915_request_get(rq)->submit/1){-...}, at: __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.483387] but this lock took another, HARDIRQ-unsafe lock in the past: <4>[ 673.483388] (&ce->pin_mutex/2){+...} <4>[ 673.483389] and interrupts could create inverse lock ordering between them. <4>[ 673.483390] other info that might help us debug this: <4>[ 673.483390] Chain exists of: &i915_request_get(rq)->submit/1 --> &engine->active.lock --> &ce->pin_mutex/2 <4>[ 673.483392] Possible interrupt unsafe locking scenario: <4>[ 673.483392] CPU0 CPU1 <4>[ 673.483393] ---- ---- <4>[ 673.483393] lock(&ce->pin_mutex/2); <4>[ 673.483394] local_irq_disable(); <4>[ 673.483395] lock(&i915_request_get(rq)->submit/1); <4>[ 673.483396] lock(&engine->active.lock); <4>[ 673.483396] <Interrupt> <4>[ 673.483397] lock(&i915_request_get(rq)->submit/1); <4>[ 673.483398] *** DEADLOCK *** <4>[ 673.483398] 2 locks held by swapper/2/0: <4>[ 673.483399] #0: ffff8883f61ac9b0 (&(>->irq_lock)->rlock){-.-.}, at: gen11_gt_irq_handler+0x42/0x280 [i915] <4>[ 673.483433] #1: ffff88845db8c418 (&(&rq->lock)->rlock){-.-.}, at: intel_engine_breadcrumbs_irq+0x34a/0x5a0 [i915] <4>[ 673.483463] the shortest dependencies between 2nd lock and 1st lock: <4>[ 673.483466] -> (&ce->pin_mutex/2){+...} ops: 614520 { <4>[ 673.483468] HARDIRQ-ON-W at: <4>[ 673.483471] lock_acquire+0xa7/0x1c0 <4>[ 673.483501] live_unlite_restore+0x1d8/0x6c0 [i915] <4>[ 673.483543] __i915_subtests+0xb8/0x210 [i915] <4>[ 673.483581] __run_selftests+0x112/0x170 [i915] <4>[ 673.483615] i915_live_selftests+0x2c/0x60 [i915] <4>[ 673.483644] i915_pci_probe+0x93/0x1b0 [i915] <4>[ 673.483646] pci_device_probe+0x9e/0x120 <4>[ 673.483648] really_probe+0xea/0x420 <4>[ 673.483649] driver_probe_device+0x10b/0x120 <4>[ 673.483651] device_driver_attach+0x4a/0x50 <4>[ 673.483652] __driver_attach+0x97/0x130 <4>[ 673.483653] bus_for_each_dev+0x74/0xc0 <4>[ 673.483654] bus_add_driver+0x142/0x220 <4>[ 673.483655] driver_register+0x56/0xf0 <4>[ 673.483657] do_one_initcall+0x58/0x2ff <4>[ 673.483659] do_init_module+0x56/0x1f8 <4>[ 673.483660] load_module+0x243e/0x29f0 <4>[ 673.483661] __do_sys_finit_module+0xe9/0x110 <4>[ 673.483662] do_syscall_64+0x4f/0x210 <4>[ 673.483665] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.483665] INITIAL USE at: <4>[ 673.483667] lock_acquire+0xa7/0x1c0 <4>[ 673.483698] live_unlite_restore+0x1d8/0x6c0 [i915] <4>[ 673.483733] __i915_subtests+0xb8/0x210 [i915] <4>[ 673.483764] __run_selftests+0x112/0x170 [i915] <4>[ 673.483793] i915_live_selftests+0x2c/0x60 [i915] <4>[ 673.483821] i915_pci_probe+0x93/0x1b0 [i915] <4>[ 673.483822] pci_device_probe+0x9e/0x120 <4>[ 673.483824] really_probe+0xea/0x420 <4>[ 673.483825] driver_probe_device+0x10b/0x120 <4>[ 673.483826] device_driver_attach+0x4a/0x50 <4>[ 673.483827] __driver_attach+0x97/0x130 <4>[ 673.483828] bus_for_each_dev+0x74/0xc0 <4>[ 673.483829] bus_add_driver+0x142/0x220 <4>[ 673.483830] driver_register+0x56/0xf0 <4>[ 673.483831] do_one_initcall+0x58/0x2ff <4>[ 673.483833] do_init_module+0x56/0x1f8 <4>[ 673.483834] load_module+0x243e/0x29f0 <4>[ 673.483835] __do_sys_finit_module+0xe9/0x110 <4>[ 673.483836] do_syscall_64+0x4f/0x210 <4>[ 673.483837] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.483838] } <4>[ 673.483868] ... key at: [<ffffffffa0a8f132>] __key.70113+0x2/0xffffffffffef2ed0 [i915] <4>[ 673.483869] ... acquired at: <4>[ 673.483935] __execlists_reset+0xfb/0xc20 [i915] <4>[ 673.483965] execlists_reset+0x3d/0x50 [i915] <4>[ 673.483995] intel_engine_reset+0xdf/0x230 [i915] <4>[ 673.484022] live_preempt_hang+0x1d7/0x2e0 [i915] <4>[ 673.484064] __i915_subtests+0xb8/0x210 [i915] <4>[ 673.484130] __run_selftests+0x112/0x170 [i915] <4>[ 673.484163] i915_live_selftests+0x2c/0x60 [i915] <4>[ 673.484193] i915_pci_probe+0x93/0x1b0 [i915] <4>[ 673.484194] pci_device_probe+0x9e/0x120 <4>[ 673.484195] really_probe+0xea/0x420 <4>[ 673.484196] driver_probe_device+0x10b/0x120 <4>[ 673.484197] device_driver_attach+0x4a/0x50 <4>[ 673.484198] __driver_attach+0x97/0x130 <4>[ 673.484199] bus_for_each_dev+0x74/0xc0 <4>[ 673.484200] bus_add_driver+0x142/0x220 <4>[ 673.484202] driver_register+0x56/0xf0 <4>[ 673.484203] do_one_initcall+0x58/0x2ff <4>[ 673.484204] do_init_module+0x56/0x1f8 <4>[ 673.484205] load_module+0x243e/0x29f0 <4>[ 673.484206] __do_sys_finit_module+0xe9/0x110 <4>[ 673.484207] do_syscall_64+0x4f/0x210 <4>[ 673.484208] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.484209] -> (&engine->active.lock){..-.} ops: 972791 { <4>[ 673.484211] IN-SOFTIRQ-W at: <4>[ 673.484213] lock_acquire+0xa7/0x1c0 <4>[ 673.484214] _raw_spin_lock_irqsave+0x33/0x50 <4>[ 673.484244] execlists_submission_tasklet+0xaf/0x100 [i915] <4>[ 673.484246] tasklet_action_common.isra.18+0x6c/0x1c0 <4>[ 673.484247] __do_softirq+0xdf/0x47f <4>[ 673.484248] irq_exit+0xba/0xc0 <4>[ 673.484249] do_IRQ+0x83/0x160 <4>[ 673.484250] ret_from_intr+0x0/0x1d <4>[ 673.484252] cpuidle_enter_state+0xb2/0x450 <4>[ 673.484253] cpuidle_enter+0x24/0x40 <4>[ 673.484254] do_idle+0x1e7/0x250 <4>[ 673.484256] cpu_startup_entry+0x14/0x20 <4>[ 673.484257] start_secondary+0x15f/0x1b0 <4>[ 673.484258] secondary_startup_64+0xa4/0xb0 <4>[ 673.484259] INITIAL USE at: <4>[ 673.484261] lock_acquire+0xa7/0x1c0 <4>[ 673.484290] intel_engine_init_active+0x7e/0xb0 [i915] <4>[ 673.484305] intel_engines_setup+0x1cd/0x3b0 [i915] <4>[ 673.484305] i915_gem_init+0x12d/0x900 [i915] <4>[ 673.484305] i915_driver_probe+0xb70/0x15d0 [i915] <4>[ 673.484305] i915_pci_probe+0x43/0x1b0 [i915] <4>[ 673.484305] pci_device_probe+0x9e/0x120 <4>[ 673.484305] really_probe+0xea/0x420 <4>[ 673.484305] driver_probe_device+0x10b/0x120 <4>[ 673.484305] device_driver_attach+0x4a/0x50 <4>[ 673.484305] __driver_attach+0x97/0x130 <4>[ 673.484305] bus_for_each_dev+0x74/0xc0 <4>[ 673.484305] bus_add_driver+0x142/0x220 <4>[ 673.484305] driver_register+0x56/0xf0 <4>[ 673.484305] do_one_initcall+0x58/0x2ff <4>[ 673.484305] do_init_module+0x56/0x1f8 <4>[ 673.484305] load_module+0x243e/0x29f0 <4>[ 673.484305] __do_sys_finit_module+0xe9/0x110 <4>[ 673.484305] do_syscall_64+0x4f/0x210 <4>[ 673.484305] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.484305] } <4>[ 673.484305] ... key at: [<ffffffffa0a8f160>] __key.70307+0x0/0xffffffffffef2ea0 [i915] <4>[ 673.484305] ... acquired at: <4>[ 673.484305] _raw_spin_lock_irqsave+0x33/0x50 <4>[ 673.484305] execlists_submit_request+0x2b/0x1e0 [i915] <4>[ 673.484305] submit_notify+0xa8/0x13c [i915] <4>[ 673.484305] __i915_sw_fence_complete+0x81/0x250 [i915] <4>[ 673.484305] i915_sw_fence_wake+0x51/0x70 [i915] <4>[ 673.484305] __i915_sw_fence_complete+0x1ee/0x250 [i915] <4>[ 673.484305] dma_i915_sw_fence_wake+0x1b/0x30 [i915] <4>[ 673.484305] dma_fence_signal_locked+0x9e/0x1b0 <4>[ 673.484305] dma_fence_signal+0x1f/0x40 <4>[ 673.484305] fence_work+0x28/0x80 [i915] <4>[ 673.484305] process_one_work+0x26a/0x620 <4>[ 673.484305] worker_thread+0x37/0x380 <4>[ 673.484305] kthread+0x119/0x130 <4>[ 673.484305] ret_from_fork+0x24/0x50 <4>[ 673.484305] -> (&i915_request_get(rq)->submit/1){-...} ops: 857694 { <4>[ 673.484305] IN-HARDIRQ-W at: <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915] <4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915] <4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0 <4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70 <4>[ 673.484305] handle_irq_event+0x2f/0x50 <4>[ 673.484305] handle_edge_irq+0x99/0x1b0 <4>[ 673.484305] do_IRQ+0x7e/0x160 <4>[ 673.484305] ret_from_intr+0x0/0x1d <4>[ 673.484305] cpuidle_enter_state+0xb2/0x450 <4>[ 673.484305] cpuidle_enter+0x24/0x40 <4>[ 673.484305] do_idle+0x1e7/0x250 <4>[ 673.484305] cpu_startup_entry+0x14/0x20 <4>[ 673.484305] start_secondary+0x15f/0x1b0 <4>[ 673.484305] secondary_startup_64+0xa4/0xb0 <4>[ 673.484305] INITIAL USE at: <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] __engine_park+0x233/0x420 [i915] <4>[ 673.484305] ____intel_wakeref_put_last+0x1c/0x70 [i915] <4>[ 673.484305] intel_gt_resume+0x202/0x2c0 [i915] <4>[ 673.484305] i915_gem_init+0x36e/0x900 [i915] <4>[ 673.484305] i915_driver_probe+0xb70/0x15d0 [i915] <4>[ 673.484305] i915_pci_probe+0x43/0x1b0 [i915] <4>[ 673.484305] pci_device_probe+0x9e/0x120 <4>[ 673.484305] really_probe+0xea/0x420 <4>[ 673.484305] driver_probe_device+0x10b/0x120 <4>[ 673.484305] device_driver_attach+0x4a/0x50 <4>[ 673.484305] __driver_attach+0x97/0x130 <4>[ 673.484305] bus_for_each_dev+0x74/0xc0 <4>[ 673.484305] bus_add_driver+0x142/0x220 <4>[ 673.484305] driver_register+0x56/0xf0 <4>[ 673.484305] do_one_initcall+0x58/0x2ff <4>[ 673.484305] do_init_module+0x56/0x1f8 <4>[ 673.484305] load_module+0x243e/0x29f0 <4>[ 673.484305] __do_sys_finit_module+0xe9/0x110 <4>[ 673.484305] do_syscall_64+0x4f/0x210 <4>[ 673.484305] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 673.484305] } <4>[ 673.484305] ... key at: [<ffffffffa0a8f6a1>] __key.80173+0x1/0xffffffffffef2960 [i915] <4>[ 673.484305] ... acquired at: <4>[ 673.484305] mark_lock+0x382/0x500 <4>[ 673.484305] __lock_acquire+0x7e1/0x15d0 <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915] <4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915] <4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0 <4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70 <4>[ 673.484305] handle_irq_event+0x2f/0x50 <4>[ 673.484305] handle_edge_irq+0x99/0x1b0 <4>[ 673.484305] do_IRQ+0x7e/0x160 <4>[ 673.484305] ret_from_intr+0x0/0x1d <4>[ 673.484305] cpuidle_enter_state+0xb2/0x450 <4>[ 673.484305] cpuidle_enter+0x24/0x40 <4>[ 673.484305] do_idle+0x1e7/0x250 <4>[ 673.484305] cpu_startup_entry+0x14/0x20 <4>[ 673.484305] start_secondary+0x15f/0x1b0 <4>[ 673.484305] secondary_startup_64+0xa4/0xb0 <4>[ 673.484305] stack backtrace: <4>[ 673.484305] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G U 5.4.0-rc1-CI-Trybot_5118+ #1 <4>[ 673.484305] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.1905020411 05/02/2019 <4>[ 673.484305] Call Trace: <4>[ 673.484305] <IRQ> <4>[ 673.484305] dump_stack+0x67/0x9b <4>[ 673.484305] check_usage_forwards+0x13c/0x150 <4>[ 673.484305] ? mark_lock+0x382/0x500 <4>[ 673.484305] mark_lock+0x382/0x500 <4>[ 673.484305] ? check_usage_backwards+0x140/0x140 <4>[ 673.484305] __lock_acquire+0x7e1/0x15d0 <4>[ 673.484305] ? debug_object_deactivate+0x17e/0x190 <4>[ 673.484305] lock_acquire+0xa7/0x1c0 <4>[ 673.484305] ? __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 673.484305] ? __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 673.484305] intel_engine_breadcrumbs_irq+0x3d0/0x5a0 [i915] <4>[ 673.484305] cs_irq_handler+0x39/0x50 [i915] <4>[ 673.484305] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 673.484305] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 673.484305] __handle_irq_event_percpu+0x41/0x2c0 <4>[ 673.484305] handle_irq_event_percpu+0x2b/0x70 <4>[ 673.484305] handle_irq_event+0x2f/0x50 <4>[ 673.484305] handle_edge_irq+0x99/0x1b0 <4>[ 673.484305] do_IRQ+0x7e/0x160 <4>[ 673.484305] common_interrupt+0xf/0xf <4>[ 673.484305] </IRQ> Signed-off-by: -
Chris Wilson authored
As we may signal a request and take the engine->active.lock within the signaler, the engine submission paths have to use a nested annotation on their requests -- but we guarantee that we can never submit on the same engine as the signaling fence. <4>[ 723.763281] WARNING: possible circular locking dependency detected <4>[ 723.763285] 5.3.0-g80fa0e042cdb-drmtip_379+ #1 Tainted: G U <4>[ 723.763288] ------------------------------------------------------ <4>[ 723.763291] gem_exec_await/1388 is trying to acquire lock: <4>[ 723.763294] ffff93a7b53221d8 (&engine->active.lock){..-.}, at: execlists_submit_request+0x2b/0x1e0 [i915] <4>[ 723.763378] but task is already holding lock: <4>[ 723.763381] ffff93a7c25f6d20 (&i915_request_get(rq)->submit/1){-.-.}, at: __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 723.763420] which lock already depends on the new lock. <4>[ 723.763423] the existing dependency chain (in reverse order) is: <4>[ 723.763427] -> #2 (&i915_request_get(rq)->submit/1){-.-.}: <4>[ 723.763434] _raw_spin_lock_irqsave_nested+0x39/0x50 <4>[ 723.763478] __i915_sw_fence_complete+0x1b2/0x250 [i915] <4>[ 723.763513] intel_engine_breadcrumbs_irq+0x3aa/0x5e0 [i915] <4>[ 723.763600] cs_irq_handler+0x49/0x50 [i915] <4>[ 723.763659] gen11_gt_irq_handler+0x17b/0x280 [i915] <4>[ 723.763690] gen11_irq_handler+0x54/0xf0 [i915] <4>[ 723.763695] __handle_irq_event_percpu+0x41/0x2d0 <4>[ 723.763699] handle_irq_event_percpu+0x2b/0x70 <4>[ 723.763702] handle_irq_event+0x2f/0x50 <4>[ 723.763706] handle_edge_irq+0xee/0x1a0 <4>[ 723.763709] do_IRQ+0x7e/0x160 <4>[ 723.763712] ret_from_intr+0x0/0x1d <4>[ 723.763717] __slab_alloc.isra.28.constprop.33+0x4f/0x70 <4>[ 723.763720] kmem_cache_alloc+0x28d/0x2f0 <4>[ 723.763724] vm_area_dup+0x15/0x40 <4>[ 723.763727] dup_mm+0x2dd/0x550 <4>[ 723.763730] copy_process+0xf21/0x1ef0 <4>[ 723.763734] _do_fork+0x71/0x670 <4>[ 723.763737] __se_sys_clone+0x6e/0xa0 <4>[ 723.763741] do_syscall_64+0x4f/0x210 <4>[ 723.763744] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 723.763747] -> #1 (&(&rq->lock)->rlock#2){-.-.}: <4>[ 723.763752] _raw_spin_lock+0x2a/0x40 <4>[ 723.763789] __unwind_incomplete_requests+0x3eb/0x450 [i915] <4>[ 723.763825] __execlists_submission_tasklet+0x9ec/0x1d60 [i915] <4>[ 723.763864] execlists_submission_tasklet+0x34/0x50 [i915] <4>[ 723.763874] tasklet_action_common.isra.5+0x47/0xb0 <4>[ 723.763878] __do_softirq+0xd8/0x4ae <4>[ 723.763881] irq_exit+0xa9/0xc0 <4>[ 723.763883] smp_apic_timer_interrupt+0xb7/0x280 <4>[ 723.763887] apic_timer_interrupt+0xf/0x20 <4>[ 723.763892] cpuidle_enter_state+0xae/0x450 <4>[ 723.763895] cpuidle_enter+0x24/0x40 <4>[ 723.763899] do_idle+0x1e7/0x250 <4>[ 723.763902] cpu_startup_entry+0x14/0x20 <4>[ 723.763905] start_secondary+0x15f/0x1b0 <4>[ 723.763908] secondary_startup_64+0xa4/0xb0 <4>[ 723.763911] -> #0 (&engine->active.lock){..-.}: <4>[ 723.763916] __lock_acquire+0x15d8/0x1ea0 <4>[ 723.763919] lock_acquire+0xa6/0x1c0 <4>[ 723.763922] _raw_spin_lock_irqsave+0x33/0x50 <4>[ 723.763956] execlists_submit_request+0x2b/0x1e0 [i915] <4>[ 723.764002] submit_notify+0xa8/0x13c [i915] <4>[ 723.764035] __i915_sw_fence_complete+0x81/0x250 [i915] <4>[ 723.764054] i915_sw_fence_wake+0x51/0x64 [i915] <4>[ 723.764054] __i915_sw_fence_complete+0x1ee/0x250 [i915] <4>[ 723.764054] dma_i915_sw_fence_wake_timer+0x14/0x20 [i915] <4>[ 723.764054] dma_fence_signal_locked+0x9e/0x1c0 <4>[ 723.764054] dma_fence_signal+0x1f/0x40 <4>[ 723.764054] vgem_fence_signal_ioctl+0x67/0xc0 [vgem] <4>[ 723.764054] drm_ioctl_kernel+0x83/0xf0 <4>[ 723.764054] drm_ioctl+0x2f3/0x3b0 <4>[ 723.764054] do_vfs_ioctl+0xa0/0x6f0 <4>[ 723.764054] ksys_ioctl+0x35/0x60 <4>[ 723.764054] __x64_sys_ioctl+0x11/0x20 <4>[ 723.764054] do_syscall_64+0x4f/0x210 <4>[ 723.764054] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4>[ 723.764054] other info that might help us debug this: <4>[ 723.764054] Chain exists of: &engine->active.lock --> &(&rq->lock)->rlock#2 --> &i915_request_get(rq)->submit/1 <4>[ 723.764054] Possible unsafe locking scenario: <4>[ 723.764054] CPU0 CPU1 <4>[ 723.764054] ---- ---- <4>[ 723.764054] lock(&i915_request_get(rq)->submit/1); <4>[ 723.764054] lock(&(&rq->lock)->rlock#2); <4>[ 723.764054] lock(&i915_request_get(rq)->submit/1); <4>[ 723.764054] lock(&engine->active.lock); <4>[ 723.764054] *** DEADLOCK *** Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111862Signed-off-by: -
Chris Wilson authored
Avoid going to the base i915 device when we already have a path from gt to the runtime powermanagement interface. The benefit is that it looks a bit more self-consistent to always be acquiring the gt->uncore->rpm for use with the gt->uncore. Signed-off-by:
-
Colin Ian King authored
Don't populate the array hw_engine_mask on the stack but instead make it static. Makes the object code smaller by 316 bytes. Before: text data bss dec hex filename 34004 4388 320 38712 9738 gpu/drm/i915/gt/intel_reset.o After: text data bss dec hex filename 33528 4548 320 38396 95fc gpu/drm/i915/gt/intel_reset.o (gcc version 9.2.1, amd64) Signed-off-by:
-
