- 10 Mar, 2020 7 commits
-
-
Chris Wilson authored
Skip useless priority bumping on adding a new dependency by making sure that we do update the priority if we would have rescheduled the active cotnext. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310115947.6482-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since the semaphore fence may be signaled from inside an interrupt handler from inside a request holding its request->lock, we cannot then enter into the engine->active.lock for processing the semaphore priority bump as we may traverse our call tree and end up on another held request. CPU 0: [ 2243.218864] _raw_spin_lock_irqsave+0x9a/0xb0 [ 2243.218867] i915_schedule_bump_priority+0x49/0x80 [i915] [ 2243.218869] semaphore_notify+0x6d/0x98 [i915] [ 2243.218871] __i915_sw_fence_complete+0x61/0x420 [i915] [ 2243.218874] ? kmem_cache_free+0x211/0x290 [ 2243.218876] i915_sw_fence_complete+0x58/0x80 [i915] [ 2243.218879] dma_i915_sw_fence_wake+0x3e/0x80 [i915] [ 2243.218881] signal_irq_work+0x571/0x690 [i915] [ 2243.218883] irq_work_run_list+0xd7/0x120 [ 2243.218885] irq_work_run+0x1d/0x50 [ 2243.218887] smp_irq_work_interrupt+0x21/0x30 [ 2243.218889] irq_work_interrupt+0xf/0x20 CPU 1: [ 2242.173107] _raw_spin_lock+0x8f/0xa0 [ 2242.173110] __i915_request_submit+0x64/0x4a0 [i915] [ 2242.173112] __execlists_submission_tasklet+0x8ee/0x2120 [i915] [ 2242.173114] ? i915_sched_lookup_priolist+0x1e3/0x2b0 [i915] [ 2242.173117] execlists_submit_request+0x2e8/0x2f0 [i915] [ 2242.173119] submit_notify+0x8f/0xc0 [i915] [ 2242.173121] __i915_sw_fence_complete+0x61/0x420 [i915] [ 2242.173124] ? _raw_spin_unlock_irqrestore+0x39/0x40 [ 2242.173137] i915_sw_fence_complete+0x58/0x80 [i915] [ 2242.173140] i915_sw_fence_commit+0x16/0x20 [i915] Closes: https://gitlab.freedesktop.org/drm/intel/issues/1318 Fixes: b7404c7e ("drm/i915: Bump ready tasks ahead of busywaits") Signed-off-by:
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-2020-03-10 - Fix CFL dmabuf display after vfio edid enabling (Tina) - Clean up scan non-priv batch debugfs entry (Chris) - Use intel engines initialized in gvt, cleanup previous ring id (Chris) - Use intel_gt instead (Chris) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200310081928.GG28483@zhen-hp.sh.intel.com
-
Radhakrishna Sripada authored
Platforms without fences don't have FBC host tracking and those registers are marked as reserved in those platforms. v2: checking num_fences to write to FBC fence registers (Ville) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200306185833.53984-2-jose.souza@intel.com
-
José Roberto de Souza authored
Most of the kms_frontbuffer_tracking tests disables the feature being tested, draw, get the CRC then enable the feature, draw again, get the CRC and check if it matches. Some times it is able to do that with a fastset, so intel_pre_plane_update() is executed but intel_fbc_can_flip_nuke() was not checking if FBC is now enabled in this CRTC leaving FBC active and causing the warning bellow in __intel_fbc_disable() [IGT] kms_frontbuffer_tracking: starting subtest fbc-1p-pri-indfb-multidraw Setting dangerous option enable_fbc - tainting kernel i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to f i915 0000:00:02.0: [drm:intel_psr_debug_set [i915]] Invalid debug mask f i915 0000:00:02.0: [drm:i915_edp_psr_debug_set [i915]] Setting PSR debug to 1 i915 0000:00:02.0: [drm:intel_atomic_check [i915]] [CONNECTOR:215:eDP-1] Limiting display bpp to 24 instead of EDID bpp 24, requested bpp 36, max platform bpp 36 [drm:intel_dp_compute_config [i915]] DP link computation with max lane count 2 max rate 270000 max bpp 24 pixel clock 138120KHz [drm:intel_dp_compute_config [i915]] Force DSC en = 0 [drm:intel_dp_compute_config [i915]] DP lane count 2 clock 270000 bpp 24 [drm:intel_dp_compute_config [i915]] DP link rate required 414360 available 540000 i915 0000:00:02.0: [drm:intel_atomic_check [i915]] hw max bpp: 24, pipe bpp: 24, dithering: 0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [CRTC:91:pipe A] enable: yes [fastset] i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] active: yes, output_types: EDP (0x100), output format: RGB i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] cpu_transcoder: EDP, pipe bpp: 24, dithering: 0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] dp m_n: lanes: 2; gmch_m: 6436858, gmch_n: 8388608, link_m: 268202, link_n: 524288, tu: 64 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0, infoframes enabled: 0x0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] requested mode: [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted mode: [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 138120 1920 1968 2018 2052 1080 1084 1086 1122 0x48 0xa [drm:intel_dump_pipe_config [i915]] crtc timings: 138120 1920 1968 2018 2052 1080 1084 1086 1122, type: 0x48 flags: 0xa i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] port clock: 270000, pipe src size: 1920x1080, pixel rate 138120 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] linetime: 119, ips linetime: 0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] num_scalers: 2, scaler_users: 0x0, scaler_id: -1 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] pch pfit: pos: 0x00000000, size: 0x00000000, disabled, force thru: no i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] ips: 0, double wide: 0 [drm:icl_dump_hw_state [i915]] dpll_hw_state: cfgcr0: 0x1c001a5, cfgcr1: 0x8b, mg_refclkin_ctl: 0x0, hg_clktop2_coreclkctl1: 0x0, mg_clktop2_hsclkctl: 0x0, mg_pll_div0: 0x0, mg_pll_div2: 0x0, mg_pll_lf: 0x0, mg_pll_frac_lock: 0x0, mg_pll_ssc: 0x0, mg_pll_bias: 0x0, mg_pll_tdc_coldst_bias: 0x0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] csc_mode: 0x0 gamma_mode: 0x0 gamma_enable: 0 csc_enable: 0 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] MST master transcoder: <invalid> i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] [PLANE:31:plane 1A] fb: [FB:262] 1920x1080 format = XR24 little-endian (0x34325258), visible: yes i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] rotation: 0x1, scaler: -1 i915 0000:00:02.0: [drm:intel_dump_pipe_config [i915]] src: 1920.000000x1080.000000+0.000000+0.000000 dst: 1920x1080+0+0 i915 0000:00:02.0: [drm:intel_psr_disable_locked [i915]] Disabling PSR1 i915 0000:00:02.0: [drm:intel_ddi_update_pipe [i915]] Panel doesn't support DRRS ------------[ cut here ]------------ i915 0000:00:02.0: drm_WARN_ON(fbc->active) WARNING: CPU: 4 PID: 1175 at drivers/gpu/drm/i915/display/intel_fbc.c:973 __intel_fbc_disable+0xa5/0x130 [i915] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_hda_intel crc32_pclmul snd_intel_dspcfg snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core cdc_ether e1000e usbnet mii snd_pcm ptp mei_me pps_core mei thunderbolt intel_lpss_pci prime_numbers CPU: 4 PID: 1175 Comm: kms_frontbuffer Tainted: G U 5.5.0-CI-Trybot_5651+ #1 Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 RIP: 0010:__intel_fbc_disable+0xa5/0x130 [i915] Code: 8b 67 50 4d 85 e4 0f 84 8f 00 00 00 e8 44 33 30 e1 48 c7 c1 72 f6 4c a0 4c 89 e2 48 89 c6 48 c7 c7 42 f6 4c a0 e8 0b 9d ce e0 <0f> 0b eb 90 48 8b 7b 18 4c 8b 67 50 4d 85 e4 74 6d e8 15 33 30 e1 RSP: 0018:ffffc90000613b68 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff8884799d0000 RCX: 0000000000000006 RDX: 0000000000001905 RSI: ffff888495dac970 RDI: ffffffff823731a1 RBP: ffff88847c05d000 R08: ffff888495dac970 R09: 0000000000000000 R10: ffffc90000613b88 R11: 0000000000000000 R12: ffff88849bba7e40 R13: ffff8884799d0000 R14: ffff888498564000 R15: 0000000000000000 FS: 00007f8157f08300(0000) GS:ffff8884a0000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffdbfea2eb8 CR3: 000000049d1cc001 CR4: 0000000000760ee0 PKRU: 55555554 Call Trace: intel_fbc_disable+0x4a/0x50 [i915] intel_update_crtc+0x12c/0x1d0 [i915] skl_commit_modeset_enables+0x14d/0x600 [i915] intel_atomic_commit_tail+0x30d/0x1480 [i915] ? queue_work_on+0x31/0x70 ? intel_atomic_commit_ready+0x3f/0x48 [i915] ? __i915_sw_fence_complete+0x1a0/0x250 [i915] intel_atomic_commit+0x312/0x390 [i915] intel_psr_fastset_force+0x119/0x150 [i915] i915_edp_psr_debug_set+0x53/0x70 [i915] simple_attr_write+0xb0/0xd0 full_proxy_write+0x51/0x80 vfs_write+0xb9/0x1d0 ksys_write+0x9f/0xe0 do_syscall_64+0x4f/0x220 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f8157240281 Code: c3 0f 1f 84 00 00 00 00 00 48 8b 05 59 8d 20 00 c3 0f 1f 84 00 00 00 00 00 8b 05 8a d1 20 00 85 c0 75 16 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53 RSP: 002b:00007ffdbfea59d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f8157240281 RDX: 0000000000000003 RSI: 00007f8157901152 RDI: 0000000000000008 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f8157901152 R13: 0000000000000008 R14: 00005589d298dce0 R15: 0000000000000000 irq event stamp: 55208 hardirqs last enabled at (55207): [<ffffffff8112f3fc>] vprintk_emit+0xcc/0x330 hardirqs last disabled at (55208): [<ffffffff81001ca0>] trace_hardirqs_off_thunk+0x1a/0x1c softirqs last enabled at (54926): [<ffffffff81e00385>] __do_softirq+0x385/0x47f softirqs last disabled at (54915): [<ffffffff810ba15a>] irq_exit+0xba/0xc0 ---[ end trace afa50c52e5a512bb ]--- [drm:__intel_fbc_disable [i915]] Disabling FBC on pipe A i915 0000:00:02.0: [drm:verify_connector_state [i915]] [CONNECTOR:215:eDP-1] i915 0000:00:02.0: [drm:intel_atomic_commit_tail [i915]] [CRTC:91:pipe A] [drm:intel_ddi_get_config [i915]] [ENCODER:214:DDI A] Fec status: 0 i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.150 [i915]] DPLL 0 v2: using intel_fbc_can_enable() instead of crtc_state->enable_fbc (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Lyude Paul authored
i915 can enable aux device nodes for DP MST by calling drm_dp_mst_connector_late_register()/ drm_dp_mst_connector_early_unregister(), so let's hook that up. Changes since v1: * Call intel_connector_register/unregister() from intel_dp_mst_connector_late_register/unregister() so we don't lose error injection - Ville Syrjälä Changes since v2: * Don't forget to clean up if intel_connector_register() fails - Ville Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: "Lee, Shawn C" <shawn.c.lee@intel.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
-
Chris Wilson authored
Always wait on the start of the signaler request to reduce the problem of dequeueing the bonded pair too early -- we want both payloads to start at the same time, with no latency, and yet still allow others to make full use of the slack in the system. This reduce the amount of time we spend waiting on the semaphore used to synchronise the start of the bonded payload. Signed-off-by:
-
- 09 Mar, 2020 21 commits
-
-
Chris Wilson authored
[ 206.875637] BUG: KCSAN: data-race in __i915_schedule+0x7fc/0x930 [i915] [ 206.875654] [ 206.875666] race at unknown origin, with read to 0xffff8881f7644480 of 8 bytes by task 703 on cpu 3: [ 206.875901] __i915_schedule+0x7fc/0x930 [i915] [ 206.876130] __bump_priority+0x63/0x80 [i915] [ 206.876361] __i915_sched_node_add_dependency+0x258/0x300 [i915] [ 206.876593] i915_sched_node_add_dependency+0x50/0xa0 [i915] [ 206.876824] i915_request_await_dma_fence+0x1da/0x530 [i915] [ 206.877057] i915_request_await_object+0x2fe/0x470 [i915] [ 206.877287] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915] [ 206.877517] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 206.877535] drm_ioctl_kernel+0xe4/0x120 [ 206.877549] drm_ioctl+0x297/0x4c7 [ 206.877563] ksys_ioctl+0x89/0xb0 [ 206.877577] __x64_sys_ioctl+0x42/0x60 [ 206.877591] do_syscall_64+0x6e/0x2c0 [ 206.877606] entry_SYSCALL_64_after_hwframe+0x44/0xa9 v2: Be safe and include mb References: https://gitlab.freedesktop.org/drm/intel/issues/1318Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200309170540.10332-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
gmbus/aux may be clocked by cdclk, thus we should make sure no transfers are ongoing while the cdclk frequency is being changed. We do that by simply grabbing all the gmbus/aux mutexes. No one else should be holding any more than one of those at a time so the lock ordering here shouldn't matter. v2: Use mutex_lock_nest_lock() (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Ville Syrjälä authored
The low level read_lut() functions don't need the entire crtc state as they know exactly what they're reading. Just need to pass in the crtc to get at the pipe. This now neatly mirrors the load_lut() direction. Signed-off-by:
Swati Sharma <swati2.sharma@intel.com>
-
Ville Syrjälä authored
PIPEGCMAX is a 11.6 (or 1.16 if you will) value. Ie. it can represent a value of 1.0 when the maximum we can store in the software LUT is 0.ffff. Clamp the value so that it gets saturated to the max the uapi supports. Signed-off-by:
-
Ville Syrjälä authored
Extract all the 'hw value -> LUT entry' stuff into small helpers to make the main 'read out the entire LUT' loop less bogged down by such mundane details. Signed-off-by:
-
Ville Syrjälä authored
A variable called 'i' having an unsigned type is just looking for trouble, and using a sized type generally makes no sense either. Change all of them to just plain old int. And do the same for some 'lut_size' variables which generally provide the loop end codition for 'i'. Signed-off-by:
-
Ville Syrjälä authored
chv_read_cgm_lut() specifically reads the CGM _gamma_ LUT so let's rename it to reflect that fact. This also mirrors the other direction's chv_load_cgm_gamma(). Signed-off-by:
-
Ville Syrjälä authored
We're talking about LUT contents here so let's call the thing 'lut' rather than 'blob_data'. This is the name the load_lut() code used before already. Signed-off-by:
-
Ville Syrjälä authored
To mirror the load_luts path let's clone an ilk+ version from i9xx_read_lut_8(). I guess the extra branch isn't a huge issue but feels better to make a clean split. Signed-off-by:
-
Ville Syrjälä authored
Split i9xx_load_luts_internal() into neat gmch vs. ilk+ chunks. Avoids at least one branch in the inner loop, and makes life a bit less confusing. Signed-off-by:
-
Ville Syrjälä authored
Only load the CGM CSC based on the cgm_mode bit like we do with the gamma/degamma LUTs. And make the function naming and arguments consistent as well. TODO: the code to convert the coefficients look totally bogus. IIRC CHV uses two's complement format but the code certainly doesn't generate that, so probably negative coefficients are totally busted. Signed-off-by:
-
Chris Wilson authored
We read the current state of intel_rps.active outside of the lock, so mark up the racy access. [ 525.037073] BUG: KCSAN: data-race in intel_rps_boost [i915] / intel_rps_park [i915] [ 525.037091] [ 525.037103] write to 0xffff8881f145efa1 of 1 bytes by task 192 on cpu 2: [ 525.037331] intel_rps_park+0x72/0x230 [i915] [ 525.037552] __gt_park+0x61/0xa0 [i915] [ 525.037771] ____intel_wakeref_put_last+0x42/0x90 [i915] [ 525.037991] __intel_wakeref_put_work+0xd3/0xf0 [i915] [ 525.038008] process_one_work+0x3b1/0x690 [ 525.038022] worker_thread+0x80/0x670 [ 525.038037] kthread+0x19a/0x1e0 [ 525.038051] ret_from_fork+0x1f/0x30 [ 525.038062] [ 525.038074] read to 0xffff8881f145efa1 of 1 bytes by task 733 on cpu 3: [ 525.038304] intel_rps_boost+0x67/0x1f0 [i915] [ 525.038535] i915_request_wait+0x562/0x5d0 [i915] [ 525.038764] i915_gem_object_wait_fence+0x81/0xa0 [i915] [ 525.038994] i915_gem_object_wait_reservation+0x489/0x520 [i915] [ 525.039224] i915_gem_wait_ioctl+0x167/0x2b0 [i915] [ 525.039241] drm_ioctl_kernel+0xe4/0x120 [ 525.039255] drm_ioctl+0x297/0x4c7 [ 525.039269] ksys_ioctl+0x89/0xb0 [ 525.039282] __x64_sys_ioctl+0x42/0x60 [ 525.039296] do_syscall_64+0x6e/0x2c0 [ 525.039311] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by:
-
Chris Wilson authored
[ 120.176548] BUG: KCSAN: data-race in __i915_schedule [i915] / effective_prio [i915] [ 120.176566] [ 120.176577] write to 0xffff8881e35e6540 of 4 bytes by task 730 on cpu 3: [ 120.176792] __i915_schedule+0x63e/0x920 [i915] [ 120.177007] __bump_priority+0x63/0x80 [i915] [ 120.177220] __i915_sched_node_add_dependency+0x258/0x300 [i915] [ 120.177438] i915_sched_node_add_dependency+0x50/0xa0 [i915] [ 120.177654] i915_request_await_dma_fence+0x1da/0x530 [i915] [ 120.177867] i915_request_await_object+0x2fe/0x470 [i915] [ 120.178081] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915] [ 120.178292] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 120.178309] drm_ioctl_kernel+0xe4/0x120 [ 120.178322] drm_ioctl+0x297/0x4c7 [ 120.178335] ksys_ioctl+0x89/0xb0 [ 120.178348] __x64_sys_ioctl+0x42/0x60 [ 120.178361] do_syscall_64+0x6e/0x2c0 [ 120.178375] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 120.178387] [ 120.178397] read to 0xffff8881e35e6540 of 4 bytes by interrupt on cpu 2: [ 120.178606] effective_prio+0x25/0xc0 [i915] [ 120.178812] process_csb+0xe8b/0x10a0 [i915] [ 120.179021] execlists_submission_tasklet+0x30/0x170 [i915] [ 120.179038] tasklet_action_common.isra.0+0x42/0xa0 [ 120.179053] __do_softirq+0xd7/0x2cd [ 120.179066] irq_exit+0xbe/0xe0 [ 120.179078] do_IRQ+0x51/0x100 [ 120.179090] ret_from_intr+0x0/0x1c [ 120.179104] cpuidle_enter_state+0x1b8/0x5d0 [ 120.179117] cpuidle_enter+0x50/0x90 [ 120.179131] do_idle+0x1a1/0x1f0 [ 120.179145] cpu_startup_entry+0x14/0x16 [ 120.179158] start_secondary+0x120/0x180 [ 120.179172] secondary_startup_64+0xa4/0xb0 Signed-off-by:
-
Chris Wilson authored
[ 145.927961] BUG: KCSAN: data-race in can_merge_rq [i915] / signal_irq_work [i915] [ 145.927980] [ 145.927992] write (marked) to 0xffff8881e513fab0 of 8 bytes by interrupt on cpu 2: [ 145.928250] signal_irq_work+0x134/0x640 [i915] [ 145.928268] irq_work_run_list+0xd7/0x120 [ 145.928283] irq_work_run+0x1d/0x50 [ 145.928300] smp_irq_work_interrupt+0x21/0x30 [ 145.928328] irq_work_interrupt+0xf/0x20 [ 145.928356] _raw_spin_unlock_irqrestore+0x34/0x40 [ 145.928596] execlists_submission_tasklet+0xde/0x170 [i915] [ 145.928616] tasklet_action_common.isra.0+0x42/0xa0 [ 145.928632] __do_softirq+0xd7/0x2cd [ 145.928646] irq_exit+0xbe/0xe0 [ 145.928665] do_IRQ+0x51/0x100 [ 145.928684] ret_from_intr+0x0/0x1c [ 145.928699] schedule+0x0/0xb0 [ 145.928719] worker_thread+0x194/0x670 [ 145.928743] kthread+0x19a/0x1e0 [ 145.928765] ret_from_fork+0x1f/0x30 [ 145.928784] [ 145.928796] read to 0xffff8881e513fab0 of 8 bytes by task 738 on cpu 1: [ 145.929046] can_merge_rq+0xb1/0x100 [i915] [ 145.929282] __execlists_submission_tasklet+0x866/0x25a0 [i915] [ 145.929518] execlists_submit_request+0x2a4/0x2b0 [i915] [ 145.929758] submit_notify+0x8f/0xc0 [i915] [ 145.929989] __i915_sw_fence_complete+0x5d/0x3e0 [i915] [ 145.930221] i915_sw_fence_complete+0x58/0x80 [i915] [ 145.930453] i915_sw_fence_commit+0x16/0x20 [i915] [ 145.930698] __i915_request_queue+0x60/0x70 [i915] [ 145.930935] i915_gem_do_execbuffer+0x3997/0x4c20 [i915] [ 145.931175] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 145.931194] drm_ioctl_kernel+0xe4/0x120 [ 145.931208] drm_ioctl+0x297/0x4c7 [ 145.931222] ksys_ioctl+0x89/0xb0 [ 145.931238] __x64_sys_ioctl+0x42/0x60 [ 145.931260] do_syscall_64+0x6e/0x2c0 [ 145.931275] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by:
-
Chris Wilson authored
[ 25.025543] BUG: KCSAN: data-race in __i915_request_create [i915] / process_csb [i915] [ 25.025561] [ 25.025573] write (marked) to 0xffff8881e85c1620 of 8 bytes by task 696 on cpu 1: [ 25.025789] __i915_request_create+0x54b/0x5d0 [i915] [ 25.026001] i915_request_create+0xcc/0x150 [i915] [ 25.026218] i915_gem_do_execbuffer+0x2f70/0x4c20 [i915] [ 25.026428] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 25.026445] drm_ioctl_kernel+0xe4/0x120 [ 25.026459] drm_ioctl+0x297/0x4c7 [ 25.026472] ksys_ioctl+0x89/0xb0 [ 25.026484] __x64_sys_ioctl+0x42/0x60 [ 25.026497] do_syscall_64+0x6e/0x2c0 [ 25.026510] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 25.026522] [ 25.026532] read to 0xffff8881e85c1620 of 8 bytes by interrupt on cpu 2: [ 25.026742] process_csb+0x8d6/0x1070 [i915] [ 25.026949] execlists_submission_tasklet+0x30/0x170 [i915] [ 25.026969] tasklet_action_common.isra.0+0x42/0xa0 [ 25.026984] __do_softirq+0xd7/0x2cd [ 25.026997] irq_exit+0xbe/0xe0 [ 25.027009] do_IRQ+0x51/0x100 [ 25.027021] ret_from_intr+0x0/0x1c [ 25.027033] poll_idle+0x3e/0x13b [ 25.027047] cpuidle_enter_state+0x189/0x5d0 [ 25.027060] cpuidle_enter+0x50/0x90 [ 25.027074] do_idle+0x1a1/0x1f0 [ 25.027086] cpu_startup_entry+0x14/0x16 [ 25.027100] start_secondary+0x120/0x180 [ 25.027116] secondary_startup_64+0xa4/0xb0 Signed-off-by:
-
Chris Wilson authored
During i915_request_retire() we decouple the i915_request.hwsp_seqno from the intel_timeline so that it may be freed before the request is released. However, we need to warn the compiler that the pointer may update under its nose. [ 171.438899] BUG: KCSAN: data-race in i915_request_await_dma_fence [i915] / i915_request_retire [i915] [ 171.438920] [ 171.438932] write to 0xffff8881e7e28ce0 of 8 bytes by task 148 on cpu 2: [ 171.439174] i915_request_retire+0x1ea/0x660 [i915] [ 171.439408] retire_requests+0x7a/0xd0 [i915] [ 171.439640] engine_retire+0xa1/0xe0 [i915] [ 171.439657] process_one_work+0x3b1/0x690 [ 171.439671] worker_thread+0x80/0x670 [ 171.439685] kthread+0x19a/0x1e0 [ 171.439701] ret_from_fork+0x1f/0x30 [ 171.439721] [ 171.439739] read to 0xffff8881e7e28ce0 of 8 bytes by task 696 on cpu 1: [ 171.439990] i915_request_await_dma_fence+0x162/0x520 [i915] [ 171.440230] i915_request_await_object+0x2fe/0x470 [i915] [ 171.440467] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915] [ 171.440704] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 171.440722] drm_ioctl_kernel+0xe4/0x120 [ 171.440736] drm_ioctl+0x297/0x4c7 [ 171.440750] ksys_ioctl+0x89/0xb0 [ 171.440766] __x64_sys_ioctl+0x42/0x60 [ 171.440788] do_syscall_64+0x6e/0x2c0 [ 171.440802] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by:
-
Chris Wilson authored
[ 7534.150687] BUG: KCSAN: data-race in __execlists_submission_tasklet [i915] / process_csb [i915] [ 7534.150706] [ 7534.150717] write to 0xffff8881f1bc24b4 of 4 bytes by task 24404 on cpu 3: [ 7534.150925] __execlists_submission_tasklet+0x1158/0x2780 [i915] [ 7534.151133] execlists_submit_request+0x2e8/0x2f0 [i915] [ 7534.151348] submit_notify+0x8f/0xc0 [i915] [ 7534.151549] __i915_sw_fence_complete+0x5d/0x3e0 [i915] [ 7534.151753] i915_sw_fence_complete+0x58/0x80 [i915] [ 7534.151963] i915_sw_fence_commit+0x16/0x20 [i915] [ 7534.152179] __i915_request_queue+0x60/0x70 [i915] [ 7534.152388] i915_gem_do_execbuffer+0x3997/0x4c20 [i915] [ 7534.152598] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 7534.152615] drm_ioctl_kernel+0xe4/0x120 [ 7534.152629] drm_ioctl+0x297/0x4c7 [ 7534.152642] ksys_ioctl+0x89/0xb0 [ 7534.152654] __x64_sys_ioctl+0x42/0x60 [ 7534.152667] do_syscall_64+0x6e/0x2c0 [ 7534.152681] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 7534.152693] [ 7534.152703] read to 0xffff8881f1bc24b4 of 4 bytes by interrupt on cpu 2: [ 7534.152914] process_csb+0xe7c/0x10a0 [i915] [ 7534.153120] execlists_submission_tasklet+0x30/0x170 [i915] [ 7534.153138] tasklet_action_common.isra.0+0x42/0xa0 [ 7534.153153] __do_softirq+0xd7/0x2cd [ 7534.153166] run_ksoftirqd+0x15/0x20 [ 7534.153180] smpboot_thread_fn+0x1ab/0x300 [ 7534.153194] kthread+0x19a/0x1e0 [ 7534.153207] ret_from_fork+0x1f/0x30 Signed-off-by:
-
Chris Wilson authored
[ 3783.276728] BUG: KCSAN: data-race in __i915_request_submit [i915] / i915_request_await_dma_fence [i915] [ 3783.276766] [ 3783.276787] write to 0xffff8881f1bc60a0 of 1 bytes by interrupt on cpu 2: [ 3783.277187] __i915_request_submit+0x47e/0x4a0 [i915] [ 3783.277580] __execlists_submission_tasklet+0x997/0x2780 [i915] [ 3783.277973] execlists_submission_tasklet+0xd3/0x170 [i915] [ 3783.278006] tasklet_action_common.isra.0+0x42/0xa0 [ 3783.278035] __do_softirq+0xd7/0x2cd [ 3783.278063] irq_exit+0xbe/0xe0 [ 3783.278089] do_IRQ+0x51/0x100 [ 3783.278114] ret_from_intr+0x0/0x1c [ 3783.278140] finish_task_switch+0x72/0x260 [ 3783.278170] __schedule+0x1e5/0x510 [ 3783.278198] schedule+0x45/0xb0 [ 3783.278226] smpboot_thread_fn+0x23e/0x300 [ 3783.278256] kthread+0x19a/0x1e0 [ 3783.278283] ret_from_fork+0x1f/0x30 [ 3783.278305] [ 3783.278327] read to 0xffff8881f1bc60a0 of 1 bytes by task 19440 on cpu 3: [ 3783.278724] i915_request_await_dma_fence+0x2a6/0x530 [i915] [ 3783.279130] i915_request_await_object+0x2fe/0x470 [i915] [ 3783.279524] i915_gem_do_execbuffer+0x45dc/0x4c20 [i915] [ 3783.279908] i915_gem_execbuffer2_ioctl+0x2c3/0x580 [i915] [ 3783.279940] drm_ioctl_kernel+0xe4/0x120 [ 3783.279968] drm_ioctl+0x297/0x4c7 [ 3783.279996] ksys_ioctl+0x89/0xb0 [ 3783.280021] __x64_sys_ioctl+0x42/0x60 [ 3783.280047] do_syscall_64+0x6e/0x2c0 [ 3783.280074] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by:
-
Chris Wilson authored
We read the current state of intel_rps.active outside of the lock, so mark up the racy access. [ 525.037073] BUG: KCSAN: data-race in intel_rps_boost [i915] / intel_rps_park [i915] [ 525.037091] [ 525.037103] write to 0xffff8881f145efa1 of 1 bytes by task 192 on cpu 2: [ 525.037331] intel_rps_park+0x72/0x230 [i915] [ 525.037552] __gt_park+0x61/0xa0 [i915] [ 525.037771] ____intel_wakeref_put_last+0x42/0x90 [i915] [ 525.037991] __intel_wakeref_put_work+0xd3/0xf0 [i915] [ 525.038008] process_one_work+0x3b1/0x690 [ 525.038022] worker_thread+0x80/0x670 [ 525.038037] kthread+0x19a/0x1e0 [ 525.038051] ret_from_fork+0x1f/0x30 [ 525.038062] [ 525.038074] read to 0xffff8881f145efa1 of 1 bytes by task 733 on cpu 3: [ 525.038304] intel_rps_boost+0x67/0x1f0 [i915] [ 525.038535] i915_request_wait+0x562/0x5d0 [i915] [ 525.038764] i915_gem_object_wait_fence+0x81/0xa0 [i915] [ 525.038994] i915_gem_object_wait_reservation+0x489/0x520 [i915] [ 525.039224] i915_gem_wait_ioctl+0x167/0x2b0 [i915] [ 525.039241] drm_ioctl_kernel+0xe4/0x120 [ 525.039255] drm_ioctl+0x297/0x4c7 [ 525.039269] ksys_ioctl+0x89/0xb0 [ 525.039282] __x64_sys_ioctl+0x42/0x60 [ 525.039296] do_syscall_64+0x6e/0x2c0 [ 525.039311] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by:
-
Matt Roper authored
The UNSLICE_UNIT_LEVEL_CLKGATE and UNSLICE_UNIT_LEVEL_CLKGATE2 registers that we update in a few engine workarounds are not masked registers (i.e., we don't have to write a mask bit in the top 16 bits when updating one of the lower 16 bits). As such, these workarounds should be applied via wa_write_or() rather than wa_masked_en() v2: - Rebase Reported-by:
Nick Desaulniers <ndesaulniers@google.com> Reported-by:
kernelci.org bot <bot@kernelci.org> References: https://github.com/ClangBuiltLinux/linux/issues/918 Fixes: 50148a25 ("drm/i915/tgl: Move and restrict Wa_1408615072") Fixes: 3551ff92 ("drm/i915/gen11: Moving WAs to rcs_engine_wa_init()") Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Tested-by:
-
Imre Deak authored
Fix the following kerneldoc warning and while at it also the doc for the corresponding vfunc hook. $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_dpll_mgr.h:285: warning: Function parameter or member 'get_freq' not described in 'intel_shared_dpll_funcs' Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
- 07 Mar, 2020 5 commits
-
-
Chris Wilson authored
Be sure to wait for the vma to be in place before we tell the GPU to execute from the wa batch. Since initialisation is mostly synchronous (or rather at some point during start up we will need to sync anyway), we can affort to do an explicit i915_vma_sync() during wa batch construction rather than check for a required await on every context switch. (We don't expect to change the wa bb at run time so paying the cost once up front seems preferrable.) Fixes: ee2413ee ("drm/i915: Add mechanism to submit a context WA on ring submission") Signed-off-by:
-
Chris Wilson authored
If the cacheline may still be busy, atomically mark it for future release, and only if we can determine that it will never be used again, immediately free it. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1392 Fixes: ebece753 ("drm/i915: Keep timeline HWSP allocated until idle across the system") Signed-off-by:
-
Chris Wilson authored
If we stop filling the ELSP due to an incompatible virtual engine request, check if we should enable the timeslice on behalf of the queue. This fixes the case where we are inspecting the last->next element when we know that the last element is the last request in the execution queue, and so decided we did not need to enable timeslicing despite the intent to do so! Fixes: 8ee36e04 ("drm/i915/execlists: Minimalistic timeslicing") Signed-off-by:
-
Chris Wilson authored
Due to the ordering of cmpxchg()/dma_fence_signal() inside node_retire(), we must also use the xchg() as our primary memory barrier to flush the outstanding callbacks after expected completion of the i915_active. Signed-off-by:
-
Chris Wilson authored
Do not poison the timeline link on the i915_request to allow both forward/backward list traversal under RCU. [ 9759.139229] RIP: 0010:active_request+0x2a/0x90 [i915] [ 9759.139240] Code: 41 56 41 55 41 54 55 48 89 fd 53 48 89 f3 48 83 c5 60 e8 49 de dc e0 48 8b 83 e8 01 00 00 48 39 c5 74 12 48 8d 90 20 fe ff ff <48> 8b 80 50 fe ff ff a8 01 74 11 e8 66 20 dd e0 48 89 d8 5b 5d 41 [ 9759.139251] RSP: 0018:ffffc9000014ce80 EFLAGS: 00010012 [ 9759.139260] RAX: dead000000000122 RBX: ffff888817cac040 RCX: 0000000000022000 [ 9759.139267] RDX: deacffffffffff42 RSI: ffff888817cac040 RDI: ffff888851fee900 [ 9759.139275] RBP: ffff888851fee960 R08: 000000000000001a R09: ffffffffa04702e0 [ 9759.139282] R10: ffffffff82187ea0 R11: 0000000000000002 R12: 0000000000000004 [ 9759.139289] R13: ffffffffa04d5179 R14: ffff8887f994ae40 R15: ffff888857b9a068 [ 9759.139296] FS: 0000000000000000(0000) GS:ffff88885ed80000(0000) knlGS:0000000000000000 [ 9759.139304] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9759.139311] CR2: 00007fff5bdec000 CR3: 00000008534fe001 CR4: 00000000001606e0 [ 9759.139318] Call Trace: [ 9759.139325] <IRQ> [ 9759.139389] execlists_reset+0x14d/0x310 [i915] [ 9759.139400] ? _raw_spin_unlock_irqrestore+0xf/0x30 [ 9759.139445] ? fwtable_read32+0x90/0x230 [i915] [ 9759.139499] execlists_submission_tasklet+0xf6/0x150 [i915] [ 9759.139508] tasklet_action_common.isra.17+0x32/0xa0 [ 9759.139516] __do_softirq+0x114/0x3dc [ 9759.139525] ? handle_irq_event_percpu+0x59/0x70 [ 9759.139533] irq_exit+0xa1/0xc0 [ 9759.139540] do_IRQ+0x76/0x150 [ 9759.139547] common_interrupt+0xf/0xf [ 9759.139554] </IRQ> Signed-off-by:
-
- 06 Mar, 2020 7 commits
-
-
Swathi Dhanavanthri authored
This workaround is to disable FF DOP Clock gating. The fix in B0 was backed out due to timing reasons and decided to be made permanent. Bspec: 52890 Signed-off-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Reviewed-by:
-
Vivek Kasireddy authored
On some platforms such as Elkhart Lake, although we may use DDI D to drive a connector, we have to use PHY A (Combo Phy PORT A) to detect the hotplug interrupts as per the spec because there is no one-to-one mapping between DDIs and PHYs. Therefore, use the function intel_port_to_phy() which contains the logic for such mapping(s) to find the correct hpd_pin. This change should not affect other platforms as there is always a one-to-one mapping between DDIs and PHYs. v2: - Convert the case statements to use PHYs instead of PORTs (Jani) v3: - Refactor the function to reduce the number of return statements by lumping all the case statements together except PHY_F which needs special handling (Jose) v4: - Add a comment describing how the HPD pin value associated with any port can be retrieved using port or phy enum value. (Jani) v5: - Use case ranges instead of individual labels and also normalize the return statement by adding -PHY_A to the expression (Ville) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by:
-
Matthew Auld authored
Depending on RNG we might try to fill an 8G region for every possible order, using the smallest possible chunk size of 4K, which seems to be very slow. Try to remedy the situation by adding an overall timeout for the test, while also selecting each order level in a random fashion. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1310Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Matthew Auld authored
Be careful not to mark an already free node as free again. Signed-off-by:
-
Matthew Auld authored
Check the edge case where batch_start_offset sits exactly on the batch size. v2: add new range_overflows variant to capture the special case where the size is permitted to be zero, like with batch_len. v3: other way around. the common case is the exclusive one which should just be >=, with that we then just need to convert the three odd ball cases that don't apply to use the new inclusive _end version. Testcase: igt/gem_exec_params/invalid-batch-start-offset Fixes: 0b537272 ("drm/i915/cmdparser: Use cached vmappings") Signed-off-by:
-
Chris Wilson authored
We only need to serialise the multiple pinning during the eb_reserve phase. Ideally this would be using the vm->mutex as an outer lock, or using a composite global mutex (ww_mutex), but at the moment we are using struct_mutex for the group. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1381 Fixes: 003d8b91 ("drm/i915/gem: Only call eb_lookup_vma once during execbuf ioctl") Signed-off-by:
-
Chris Wilson authored
We only call i915_schedule() when we know we have changed the priority on a request and so require to propagate any change in priority to its signalers (for PI). By unconditionally checking all of our signalers, we avoid skipping changes made prior to construction of the request (as the request may be waited upon before submission when used in parallel). References: https://gitlab.freedesktop.org/drm/intel/issues/1318Signed-off-by:
-
